许可证大检阅
据IDC最新发布的报告《中国Linux市场2009—2013年预测与分析》显示了2008年中国Linux总体市场收入增长率为26%，随着Linux在市场营销上的巨大成功，开源软件走进了公众的视野。在我国，开源软件的技术价值、应用价值和管理价值也逐步得到人们的认可，特别是为了发展民族软件产业和抵制大公司垄断，在政府、企业和一些有识之士的共同推动下，开源软件在中国也有了相当高的知名度。那么是否软件一开源就万事大吉，可以恣意妄为了呢?答案并不是这样。在开源领域，有着许多不同的知识产权许可证，每一个许可证都有着自己的特点及严格的规定，下面将对一些应用比较广泛的许可证分别进行分析。
一、GPL许可证
GPL许可证是General Public License的缩写。GPL许可证是自由软件联盟GNU开源软件许可证的一种，是开源软件领域最富盛名的一种许可证。同时，GPL许可证也是开源软件领域对被许可人权利限制最严的。
GNU自由软件之父Richard Stallman在倡导自由软件联盟计划时，从软件的版权许可协议人手，创设了一种与其开源软件发展相适应的“通用公共许可协议”，凡想加入GNU的软件著作人都要接受这份许可协议，其宗旨就是保证用户有无限复制和修改的权利。在GPL导言部分中，对自由软件和知识产权的相关问题进行了论述。
GPL “自由” 的法律含义
开源软件这一定义的来源是从技术角度，而自由软件这一定义本身就是版权意义上的范畴。自由软件的“自由” 体现为通过版权许可给予的自由，而不是自由的没有知识产权。也就是说， 自由软件不是没有版权，它首先是承认软件的版权—— 软件有原始的版权所有者，然后纳入自由软件的版权许可约束，使每个人在维持该许可的条款不变的情况下，都有权复制、修改和发布软件或其衍生的工作，这就是所谓的自由软件的自由理念。
GPL与自由软件的版权许可
对于普通的商业软件，软件开发商与使用者之间一般都会设立软件使用许可协议，即“一般商业许可”(General Business License，GBL)。这种许可协议一般由开发商单方拟订，用户接受协议是使用软件的前提，而获得许可的前提是支付费用购买软件产品。其许可条款一般按照版权法或专门的软件保护条例，或者通过双方合意达成略高于版权法和软件保护条例保护标准的软件许可使用条款。面对于这种显然不适合自由软件的GBL，Richard在倡导自由软件联盟计划时，从软件的版权许可协议人手，创设了一种与自由软件发展相适应的GPL许可证，凡想加入GNU的软件著作人都要接受这份许可协议，其宗旨就是保证用户有无限复制和修改的权利。更有趣的是，相对于“著作权”(CopyRight)这一名词，Richard新造了一个词，将这种许可协议叫做“CopyLeft”。当然，GPL许可证既然是一种软件知识产权的保护方式，它并不排斥软件开发者从软件中获取利益，只是盈利的方式有所改变：从过去依赖软件的销售，转向主要提供软件及信息服务。而且，现有商业软件嫁接到GNU/Linux等自由软件上时，也不一定非要公布源代码和提供免费，这意味着，自由软件可以与商业软件共存。
GPL与软件专利
一人或一个单位将一项软件技术申请为专利，他人即使是独立思考和完成的软件，只要涵盖专利的必要技术特征，就不得使用，否则构成侵犯专利权。软件公司所开发的软件，在不知不觉中就成了侵犯专利权的牺牲品。鉴于此，许多软件组织已发出了反对软件专利的呼声。GNU自由软件受到专利的威胁来自两个方面：一是不受GPL约束的第三人拥有某项软件专利，而自由软件的原始开发者或后续修改者在程序或其衍生作品上同样使用了这项技术，二是自由软件的再发布者以个人名义将自由软件中的某项技术获得专利，事实上将自由软件变为私有。对于后一个专利问题，GPL有权力约束专利申请人。GPL明确地规定：要么申请到专利后允许任何人自由使用(这等于没有专利)，要么不准许有专利。对于第一个专利问题，GPL许可证是无权约束专利权人的， 而且如果在该专利有效区域内发布该自由软件， 可能会导致专利侵权责任。对于这个情况，GPL许可证做出了无奈的规定：“如果由于法院判决或专利侵权的指控或任何其他原因(不限于专利纠纷)，强加于你的限定条件(不管时法院判决、协议或其他)和许可证的限定条件有冲突，你不能因此而脱离本许可证条款的约束。在你不能同时满足本许可争规定的义务及其他相关的义务时，结果只能是你根本不得发布程序。例如，如果某一专利许可不允许所有那些直接或间接从你哪里接受副本的人们在不付专利费的情况下重新发布程序，惟一能同时满足两方面要求的办法是完全停止发布程序。”在GPL的导言部分中，还专门有一项关于自由软件可否申请软件专利的条款“鉴于任何自由软件时刻处于软件专利的威胁之下，我们希望能避免这种情况：自由软件的再传播者在实施过程中使得这项软件程序获得专利独占权，正是基于此目的，我们明确地要求承诺任何自由软件可以去获得专利授权的前提是一旦获得软件专利授权必须向所有的人以符合自由软件使用条件的标准许可使用该专利，否则就不可去申请软件专利。”GPL也考虑到了更为严酷的情况：在某些国家由于专利问题， 自由软件的发布和使用受到限制。这种情况下，原始版权人可以增加限制发布地区的条款，将这些国家明确排除在外。针对开源软件本身，从这里可以看出GPL多少是排斥软件专利的。
二、LGPL许可证
LGPL许可证是LESSER GENERAL PUBLIC LICENSE的简写。也叫LIBRARY GENERAL PUBLIC LICENSE， 中文译为“较宽松公共许可证”或者“函数库公共许可证”。该许可证适用于一些由自由软件基金会与其它决定使用此许可证的软件作者所特殊设计的软件软件包--比如函数库(即LIBRARY)。
LGPL许可证的特点
LGPL许可证，也是自由软件联盟GNU开源软件许可证的一种，大部分的GNU软件，包括一些函数库，是受到原来的G P L许可证保护的。而LGPL许可证，适用于特殊设计的函数库，且与原来的通用公共许可证有很大的不同，给予了被许可人较为宽松的权利，所以叫“较宽松公共许可证”。在特定的函数库中使用它，以准许非自由的程序可以与这些函数库连结。
当一个程序与一个函数库连结，不论是静态连结或使用共享函数库，二者的结合可以合理地说是结合的作品，一个原来的函数库的衍生品。因此，原来的通用公共许可证只有在整个结合品满足其自由的标准时，才允许连结。较宽松通用公共许可则以更宽松的标准允许其它程序代码与本函数库连结。例如，在少数情况下，可能会有特殊的需要而鼓励大家尽可能广泛地使用特定的函数库，因而使它成为实际上的标准。为了达到此目标， 必须允许非自由的程序使用此函数库。一个较常发生的情况是，一个自由的函数库与一个被广泛使用的非自由函数库做相同的工作，在此情况下，限制只有自由软件可以使用此自由函数库不会有多少好处，故我们使用了LGPL许可证。在其他情况下，允许非自由程序使用特定的函数库，可以让更多的人们使用自由软件的大部分。例如，允许非自由程序使用GNUC函数库，可以让更多的人们使用整个GNU作业系统，以及它的变形，GNU／Linux操作系统。尽管LGPL许可证对使用者的自由保护是较少的，但它却能确保与此函数库连结的程序的使用者拥有自由，而且具有使用修改过的函数库版本来执行该程序的必要方法。
三、MPL许可证
MPL是The Mozilla Public License的简写，是1998年初Netscape的Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA认定的开源软件许可证)。但是，相比而言MPL还有以下几个显著的不同之处：
◆ MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来， 以保证其他人可以在MPL的条款下共享源代码。但是，在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。
◆ MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
◆ 对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人，并书面向公众免费许可这些源代码)，也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
◆ 对源代码的定义而在MPL (1．1版本)许可证中，对源代码的定义是：“源代码指的是对作品进行修改最优先择取的形式，它包括：所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’(原文为‘Script’)，或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
◆ MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。
四、BSD许可证
BSD许可证原先是用在加州大学柏克利分校发表的各个4.4BSD，4.4BSD-Lite版本上面(BSD是Berkly Software Distribution的简写)的，后来也就逐渐沿用下来。1979年加州大学伯克利分校发布了BSD Unix，被称为开放源代码的先驱，BSD许可证就是随着BSD Unix发展起来的。BSD许可证现在被Apache和BSD操作系统等开源软件所采纳。相较于GPL许可证和MPL许可证的严格性，BSD许可证就宽松许多了，一样是只需要附上许可证的原文，不过比较有趣的是，它还要求所有进一步开发者将自己的版权资料放上去，所以拿到以BSD许可证发行的软件可能会遇到一个小状况，就是这些版权资料许可证占的空间比程序还大。
五、QPL许可证
QPL是The Qt Public License的简称，是挪威一家机构创设的。QPL许可证的基本要求是获得源代码、修改源代码，并可将修改从原始代码中分离出来，修改可以按照作者的意愿被组合到新版本中，二进制代码可以和原始代码同名，这一点对于动态连接库来说尤其重要，任何人都可以修正错误，这对于系统的发布者来说很关键，修改过的软件可以按照满足QPL许可证基本要求的任何开源软件许可证进行发布。
六、QNCL许可证
QNCL许可证是Qt NonCommercial License的简称，是QPL许可证的“兄弟版”，就像GPL许可证与LGPL许可证的关系一样，QNCL许可证比QPL许可证更严格一些。在修改和发布方面的规定，QNCL$~可证与QPL许可证是一样的，差异就在于软件的范围方面，或者说在连接方面。QNCL许可证规定“假如一个应用程序给你提供了一个入口，使你有权使用QNCL许可证下的软件的功能开发程序、重复使用程序的某一部分或其他软件的某一部分，那么对该应用程序的使用视为是使用QNCL许可证下的软件的行为，该应用程序应受到QNCL许可证的约束”。QNCL许可证比QPL许可证更严格之处在于，QNCL许可证像GPL许可证那样，完全禁止根据本许可证得到的开放源码软件与其他非系统库函数连接的软件以其
他许可方式一起发布。
七、Jabber许可证
Jabber许可证的全称是Jabber Open Source License，由美国Jabber．Com，Inc．公司提供。Jabber许可证在源代码的复制、发行规定方面基本上和其他许可证没有什么特别，但有一些细节规定值得借鉴：
◆ 可以将通过该许可证获得的源代码及修改过的源代码与其他类型的不受该许可证约束的代码结合， 以新产品的形式发布，只要其中经该许可证获得的源代码及修改过的源代码能以与该许可证的要求类似的、符合OSI认证的其他开源软件许可证的方式发布。
◆ 明确了需将源代码置于公众可以得到的状态的时间至少应为12个月。
◆ 第三方对法定权利的声明。假如使用者发现通过本许可证获得的源代码及应用程序接口中有一方拥有的知识产权， 应单独在源码的发布时冠以“LEGAL”为抬头的声明， 写明知识产权权利要求的细节， 提请源代码的接受者知道自己获得了哪些知识产权的授权，让源码的接受者知道如何与知识产权权利人联系。
◆ 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼。
八、Common许可证
Common许可证的全称是Common Public License。在满足OSIA开源软件许可证认证标准的前提下，Common许可证还有一些细节性的规定值得参考：
◆ 明确了专利授权。一般的开源软件都明确源代码的版
权人将自己的修改权、复制权等版权权利向公众许可，但保留署名权，而Common许可证在此基础上还明确假如源代码中含有专利权，源代码专利权人将复制、使用的专有权利向公众许可。
◆ 规定可以将源代码及修改过的源代码与其他类型的不受本许可证约束的代码结合，以新产品的形式发布， 只要其中经该许可证获得的源代码及修改过的源代码能按该许可证的要求发布即可。
◆ 细化了该许可证终止的情形，包括发生专利侵权诉讼。
◆ 明确了一个独立承担责任的原则，就是假如按该许可证使用源代码的使用者将获得的源代码应用于商业使用，那么他就要对在商业应用中出现的由于使用该源代码程序而产生的侵权诉讼承担完全责任。这一条规定是比较特殊的，绝大多数开源软件许可证都不这么要求。
九、IBM许可证
IBM许可证的全称是IBM Public License。在满足OSIA开源软件许可证认证标准的前提下，IBM许可证还有如下一些细节性规定：
◆ 明确了专利授权。一般的开源软件都明确源代码的版权人将自己的修改权、复制权等版权权利向公众许可，但保留署名权，而IBM许可证在此基础上还明确假如源代码中含有专利权，源代码专利权人将复制、使用的专有权利向公众许可。
◆ 细化了该许可证终止的情形，包括不按该许可证的要求发布和使用源代码、发生专利侵权诉讼等。
◆ 像Common许可证一样，IBM许可证也明确了独立承担责任原则，即假如按该许可证使用源代码的使用者将获得的源代码应用于商业使用，那么他就要对在商业应用中出现的、由于使用该源代码程序而产生的侵权诉讼承担完全责任。
本文出自 “李晨光原创技术博客” 博客，转载请与作者联系！
