背景说明：对于软件开发者来说，无论是个人还是商业组织，为了分享自己的优秀作品、为了扩大自身影响力，多多少少都有想把自己的软件作品以开源的形式公之于众的想法。但无论是开源自己的软件，还是使用已开源的软件，出于商业和法律因素的考虑，我们都应该搞清楚：当我们使用开源软件或者将自己的作品开源时，我们保留了啥权力？我们又放弃了啥权力？
主流的开源许可协议有以下几种：GPL、MPL、LGPL、BSD、MIT、Apache License。从 Link 依赖、修改源码、版权说明、源码软件是否可用于产品广告，这几个维度，可以将以上几个主流开源协议的宽松程度，做如下图所示的梳理：
本文主要介绍 GPL、MPL、LGPL ，下篇文章介绍 BSD、MIT、Apache。
一、GPL：
1、概念：
GPL，即GNU通用公共许可协议，是 GNU General Public License 的简写。它是由自由软件基金会(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、官方网址：
二、LGPL:
1、概念：
LGPL，即GNU宽通用公共许可证，是 GNU Lesser General Public License 的简称。它是由自由软件基金会(FSF)公布的自由软件许可证。
2、版本演进历史：
第一版(2.0)：1991年发布，第一个字母 L 定义为 Library，为与 GPLv2 保持一致而采用 2.0 版的编号。
第二版(2.1)：1999年发布，第一个字母 L 定义为 Lesser，以显示 FSF 认为并不是所有程序库都应当采用该许可证的态度。
第三版(3.0)：2007年发布，它以在 GPL 第3版之上附加应用一系列许可的方式表现。
3、协议特点：
LGPL和GPL不同，GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同，LGPL允许商业软件通过引用(link)的方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
4、LGPL的发展和分析：
从第一版的 L 表示 Library 的含义以及其版本号直接和GPL保持一致(第一版就是2.0)可知，该协议是GPL的补充协议，是一个主要为开源类库使用设计的开源协议，因为FSF逐渐意识到，GPL协议的强制传染性在某些场景下太过苛刻，会阻碍开源产品被更广泛的传播和使用，实际上很多软件开发过程中使用开源软件的场景，仅仅是把某个开源软件当做底层的库来引用，针对此种场景，FSF在1991年发布GPL第二版时，发布了LGPL第一版。
LGPL的含义可以理解为：它允许企业与软件开发者将LGPL授权的软件以依赖库链接的形式集成至他们自己的软件内（即使该软件是私有软件也被允许），同时不会受到类似于GPL传染特性的许可证强制对软件开源的限制。但如果修改LGPL协议的代码而产生的衍生代码，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。
采用LGPL的项目本身虽然仍有“Copyleft”的限制条件，但这些限制不会感染到仅仅只链接到本项目的软件。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。LGPL为了在GPL与其他许可式许可证之间获取折衷，常被用于一些GNU程序库，亦可使用于独立存在的应用程序中，比较有名的例子为 Mozilla 跟 http://OpenOffice.Org。
三、MPL：
1、概念：
MPL，即 Mozilla公共许可证，是 Mozilla Public License 的简称，由Mozilla基金会开发并维护。
2、版本演进历史：
第一版，1.0版本，1998年发布。
第二版，1.1版本，其主要变更是理清了关于专利部分的条款，以及允许多个许可证之间共存。
第三版，2.0版本，2012年1月3日发布。该版本使许可协议更加清晰，更加方便应用，同时也兼容于GPL及Apache许可证。
从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产品线许可，还有LibreOffice 4.0（同时使用LGPLv3）。
四、BSD 许可证：
1、概念：
BSD 许可协议，即 Berkeley Software Distribution license 的简称，是由加州大学伯克利分校发布并维护的开源软件许可证。BSD许可证是自由软件中使用最广泛的许可协议之一。
2、两个概念：
BSD：人们常说的BSD，指的是 Berkeley Software Distribution，即伯克利软件套件，是加州大学伯克利分校在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 Hoskins 删除了BSD许可证的第三条。从此以后，自由软件作者就可以方便地采用BSD许可证下的软件，从而跟GPL下的作品融合。
原来的许可证有时被称为“BSD-old”（老BSD）或“4-clause BSD”（四句版BSD），当前的BSD许可证有的被称为“BSD-new”（新BSD）、“revised BSD”（修订的BSD）或“3-clause BSD”（三句版BSD）。
5、协议分析：
当发布使用了BSD协议的代码或以BSD协议代码为基础做二次开发自己的产品时，需满足以下三个条件：
- 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
- 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
- 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD协议鼓励项目代码共享，但需要尊重作者的著作权。BSD协议由于允许使用者修改和重新发布代码，也允许在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
很多公司在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。遵守BSD 协议的软件，允许用作商业用途，甚至可按照专属许可证进行再发布。
五、MIT 协议：
1、概念：
MIT 许可协议：即 The MIT License，该许可协议之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称“X许可协议”（X License）或“X11许可协议”（X11 License）。
2、版本演进历史：
1988，由自麻省理工学院(MIT)发布。
3、协议特点：
MIT许可协议是许多软件许可条款中被广泛使用的其中一种。与其他常见的软件许可协议（如GPL、LGPL、BSD）相比，MIT是相对宽松的软件许可协议，赋予软件被许可人更大的权利与更少的限制。
4、协议分析：
- 被许可人权利：被许可人有权利使用、复制、修改、合并、出版发行、散布、再许可和/或贩售软件及软件的副本，及授予被供应人同等权利，惟服从以下义务。
- 被许可人义务：在软件和软件的所有副本中都必须包含以上著作权声明和本许可声明。
5、其他重要特性：
- 此许可协议并非属copyleft的自由软件许可协议条款，允许在自由及开放源代码软件或非自由软件（proprietary software）所使用。
- MIT的内容可依照软件代码著作权者的需求更改内容，这也是MIT与BSD本质上的不同处。
- MIT许可协议可与其他许可协议并存。MIT条款也是自由软件基金会（FSF）所认可的自由软件许可协议条款，与GPL兼容。
有许多团体均采用MIT许可证，例如著名的SSH连线软件PuTTY与X窗口系统、Expat、Mono开发平台库、Ruby on Rails、Lua等等也都采用MIT许可协议。
六、Apache 许可协议：
1、概念：
Apache许可证，即 Apache License，是一个由Apache软件基金会(ASF)发布的自由软件许可证。
Apache许可证最初为 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、协议分析说明：
如果声明文本文件是作为原始作品发布的一部分，则派生作品必须包含该通知文本文件的可读副本，可以是文档或显示在软件中。
声明文件的内容不会修改许可证，因为它们仅用于提供信息，并且可以在许可证文本中添加更多属性声明，前提是这些声明不能被理解为修改许可证。修改可能有适当的著作权声明，并可能为修改提供不同的许可条款。
七、许可证的对比与总结：
对于一个开源协议来说，规定得太宽松，会导致作者丧失对开源软件的很多权利，规定的太严格，又不利于开源软件的使用和传播。用一张图总结以上介绍的几个主流开源许可证的权限宽松情况：
开源协议的权限解析(二)
我们在选择使用开源软件、或者准备开源自己的软件时，一定要明白自己的用途，选择合适的许可证。希望我们站在巨人肩膀上前行的同时，不忘用法律的武器来为我们自身保驾护航。