开源许可协议：GPL、LGPL、AGPL、MPL和BSD、MIT、Apache

本文介绍: 开源许可协议：GPL、LGPL、AGPL、MPL和BSD、MIT、Ap a ch e

概述

开源许可证分为2种类型：宽松型和著作权型。

1、宽松型(Pe rm i ss i v e)：该类许可证往往只要求被许可方保留原作品的版权信息，对用户施加的限制较少，衍生软件可以成为私有软件，如Ap a ch e、MIT、BSD系列许可证。由于这类许可证允许衍生软件闭源，对商业化非常友好，因此广受欢迎。

2、著作权型（copy left）：也称为互惠型、强保护型，要求对软件的修改和扩展，必须按照获得该软件的许可证进行开源，旨在促进开发人员的合作，保护源代码的自由共享，如GPL系列许可证。对于强制开源的许可证，使用要慎重，因为违反开源许可证被起诉已经有很多判例。进一步，可以区分为强著佐权和弱著佐权，前者包括AGPL、SSPL、GPL许可证等；后者包括LGPL系列许可证、MPL许可证等。强著佐权要求对软件的修改和扩展，必须按照获得该软件的许可证进行开源，且不得违背原作品的限制条款。弱著佐权要求对软件的修改、重新分发必须按照获得该软件的许可证进行开源，但合并这些软件代码的大型作品可以成为私有作品。

二、GPL、AGPL、LGPL及MPL许可证解读及合规使用

背景说明：对于软件开发者来说，无论是个人还是商业组织，为了分享自己的优秀作品、为了扩大自身影响力，多多少少都有想把自己的软件作品以开源的形式公之于众的想法。但无论是开源自己的软件，还是使用已开源的软件，出于商业和法律因素的考虑，我们都应该搞清楚：当我们使用开源软件或者将自己的作品开源时，我们保留了啥权力？我们又放弃了啥权力？

主流的开源许可协议有以下几种：GPL、LGPL、MPL、BSD、MIT、Ap a ch e Li cens e。从 Lin k 依赖、修改源码、版权说明、源码软件是否可用于产品广告，这几个维度，可以将以上几个主流开源协议的宽松程度，做如下图所示的梳理：

本文主要介绍 GPL、LGPL、AGPL、MPL和BSD、MIT、Ap ac h e

一、GPL许可证

1、概念：

GPL，即GNU通用公共许可协议，是 GNU Gener al Pub li c Li cense 的简写。它是由自由软件基金会(FSF)公布的自由软件许可证。

2、版本演进历史：

GPLv1：1989年2月25日发布。

GPLv2：1991年6月发布。

GPLv3：2007年6月29日发布。

3、协议特点：

GPL协议最大的一个特征是具有传染性，即GPL对于许可证有强制继承的要求，这也是GPL与其他许可证在哲学思想上最大的差异。

4、权利和义务：

GPL 规定了使用遵循了GPL协议软件时，使用者的权力和义务如下：

权力：

获取源码的权力；

修改源码的权利；

自由处理衍生作品的权利。

义务：

使用了遵循GPL协议发布的软件，自身也必须遵守GPL协议。这也是GPL被人称为有传染性的原因。

必须开放源代码；允许使用者自由获取(复制)、修改、发布的产品，即拥有获取源码、修改源码、分发软件的自由。

5、GPL 自由权利的描述：

GPL的条款和条件必须提供给任何接受GPL应用的作品的副本（“被许可人”）的人员。

任何遵守条款和条件的被授证人员都有权修改作品，以及复制和重新分发作品或任何派生版本。

GPL下的软件可以用于所有目的，包括商业目的，甚至作为创建专有软件的工具，例如使用GPL许可的编译器时，分发GPL许可作品（如软件）的用户或公司可能会收取副本费用或无偿提供费用。

6、分析说明：

这里被授权人，可以理解为，是使用了遵循GPL协议软件的作品的作者或者组织。

第三点将GPL与禁止商业再分发的软件许可区分开来，也与共享软件许可证区分开来。FSF认为自由软件不应该限制商业使用和发布（包括再发布）。GPL明确规定，GPL作品可能以任何价格出售。

许可只依赖于使用的库和软件组件，而不是依赖于底层平台。例如，作为GPL许可操作系统（如Linux）下的应用程序运行的软件不需要根据GPL进行许可或者以源代码可用性分发。

7、官方网址：

https://www.gnu.org/licenses/gpl-3.0.html

二、LGPL许可证

1、概念：

LGPL，即GNU宽通用公共许可证，是 GNU Lesse r General Pub li c Li cense 的简称。它是由自由软件基金会(FSF)公布的自由软件许可证。

2、版本演进历史：

第一版(2.0)：1991年发布，第一个字母 L 定义为 Li b r ar y，为与 GPLv2 保持一致而采用 2.0 版的编号。

第二版(2.1)：1999年发布，第一个字母 L 定义为 Lesse r，以显示 FSF 认为并不是所有程序库都应当采用该许可证的态度。

第三版(3.0)：2007年发布，它以在 GPL 第3版之上附加应用一系列许可的方式表现。

3、协议特点：

LGPL和GPL不同，GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同，LGPL允许商业软件通过引用(link)的方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

4、LGPL的发展和分析：

从第一版的 L 表示 Li b r ar y 的含义以及其版本号直接和GPL保持一致(第一版就是2.0)可知，该协议是GPL的补充协议，是一个主要为开源类库使用设计的开源协议，因为FSF逐渐意识到，GPL协议的强制传染性在某些场景下太过苛刻，会阻碍开源产品被更广泛的传播和使用，实际上很多软件开发过程中使用开源软件的场景，仅仅是把某个开源软件当做底层的库来引用，针对此种场景，FSF在1991年发布GPL第二版时，发布了LGPL第一版。

LGPL的含义可以理解为：它允许企业与软件开发者将LGPL授权的软件以依赖库链接的形式集成至他们自己的软件内（即使该软件是私有软件也被允许），同时不会受到类似于GPL传染特性的许可证强制对软件开源的限制。但如果修改LGPL协议的代码而产生的衍生代码，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。

采用LGPL的项目本身虽然仍有“Co py left”的限制条件，但这些限制不会感染到仅仅只链接到本项目的软件。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。LGPL为了在GPL与其他许可式许可证之间获取折衷，常被用于一些GNU程序库，亦可使用于独立存在的应用程序中，比较有名的例子为 Mozilla 跟 http://OpenOffice.Org。

三、AGPL许可证

AGPL（GNU Affe ro General Public License，Affe ro通用公共许可证）许可证是一种强著作权许可证。该许可证可以说是对GPL的一次“查漏补缺”，它继承了GPL所有条款，并在此基础上增加了一条：如果其许可下的软件与用户通过网络进行交互，那么就需要提供源代码给用户，所有的修改也同样要提供给用户。AGPL和GPL协议是兼容的。

最初的Affe ro GPL基于GPLv2于2002年发布，其发布者并非自由软件基金会，而是一家名为Affe ro的初创软件公司。之后，自由软件基金会2007年基于GPLv3发布了自己版本的AGPLv3，并在名称中保留了Affe ro，以向这段历史致敬。目前，AGPLv3是使用较为广泛的版本。

GPL的义务仅在分发代码时才会被触发。这是因为“使用”并非版权的关注焦点，版权自诞生以来一直关注的是“复制”。从版权的英文 copy right可知，版权一直以来都是一种涉及复制（co py）的权利。在传统行业中并未遇到大的问题，但是在云服务下，云服务厂商不再向用户提供（分发）软件的副本，因此，云服务厂商可以随意使用GPL代码而无需支付任何形式的成本，并且这一切都是合法的。为了应对该应用服务提供商漏洞（application service provider (ASP) loop hole），AGPL规定，通过远程网络交互时也视为“分发”，需要提供源代码。

四、MPL许可证

1、概念：

MPL，即 Mozilla公共许可证，是 Mozilla Public License 的简称，由Mozilla基金会开发并维护。

2、版本演进历史：

第一版，1.0版本，1998年发布。

第二版，1.1版本，其主要变更是理清了关于专利部分的条款，以及允许多个许可证之间共存。

第三版，2.0版本，2012年1月3日发布。该版本使许可协议更加清晰，更加方便应用，同时也兼容于GPL及Ap ac he许可证。

从1.1版本开始，允许遵循MPL许可证的项目里多个许可证的共存，这一特性旨在鼓励与偏好使用GPL许可的开发者合作。1.1版本的结构，法律切合度，以及其对专利权的明确态度都深深的影响了后来流行的许可协议，有点像是第三版的GPL。很多项目都以此派生出他们自己的许可协议，如Sun Microsystems的通用开发与散布许可证。

3、协议特点：

MPL允许在其授权下的源代码与其他授权的文件进行混合，包括私有许可证，但在MPL授权下的代码文件必须保持MPL授权，并且保持开源。

可以理解为：遵循MPL的项目允许使用者对于MPL作品进行二次开发和发布，但MPL的部分、以及修改的部分，需要遵循MPL协议，并对修改部分作出说明，但允许衍生项目中有私有模块的存在。

这样的条款让MPL既不像MIT和BSD那样允许派生作品完全转化为私有，也不像GPL那样要求所有的派生作品包括新的组件在内的作品全部必须保持GPL。

一句话，MPL协议通过允许在派生项目中存在私有模块，同时保证核心文件的开源，同时激励了商业及开源社区来参与帮助开发核心软件。

4、发展与应用：

MPL既是得到自由软件基金会(FSF)承认的自由软件许可证，也是得到开放源代码促进会(OSF)承认的开源软件许可证。

该协议融合了BSD许可证和GNU通用公共许可协议的特性，追求平衡专有软件和开源软件开发者之间的顾虑。

MPL用于 Mozilla Firefox、Mozilla Thunderbird 及其他 Mozilla软件的许可，也被其他产品所用，如Adobe以此为Flex产品线许可，还有LibreOffi ce 4.0（同时使用LGPLv3）。

五、BSD 许可证

1、概念：

BSD 许可协议，即 Berk eley Soft ware Distribu tion license 的简称，是由加州大学伯克利分校发布并维护的开源软件许可证。BSD许可证是自由软件中使用最广泛的许可协议之一。

2、两个概念：

BSD：人们常说的BSD，指的是 Berk eley Soft ware Distribu tion，即伯克利软件套件，是加州大学伯克利分校在AT&T贝尔实验室的Unix操作系统基础上，开发打包的操作系统及相关软件套件。

BSD许可协议：BSD套件遵循某种开源许可证的方式发布，这种许许可证因此而得名，被叫做 BSD许可证。

3、BSD协议特点：

BSD开源协议是一个给予使用者很大自由的协议，可以自由的使用、修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

4、版本演进历史：

旧版BSD：1998发布初版。

新版BSD：1999年发布修订版。

BSD协议的初稿内含有一项额外的条款，要求所有从以BSD许可证授权的软件派生著作，都必须要包含一段文字以交代源代码的来源。该条文列于原BSD许可证的第三条。

GNU项目将这个称为“令人感到不舒服的BSD交代条款”，GNU工程认为存在两个问题：

第一，修改源码的人都希望将其大名加到鸣谢中，如果一个项目参加的人非常多，或者软件包中包含许多个单独项目，鸣谢阵容将会变得非常庞大。

第二，这跟GNU通用公共许可协议相抵触，GPL不允许增加额外的限制，所以软件只能在GNU跟BSD之间选择。由于这两个许可证在自由软件中使用很普遍，如果作者想将GPL和BSD有所结合，就会出现冲突。

应自由软件基金会和GNU计划的发起者斯托曼的请求，1999年7月22日，伯克利技术许可办公室的主管 William Hos k ins 删除了BSD许可证的第三条。从此以后，自由软件作者就可以方便地采用BSD许可证下的软件，从而跟GPL下的作品融合。

原来的许可证有时被称为“BSD-old”（老BSD）或“4-clause BSD”（四句版BSD），当前的BSD许可证有的被称为“BSD-new”（新BSD）、“re vi sed BSD”（修订的BSD）或“3-clause BSD”（三句版BSD）。

5、协议分析：

当发布使用了BSD协议的代码或以BSD协议代码为基础做二次开发自己的产品时，需满足以下三个条件：

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

不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD协议鼓励项目代码共享，但需要尊重作者的著作权。BSD协议由于允许使用者修改和重新发布代码，也允许在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。

很多公司在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。遵守BSD 协议的软件，允许用作商业用途，甚至可按照专属许可证进行再发布。

六、MIT 协议

1、概念：

MIT 许可协议：即 The MIT License，该许可协议之名源自麻省理工学院（Massa c huset ts Institute of Tec h no log y, MIT），又称“X许可协议”（X License）或“X11许可协议”（X11 License）。

2、版本演进历史：

1988，由自麻省理工学院(MIT)发布。

3、协议特点：

MIT许可协议是许多软件许可条款中被广泛使用的其中一种。与其他常见的软件许可协议（如GPL、LGPL、BSD）相比，MIT是相对宽松的软件许可协议，赋予软件被许可人更大的权利与更少的限制。

4、协议分析：

被许可人权利：被许可人有权利使用、复制、修改、合并、出版发行、散布、再许可和/或贩售软件及软件的副本，及授予被供应人同等权利，惟服从以下义务。

被许可人义务：在软件和软件的所有副本中都必须包含以上著作权声明和本许可声明。

5、其他重要特性：

此许可协议并非属co py left的自由软件许可协议条款，允许在自由及开放源代码软件或非自由软件（proprieta ry software）所使用。

MIT的内容可依照软件代码著作权者的需求更改内容，这也是MIT与BSD本质上的不同处。

MIT许可协议可与其他许可协议并存。MIT条款也是自由软件基金会（FSF）所认可的自由软件许可协议条款，与GPL兼容。

有许多团体均采用MIT许可证，例如著名的SSH连线软件PuTTY与X窗口系统、Expat、Mono开发平台库、Ruby on Rai ls、Lua等等也都采用MIT许可协议。

七、Ap ache 许可协议

1、概念：

Ap ache许可证，即 Ap ache License，是一个由Ap ache软件基金会(ASF)发布的自由软件许可证。

Ap ache许可证最初为 Apache Web 服务器而撰写，Apache许可证在Apache社区内外被广泛使用；Apache基金会下属所有项目都使用Apache许可证；许多非Apache基金会项目也使用了Apache许可证。

官网：http://www.apache.org/licenses/

2、版本演进历史：

Apache License 1.0，1995年发布。

http://www.apache.org/licenses/LICENSE-1.0

Apache License 1.1，2000年发布。

http://www.apache.org/licenses/LICENSE-1.1

Apache License 2.0，2004年发布。

http://www.apache.org/licenses/LICENSE-2.0

3、协议要求：

Apache许可证，具体要求如下：

对所有未修改的部分应用相同的许可证，并且在每个许可文件中，必须保留再分发代码中的任何原始著作权、专利、商标和归属通知(不需要包括任何部分的派生作品)；

在每个更改的许可文件中，都必须添加一条通知，说明对该文件进行了更改。

不强制要求派生和修改产物使用相同的许可证进行发布。

4、协议分析说明：

如果声明文本文件是作为原始作品发布的一部分，则派生作品必须包含该通知文本文件的可读副本，可以是文档或显示在软件中。

声明文件的内容不会修改许可证，因为它们仅用于提供信息，并且可以在许可证文本中添加更多属性声明，前提是这些声明不能被理解为修改许可证。修改可能有适当的著作权声明，并可能为修改提供不同的许可条款。

八、CC0协议

Creative Commons Zero v1.0 Universal（知识共享 CC0 1.0 通用）协议是由 Creative Commons（知识共享）组织发布的一种公共领域贡献许可证，其声明将作品贡献至公共领域，在法律允许的范围，放弃所有他在全世界范围内基于著作权法对作品享有的权利，包括所有相关权利和邻接权利。

条款简述

在 CC0 协议许可下，您可以：

商业化使用

再分发

修改

私人使用

除此之外，该软件：

提供责任限制

限制专利使用

限制商标使用

不提供任何担保

如何使用

我们建议您遵循 CC0 (creativecommons.org) 网站的指引进行使用，请注意，这不是一个注册过程，知识共享不会存储或保存您输入的任何信息。此工具将指导您完成生成包含嵌入元数据的 HTML 的过程，以便将您的工作标记为在 CC0 下可用。您的作品不会与 CC0 关联，也不会在 CC0 下提供，除非您将其标记为 CC0 发布。

Creative Commons Licenses*

Creative Commons Licenses 是由 Creative Commons（知识共享）组织发布的一系列许可证的统称，习惯上，我们将这一系列许可证称为 CC 许可证。

CC 许可证有多个版本和多个变种。3.0 版本是一个早期版本，其特点是以一个未本地化版本（Unlocalized）为起点，针对全球各个国家和地区的当地法律制定了不同的版本（例如 CC BY 3.0 中国大陆和 CC BY 3.0 美国）；在 4.0 版本中，Creative Commons 使用了一个统一的法律文件来代替先前版本的多个不同的本地化法律文件。在这里，我们主要介绍 CC 4.0 版本许可证。