【转】各种开源协议及其关系
May 11 2015 更新日期:May 11 2015
开源许可协议
License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。
开源协议的种类
现今存在的开源协议很多，而经过Open Source Initiative 组织通过批准的开源协议目前有60多种http://www.opensource.org/licenses/alphabetical。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。
Apache License, 2.0(Apache-2.0)
Apache Lience允许使用者修改和重新发布代码(以其他协议形式)，允许闭源商业发布和销售。
Apache Lience鼓励代码共享和尊重原作者的著作权。
使用Apache Licence协议，需要遵守以下规则：
- 需要给代码的用户一份Apache Lience；
- 如果你修改了代码，需要在被修改的文件中说明；
- 在延伸的代码中（修改或衍生的代码）需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。
- 如果再发布的产品中包含了Notice文件，则需要在Notice文件中带有Apache Lience。你可以在Notice中增加自己的许可，但不可以表现为对Apache Lience构成更改。
除了这些条件它还有这些好处：
1）永久权利 一旦被授权，永久拥有。
2）全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
3）授权免费 无版税， 前期、后期均无任何费用。
4）授权无排他性 任何人都可以获得授权
5）授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码
使用apache Licence vesion 2.0协议的开源软件有：Hadoop 、apache httpserver、Spring Framework、MongoDB 。
GPL (GNU General Public License)
它的主要内容为：只要在一个软件中使用(“使用”指类库引用或者修改后的代码) GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这个协议就不太适合商用软件，或者准备使用GPL开源组件的商用项目。基于这个协议的项目，极大的提高了开源软件的数量。
使用GPL协议，需要遵守以下规则：
1、确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软 件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
2、GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
3、无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
4、开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。
目前用的多的是GPLV1，GPLV2。这两个什么区别看后面那张树形图。采用这个协议的开源软件有：Linux、 MySQL。
LGPL (GNU Library or “Lesser” General Public License)
由于GPL太严格，限制了很多商用软件使用GPL组件才推出了这个LGPL。LGPL允许商业软件通过引用类库的方式使用LGPL组件（不直接使用源代码），这样可以不需要开源商业软件的代码。但是如果要修改原始组件的代码，则涉及修改部分的代码和基于原来代码衍生的代码都必须采用LGPL协议。LGPL不适合以LGPL协议为基础的代码进行二次开发的商业软件，但是商用软件可以采用编译后的类库引用就不需要公开源代码了。
采用这个协议的开源软件有： JBoss、 FCKeditor 、 Hibernate。之前extjs就因为从LGPL转换到GPL带来了不少的震动。
BSD开源协议(Berkerley Software Distribution)
目前分为BSD 3-Clause和BSD 2-Clause。顾名思义，3-Clause包含3个条款，2-Clause只有两个。
这个协议相对上面两个协议宽松很多，允许使用者修改和重新发布代码，也允许使用或在BSD代码基础上开发商业软件发布和销售，因此是适用于商业软件的。
使用者别太高兴，使用时还必须做到满足三个条件（2-Clause则不带第3条）：
1）如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2）如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3）不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。适用BSD协议的开源软件有： nginx、CruiseControl、Redis。
要点：商业软件可以使用，也可以修改使用BSD协议的代码。
MIT (MIT license)
源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。
要点：商业软件可以使用，也可以修改MIT协议的代码，甚至可以出售MIT协议的代码。
MPL (Mozilla Public License 1.1)
MPL协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者 。这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改，无偿使用得。MPL软件对链接没有要求。
要点：商业软件可以使用，也可以修改MPL协议的代码，但修改后的代码版权归软件的发起者。
EPL (Eclipse Public License 1.0)
EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
使用EPL协议，需要遵守以下规则：
- 当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权；
- EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法；
- 当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；
- 独立的模块(Separate Module),不需要开源。
要点：商业软件可以使用，也可以修改EPL协议的代码，但要承担代码产生的侵权责任。
协议的选择
简单宽松的协议
如果你只想要一个简单点的协议不想太麻烦的话。
MIT协议相对宽松但还是抓住了要点的。此协议允许别人以任何方式使用你的代码同时署名原作者，但原作者不承担代码使用后的风险，当然也没有技术支持的义务。jQuery和Rails就是MIT协议。
考虑有专利的情况
如果你的作品中涉及到专利相关。
Apache协议也是个相对宽松与MIT类似的协议，但它简单指明了作品归属者对用户专利上的一些授权（我的理解是软件作品中含有专利，但它授权你可以免费使用）。Apache服务器，SVN还有NuGet等是使用的Apache协议。
代码分享与促进
如果你在乎作品的传播和别人的修改，希望别人也以相同的协议分享出来。
GPL（V2或V3）是一种版本自由的协议（可以参照copy right来理解，后者是版本保留，那copyleft便是版权自由，或者无版权，但无版权不代表你可以不遵守软件中声明的协议）。此协议要求代码分发者或者以此代码为基础开发出来的衍生作品需要以同样的协议来发布。此协议的版本3与版本2相近，只是多3中加了条对于不支持修改后代码运行的硬件的限制（没太明白此句话的内涵）。
协议的区别
下面的树形图很好阐述了当前主流许可协议的区别:
这里是目前github上项目采用的开源协议的比例分布：
