常见的开源许可协议及如何选择（整理）

一.何为License

License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业。当然本文要讨论的当然是开源协议。

二.常见的开源协议：

常见的开源许可协议有：GPL、LGPL、BSD、Apache Licence vesion 2.0、MIT、 MPL、EPL 。

1.GPL，全称 GNU General Public License。它的主要内容为：只要在一个软件中使用(“使用”指类库引用或者修改后的代码) GPL 协议的产品，则该软件产品必须也采用GPL协议， 既必须也是开源和免费 。这个协议就不太适合商用软件，或者准备使用GPL开源组件的商用项目。基于这个协议的项目，极大的提高了开源软件的数量。目前用的多的是GPLV1，GPLV2。采用这个协议的开源软件有：Linux、 MySQL 。

2.LGPL，最初是Library GPL的缩写，后来改称作GNU Lesser General Public License。由于GPL太严格，限制了很多商用软件使用GPL组件才推出了这个LGPL。LGPL允许商业软件通过引用类库的方式使用LGPL组件（不直接使用源代码），这样可以不需要开源商业软件的代码。但是如果要修改原始组件的代码，则涉及修改部分的代码和基于原来代码衍生的代码都必须采用LGPL协议。LGPL不适合以LGPL协议为基础的代码进行二次开发的商业软件，但是商用软件可以采用编译后的类库引用就不需要公开源代码了。采用这个协议的开源软件有： JBoss、 FCKeditor 、 Hibernate。之前extjs就因为从LGPL转换到GPL带来了不少的震动。

3.BSD，全称 Berkeley Software Distribution。这个协议相对上面两个协议宽松很多，允许使用者修改和重新发布代码，也允许使用或在BSD代码基础上开发商业软件发布和销售，因此是适用于商业软件的。 基本上使用者可以”为所欲为”,可以自由的使用，修改 源代码 ，也可以将修改后的代码作为开源或者专有 软件 再发布 。 使用者别太高兴，使用时还必须做到满足三个条件：

（1）如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。

（2）如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。

（3）不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。适用BSD协议的开源软件有： nginx、CruiseControl、Redis。

4.apache Licence vesion 2.0，这个协议除了为用户提供版权许可之外，还有专利许可。与BSD协议权限类似， 允许代码修改，再发布，适用商业软件。但是也需要满足以下条件：

（1）需要给代码的用户一份Apache Licence。

（2）如果你修改了代码，需要在被修改的文件中说明。

（3） 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。

（4）如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

除了这些条件它还有这些好处：

（1） 永久权利 一旦被授权，永久拥有。

（2） 全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。

（3）授权免费 无版税， 前期、后期均无任何费用。

（4） 授权无排他性 任何人都可以获得授权

授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码

使用apache Licence vesion 2.0协议的开源软件有：Hadoop 、apache httpserver、Spring Framework、MongoDB 。

5.MIT，源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。

6. MPL是The Mozilla Public License的简写，是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA 认定的开源软件许可证）。但是，相比而言MPL还有以下几个显著的不同之处:

（1）MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL 许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。 

（2）MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。 

（3）对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是 专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。 

（4）对源代码的定义 

而在MPL（1.1版本）许可证中，对源代码的定义是:“源代码指的是对作品进行修改最优先择 取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’（原文为‘Script’），或者不是与初始 源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。” 

（5）MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

7. EPL 是Eclipse Public License的简写，EPL允许获取者任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议，需要遵守以下规则：

1. 当一个贡献者将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权；
2. EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code（指的是源码经过编译后，生成的类似“类库”一样的，提供了各种接口供他人使用的目标代码 （就如,DLL、JAR等））的时候,你必须声明它的源码是可以获取的,而且要告知获取方法；
3. 当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；
4. 独立的模块(指的是，参考或借助“源代码”开发出来的独立的，不包含、不依赖于原“源代码模块”的功能模块),不需要开源。

列出了常用协议，还有一些比较常用的大家就谷歌了，比如：Creative Commons、Eclipse Public License 1.0等。

协议总结：

不过先来了解一些下方表格中出现的用词的解释：

• 协议和版权信息(License and copyright notice)：在代码中保留作者提供的协议和版权信息
• 声明变更(State Changes)：在代码中声明对原来代码的重大修改及变更
• 公开源码(Disclose Source)：代码必需公开。如果是基于LGPL协议 下，则只需使用的开源代码公开，不必将整个软件源码公开
• 库引用(Library usage)：该库可以用于商业软件中
• 责任承担(Hold Liable)：代码的作者承担代码使用后的风险及产生的后果
• 商标使用(Use Trademark)：可以使用作者的姓名，作品的Logo，或商标
• 附加协议(Sublicensing)：允许在软件分发传播过程中附加上原来没有的协议条款等

协议	描述	要求	允许	禁止
Apache	一个较宽松且简明地指出了专利授权的协议。	协议和版权信息 声明变更	商用 分发 修改 专利授权 私用 附加协议	责任承担（禁止让作者承担责任，可以理解为免责） 商标使用
GPL	此协议是应用最为广泛的开源协议，拥有较强的版权自由( copyleft )要求。衍生代码的分发需开源并且也要遵守此协议。此协议有许多变种，不同变种的要求略有不同。	公开源码 协议和版权信息 声明变更	商用 分发 修改 专利授权 私用	责任承担 附加协议
MIT	宽松简单且精要的一个协议。在适当标明来源及免责的情况下，它允许你对代码进行任何形式的使用。	协议和版权信息	商用 分发 修改 私用 附加协议	责任承担
BSD	较为宽松的协议，包含两个变种BSD 2-Clause 和BSD 3-Clause，两者都与MIT协议只存在细微差异。	协议和版权信息	商用 分发 修改 私用 附加协议	责任承担
EPL	对商用非常友好的一种协议，可以用于软件的商业授权。包含对专利的优雅授权，并且也可以对相关代码应用商业协议。	公开源码 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担
LGPL	主要用于一些代码库。衍生代码可以以此协议发布（言下之意你可以用其他协议），但与此协议相关的代码必需遵循此协议。	公开源码 库引用 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担
MPL	Mozilla Public License(MPL 2.0)是由Mozilla基金创建维护的。此协议旨在较为宽松的BSD协议和更加互惠的GPL协议中寻找一个折衷点。	公开源码 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担 商标使用

三.快速选择：

目前流行的开源协议有很多，并且同一款协议有很多变种，比如你或许看到过' CC Attribution-NoDerivs',' CC Attribution-NonCommercial'同属CC协议。如此纷繁的协议该如何选择？协议太宽松会导致作者丧失对作品的很多权利，太严格又不便于使用者使用及作品的传播。所以除了协议多之外，你还要考虑你对作品想保留哪些权利，放开哪些限制。 如果你不想了解太多，只是想要一个简直直接的答案，下面给出的建议或许适合你。下方关于协议的选择及表格来自GitHub  choosealicence 项目。

1.简单宽松的协议

如果你只想要一个简单点的协议不想太麻烦的话。

MIT协议 相对宽松但还是抓住了要点的。此协议允许别人以任何方式使用你的代码同时署名原作者，但原作者不承担代码使用后的风险，当然也没有技术支持的义务。jQuery和Rails就是MIT协议。

2.考虑有专利的情况

如果你的作品中涉及到专利相关。

Apache协议 也是个相对宽松与MIT类似的协议，但它简单指明了作品归属者对用户专利上的一些授权（我的理解是软件作品中含有专利，但它授权你可以免费使用）。Apache服务器，SVN还有NuGet等是使用的Apache协议。

3.代码分享与促进

如果你在乎作品的传播和别人的修改，希望别人也以相同的协议分享出来。

GPL（ V2 或 V3 ）是一种版本自由的协议（可以参照copy right来理解，后者是版本保留，那copyleft便是版权自由，或者无版权，但无版权不代表你可以不遵守软件中声明的协议）。此协议要求代码分发者或者以此代码为基础开发出来的衍生作品需要以同样的协议来发布。此协议的版本3与版本2相近，只是多3中加了条对于不支持修改后代码运行的硬件的限制（没太明白此句话的内涵）。

有一篇博客的 树形图 很好阐述了当前主流许可协议的区别。

另附一张目前github上项目采用的许可协议比例图：