各位朋友，我是 Payne，大家好，欢迎大家关注我的博客，我的博客地址是https://qinyuanpei.github.io。最近前端技术圈因为 React 专利事件再次被大家关注，印象中 Angular 和 Vue 的纷争刚刚过去不久，果然前端技术圈对"造轮子"和"搞事情"有着近乎执著的追求。作为一个在知乎吃瓜的伪前端工程师，我对这凑热闹这种事情从来都是是颇为喜欢的。如果说 Angular 和 Vue 冲突主要来自大漠穷秋和尤小尤的个人战场，那么这次 React 专利事件则是商业公司之间对社区主导力量的一次争夺和抗衡。开源是一种近似乌托邦般的理想社会，它倡导的"人人为我，我为人人"这种近乎大同社会的观念，在面临商业化浪潮洗礼的时候难会和商业利益发生冲突，譬如 Google 因为使用 Java 而和甲骨文纠纷不断，最终不得不选择 Kotlin 作为 Android 开发的主力语言。所以这篇文章我想和大家通过 React 专利事件来聊聊开源软件许可，以及我们如何在商业化和开源社区间找到一个平衡点。
其实 React 专利事件由来已久，如果不是在知乎上看到“百度要求内部全面停止使用 React/React Native”的问题，我是完全没有意识到事态居然发展到如此严重的。每次前端技术圈"搞事情"的时候，基本上都会在我的知乎首页刷屏，可是对我这样的伪前端工程师而言，我仅仅是关注了"Web 开发"这个话题而已。忽略知乎首页推荐算法的缺陷，这的确动侧面说明了目前前端领域非常热门的事实，可它不能说明某些前端工程师的技术水平有多高，在引入前后端分离和前端构建工具以后，前端开发的基础设施渐渐地丰富起来了，可是前端开发目前经历着的一切，无一不在后端开发中涉及到，我没有想要成为全栈工程师的野心，在讨论这个事件以前我认为有必要了解下整个事件的始末：
其实作为一名软件工程师，这些和法律息息相关的内容，原本是不需要我们去关注的，因为即使公司在使用这些开源软件中发生法律纠纷，通常都会有法务人员协助公司去解决相关事宜，无论如何都轮不到我们这些人来关心的。不过这个事件的现实意义是，我们在做技术选型时，专利等可能引起法律纠纷的问题，一样是需要纳入考虑范围的。因为如果是个人性质或者纯玩性质的项目，我们的确无需在意太多。而如果你是商业性质项目、或者是公司自营项目，或者是服务于甲方，那么你必须考虑你使用开源软件的方式是否符合相关的软件许可。国内因为盗版软件盛行的原因，大家在心底里好像都不认同软件许可，但是像外企或者是对信息安全比较重视的企业，通常要么对许可证书比较看重，要么对开源软件不太感冒，所以像最近的 WePhone 创始人自杀这种事件，都在告诉我们一个道理，程序员不要整天都关注技术层面上的东西，虽然技术世界有很多纯粹而美好的事情，但当它和人类联系在一起、和政治联系在一起的时候，它就完全不在我们的控制之中了，所以我觉得我们有必要了解些法律相关的事情，那么从何处开始呢？我们不妨就来说说主流的开源软件许可吧！
这个世界上的开源软件许可证书大约有上百种，我们不可能也没有必要了解所有的开源软件许可证书。对于主流的开源软件许可，我们有 GPL、BSD、MIT、MPL、Apache 和 LGPL，相信大家都没有兴趣去阅读这些晦涩深奥的 License，所以我们不打算在这里逐一介绍它们，事实上搞清楚它们在具体限制上的差异是件非常困难的事情。我们希望用最简洁的语言来描述这些开源软件许可：
好了，相信到这里大家就能够明白，为什么这次 React 专利事件能在社区里引起轰动。我认为主要的原因有两点：
第一，React 在 BSD 协议许可的基础上增加的专利许可，对许可证书授权方和被授权方而言，存在待遇上的不对等性。实际上在 React 为前端带来虚拟 DOM、单向数据流和不可变对象等一系列函数式编程的概念的同时，Facebook 在开源社区中的话语权同样越来越大，Facebook 在开源协议中夹藏私货的确让人有种"挟天子以令诸侯"的感觉，曾几何时，社区指责微软没有开放全部的 OpenXML 标准，因为大家都觉得按照这个标准实现的 Office 文档和微软家的存在差异，可是面对这种和自家产品紧密联系的项目要开源，我觉得这不单是 Facebook 会有所提防，恐怕所有的商业公司都会有类似的想法吧，所以在这个事件中，隐含的一个点就是，一旦当使用 React 的公司和 Facebook 发生业务上的竞争，React 将成为 Facebook 获得诉讼胜利的一个重要筹码，因为根据 React 的专利协议，Facebook 有权在开展诉讼时从被授权方手中收回 React 的使用权，所以我们不难理解为什么百度和 Wordpress 都宣称要停止使用 React，除了不想受制于人以外，像百度这种未来可能会和 Facebook 在 AI 等领域发生竞争的公司，宁可自己造一套轮子而不愿让自家专利被对方使用的做法，我觉得是可以理解的。
第二，React 在开源协议中附加专利许可的做法，从商业公司自我保护的角度来看，的确是无可厚非，不过这种做法未免会给开源社区带来不好的风气。我们都知道开源软件并不等同于免费软件，因为开源软件通过许可证书来保证开源软件代码是以一种合理的方式被使用。在很久很久以前，MySQL 是我非常喜欢的一个数据库，因为它可以让我摆脱 SQLServer 臃肿的体积。什么？你说.NET 技术体系中怎么会出现 MySQL？可这正是.NET 选择开源、选择了跨平台，我们才有机会在更广阔的世界里去做些有趣的事情不是吗，我们必须承认开源对这个世界的重要意义，当你发觉你身边的同事都在重复写些垃圾的代码时候，你或许就会意识到，其实在这个世界上有很多东西，我们是可以站在巨人的肩膀上看得更远的。当你因为目光短浅而小心谨慎地维护着那些破旧的代码的时候，我们除了一天天老去别无所获。自从 MySQL 被甲骨文收购以后，我觉得这个世界开始缺少些有趣的东西，甲骨文和 Google 关于 Java 的官司让 Google 最终选择了 Kotlin，所以你可以看到开源这件事情对这个世界是绝对有利的，很多人担心这些代码开源到互联网上对商业公司不利，其实我们都清楚，没有环境和生态的代码基本不会有人关心，我们是不是该重新审视下开源？
OK，我知道现在大家都在思考一件事情，既然开源对这个世界的进步是有利的，那么是否开源就不应该成为我们思考的问题，我们真正应该考虑的问题是，如何选择一个合适的开源软件许可证书，在商业化和开源间找到一个平衡点。对于这个问题，我想大家一定会犯选择困难症，不过没有关系啦，我想此时下面这张图也许可以帮到大家：
或许在数日前，你还在为 React 专利事件而苦恼，或者考虑在 Preact 的基础上实现一个新的 React，或者考虑转向 Angular 和 Vue 这两个框架，此时此刻 Facebook 宣布将 React 的开源协议修改为 MIT，或许这算是开源社区的一次胜利，或许这算是整个专利事件的尘埃落定，或许有人继续担心 Facebook 搞其他事情，可是这个世界原本就是在每天都发生变化着的，对于未来我们常常是无从得知它的足迹会在哪里。人生本来就是一个人的逆旅，要想在这充满变化的世界里获得安全感，唯有努力让自己处于不败之地，技术何尝不是这样呢，想想这 20 年间我们经历了多少技术的变革，从来没有一门框架可以让我们一劳永逸，所以对于小公司而言，大可不必担心 Facebook 会因为专利问题和你产生法律上的纠纷，该用什么就用什么框架，因为没有绝对完美的框架，能结合业务场景选择合适的框架，为这个世界带来一点点微小的变化，这样子我们就足够开心啦！而对于 BAT 这样的互联网大厂，则应该考虑走自主研发的差异化路线，因为如果你不想受制于人，最好的方法就是让别人依赖你，而不是去努力依赖别人。作为一个伪前端工程师，我觉得不管什么时候，我们都要努力打好基础，而不是在一堆框架中疲于奔命，对热衷于搞事情和造轮子的前端技术圈来说，下一次的讨论热点会是什么，你我都未必能想到，这个时候还有什么比努力更重要的事情呢。好了，这篇文章就是这样了，希望大家能够喜欢，我们下一篇见。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
