开源许可证--详解/对比-蒲公英云

原文网址：开源许可证—详解/对比_IT利刃出鞘的博客-CSDN博客

简介

本文介绍开源许可证的含义以及它们的区别。

常用的开源许可证由宽松到严紧排序：MIT> BSD > Apache > LGPL > Mozilla > GPL

许可证分类

宽松式许可证

权限

没有使用限制
没有担保
没有披露要求（notice requirement）
用户可以修改代码后闭源

包含的许可证

BSD
MIT
Apache 2

Copyleft

权限

如果分发二进制格式，必须提供源码
修改后的源码，必须与修改前保持许可证一致
不得在原始许可证以外，附加其他限制
修改后的 Copyleft 代码不得闭源

包含的许可证

Affero
GPL (AGPL)
GPL
LGPL
Mozilla（MPL）

GPL许可证

来源

自由软件基金会

权限

允许任何人观看、修改，并散播程序软件里的原始程序码
唯一条件：如果要发布修改后的版本就要连源代码一起公布

开源许可证的选择

许可证详解

MIT许可证

来源

来源于大学，MIT 许可证是史上最为简洁和慷慨（permissive）的开源协议之一。

权限

用户可以拿你的代码做任何想做的事情
用户在项目副本中要包含版权声明和许可声明
你无需承担任何责任

格式

一般使用 MIT 授权的项目，需在源文件头部增加以下内容：

Copyright [yyyy] [name of copyright owner]. All rights reserved.

[yyyy]：表示该源文件创建的年份。
[name of copyright owner]：即版权所有者。如果为个人项目，就写个人名称；若为团队项目，则宜写团队名称。

应用案例

JQuery
Rails

BSD协议

来源

来源于大学，BSD可证与MIT差不多，也非常简单、慷慨。

权限

用户可以自由的使用、修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
用户再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

应用案例

比较灵活，BSD深受大公司的欢迎。

商用

BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。很多公司在选用开源产品的时候首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

Apache许可证

来源

来自Apache，类似MIT许可证，但它重视专利权。

权限

允许代码修改，再发布（作为开源或商业软件）
如果修改了代码，需要在被修改的文件中说明。
需要给代码的用户一份Apache Licence
明确禁止商标使用权，不允许使用作者的名号/商标进行商业行为

格式

该许可证要求在所有的源文件中的头部放置以下内容才能算协议对该文件有效：

Copyright [yyyy] [name of copyright owner]

[yyyy]：表示该源文件创建的年份。

应用案例

Apache 家族
SVN
NuGet

商用

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

LGPL许可证

来源

来源自由软件联盟GNU，可以翻译为更宽松的GPL协议，也属于传染性开源。

权限

用户如果只是对LGPL软件的程序库的程序进行调用而不是包含其源代码时，相关的源程序无需开源
GPL许可证
来源自由软件联盟GNU，GPL/LGPL侧重于代码及衍生代码的开源与免费使用。如果你使用了GPL的代码，就必须沿袭这个协议，做出来的产品，无论商业不商业，必须开源。
后续使用该软件源程序开发软件者亦应当根据GPL协议把自己编写的源程序进行公开。
GPL协议要求的关键在于开放源程序，但并不排斥软件作者向用户收费

应用案例

Linux

Mozilla许可证

权限

允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。
要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。
允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。