各位朋友，我是 Payne，大家好，欢迎大家关注我的博客，我的博客地址是https://qinyuanpei.github.io。最近前端技术圈因为 React 专利事件再次被大家关注，印象中 Angular 和 Vue 的纷争刚刚过去不久，果然前端技术圈对"造轮子"和"搞事情"有着近乎执著的追求。作为一个在知乎吃瓜的伪前端工程师，我对这凑热闹这种事情从来都是是颇为喜欢的。如果说 Angular 和 Vue 冲突主要来自大漠穷秋和尤小尤的个人战场，那么这次 React 专利事件则是商业公司之间对社区主导力量的一次争夺和抗衡。开源是一种近似乌托邦般的理想社会，它倡导的"人人为我，我为人人"这种近乎大同社会的观念，在面临商业化浪潮洗礼的时候难会和商业利益发生冲突，譬如 Google 因为使用 Java 而和甲骨文纠纷不断，最终不得不选择 Kotlin 作为 Android 开发的主力语言。所以这篇文章我想和大家通过 React 专利事件来聊聊开源软件许可，以及我们如何在商业化和开源社区间找到一个平衡点。

事件始末

其实 React 专利事件由来已久，如果不是在知乎上看到“百度要求内部全面停止使用 React/React Native”的问题，我是完全没有意识到事态居然发展到如此严重的。每次前端技术圈"搞事情"的时候，基本上都会在我的知乎首页刷屏，可是对我这样的伪前端工程师而言，我仅仅是关注了"Web 开发"这个话题而已。忽略知乎首页推荐算法的缺陷，这的确动侧面说明了目前前端领域非常热门的事实，可它不能说明某些前端工程师的技术水平有多高，在引入前后端分离和前端构建工具以后，前端开发的基础设施渐渐地丰富起来了，可是前端开发目前经历着的一切，无一不在后端开发中涉及到，我没有想要成为全栈工程师的野心，在讨论这个事件以前我认为有必要了解下整个事件的始末：

2016 年 7 月，Facebook 在 React.js 的开源许可协议中添加的附加专利条款首次在社区中引发广泛讨论。
2016 年 11 月，Facebook 发布官方问答，对附加专利条款进行了澄清，强化了其 BSD 许可证 + 专利许可证的概念。
2017 年 4 月，Apache Cassandra 项目正在考虑是哟过 Facebook 开源的数据库 RocksDB 作为存储引擎，可是考虑到专利授权的问题，Jeff Jirsa 向 Apache 法律社区寻求帮助。
2017 年 6 月，Apache 法律社区开始讨论 Facebook Patents License 协议专利授权的不对称问题，且该协议与 Apache Software License，即 Apache 2.0 等不兼容。
2017 年 7 月 15 日，Apache 软件基金会正式发表声明称：Facebook BSD + Patense License 正式被列入"Category X"列表，因此 Apache 项目中将不能含有或者依赖任何该协议的代码，而已发布的代码必须在 8 月 31 日前完成替换。
2007 年 8 月 19 日，Facebook 对 Facebook BSD + Patense License 有了新的解释，解释指出，专利许可证的存在是为了防御无量的专利诉讼，Facebook 增加专利许可证是为了保护核心技术。
2017 年 9 月 16 日，百度内部全面禁止使用 React/React Native 的消息在知乎上引发热烈讨论。
2017 年 9 月 17 日，Wordpress 官方称因为 React 专利问题而停止在博客程序 Wordpress 中使用 React 技术。
2017 年 9 月 23 日，Facebook 迫于社区压力对外宣称将在数周后将 React 授权许可修改为 MIT。

主流软件许可

其实作为一名软件工程师，这些和法律息息相关的内容，原本是不需要我们去关注的，因为即使公司在使用这些开源软件中发生法律纠纷，通常都会有法务人员协助公司去解决相关事宜，无论如何都轮不到我们这些人来关心的。不过这个事件的现实意义是，我们在做技术选型时，专利等可能引起法律纠纷的问题，一样是需要纳入考虑范围的。因为如果是个人性质或者纯玩性质的项目，我们的确无需在意太多。而如果你是商业性质项目、或者是公司自营项目，或者是服务于甲方，那么你必须考虑你使用开源软件的方式是否符合相关的软件许可。国内因为盗版软件盛行的原因，大家在心底里好像都不认同软件许可，但是像外企或者是对信息安全比较重视的企业，通常要么对许可证书比较看重，要么对开源软件不太感冒，所以像最近的 WePhone 创始人自杀这种事件，都在告诉我们一个道理，程序员不要整天都关注技术层面上的东西，虽然技术世界有很多纯粹而美好的事情，但当它和人类联系在一起、和政治联系在一起的时候，它就完全不在我们的控制之中了，所以我觉得我们有必要了解些法律相关的事情，那么从何处开始呢？我们不妨就来说说主流的开源软件许可吧！

这个世界上的开源软件许可证书大约有上百种，我们不可能也没有必要了解所有的开源软件许可证书。对于主流的开源软件许可，我们有 GPL、BSD、MIT、MPL、Apache 和 LGPL，相信大家都没有兴趣去阅读这些晦涩深奥的 License，所以我们不打算在这里逐一介绍它们，事实上搞清楚它们在具体限制上的差异是件非常困难的事情。我们希望用最简洁的语言来描述这些开源软件许可：

GPL：即 GNU 通用公共授权(GNU General Public License)，其出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但是不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这就是为什么我们能用免费的各种包括商业公司在内的 Linux 版本，以及 Linux 上各种各样的由个人、组织和商业软件公司开发的免费软件。
BSD：即Berkly Software Distribution，基本上是一个给予使用者极大自由空间的一种开源协议，使用者可以自由地对代码进行使用、修改和二次发布，该协议鼓励代码共享，其出发点是尊重代码作者的著作权，要求保留原代码中的 BSD 协议，保留创作者署名权利，即不得以开源软件作者/机构的名义进行市场推广。
MIT：即Massachusetts Institute of Technology，这是一个完全给予使用者自由空间的简短而宽泛的授权协议，作者唯一的诉求是保留版权，使用者可以复制、修改、合并、发布、分、授权和销售软件副本，并根据程序的需要适度修改授权条款，唯一的要求是必须在发行版里附加原许可协议的声明，无论是以源代码还是二进制形式发布。
MPL：即The Mozilla Public License，该协议同 GPL 和 BSD 基本一致，差异主要体现在：源代码提供者不能提供已经受到专利保护的源代码、要求再发布者必须提供对代码程序修改的说明、允许通过 MPL 许可获得的源代码同其他类型源代码进行混合(第二条献给那些不好好在 Git 里写注释的同学)。
Apache：即著名的非盈利开源组织 Apache 采用的协议，该协议和 BSD 类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，作为开源或商业软件再发布，主要关注点有：（1）需要给代码的用户一份 Apache License；（2）如果改动代码需要在被修改文件中做出说明；（3）衍生代码必须保留原有协议、商标、专利或者说明等；（4）不得对 Apache 协议进行修改。
LGPL：LGPL，即 GPL V2，是 GPL 的一个为主要为类库使用设计的开源协议，和 GPL 要求任何使用/修改/衍生之 GPL 类库的的软件必须采用 GPL 协议不同。LGPL 允许商业软件通过类库引用(link)方式使用 LGPL 类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码，可以被商业软件作为类库引用并发布和销售的同时，保障作者的知识产权，避免有人利用源代码复制并开发类似产品。

好了，相信到这里大家就能够明白，为什么这次 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 这样的互联网大厂，则应该考虑走自主研发的差异化路线，因为如果你不想受制于人，最好的方法就是让别人依赖你，而不是去努力依赖别人。作为一个伪前端工程师，我觉得不管什么时候，我们都要努力打好基础，而不是在一堆框架中疲于奔命，对热衷于搞事情和造轮子的前端技术圈来说，下一次的讨论热点会是什么，你我都未必能想到，这个时候还有什么比努力更重要的事情呢。好了，这篇文章就是这样了，希望大家能够喜欢，我们下一篇见。