之前只知道项目有开源和闭源之分，但是却不懂项目开源协议有哪些不同，看着项目从这个协议变更到那个协议，对于其中的变化也是不以为意。这次就来详细了解一下，看看不同的开源协议各自有什么特点。
Apache License
- 需要给代码的用户一份 Apache License
- 如果修改了代码，需要在被修改的文件中说明
- 在衍生的代码中需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
- 如果在发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但是不可以表现为对Apache Licence构成更改。
- Apache Licence 也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足并作为商业产品发布/销售。
使用这个协议的好处有：
- 永久权利。一旦被授权，永久拥有。
- 全球范围的权利。在一个国家得到授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
- 授权免费。务办税，前期、后期均无任何费用。
- 授权无排他性。任何人都可以获得授权。
- 授权不可撤销。一旦获得授权，没有任何人可以取消。比如，你基于该产品开发了衍生产品，不用担心会在某一天会被禁止试用该代码。
BSD
"Berkeley Software Distribution"的缩写，意思是“伯克利软件发行版”。
BSD开源协议：是一个基于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码作为基础做二次开发自己的产品时，需要满足三个条件：
- 如果发布的产品中包含有BSD协议的代码，则必须带有BSD协议。
- 如果再发布的只是二级制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中BSD协议。
- 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在在BSD代码上开发软件发布或销售，对商业集成是很友好的协议。很多公司选用开源产品的时候首选BSD协议，因为可以完全控制这些第三方的代码，必要的时候可以修改或者二次开发。
GPL
GNU General Public Licence: GNU通用公共许可协议
Linux采用了GPL
GPL允许代码以及衍生代码的免费试用和引用/修改。但不允许修改后和衍生的代码作为闭源商业软件发布和销售。所以我们用的Linux都是免费的。
LGPL
LGPL是GPL的一个为主要类库试用设计的开源协议。和GPL不用的是，LGPL允许商业软件通过类库引用的方式使用LGPL类库而不需要开源商业软甲你的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用发布和销售。
MIT
MIT适合BSD一样宽泛的许可协议，源自麻省理工学院，又称X11协议。作者只想保留版权，而无任何其他的限制。MIT是目前限制最少的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。适用MIT的软件项目有：jquery，node.js.
MPL
MPL协议允许免费重发布，免费修改。但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益。它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在始作俑者手中。但MPL是允许修改，无偿试用的。
EPL
EPL允许代码使用、复制、分发、传播、展示以及修改后闭源二次商业发布。
使用EPL协议，需要遵守以下规则：
- 当一个二次开发者将源码整体或者部分再次开源发布时，必须要继续遵守EPL开源协议来发布，而不能改用其他歇息发布，除非得到源码拥有者的授权。
- EPL协议下，你可以将远吗不做任何修改来商业发布，但如果你要发布修改后的源码，必须声明它的源码是可以获取的，且要告知获取方法。
- 当你需要将EPL下的源码作为一部分跟其他私有源码混合一起作为产品发布的时候，你可以将整个产品以私人的协议发布，但要声明哪一部分代码是EPL协议下的，而且那部分代码继续遵循EPL协议。
- 独立的模块，不需要开源？
Creative Commons知识共享协议
Creative Commons（CC）许可协议并不能说是真正意义上的开源协议，它们大多被用于设计类的工程上。CC协议种类繁多，每一种都授权特定的权利。一个CC许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。下面是这几部分的简介：
- 署名。作品上必须附有作品的归属。
- 相同方式共享。衍生品也必须是CC协议。
- 非商业用途。衍生品不能用于商业目的。
- 禁止衍生作品。