常见的开源软件许可证
常见的开源软件许可证
OSIA发布的开源软件许可证(The Approved Licenses) 目前(2006/3/26)共58种，详细
列表可
以查看：http://www.gnu.org/philosophy/license-list.html 除了大家比较熟悉的GPL协议之外，开源界还有很多许可证，如LGPL许可证、BSD许可证等，下面就来一一介绍。
1.GPL
GNU General Public License，简称 GPL 。GPL 既是一个软件许可证，又是一份政治宣言。由于 GPL 在一些法律教授的协助下完成，因而要比其他的同类许可证写得好得多。 GPL 的文本不是 GPL 之下的程序自身。它的许可证很简单：准许任何人复制和发行未经任何改动的许可证文本的拷贝。但对它进行改动是不允许的。开源软件许可证的文本通常不是开源软件本身，这点很重要。显然，如果任何人都可以修改许可证，那么许可证也就不能提供任何保护了。 GPL 的条款符合开源软件的定义。 GPL 并不需要开源软件定义中的第四点“作者源代码的完整性”中的任何条款。 GPL 不允许私自对程序进行更改。更改后的程序必须在 GPL 之下发行。当然，一个 GPL 化的程序的作者愿意接受别人的改进，包括商业公司为满足自己的需要而进行的更改。GPL 不允许将 GPL 化的程序合并尽到一个所有权程序中。 GPL 对所有权程序的定义是：许可证中所赋予的权力不如 GPL 多的任何一个程序。 GPL 也存在一些漏洞。它允许适用于不完全都是开源软件的程序中。软件库通常是与编译器或你正在使用的操作 系统一起发行的。它可能与一个已经 GPL 化的软件相联系，结果成为一个部分自由的程序。版权所有者通常就是程序的作者，他将 GPL 用于程序上而有权违反他自己的许可证。
2.LGPL许可证
LGPL许可证是LESSER GENERAL PUBLIC LICENSE的简写，也叫LIBRARY GENERAL PUBLIC LICENSE，中文译为“较宽松公共许可证”或者“函数库公共许可证”。该许可证适用于一些由自由软件基金会与其它决定使用此许可证的软件作者所特殊设计的软件软件包─比如函数库（即Library）。GNU Library General Public License，简称 LGPL ，是 GPL 的派生物。它是为软件库而设计的。与 GPL 不同，LGPL 化的程序可以合并到专有版权程序中。与 Linux 系统一起提供的 C 语言库就是 LGPL 的一个实例。它可被用于建立一个专有版权程序，否则的话 Linux 就只对自由软件作者有用。 LGPL 化的程序可以在任何时候转换成 GPL 化的程序。一旦作出这种转换，就不能再转换回 LGPL ，或由它派生的 LGPL 化的程序了。 尽管LGPL许可证对使用者的自由保护是较少的，但它却能确保与此函数库连结的程序的使用者拥有自由，而且具有使用修改过的函数库版本来执行该程序的必要方法。
3.NPL 和 MPL
Netscape Public License，简称 NPL ，是当 Netscape 准备生产他们的 Netscape 浏览器开源软件时开发的。Netscape 为他们自己的产品保留了“Navigator”商标。 NPL 的一个重要的特征是它给予 Netscape 专门的特权，而不包括其他的任何人。当你对他们的软件进行更改后，Netscape 有对这些更改重新发放许可证的特权。他们可将这些更改据为己有，然后再进行改进，却拒绝给你最终的结果。这一条款在当时是必要的，因为当 Netscape 准备加入开源软件时，它与别的公司已经有合同，承诺在非开源软件许可证下向他们提供 Navigator 。
Netscape 又开发了 Mozilla Public License，即 MPL 。MPL 与 NPL 很相似，但不包含循序 Netscape 对别人做的修改再发放许可证的内容。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同。MPL 授权对于“发行”的更改仍以同样 MPL 版权下进行发布，这样使得它可用于返还该项目。“发行”被定义为以源代码发布的文件。这很重要，因为它允许公司增加一个与专有代码库的接口，而不需授权其他的代码库具有 MPL 版权――只授权该接口具有 MPL 。这样这个软件可以或多或少地组合到商业软件环境中。
4.BSD许可证
BSD许可证原先是用在加州大学柏克利分校发表的各个4.4BSD/4.4BSD-Lite版本上面（BSD是Berkly Software Distribution的简写）的，后来也就逐渐沿用下来。1979年加州大学伯克利分校发布了BSD Unix，被称为开放源代码的先驱，BSD许可证就是随着BSD Unix 发展起来的。BSD许可证现在被 Apache和BSD操作系统等开源软件所采纳。 相较于GPL许可证和MPL许可证的严格性，BSD许可证就宽松许多了，一样是只需要附上许可证的原文，不过比较有趣的是，它还要求所有进一步开发者将自己的版权资料放上去，所以拿到以BSD许可证发行的软件可能会遇到一个小状况，就是这些版权资料许可证占的空间比程序还大。
5.QPL许可证和QNCL许可证
QPL是The Qt Public License的简称，是挪威一家机构创设的。QPL许可证的基本要求是获得源代码、修改源代码，并可将修改从原始代码中分离出来;修改可以按照作者的意愿被组合到新版本中;二进制代码可以和原始代码同名，这一点对于动态连接库来说尤其重要;任何人都可以修正错误，这对于系统的发布者来说很 关键;修改过的软件可以按照满足QPL许可证基本要求的任何开源软件许可证进行发布。
QNCL许可证是Qt Non Commercial License的简称，是QPL许可证的“兄弟版”，就像GPL许可证与LGPL许可证的关系一样，QNCL许可证比QPL许可证更严格一些。 在修改和发布方面的规定，QNCL许可证与QPL许可证是一样的，差异就在于软件的范围方面，或者说在连接方面。QNCL许可证规定“假如一个应用程序给你提供了一个入口，使你有权使用QNCL许可证下的软件的 功能开发程序、重复使用程序的某一部分或其他软件的某一部分，那么对该应用程序的使用视为是使用QNCL许可证下的软件的行为，该应用程序应受到QNCL许可证的约束”。QNCL许可证比QPL许可证更严格之处在于，QNCL许可证像GPL许可证那样，完全禁止根据本许可证得到的开放源码软件与其他非系统库函数连接的软件以其他许可方式一起发布。
6.Jabber许可证
Jabber许可证的全称是Jabber Open Source License，由美国Jabber.Com, Inc.公司提供。Jabber许可证在源代码的复制、发行规定方面基本上和其他许可证没有什么特别，但有一些细节规定值得借鉴: 可以将通过该许可证获得的源代码及修改过的源代码与其他类型的不受该许可证约束的代码结合，以新产品的形式发布，只要其中经该许可证获得的源代码及修改过的源代码能以与该许可证的要求类似的、符合OSI认证的其他开源软件许可证的方式发布。 明确了需将源代码置于公众可以得到的状态的时间至少应为12个月。 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼。
7. IBM许可证
IBM许可证的全称是IBM Public License。在满足OSIA开源软件许可证认证标准的前提下，IBM许可证还有如下一些细节性规定: 明确了专利授权。一般的开源软件都明确源代码的版权人将自己的修改权、复制权等版权权利向公众许可，但保留署名权，而IBM许可证在此基础上还明确假如源代码中含有专利权，源代码专利权人将复制、使用的专有权利向公众许可。 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼等。
8.MIT 许可证
MIT许可证的全称是MIT license，是Massachusetts Institute of Technology (MIT) 公司建立的基于BSD许可证的，简单的说，MIT 许可证比 GPL 更加自由。类似与 BSD 许可证，但也比 BSD 许可证更为宽松。
9.SISSL许可证
ISSL许可证的全称是The Sun Industry Standards Source License 是sun公司建立的 ，中文名称Sun工业标准源码许可证。SISSL是OpenOffice.org社区为了在商业领域中 推广使用OpenOffice.org，根据 企业 用户、独立软件提供商、软件集成商等的需求，特别设计的软件许可证。该许可证要求使用者遵循OpenOffice.org XML文件格式和API规范一致和开放的特点，其目的是在保证OpenOffice.org及其衍生软件在保持兼容性的基础上，给商业伙伴最大程度地定制软件的自由。SISSL是经过开源软件促进会（Open Source Initiative）认证的开源软件许可证。
10.Apache许可证
Apache许可证是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码 共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似： 需要给代码的用户一份Apache 许可证 ， 如果你修改了代码，需要再被修改的文件中说明。 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache 许可证。你可以在Notice中增加自己的许可，但不可以表现为对Apache 许可证构成更改。 Apache 许可证也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
11.CPL许可证
CPL许可证的全称是Common Public Liecense， CPL 是 IBM 提出的并通过了OSI（Open Source Initiative）批准的开源协议。主要用于一些IBM 或跟 IBM 相关的开源软件 /项目中。如 很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等。 CPL也是一项对商业应用友好的协议。它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布，这点跟BSD 很类似，也属于自由度比较高的开源协议。
表1 是以上介绍的开源许可证的比较
表1开源许可证异同对比
相同点
1、承认版权；
2、发布的义务――将获得的源代码再发布；
3、对发布的源代码的要求――须保证源代码的完整和可以被获得；
4、允许修改――可以根据获得的源代码产生演绎作品；
5、没有担保：
不同点
是否允许同其他非开放源代码软件代码混合
是否可以不公开对源代码的修改
是否明确了专利许可授权
是否明确了专利侵权诉讼导致许可证协议终止
是否明 确禁止与函数库连接
是否只能按本许可证发布源代码
GPL 许可证
否
否
否
否
是
是
LGPL 许可证
是
否
否
否
否
否
BSD 许可证
是
是
否
否
否
否
NPL 许可证
是
是
否
?
否
否
MPL 许可证
是
是
否
否
否
否
QPL 许可证
是
是
否
否
否
否
QNCL 许可证
否
是
否
否
否
否
APACHE 许可证
是
是
否
否
否
否
SISSL 许可证
是
否
是
是
否
※
Jabber 许可证
是
是
否
是
否
否
IBM 许可证
是
是
是
是
否
否
CPL许可证
是
是
是
是
否
否
说明：
“#”指对于原始获得的源代码及修改的源代码，必须按本许可证及本许可证的后续版本发布，但是可以将源代码及修改过的源代码与其他类型的不受本许可证约束的代码结合，以新产品的形式发布。
“不担保”（即No Warranty）条款： 由于源代码程序准予免费使用，在一般情况下，对程序没有担保。除非另有书面说明，版权所有者或其他提供程序的人们“一样”不提供任何类型的担保。如果程序出现缺陷，被许可人承担所有必要的服务，修复和改正的费用。
以查看：http://www.gnu.org/philosophy/license-list.html 除了大家比较熟悉的GPL协议之外，开源界还有很多许可证，如LGPL许可证、BSD许可证等，下面就来一一介绍。
1.GPL
GNU General Public License，简称 GPL 。GPL 既是一个软件许可证，又是一份政治宣言。由于 GPL 在一些法律教授的协助下完成，因而要比其他的同类许可证写得好得多。 GPL 的文本不是 GPL 之下的程序自身。它的许可证很简单：准许任何人复制和发行未经任何改动的许可证文本的拷贝。但对它进行改动是不允许的。开源软件许可证的文本通常不是开源软件本身，这点很重要。显然，如果任何人都可以修改许可证，那么许可证也就不能提供任何保护了。 GPL 的条款符合开源软件的定义。 GPL 并不需要开源软件定义中的第四点“作者源代码的完整性”中的任何条款。 GPL 不允许私自对程序进行更改。更改后的程序必须在 GPL 之下发行。当然，一个 GPL 化的程序的作者愿意接受别人的改进，包括商业公司为满足自己的需要而进行的更改。GPL 不允许将 GPL 化的程序合并尽到一个所有权程序中。 GPL 对所有权程序的定义是：许可证中所赋予的权力不如 GPL 多的任何一个程序。 GPL 也存在一些漏洞。它允许适用于不完全都是开源软件的程序中。软件库通常是与编译器或你正在使用的操作 系统一起发行的。它可能与一个已经 GPL 化的软件相联系，结果成为一个部分自由的程序。版权所有者通常就是程序的作者，他将 GPL 用于程序上而有权违反他自己的许可证。
2.LGPL许可证
LGPL许可证是LESSER GENERAL PUBLIC LICENSE的简写，也叫LIBRARY GENERAL PUBLIC LICENSE，中文译为“较宽松公共许可证”或者“函数库公共许可证”。该许可证适用于一些由自由软件基金会与其它决定使用此许可证的软件作者所特殊设计的软件软件包─比如函数库（即Library）。GNU Library General Public License，简称 LGPL ，是 GPL 的派生物。它是为软件库而设计的。与 GPL 不同，LGPL 化的程序可以合并到专有版权程序中。与 Linux 系统一起提供的 C 语言库就是 LGPL 的一个实例。它可被用于建立一个专有版权程序，否则的话 Linux 就只对自由软件作者有用。 LGPL 化的程序可以在任何时候转换成 GPL 化的程序。一旦作出这种转换，就不能再转换回 LGPL ，或由它派生的 LGPL 化的程序了。 尽管LGPL许可证对使用者的自由保护是较少的，但它却能确保与此函数库连结的程序的使用者拥有自由，而且具有使用修改过的函数库版本来执行该程序的必要方法。
3.NPL 和 MPL
Netscape Public License，简称 NPL ，是当 Netscape 准备生产他们的 Netscape 浏览器开源软件时开发的。Netscape 为他们自己的产品保留了“Navigator”商标。 NPL 的一个重要的特征是它给予 Netscape 专门的特权，而不包括其他的任何人。当你对他们的软件进行更改后，Netscape 有对这些更改重新发放许可证的特权。他们可将这些更改据为己有，然后再进行改进，却拒绝给你最终的结果。这一条款在当时是必要的，因为当 Netscape 准备加入开源软件时，它与别的公司已经有合同，承诺在非开源软件许可证下向他们提供 Navigator 。
Netscape 又开发了 Mozilla Public License，即 MPL 。MPL 与 NPL 很相似，但不包含循序 Netscape 对别人做的修改再发放许可证的内容。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同。MPL 授权对于“发行”的更改仍以同样 MPL 版权下进行发布，这样使得它可用于返还该项目。“发行”被定义为以源代码发布的文件。这很重要，因为它允许公司增加一个与专有代码库的接口，而不需授权其他的代码库具有 MPL 版权――只授权该接口具有 MPL 。这样这个软件可以或多或少地组合到商业软件环境中。
4.BSD许可证
BSD许可证原先是用在加州大学柏克利分校发表的各个4.4BSD/4.4BSD-Lite版本上面（BSD是Berkly Software Distribution的简写）的，后来也就逐渐沿用下来。1979年加州大学伯克利分校发布了BSD Unix，被称为开放源代码的先驱，BSD许可证就是随着BSD Unix 发展起来的。BSD许可证现在被 Apache和BSD操作系统等开源软件所采纳。 相较于GPL许可证和MPL许可证的严格性，BSD许可证就宽松许多了，一样是只需要附上许可证的原文，不过比较有趣的是，它还要求所有进一步开发者将自己的版权资料放上去，所以拿到以BSD许可证发行的软件可能会遇到一个小状况，就是这些版权资料许可证占的空间比程序还大。
5.QPL许可证和QNCL许可证
QPL是The Qt Public License的简称，是挪威一家机构创设的。QPL许可证的基本要求是获得源代码、修改源代码，并可将修改从原始代码中分离出来;修改可以按照作者的意愿被组合到新版本中;二进制代码可以和原始代码同名，这一点对于动态连接库来说尤其重要;任何人都可以修正错误，这对于系统的发布者来说很 关键;修改过的软件可以按照满足QPL许可证基本要求的任何开源软件许可证进行发布。
QNCL许可证是Qt Non Commercial License的简称，是QPL许可证的“兄弟版”，就像GPL许可证与LGPL许可证的关系一样，QNCL许可证比QPL许可证更严格一些。 在修改和发布方面的规定，QNCL许可证与QPL许可证是一样的，差异就在于软件的范围方面，或者说在连接方面。QNCL许可证规定“假如一个应用程序给你提供了一个入口，使你有权使用QNCL许可证下的软件的 功能开发程序、重复使用程序的某一部分或其他软件的某一部分，那么对该应用程序的使用视为是使用QNCL许可证下的软件的行为，该应用程序应受到QNCL许可证的约束”。QNCL许可证比QPL许可证更严格之处在于，QNCL许可证像GPL许可证那样，完全禁止根据本许可证得到的开放源码软件与其他非系统库函数连接的软件以其他许可方式一起发布。
6.Jabber许可证
Jabber许可证的全称是Jabber Open Source License，由美国Jabber.Com, Inc.公司提供。Jabber许可证在源代码的复制、发行规定方面基本上和其他许可证没有什么特别，但有一些细节规定值得借鉴: 可以将通过该许可证获得的源代码及修改过的源代码与其他类型的不受该许可证约束的代码结合，以新产品的形式发布，只要其中经该许可证获得的源代码及修改过的源代码能以与该许可证的要求类似的、符合OSI认证的其他开源软件许可证的方式发布。 明确了需将源代码置于公众可以得到的状态的时间至少应为12个月。 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼。
7. IBM许可证
IBM许可证的全称是IBM Public License。在满足OSIA开源软件许可证认证标准的前提下，IBM许可证还有如下一些细节性规定: 明确了专利授权。一般的开源软件都明确源代码的版权人将自己的修改权、复制权等版权权利向公众许可，但保留署名权，而IBM许可证在此基础上还明确假如源代码中含有专利权，源代码专利权人将复制、使用的专有权利向公众许可。 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼等。
8.MIT 许可证
MIT许可证的全称是MIT license，是Massachusetts Institute of Technology (MIT) 公司建立的基于BSD许可证的，简单的说，MIT 许可证比 GPL 更加自由。类似与 BSD 许可证，但也比 BSD 许可证更为宽松。
9.SISSL许可证
ISSL许可证的全称是The Sun Industry Standards Source License 是sun公司建立的 ，中文名称Sun工业标准源码许可证。SISSL是OpenOffice.org社区为了在商业领域中 推广使用OpenOffice.org，根据 企业 用户、独立软件提供商、软件集成商等的需求，特别设计的软件许可证。该许可证要求使用者遵循OpenOffice.org XML文件格式和API规范一致和开放的特点，其目的是在保证OpenOffice.org及其衍生软件在保持兼容性的基础上，给商业伙伴最大程度地定制软件的自由。SISSL是经过开源软件促进会（Open Source Initiative）认证的开源软件许可证。
10.Apache许可证
Apache许可证是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码 共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似： 需要给代码的用户一份Apache 许可证 ， 如果你修改了代码，需要再被修改的文件中说明。 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache 许可证。你可以在Notice中增加自己的许可，但不可以表现为对Apache 许可证构成更改。 Apache 许可证也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
11.CPL许可证
CPL许可证的全称是Common Public Liecense， CPL 是 IBM 提出的并通过了OSI（Open Source Initiative）批准的开源协议。主要用于一些IBM 或跟 IBM 相关的开源软件 /项目中。如 很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等。 CPL也是一项对商业应用友好的协议。它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布，这点跟BSD 很类似，也属于自由度比较高的开源协议。
表1 是以上介绍的开源许可证的比较
表1开源许可证异同对比
相同点
1、承认版权；
2、发布的义务――将获得的源代码再发布；
3、对发布的源代码的要求――须保证源代码的完整和可以被获得；
4、允许修改――可以根据获得的源代码产生演绎作品；
5、没有担保：
不同点
是否允许同其他非开放源代码软件代码混合
是否可以不公开对源代码的修改
是否明确了专利许可授权
是否明确了专利侵权诉讼导致许可证协议终止
是否明 确禁止与函数库连接
是否只能按本许可证发布源代码
GPL 许可证
否
否
否
否
是
是
LGPL 许可证
是
否
否
否
否
否
BSD 许可证
是
是
否
否
否
否
NPL 许可证
是
是
否
?
否
否
MPL 许可证
是
是
否
否
否
否
QPL 许可证
是
是
否
否
否
否
QNCL 许可证
否
是
否
否
否
否
APACHE 许可证
是
是
否
否
否
否
SISSL 许可证
是
否
是
是
否
※
Jabber 许可证
是
是
否
是
否
否
IBM 许可证
是
是
是
是
否
否
CPL许可证
是
是
是
是
否
否
说明：
“#”指对于原始获得的源代码及修改的源代码，必须按本许可证及本许可证的后续版本发布，但是可以将源代码及修改过的源代码与其他类型的不受本许可证约束的代码结合，以新产品的形式发布。
“不担保”（即No Warranty）条款： 由于源代码程序准予免费使用，在一般情况下，对程序没有担保。除非另有书面说明，版权所有者或其他提供程序的人们“一样”不提供任何类型的担保。如果程序出现缺陷，被许可人承担所有必要的服务，修复和改正的费用。