开源软件许可证的分类及比较
2010-07-12 13:39阅读：
该文刊载于《中国版权》（CSSCI源）2005年第5期，转载引用请注明出处。
摘要：开放源码软件许可证按其所属的利益群体可分为三类。第一类是由自由软件基金会颁发的许可证，有GPL、LGPL；第二类是由高等院校颁发的许可证，有BSD许可证、MIT许可证等；第三类是由商业公司发展的许可证，有MPL、IBM公共许可证等。对于不同特性的开放源码软件，可根据三类许可证各自的特点予以相应的采用。
关键词：开放源码；软件许可证；通用公共许可证
中图分类号：
文献标识码：A
文章编号：
以Linux为代表的开源软件在国内正成为民族软件的一支重要力量。与其他商业软件一样，开源软件实行的也是许可证形式的版权保护。只不过在以Windows为代表的传统专有软件中，许可证保护的是软件商基于封闭程序源代码而获得的垄断利益。而开源软件则希望通过开放源代码，在软件商和公众利益间取得一定的平衡。从国际上通行的各种开源软件来看，根据其所属的利益群体分为三类：第一类是由自由软件基金会颁发的许可证，有GPL、LGPL；第二类是由高等院校颁发的许可证，有BSD、MIT许可证等；第三类是由商业公司发展的许可证，有MPL许可证等。
一、自由软件许可证
自由软件基金会发布的GNU General Public License
[i]
（通用公共许可证，简称GPL）是目前最为流行的一份开源许可证。GPL之所以出名，不仅是因为它被Linux这样流行的操作系统所采用，更重要的它是一份关于软件自由的政治宣言。而且由于GPL是在一些法律教授的协助下完成的，具体条款的用词显得更准确，逻辑结构也更紧密，而被大多数开源软件项目所采用。
GPL首先关注的是软件自由这个话题：“大多数软件许可证决意剥夺你共享和修改软件的自由。相比之下，GNU通用公共许可证力图保证你共享和修改自由软件的自由。——保证自由软件对所有用户是自由的。”这表明GPL与传统的商业专有软件许可证有本质的不同：专有软件许可证给予用户的权利是只允许在一台机器上使用、运行软件副本的权利，而没有复制、发布和修改软件的权利；而GPL则认为用户运行程序的权利是天生的，不需要许可就能获得，GPL授予用户的是专有软件许可协议禁止的复制、发布和修改软件的权利。如何做到这一点，GPL认为，“为了保护你的权利，我们需要作出规定：禁止任何人不承认你的权利，或者要求你放弃这些权利。”。为此，GPL采取两项措施来保证用户的权利：“（1）给软件以版权保护。（2）给你提供许可证，它给你复制，发布和修改这些软件的法律许可。”对于一个自由软件来说，通常都是在不支付任何成本的情况下获得的，软件所有者并未从发布程序上得到足够的回报，用以建立相关的责任保险和担保费用。所以在序言里，GPL专门声明不承担担保，希望借此使软件所有者免于承担与使用该软件而产生的关联责任。
GPL的另一重要贡献是其对“派生成果”的独特约定。许可证接受人可以修改接受到的程序的任何部分，以此形成基于程序的作品，并进行复制和发布。但行使这一权利必须同时满足三项条件：第一个条件是许可证接受人必须在修改过的文件中附有明确的说明，表明自己修改过这一文件以及在何时修改；第二个条件是发布的派生成果必须作为一个整体，允许第三方在GPL条款下使用，并且不得对此项授权收取任何费用；第三个条件是如果派生程序在运行时以交互的方式读取命令，那么许可证接受人必须使它在开始进入常规的交互使用方式时打印或显示适当的版权声明和没有担保的声明（或者许可证接受人提供担保的声明）。
满足完三项条件之后，在这一款中，GPL还对在GPL程序基础之上独立创造的成果做出了有争议性的规定，该规定也被商业软件公司认为是“GNU病毒”（GNU
virus）。第2款规定：“如果能够确定作品的一部分并非程序的衍生产品，可以合理地认为这部分是独立的，是不同的作品。当你将它作为独立作品发布时，它不受此许可证和它的条款的约束。但是当你将这部分作为基于程序的作品的一部分发布时，作为整体它将受到许可证条款约束。准予其他许可证持有人的使用范围扩大到整个产品。也就是每个部分，不管它是谁写的。”这也就是说许可证接受人自己独立创造的程序很有可能被GPL感染，被卷入到GPL的许可证条款当中去，成为自由软件，从而丧失了自己想获取的软件版权利益。对于这一点，GPL认为自己的做法是正当的：“本条款的意图不在于索取权利，或剥夺全部由你写成的作品的权利。而是履行权利来控制基于程序的集体作品或衍生作品的发布。”此外，该条款还说明，如果把一个非GPL程序与GPL程序放在同一个存贮体或发布在媒体的同一卷上，并不导致这个非GPL程序也要受GPL许可证的制约。
比GPL约定宽松一点的还有较宽松通用公共许可证 (Lesser General Public
License)，主要针对一些特殊设计的程序库。在该许可证下，允许专有软件可以同程序库链接而不被自由软件化。
二、学院开放许可证
GPL不是最早的开源许可证，更早一点的是由加州大学伯克利分校针对自己开发的Unix操作系统而推出的BSD许可
[ii]。Unix操作系统1969年发端于AT& T贝尔实验室，最初，AT&
T并没有把它当作商品，而是作为研究项目，以收取少量许可使用费的方式，向大学和研究机构开放。到了七十年代末期，加州大学伯克利分校计算机系统研究小组（CSRG）对Unix进行了相当多的改进，如更好的内存管理，快速且健壮的文件系统等，大部分原有的源代码都被重新写过，以支持新特性。很多其他Unix使用者，包括其他大学和商业机构，都希望能得到CSRG改进的Unix系统。因此CSRG中的研究人员把他们的Unix组成一个完整的Unix系统──BSD
Unix（Berkeley Software Distribution），向外发行。
相对于严格、复杂的GNU
GPL来说，BSD许可要来得宽松、简单。用户可以在BSD许可软件上做自己想做的事，甚至对这些软件进行更改而转为专有软件。这也就是说，用户可以得到有BSD许可证的程序源代码，更改后可以只销售程序的二进制版本或目标代码，而不需要同时发行经过更改后的程序源代码，也不需要对更改后的程序使用BSD许可证。尽管如此宽松，但BSD许可软件仍是有版权保护的软件，而不是公共域（无版权）软件，因为它要求软件在分发源代码或二进制代码时必须保有原作者和贡献者的版权声明以及拒绝担保的声明。
早期的BSD许可证包含一个令人厌烦的条款（第3款），该条款要求每当用户在广告中谈及一个BSD许可证软件的特征时，必须同时提及（通常在脚注中）软件是在加州大学开发的。这一条款引起了包括自由软件阵营和商业专有软件公司在内软件界的集体抱怨，后来在1999年7月22日，加州大学把这一条款完全删除。在BSD
Unix的基础上，BSD许可证的发行条款下，又诞生了诸如FreeBSD、NetBSD和OpenBSD等变种。
另外一个较知名的学院开放许可证是麻省理工学院许可证（Massachusetts Institute of Technology
License）
[iii]，它和BSD许可证几乎等同，MIT许可证在强调作者版权声明和拒绝担保的条件下，允许后来的开发者对在其条款下发行的软件进行任意的修改，派生成果可以被开发者据为己有，而不用公布源代码。但MIT许可证要比BSD更简单，它从发布之初就没有像BSD一样扰人的广告条款。也正是受到MIT许可证的压力，BSD许可证后来才有删除广告条款的行动。
三、商业开放许可证
第三类开源许可证是以网景公司为代表的商业开放许可证。1998年，在微软捆绑搭售的网络探险家（Internet
Explorer，简称IE）不断增大的市场压力下，网景公司决定改变战略，开放其网络浏览器，加入到开放源码阵营。网景的计划得到了许多开源社区领导人物的支持，如斯托曼、雷蒙德、托沃兹以及红帽公司的罗伯特·杨都纷纷给网景公司提出了自己的建议，他们花了大量的时间与网景公司的法律小组讨论现存的许可证，主要是GPL、LGPL、BSD许可证，看其是否符合浏览器的要求。在研讨了三种许可证的特点之后，网景公司的法律小组决定自己写一个许可证，花了一个月的时间，网景公共许可证（Netscape
Public
License，简称NPL）出来并在网上公布。这份许可证草案在一上网就激起了开放源码社区的反弹，召来了众多的批评——NPL的一部分条款向网景公司提供了特别的权力，让网景公司在它的其他产品中使用这些受NPL约束的程序代码，但是这些其他产品却可以不受NPL的约束。当黑客们对软件进行更改后，网景公司有对这些更改重新发放许可证的特权，他们可以将这些更改据为己有，然后再进行改进，但却拒绝再返回给公众。开源社区的成员认为NPL赋予了网景公司太多的特权，不能接受。
开源社区对NPL草案的批评反馈到了网景公司的起草委员会，他们对NPL重新进行了修订，这个修订本产生了另外一个许可证——魔斯拉公共许可证（Mozilla
Public License，简称MPL）
[iv]，该许可证删除了网景公司的特权条款，试图在吸引开源社区成员参与开发与达到公司的商业目的之间取得一种平衡。
最后，网景公司产生了两个许可证。第一个是网景公共许可证，网景公司宣布浏览器所有的代码都在NPL的形式下发布，对代码的改进也须按NPL的形式发布，该许可证通过这种方式保护了浏览器中授权网景使用代码的第三方的利益。第二个许可证是魔斯拉公共许可证，网景公司宣布，新开发的代码将按照MPL的形式发布。MPL现已在很多方面成为商业软件公司转向开放源码许可的一个典型范例。与GPL、BSD类型许可相比，MPL的一个重要突破是对软件初始的原创性工作和后来开发的贡献者（Contributors）工作两者做了区分。在第2款，实际上包含了两个许可，一个是软件原始开发者（Initial
developer）的授权，另一个是软件贡献者的授权，都授予用户对软件使用、复制、分发和修改的权利以及与这些事所相关的由许可证颁发人所持有的专利权。第3款规定，用户对代码的修改受MPL的约束，修改的源代码必须可以得到，修改的事项也必须注明，用户所知的第三方的知识产权也必须在随每个源代码的复制品分发时用一个法律文件注明。MPL还对版权声明的形式做出了规定，版权声明应该内藏于每个源代码的复本，并且所有的文件都需包含一个MPL的复本。MPL与GPL的一个最关键不同是，MPL只强调修改的代码需在MPL下发行，它允许商业公司增加一个与专有代码库的应用程序接口（API），这样专有软件就可以通过这个接口而和MPL软件连接，但专有软件却不会因此而被纳入到MPL当中去。从这一点来看，没有“GNU病毒”的MPL更像BSD许可而不是GPL。
MPL在许多方面借鉴了GPL的做法，如强调版权声明、拒绝担保、自动终止权利等，但由于有许多专业律师参与了MPL的制定，MPL被认为更具有法律严谨、仔细的特性，它的第11款对法律适用地做出了规定，说明许可证主要受美国加利福尼亚法律管辖。
MPL创造了一种把商业软件释放到开源社区的一个模式，继网景公司之后，IBM、苹果、SUN等公司也纷纷以MPL为样本，制定了自己的开源许可证。对于商业软件公司来说，MPL在GPL与BSD之间架起了一座桥梁。
四、许可证的比较与选择
许可证
特征
|
自由软件许可证
|
学院开放许可证
|
商业开放许可证
|
GPL 2.0
|
LGPL2.1
|
MIT 许可证
|
BSD许可证
|
MPL1.1
|
IPL 1.0
|
被开放源代码协会认证
|
是
|
是
|
是
|
是
|
是
|
是
|
可自由地运行程序
|
是
|
是
|
是
|
是
|
是
|
是
|
可以与自由软件混合
|
是
|
是
|
是
|
是
|
否
|
否
|
可以与专有软件混合
|
否
|
是
|
是
|
是
|
是
|
是
|
可修改代码
|
是
|
是
|
是
|
是
|
是
|
是
|
增加的代码须和受保护的代码区分
|
否
|
否
|
否
|
否
|
是
|
是
|
修改版本可被专有
|
否
|
否
|
是
|
是
|
是
|
是
|
有自动终止权利条款
|
是
|
是
|
否
|
否
|
是
|
是
|
有版权声明
|
是
|
是
|
是
|
是
|
是
|
是
|
有拒绝担保和责任限制条款
|
是
|
是
|
是
|
是
|
是
|
是
|
有适用法律地的规定
|
否
|
否
|
否
|
否
|
是
|
是
|
|
|
|
|
|
|
|
|
如上图所示，我们了解了开源软件许可证的三种类型。第一种是由自由软件基金会主导推广的自由软件许可证，典型如GPL，这种许可证是条款限制最严格的许可证，其目的是保持软件自由的属性。在这种许可证下，任何组织或者个人（包括自由软件基金会）都不能控制开发的软件，都不能改变软件自由的属性。它为自由软件的自循环提供了一个封闭的法律环境。当然，在软件商业化的压力下，自由软件基金会也发布了另外一种较宽松的许可证LGPL，它为专有软件使用自由软件提供了某种可能性，但这种可能性以不侵犯软件的自由为限。对于想利用自由软件成果而又想保持自己软件专有特权的商业公司来说，GPL、LGPL有着诸多的法律陷阱，稍不留意就有可能使专有软件变为自由软件，但对自由软件阵营来说，这些“病毒”条款为自由软件防范专有软件的入侵打造了一堵坚实的防火墙。
第二种是由一些大学科研机构颁发的学院开放软件许可证，典型如BSD许可，这种许可证是限制最少的许可证。与GPL对软件专有而产生的垄断利益的严格排斥相比，BSD类型可算得上是网络世界的免费午餐。除了一些无关商业利益的版权声明和拒绝担保条款，它对发布的程序源代码今后的走势几乎不加任何控制，用户可以对在这类许可证发行下的软件做自己想做的任何事。但这类许可证最大的问题是极易导致软件工程“分叉”的出现，因为它没有法律条款保障使用该软件的用户会将他对软件修改的成果（衍生作品）返回到该项目中。就像在BSD
Unix系统发展历史中所见到的，后来衍生了诸多各式各样的版本，有商业专有的，也有自由使用的，各种版本互不兼容，使得Unix系统进展缓慢。而Unix系统的变种Linux却凭借GPL许可，调动各种资源，后来居上，逐步取代了Unix。
第三种是由一些商业软件公司转向开放源码策略的开放许可证，这些软件公司在微软不断扩张的垄断势力压力下，试图通过对软件开发商业模式的改变——由封闭源码转向开放源码，来摆脱对微软底层封闭操作系统的依赖，这种许可证对软件发行的限制程度界于GPL与BSD许可之间。它的最突出的特点是把软件分为两部分：隐藏的（受保护的）部分和贡献的部分。如果有人要修改和分发隐藏的部分，则他们还须分发修改部分的源代码；如果有人要更改软件但使它们的修改保持专有，则他们可以不带源代码分发它们，但须有一个受该许可证保护的应用程序接口来访问受保护的代码。这种类型的许可证一方面保证了软件工程的延续性，降低了软件工程出现大面积“分叉”的可能；另一方面，又为商业软件公司的专有赢利模式提供了可能。
对于不同特性的软件而言，可以采用不同的版权许可证。软件底层操作系统最好采纳GPL，因为对于底层操作系统来说，保持软件的开放性和可持续性是非常重要的，Linux的成功或多或少证明了这一点；对工具软件（或是支持软件）来言，开放源码和专有经营是并行不悖的，实际上许多商业软件公司正在Linux
系统上从事这样的工作，采用诸如MPL或IPL类型的许可证在此比较合适；在应用软件层面上，软件专有的开发模式占据了优势，但
参考文献
[[i]] GNU General Public License[EB/OL]
.http://www.gnu.org/licenses/gpl.html.
[[ii]] The BSD License[EB/OL]
.http://osi.open5ource.net/licenses/bsd-license.php.
[[iii]] The MIT License[EB/OL]
.http://osi.open5ource.net/licenses/mit-license.php
