一、开源许可证的分类
开源许可证分为2种类型：宽松型和著佐权型。
1、宽松型(Permissive)：该类许可证往往只要求被许可方保留原作品的版权信息，对用户施加的限制较少，衍生软件可以成为私有软件，如Apache、MIT、BSD系列许可证。由于这类许可证允许衍生软件闭源，对商业化非常友好，因此广受欢迎。
2、著佐权型（copyleft）：也称为互惠型、强保护型，要求对软件的修改和扩展，必须按照获得该软件的许可证进行开源，旨在促进开发人员的合作，保护源代码的自由共享，如GPL系列许可证。对于强制开源的许可证，使用要慎重，因为违反开源许可证被起诉已经有很多判例。进一步，可以区分为强著佐权和弱著佐权，前者包括AGPL、SSPL、GPL许可证等；后者包括LGPL系列许可证、MPL许可证等。强著佐权要求对软件的修改和扩展，必须按照获得该软件的许可证进行开源，且不得违背原作品的限制条款。弱著佐权要求对软件的修改、重新分发必须按照获得该软件的许可证进行开源，但合并这些软件代码的大型作品可以成为私有作品。
二、GPL、AGPL、LGPL及MPL许可证解读及合规使用
1、GPL许可证
（1）概述
GPL（GNU General Public License，通用公共许可证）是一种著佐权许可证。基于GPL的软件允许商业化销售，但不允许封闭源代码。如果对遵循GPL的软件进行任何改动和/或再次开发并予以发布，只要包含了GPL的代码，则产品必须继承GPL协议，不允许封闭源代码。GPL先后发布了有3个版本，常用的GPL许可证为GPL v2 和GPL v3 。
（2）使用要求
A. 发布未修改的开源软件，应当保留完整的著作权和无担保责任的法律声明；
B. 发布修改过的开源软件，应当在源代码中明确标注修改的内容和日期；
C. 开源软件目标代码的分发，需要在同一物理介质上附随源代码；
D. 开源软件目标代码不能附随源代码的，须包含一份至少三年内有效的，承诺提供源代码的书面文件。并且提供源代码的价格不得超过实际发布源代码所需成本；
E. 修改和发布开源软件的，视为自动遵守GPL许可证约束；
F. 任何基于“受GPL许可证约束的开源软件”的覆盖作品、衍生作品和结合作品均受GPL许可证约束；
G. 以指定地点（如ftp）提供目标代码复制的，应当在相同地点提供源代码以供复制；
H. 在GPL v3中，不得禁止用户破解（或反编译）开源软件，以及不得限制用户破解（或反编译）开源软件的运行（GPLv3禁止Tivoization这样的程序，即用户不得利用用户或第三方禁止技术破解措施的权利来限制使用者使用或者修改程序）；
I. 在GPL v3中，用户不可以发起诉讼（包括联合诉讼和反诉）声称程序或其任何一部分侵犯了其任何专利权，否则用户在该开源程序授权下获取的专利权将自动终止。（专利报复条款）
2、AGPL许可证
AGPL（GNU Affero General Public License，Affero通用公共许可证）许可证是一种强著佐权许可证。该许可证可以说是对GPL的一次“查漏补缺”，它继承了GPL所有条款，并在此基础上增加了一条：如果其许可下的软件与用户通过网络进行交互，那么就需要提供源代码给用户，所有的修改也同样要提供给用户。AGPL和GPL协议是兼容的。
最初的Affero GPL基于GPLv2于2002年发布，其发布者并非自由软件基金会，而是一家名为Affero的初创软件公司。之后，自由软件基金会2007年基于GPLv3发布了自己版本的AGPLv3，并在名称中保留了Affero，以向这段历史致敬。目前，AGPLv3是使用较为广泛的版本。
GPL的义务仅在分发代码时才会被触发。这是因为“使用”并非版权的关注焦点，版权自诞生以来一直关注的是“复制”。从版权的英文copyright可知，版权一直以来都是一种涉及复制（copy）的权利。在传统行业中并未遇到大的问题，但是在云服务下，云服务厂商不再向用户提供（分发）软件的副本，因此，云服务厂商可以随意使用GPL代码而无需支付任何形式的成本，并且这一切都是合法的。为了应对该应用服务提供商漏洞（application service provider (ASP) loophole），AGPL规定，通过远程网络交互时也视为“分发”，需要提供源代码。
3、LGPL许可证
（1）概述
LGPL(GNU Lesser General Public License，宽通用公共许可证）是一种弱著佐权许可证，LGPL与GPL相比更为宽松，允许商业化销售，不允许封闭源代码。对遵循 LGPL的软件进行任何改动和/或再次开发并予以发布时，产品必须继承LGPL许可证，不允许封闭源代码。
LGPL许可证的初衷在于扩大开源组织库函数的影响力，使GNU库函数的广泛应用，成为事实的软件开发标准，因此LGPL允许商业软件在一定条件下使用GNU库函数，而不受开源的影响。LGPL许可证，适用于特殊设计的函数库。准许非自由的程序可以与这些函数库连结。在以LGPL发布的库的基础上开发新的库的时候，新的库必须以LGPL发布，但是如果仅仅是动态链接，那么则不受限制。
这个许可证以前被称为GNU库（Library）通用公共许可证。此许可证最新版本为“版本3”，2007年6月29日发布，较早的版本有2.0和2.1版。
详细信息可参考：
www.gnu.org/licenses/lgpl.html
（2）使用要求
A. 发布未修改的开源库函数，应当保留完整的著作权和无担保责任的法律声明；
B. 发布修改过的开源库函数，应当在源代码中明确标注修改的内容和日期；
C. 修改库函数文件中个别函数的，应当尽量保证其他函数功能的完整性；
D. 受LGPL约束的目标代码，发布时须明确注明：（a）库函数被引用；（b）被引用的库函数受LGPL许可证约束；（c）附带完整的LGPL许可证文本;
E. 开源库函数目标代码的分发，需要在同一物理介质上附随源代码；
F. 开源库函数目标代码不能附随源代码的，须包含一份至少三年内有效的，承诺提供源代码的书面文件。并且提供源代码的价格不得超过邮寄成本；
G. 以指定地点（如ftp）提供目标代码复制的，应当在相同地点提供源代码供复制；
H. 修改和发布开源库函数的，视为自动遵守LGPL许可证约束。
4、MPL许可证
（1）概述
MPL（The Mozilla Public License）是一种弱著佐权许可证，1998年初由Netscape的 Mozilla小组为其开源软件项目设计。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。
MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。MPL许可证允许在其授权下的源代码与开发者个人文件进行混合，闭源商用，但在MPL授权下的代码文件必须遵守MPL许可证，并且保持开源。
MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
MPL许可证有V1.1和V2两个版本。
详细信息可参考：https://mozilla.org/MPL/2.0/.
（2）使用要求
A. 源代码分发时必须包含MPL许可证，不得对许可证文本进行修改；
B. 分发目标代码时需要确保在同一物理分发媒介下，源代码文件可获得。
通过电子信息渠道分发代码的，对于原始版本须从版本发布之日起保留12个月，对于修订版本须从版本发布之日起保留6个月。MPL v2版本没有上述保留源代码的时间要求。
C. 分发过程中，对源代码进行修订了的，需要有文档明确记载修改的内容和时间，并标明原作者信息。
D. 基于MPL许可证源代码合入其他代码得到的衍生版本，如果合入其他代码需要第三方授权信息的，则应建立名称为“LEGAL”的文件进行详细说明授权途径，并随版本一起分发。
E. 将MPL许可证源代码合入其他代码得到的衍生版本，可以进行闭源商用。但必须确保MPL许可证覆盖下的源代码继续开源使用。
F.专利报复条款：若使用者（被授权人）提起诉讼，宣称程序原始开发者或贡献者的程序侵犯其任何一项专利权，那么根据MPL的规定，原始开发者或贡献者可以要求该提起诉讼的被授权人撤销控诉或是支付授权金，否则原有的专利授权将会终止。
本期上篇我们主要对GPL、AGPL、LGPL和MPL这四个许可证进行了解读，第二期（下）我们讲对Apache、MIT、BSD以及常见的开源许可证之间的兼容性关系进行分析。
开源许可证分为2种类型：宽松型和著佐权型。
1、宽松型(Permissive)：该类许可证往往只要求被许可方保留原作品的版权信息，对用户施加的限制较少，衍生软件可以成为私有软件，如Apache、MIT、BSD系列许可证。由于这类许可证允许衍生软件闭源，对商业化非常友好，因此广受欢迎。
2、著佐权型（copyleft）：也称为互惠型、强保护型，要求对软件的修改和扩展，必须按照获得该软件的许可证进行开源，旨在促进开发人员的合作，保护源代码的自由共享，如GPL系列许可证。对于强制开源的许可证，使用要慎重，因为违反开源许可证被起诉已经有很多判例。进一步，可以区分为强著佐权和弱著佐权，前者包括AGPL、SSPL、GPL许可证等；后者包括LGPL系列许可证、MPL许可证等。强著佐权要求对软件的修改和扩展，必须按照获得该软件的许可证进行开源，且不得违背原作品的限制条款。弱著佐权要求对软件的修改、重新分发必须按照获得该软件的许可证进行开源，但合并这些软件代码的大型作品可以成为私有作品。
二、GPL、AGPL、LGPL及MPL许可证解读及合规使用
1、GPL许可证
（1）概述
GPL（GNU General Public License，通用公共许可证）是一种著佐权许可证。基于GPL的软件允许商业化销售，但不允许封闭源代码。如果对遵循GPL的软件进行任何改动和/或再次开发并予以发布，只要包含了GPL的代码，则产品必须继承GPL协议，不允许封闭源代码。GPL先后发布了有3个版本，常用的GPL许可证为GPL v2 和GPL v3 。
| 版本 | 发布时间 | 简介 |
| GPL v1 | 1989年1月 | GPLv1中如果发布了可执行的二进制代码，就必须同时发布可读的源代码，并且在发布任何基于GPL许可的软件时，不能添加任何限制性的条款。 http://www.gnu.org/licenses/gpl-1.0.html |
| GPL v2 | 1991年6月 | 在GPLv2中所做的最大的改动就是增加了“自由还是死亡”（Liberty or Death）的条款。该条款规定，发布源于GPL的软件时，源代码应公开，如果规定只能以二进制代码的形式发布软件，那么使用者将根本无权发布该软件。 http://www.gnu.org/licenses/gpl-2.0.html |
| GPL v3 | 2007年6月 | 在所进行的修改中最重要的有四个：解决软件专利问题；与其他许可证的兼容性；一些概念的新定义（如发布、传播、源代码）；解决数字版权管理 (DRM) 问题。 http://www.gnu.org/licenses/gpl-3.0.html |
（2）使用要求
A. 发布未修改的开源软件，应当保留完整的著作权和无担保责任的法律声明；
B. 发布修改过的开源软件，应当在源代码中明确标注修改的内容和日期；
C. 开源软件目标代码的分发，需要在同一物理介质上附随源代码；
D. 开源软件目标代码不能附随源代码的，须包含一份至少三年内有效的，承诺提供源代码的书面文件。并且提供源代码的价格不得超过实际发布源代码所需成本；
E. 修改和发布开源软件的，视为自动遵守GPL许可证约束；
F. 任何基于“受GPL许可证约束的开源软件”的覆盖作品、衍生作品和结合作品均受GPL许可证约束；
G. 以指定地点（如ftp）提供目标代码复制的，应当在相同地点提供源代码以供复制；
H. 在GPL v3中，不得禁止用户破解（或反编译）开源软件，以及不得限制用户破解（或反编译）开源软件的运行（GPLv3禁止Tivoization这样的程序，即用户不得利用用户或第三方禁止技术破解措施的权利来限制使用者使用或者修改程序）；
I. 在GPL v3中，用户不可以发起诉讼（包括联合诉讼和反诉）声称程序或其任何一部分侵犯了其任何专利权，否则用户在该开源程序授权下获取的专利权将自动终止。（专利报复条款）
2、AGPL许可证
AGPL（GNU Affero General Public License，Affero通用公共许可证）许可证是一种强著佐权许可证。该许可证可以说是对GPL的一次“查漏补缺”，它继承了GPL所有条款，并在此基础上增加了一条：如果其许可下的软件与用户通过网络进行交互，那么就需要提供源代码给用户，所有的修改也同样要提供给用户。AGPL和GPL协议是兼容的。
最初的Affero GPL基于GPLv2于2002年发布，其发布者并非自由软件基金会，而是一家名为Affero的初创软件公司。之后，自由软件基金会2007年基于GPLv3发布了自己版本的AGPLv3，并在名称中保留了Affero，以向这段历史致敬。目前，AGPLv3是使用较为广泛的版本。
GPL的义务仅在分发代码时才会被触发。这是因为“使用”并非版权的关注焦点，版权自诞生以来一直关注的是“复制”。从版权的英文copyright可知，版权一直以来都是一种涉及复制（copy）的权利。在传统行业中并未遇到大的问题，但是在云服务下，云服务厂商不再向用户提供（分发）软件的副本，因此，云服务厂商可以随意使用GPL代码而无需支付任何形式的成本，并且这一切都是合法的。为了应对该应用服务提供商漏洞（application service provider (ASP) loophole），AGPL规定，通过远程网络交互时也视为“分发”，需要提供源代码。
3、LGPL许可证
（1）概述
LGPL(GNU Lesser General Public License，宽通用公共许可证）是一种弱著佐权许可证，LGPL与GPL相比更为宽松，允许商业化销售，不允许封闭源代码。对遵循 LGPL的软件进行任何改动和/或再次开发并予以发布时，产品必须继承LGPL许可证，不允许封闭源代码。
LGPL许可证的初衷在于扩大开源组织库函数的影响力，使GNU库函数的广泛应用，成为事实的软件开发标准，因此LGPL允许商业软件在一定条件下使用GNU库函数，而不受开源的影响。LGPL许可证，适用于特殊设计的函数库。准许非自由的程序可以与这些函数库连结。在以LGPL发布的库的基础上开发新的库的时候，新的库必须以LGPL发布，但是如果仅仅是动态链接，那么则不受限制。
这个许可证以前被称为GNU库（Library）通用公共许可证。此许可证最新版本为“版本3”，2007年6月29日发布，较早的版本有2.0和2.1版。
详细信息可参考：
www.gnu.org/licenses/lgpl.html
（2）使用要求
A. 发布未修改的开源库函数，应当保留完整的著作权和无担保责任的法律声明；
B. 发布修改过的开源库函数，应当在源代码中明确标注修改的内容和日期；
C. 修改库函数文件中个别函数的，应当尽量保证其他函数功能的完整性；
D. 受LGPL约束的目标代码，发布时须明确注明：（a）库函数被引用；（b）被引用的库函数受LGPL许可证约束；（c）附带完整的LGPL许可证文本;
E. 开源库函数目标代码的分发，需要在同一物理介质上附随源代码；
F. 开源库函数目标代码不能附随源代码的，须包含一份至少三年内有效的，承诺提供源代码的书面文件。并且提供源代码的价格不得超过邮寄成本；
G. 以指定地点（如ftp）提供目标代码复制的，应当在相同地点提供源代码供复制；
H. 修改和发布开源库函数的，视为自动遵守LGPL许可证约束。
4、MPL许可证
（1）概述
MPL（The Mozilla Public License）是一种弱著佐权许可证，1998年初由Netscape的 Mozilla小组为其开源软件项目设计。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。
MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。MPL许可证允许在其授权下的源代码与开发者个人文件进行混合，闭源商用，但在MPL授权下的代码文件必须遵守MPL许可证，并且保持开源。
MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
MPL许可证有V1.1和V2两个版本。
详细信息可参考：https://mozilla.org/MPL/2.0/.
（2）使用要求
A. 源代码分发时必须包含MPL许可证，不得对许可证文本进行修改；
B. 分发目标代码时需要确保在同一物理分发媒介下，源代码文件可获得。
通过电子信息渠道分发代码的，对于原始版本须从版本发布之日起保留12个月，对于修订版本须从版本发布之日起保留6个月。MPL v2版本没有上述保留源代码的时间要求。
C. 分发过程中，对源代码进行修订了的，需要有文档明确记载修改的内容和时间，并标明原作者信息。
D. 基于MPL许可证源代码合入其他代码得到的衍生版本，如果合入其他代码需要第三方授权信息的，则应建立名称为“LEGAL”的文件进行详细说明授权途径，并随版本一起分发。
E. 将MPL许可证源代码合入其他代码得到的衍生版本，可以进行闭源商用。但必须确保MPL许可证覆盖下的源代码继续开源使用。
F.专利报复条款：若使用者（被授权人）提起诉讼，宣称程序原始开发者或贡献者的程序侵犯其任何一项专利权，那么根据MPL的规定，原始开发者或贡献者可以要求该提起诉讼的被授权人撤销控诉或是支付授权金，否则原有的专利授权将会终止。
本期上篇我们主要对GPL、AGPL、LGPL和MPL这四个许可证进行了解读，第二期（下）我们讲对Apache、MIT、BSD以及常见的开源许可证之间的兼容性关系进行分析。