参考文档：
http://www.cnbeta.com/articles/107523.htm
https://linux.cn/article-3739-1.html
http://www.smashingmagazine.com/2010/03/a-short-guide-to-open-source-and-similar-licenses/
http://univasity.iteye.com/blog/1292658
什么是许可协议？
什么是许可，当你为你的产品签发许可，你是在出让自己的权利，不过，你仍然拥有版权和专利（如果申请了的话），许可的目的是，向使用你产品的人提供一定的权限。
不管产品是免费向公众分发，还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。
而开源许可协议使这些事情变得简单，开发者很容易向一个项目贡献自己的代码，它还可以保护你原始作者的身份，使你至少获得认可，开源许可协议还可以阻止其它人将某个产品据为己有。以下是开源界的 5 大许可协议。
OSI：开放源代码促进会（Open Source Initiative）， http://opensource.org
通过OSI批准的许可协议： http://opensource.org/licenses/alphabetical
理解许可协议
Contributors（贡献者） ——指的是对某个开源软件或项目提供了代码（包括最初的或者修改过）的人或实体（团队、公司、组织等）。
按照贡献的先后可分为"创始人"（an initial Contributor）和"参与者"（subsequent Contributors）。
Recipients（获取者） ——指的是开源软件或项目的使用者。
显然，subsequent Contributors也属于Recipients之列。
Source Code（源码） ——指的是由各种语言写成的源代码 。
Object Code（目标代码） ——指的是Source Code经过编译后，生成的类似“类库”一样的，提供了各种接口供他人使用的目标代码 （就如,DLL、JAR等）。
Derivative Module（衍生模块） ——指的是，依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码，是对“源代码模块”的增强、改善和延续。
Separate Module（独立模块） ——指的是，参考或借助“源代码”开发出来的独立的，不包含、不依赖于原“源代码模块”的功能模块。
理解开源许可协议：http://openacs.org/about/licensing/open-source-licensing
GNU GPL
GNU General Public Licence ，GPL保证源代码及其衍生永远保持开源，不允许修改后和衍生的代码做为闭源的商业软件发布和销售，不适用于商业软件。Linux使用的就是该此许可协议。
GPL具有“传染性”，只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL协议的产品,则该软件产品必须也采用 GPL协议,既必须也是开源和免费。
GPL是针对软件源代码的版权,而不是针对软件编译后二进制版本的版权.你有权免费获得软件的源代码,但是你没有权力免费获得软件的二进制发行版本。GP对软件发行版本唯一的限制就是:你的发行版本必须把完整的源代码一同提供。 --引自Java视线论坛的Robbin
规则条款：
- 确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
- GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
- 无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
- 开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。
用于某些程序的某些协议有一些问题和限制，你可以看一下 @PierreJoye 写的 Practical Guide to GPL Compliance 一文。使用 GPL 协议，你必须在源代码代码中包含相应信息，以及协议本身。
GNU LGPL
Lesser General Public Licence，LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码，这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。适合那些用于非 GPL 或非开源产品的开源类库或框架。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
规则条款：
如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。（引用或修改LGPL的代码及其衍生也必须使用LGPL开源，源于闭源的代码不需要开源）。
因此LGPL协议的开源代码很适合作为第三方类库被商业软件直接引用，但不适合希望以开源代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
BSD
(Berkeley Software Distribution，伯克利软件套件)，BSD 在软件分发方面的限制比别的开源协议（如 GNU GPL）要少。该协议有多种版本，最主要的版本有两个，新 BSD 协议与简单 BSD 协议，这两种协议经过修正，都和 GPL 兼容，并为开源组织所认可。
鼓励代码共享，要求尊重原作者的著作权，允许使用者修改和重新发布代码(以其他协议形式)，允许闭源商业发布和销售。
规则条款：
- 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
- 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
- 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
新 BSD 协议（BSD 3-Clause, 3条款）在软件分发方面，除需要包含一份版权提示和免责声明之外，没有任何限制。另外，该协议还禁止拿开发者的名义为衍生产品背书，但简单 BSD 协议（BSD 2-Clause, 2条款）删除了这一条款。
Apache
Apache Licence是著名的非盈利开源组织Apache采用的协议。Apache 协议 2.0 和别的开源协议相比，除了为用户提供版权许可之外，还有专利许可，对于那些涉及专利内容的开发者而言，该协议最适合（这里有一篇文章阐述这个问题）。
鼓励代码共享，要求尊重原作者的著作权，允许使用者修改和重新发布代码（包括以其他协议形式），允许闭源商业发布和销售。
规则条款：
- 给代码用户一份Apache Liences。（在声明中对参与开发的人给予认可并包含一份许可协议原文）
- 如果修改了代码，需要在被修改的文件中说明。
- 修改或衍生的代码需要带有原始代码中的协议，商标，专利声明和其他原作者规定需要保护的声明。
- 如果再发布产品中保护Notice，则Notice文件中要带有Apache Liences，可以增加自己的许可，但是不能表现为对Apache Lience构成更改。
MIT
MIT 协议，源自麻省理工学院，又称X License, X11 License。和BSD一样宽松。
只要求保留作者版权，无其他任何限制。
条款规则：
- 该软件及其相关文档对所有人免费，可以任意处置，包括使用，复制，修改，合并，发表，分发，再授权，或者销售。
- 唯一的限制是，软件中必须包含原版权和许可声明，无论是以源码还是二进制发布。
MPL License（Mozilla Public License）
允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。
这种授权维护了商业软件的利益，，它要求基于这种软件的修改无偿贡献版权给该软件。
这样，围绕该软件的所有代码得版权都集中在发起开发人得手中。
但MPL是允许修改，无偿使用的。
MPL软件对链接没有要求。(要求假如你修改了一个基于MPL协议的源代码，则必须列入或公开你所做的修改，假如其他源代码不是基于MPL则不需要公开其源代码)
CDDL
Common Development and Distribution License，通用开发与销售许可协议，是MPL（Mozilla Public License）的扩展协议，它允许公共版权使用，无专利费，并提供专利保护，可集成于商业软件中，允许自行发布许可。
EPL
Eclipse Public License 1.0，EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
规则条款：
- 当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权；
- EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法；
- 当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；
- 独立的模块(Separate Module),不需要开源。
Creative Commons
Creative Commons(CC)，知识共享许可协议， 并非严格意义上的开源许可，它主要用于设计，您在自己的作品上使用知识共享许可协议，并不意味着放弃您的著作权，而是在特定的条件下将您的部分权利授予公共领域内的使用者。Creative Commons 有多种协议，每种都提供了相应授权模式，但主要是以下 4 种基本权利组合：
- 署名权
允许对作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但在这些过程中必须以原作者的名义署名。 - 非商业
允许对作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但仅限于非商业性目的。但商业的定义有些模糊，比如，有的人认为非商业用途指的是不能销售，有的认为是甚至不能放在有广告的网站，也有人认为非商业的意思是非盈利。 - 不能衍生新作品
允许对作品原封不动地进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但不得进行演绎创作。 - 保持一致
只有在对新作品使用与原作品相同的许可协议的情况下，才允许发行其演绎作品。
这些许可形式可以结合起来用，其中最严厉的组合是“署名，非商用，不能衍生新作品”，意味着，你可以分享作品，但不能改动或以此盈利，而且必须为原作者署名。在这种许可模式下，原始作者对作品还拥有完全的控制权，而最宽松的组合是“署名”，意味着，只要使用原始作者署名，就可以自由处置。
如何选择开源协议
