GPL LPGL BSD MIT AGPL MPL Apache Licence - 常见开源软件许可协议 汇总
GPL LPGL BSD MIT AGPL MPL Apache Licence - 常见开源软件许可协议 汇总现今存在的软件开源协议很多，而经 Open Source Initiative 组织通过批准的开源协议，目前有 58 种。
常见的开源协议，如 BSD、GPL、LGPL、MIT、等都是 OSI 批准的协议。如要开源自己的代码，最好也是选择这些被批准的开源协议。
GPL (Gun General Public License)
著名的开源 Linux 操作系统，就采用了 GPL 协议。GPL 、BSD、Apache Licence、等开源许可协议，鼓励代码重用的开源范围有些不一样。
GPL 协议的出发点是代码开源、免费使用、引用-修改-衍生代码的开源-免费使用；不允许修改后和衍生的代码，作为闭源商业软件部分进行发布、销售。这也就是为什么我们能使用各种免费 linux 操作系统，包括商业公司的 linux 和 linux 上各种各样的由个人、组织、以及商业软件公司开发的免费软件的根本原因。
GPL 协议的主要内容，是：只要一软件使用(类库引用、修改后的代码或衍生代码) GPL 协议开源代码，则该软件也必须采用 GPL 协议 (也必须开源和免费，这就是所谓的 "病毒传染性" 和 "不允许闭源的商业发布")。
由于 GPL 严格要求使用了 GPL 类库的软件也必须使用 GPL 协议，对于使用 GPL 协议开源代码的商业软件或对代码有保密要求的，就不适合集成作为类库和二次开发的基础。
GPL LPGL Mozilla BSD MIT Apache Licence 许可协议
LGPL (GNU Lesser General Public License)
LGPL 允许商业软件通过类库引用 (link) 方式使用 LGPL 类库，而不需要开源商业软件的源代码。这使得采用 LGPL 协议的开源代码，可被商业软件作为类库引用发布和销售。
但是，如修改 LGPL 协议源代码或衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码，都必须采用 LGPL 协议。因此，LGPL 协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生方式做二次开发的商业软件采用。
GPL 和 LGPL 都保障了原作者的知识产权，避免有人利用开源代码复制并开发类似产品。
AGPL原有的 GPL 协议，由于网络服务公司的兴起 (譬如：Google) 产生了一些漏洞；譬如：使用 GPL 的自由软件，并不发布于网络中，则可自由使用 GPL 协议却不开源自己私有的解决方案。AGPL 则增加了对此做法的约束。
AGPL 是 GPL 的一个版权补充许可协议，在 GPL 的基础上增加了一些限制。商业软件不能使用 AGPL 版权许可协议的代码。
AGPL 版权许可协议是为避免一个 GPL/LGPL 协议中的漏洞，称之为 Web Service Loopwhole。主要由于 GPL 是针对传统软件分发中的商业模式 (以微软为代表)，如使用 GPL 版权许可协议代码为基础完成自己的软件，当分发软件时，也必须采用 GPL 版权许可协议。
随着以 Google 为代表的作为互联网服务公司的兴起，它们 "不分发软件，为客户提供网络服务" 的商业模式就不受 GPL 协议约束；所以，Google 公司在构筑其搜索引擎时，可随心所欲的借用现有 GPL 协议的开源代码，无需开源其修改后的成果。AGPL 版权许可协议就在 GPL 协议的基础上加上了这个约束。
BSD (Berkeley Software Distribution)
BSD 开源协议，是一个给予使用者很大自由的协议。基本上说，使用者可 "为所欲为"，可自由使用、修改源代码，也可将修改后的代码，作为开源或专有软件再发布。
但是，"为所欲为" 的前提是，当你发布使用了 BSD 协议的代码，或以 BSD 协议代码为基础做二次开发自己的产品时，需要满足 3 个条件:
1. 如再发布的产品中包含源代码，则在源代码中必须带有原代码中的 BSD 协议。
2. 如再发布的只是二进制类库、软件，则需在类库、软件的文档和版权声明中，包含原代码中的 BSD 协议。
3. 不可使用开源代码的作者、机构名字、原产品名字做市场推广。
以规则的目的，只有一个：他人的东西，别人以 BSD 开源了，就不能不做任何声明而占为己有，更不能用他人的名义来做商业推广，只对自己的东西拥有绝对控制权。
BSD 协议鼓励代码共享，但需尊重代码原作者的著作权。由于 BSD 允许使用者修改和重新发布代码，也允许使用或在 BSD 代码上开发商业软件并发布和销售；因此，是对商业集成很友好的协议。
很多公司、企业在选用开源产品时，都首选 BSD 协议；因为，可完全控制这些第 3 方源代码，在必要时还可修改或二次开发。
MIT
MIT 是和 BSD 一样宽范的许可协议，作者只想保留版权，而无任何其他限制。
也就是说，必须在发行版里包含原许可协议的声明，无论是以二进制发布的，还是以源代码发布的。
MPL
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 许可第 3 条第 7 款中允许被许可人，将经 MPL 许可获得的源代码同自己其他类型的代码混合得到自己的软件程序。
3、对软件专利的态度，MPL 许可不像 GPL 许可那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已受专利保护的源代码 (除非他本人是专利权人，并书面向公众免费许可这些源代码)，也不能在将这些源代码以开放源代码许可形式许可后再去申请与这些源代码有关的专利。
4、MPL (1.1 版) 许可中，对源代码的定义是："源代码指的是对作品进行修改最优先择取的形式，它包括：所有模块的所有源程序，加上有关的接口定义，加上控制可执行作品的安装和编译的脚本，或没有与初始源代码存在显著不同的源代码，或是被源代码贡献者选择的从公共领域可得到的程序代码"。
5、MPL 许可第 3 条有专门的一款，是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件，对源代码程序修改的时间和修改的方式有描述。
Apache Licence 2.0
Apache Licence 是著名的非盈利开源组织 Apache 采用的协议。
Apache Licence 协议和 BSD 类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布 (作为开源或商业软件)。需满足的条件也和 BSD 类似:
1. 需要给代码的用户一份 Apache Licence
2. 如修改了代码，需在被修改的文件中说明
3. 在延伸代码中 (修改和有源代码衍生的代码中) 需带有原代码中的协议、商标、专利声明和其他原作者规定需包含的说明
4. 如再发布的产品中包含一个 Notice 文件，则在 Notice 文件中需带有 Apache Licence。可在 Notice 中增加自己的许可，但不可表现为对 Apache Licence 构成更改。
Apache Licence 也是对商业应用友好的许可，使用者可在需要时修改代码来满足需求，并作为开源或商业产品发布和销售。
Source Code 和 Object Code
Source Code 指的是，以各种编程语言写成的源代码，通过 Source Code 结合文档，可了解整个软件的体系结构及具体到某个功能函数的实现方法等。
Object Code 指的是 Source Code 经编译后，生成的类似于 "类库"，提供各种接口供他人使用的目标码，也就是常见的 *.dll *.so *.pyd 等格式文件。
区分这两个概念的目的，在于：有些开源只发布 Object Code，当然，大多数发布的是 Source Code。很多开源协议也对 "发布哪种 Code 时应怎样" 有明确约束。
Contributors 和 Recipients
Contributors 指的是，对某个开源软件或项目提供了代码 (包括最初的，或修改过的) 的人或实体 (团队、公司、组织、等)。
Contributors 按参与开源软件的时间先后顺序，可分为 an initial Contributor 和 subsequent Contributors。
Recipients 指的是，开源软件或项目的获取者，显然，subsequent Contributors 也属 Recipients 之列。
Derivative Module 和 Separate Module
Derivative Module 指的是，依托或包含 "最初的" 或 "从别人处获取的" 开源代码而产生的代码，是原 "源代码" 的增强 (不等于增加)、改善和延续的模块，译为 "衍生模块"。
Separate Module 指的是，参考或借助原 "源代码"，开发出的独立的、不包含、不依赖于原 "源代码模块"，译为 "独立的模块"。
理解这两个概念的目的，在于：很多协议对涉及商业发布时，会有哪些是衍生的，哪些是独立的，有着明确的商业发布规定。
http://forum.digitser.cn/data/attachment/forum/201605/19/132155fevczeyds5e5y1wy.jpg"长按二维码" 或 "扫一扫" 关注 "德云社区" 微信公众号
版权声明：
本文为独家编译稿件，版权归 德云社区，未经许可不得转载；否则，将追究其法律责任。
页:
[1]