引子
目前，百度已经要求外部产品线停止使用 React / React Native 等 Facebook 下涉及特定专利条款的开源产品，给半年时间来「转型」，推荐使用 Vue 或者自研的 San 作为替代方案。内部产品如果是新产品，则不能使用 React。
另外百度内部在自研 React Native 的替代方案。
何为React？ React.js 萌芽于 Facebook 内部开发 Instagram 的项目中，是一个用来构建用户界面的优秀 JS 库，于 2013 年 5 月开源。
由于 React的设计思想极其独特，属于革命性创新，性能出众，代码逻辑却非常简单。所以，越来越多的人开始关注和使用，认为它可能是将来 Web 开发的主流工具。
但是在 2016 年 7 月，React.js 开源许可协议中的附加专利条款(Additional patent grant)引起了激烈争论。
请看 React 官方团队的描述：React is BSD licensed. We also provide an additional patent grant.
即：BSD 许可证 + 专利许可证。
BSD Lisense : en.wikipedia.org/wiki/BSD_li… ，没有异议。
问题就出在了专利许可条款:github.com/facebook/re… ，节选原文如下：
The license g ranted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion:(i)against Facebook or any of its subsidiaries or corporate
affiliates,(ii)against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or(iii)against any party relating
to the Software.
注意：
由i和ii可以清楚的看出：你不能基于 React 做任何构成与 Facebook （包括其合作方或客户）直接或间接竞争的事情。如果你采取法律行动或者以其他方式挑战 Facebook，那么你使用 React 的许可会被立即撤销。
由iii可以看出：你也不能与其他使用 React 的公司发生法律纠纷，否则你使用 React 的许可也会被撤销。
（节选出处 http://elevenbeans.github.io/2017/08/29/Explaining-React-s-license/ ）
也许坐在办公桌前的你只是看个热闹，但是手中用着大量开源代码的我们，有必要提升开源使用的习惯和素养了。
你看，强如百度也中招了，替换开发技术框架的成本可是非常高的。
正文
开源协议
开源软件(Open source software)对我们来说越来越不陌生，开源软件一方面让我们享用到了“免费的午餐”，另一方面有效的利用和学习开源软件，也能促进我们开发软件时的效率、提升软件质量。但是在使用和借鉴开源软件的时候，我们不得不关心一下它对使用者的诸多限制，比较常见的方式即协议授权(licence)，这些协议中明确说明了使用者应该遵循的原则。
现在开源协议众多，通过Open Source Initiative组织批准的开源协议有50多种，本文介绍其中一些常见的协议
BSD开源协议是一个给予使用者很大自由的协议。开发者可以自由使用和修改源代码，也可以讲修改后的源代码作为开源或者专有软件再发布。但是有一下几个要求：
如果再发布的产品中含有源代码，则在源代码中必须带有原来代码中的BSD协议。
如果再发布的只是二进制类库/软件，则需要再类库/软件的文档和版权申明中包含原有代码中的BSD协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Apache Licence 2.0(Apache-2.0)
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和最终原作者的著作权，同样允许源代码修改和再发布。但是也需要遵循以下条件：
需要给代码的用户一份Apache Licence。
如果修改了代码，需要再被修改的文件中说明。
在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以再Notice中增加自己的许可，但是不可以表现为对Apache Licence构成更改。
使用这个协议的好处是:
永久权利 一旦被授权，永久拥有。
全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
授权免费 无版税， 前期、后期均无任何费用。
授权无排他性 任何人都可以获得授权
授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码
Apache Licence也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品
MIT是和BSD一样宽范的许可协议,源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。作者只想保留版权,而无任何其他了限制。MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。
MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。
MPL(Mozilla Public License 1.1)
MPL协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者 。这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改，无偿使用得。MPL软件对链接没有要求。
EPL (Eclipse Public License 1.0)
EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
使用EPL协议，需要遵守以下规则：
1.当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权；
2.EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法；
3.当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；
4.独立的模块(Separate Module),不需要开源。
各协议分析图
乌克兰程序员Paul Bagwell，画了一张分析图，说明应该怎么选择。阮一峰对图进行了汉化，如下图：
