软件许可证相关问题

 

（二）、开放源代码软件的认定

“开放源代码首创行动组织”（Open Source Initiative Association，简称OSIA）是一个非盈利的组织，是美国的Bruce Perens 和 Eric S. Raymond 等人于1998年在美国加州发起设立的，倡导了“开放源代码首创行动” （Open Source Initiative，简称OSI），其目的就是要让开放源代码软件的发展有一个更好的土壤。组织建立的目的就是想尽可能统一开放源代码软件的标准，捍卫开放源代码这一神圣的定义，为此，该组织从软件的许可问题入手，结合证明商标，为开放源代码软件业的发展做出了重大的贡献。

开放源代码首创行动组织，作为一个自发建立的非官方组织，为了在开放源代码软件领域实现统一标准的目的，确实难度很大，但是该组织的定位和战略很好，将自己定位为一个行业自律协会性质，并且巧妙的应用了商标战略。将Open Source Initiative、OSI申请了证明商标[注10]，自己作为证明商标的管理者[注11]（OSIA原想将Open Source 、OS等申请为产品商标，但是由于具有描述性的特征，所以未被授权，所以才转申请了证明商标）[注12]。是否是开放源代码软件，不光要看权利人是否提供源代码，另外一个很重要的标志就是许可证的问题，因为绝大多数的开放源代码软件在发布时都会附带一个许可协议，即我们所说的许可证，在许可证中，会规定许可人和被许可人的权利与义务，而正是这些权利和义务，决定了权利人是否将源代码真正的向社会公众开放，从而可以实现是否是开放源代码软件的判断。OSIA正是从软件的许可证上着手，将证明商标许可给那些经其审核认定为开放源代码软件的软件提供者。这样，凡被认定为开放源代码软件许可证的，都可以表明OS、OSI等商标标识，从而得到开放源代码软件界的认可。

经过3年多的发展，“开放源代码首创行动”取得了很大的成功，像自由软件联盟GNU、IBM、NOKIA、NETSCAPE等的开放源代码软件许可证都先后得到了OSIA的认证，迄今为止，经OSIA认证的开放源代码软件的软件许可证有如下21种：

1 、The GNU General Public License (GPL)  

2 、The GNU Library or "Lesser" Public License (LGPL)  

3 、The BSD license  

4 、The MIT license  

5 、The Artistic license  

6 、The Mozilla Public License v. 1.0 (MPL)  

7 、The Qt Public License (QPL)  

8 、The IBM Public License  

9 、The MITRE Collaborative Virtual Workspace License (CVW License)  

10 、The Ricoh Source Code Public License  

11 、The Python license  

12 、The zlib/libpng license  

13 、The Apache Software License  

14 、The Vovida Software License v. 1.0  

15 、The Sun Internet Standards Source License (SISSL)  

16 、The Intel Open Source License  

17 、The Mozilla Public License 1.1 (MPL 1.1)  

18 、The Jabber Open Source License  

19 、The Nokia Open Source License  

20 、The Sleepycat License  

21 、The Nethack General Public License

其中开放源代码软件业最著名的GPL、LGPL、MPL、MPL1.1软件许可证，都经过OSIA的认证。

在开放源代码首创行动组织的开放源代码的定义（The Open Source Definition）中，指明了该组织对开放源代码软件的认定标准有如下几个方面[注13]：

 

1 、发布的自由

开放源代码软件的许可证不能有任何限制再销售或限制本程序同其他代码性质程序联合发布的条款，也不能有额外的收费要求。[注14]

 

2 、关于对源代码的要求

要求软件的发布形式必须为开放源代码的形式，即使有的软件在初始发布时不便于在程序中发布源代码，但必须有免费的方式在软件初始发布的同时提供明确的路径获得源代码，无论是书面印刷的还是通过因特网下载。

另外，这些源代码必须是完备的，至少要能保证专业领域的人员能够进行修改。而且在软件发布时任何故意混淆源代码的行为是被禁止，任何通过预处理程序或翻译程序对源代码进行阻隔的行为也是被禁止的。

开放源代码软件许可证可以禁止被许可人以直接在初试源代码版本上修改的模式发布，但是前提是在源代码软件初始发布的时候就必须允许以在源代码程序版本后用附属文件的形式发布修改版本。

 

3 、关于演绎作品

开放源代码软件许可证必须允许源代码可以被修改和允许根据源代码产生有版权法意义上的演绎作品。

 

4 、其他要求

其他的要求包括不得对许可对象有歧视、不得对软件被使用的领域有歧视、不得要求本开放源代码许可证生效的条件是在遵从其他软件许可证的前提下、许可证必须是适用于开放源代码这一类软件的而不是只针对某一个软件和开放源代码软件许可证不得贬低其他软件许可证等条款[注15]。

OSIA 对开放源代码软件许可证的认定程序是由许可证提供人启动的，凡许可证提供人自己认为自己的许可证符合开放源代码软件的要求的，可以向OSIA提出加入OSIA开放源代码软件许可证体系的申请，OSIA将通过委员会审查和公众审查来决定是否承认该软件许可证为OSI系列的开放源代码软件许可证[注16]。  

　

（三）、开放源代码软件得以快速发展的原因

——Internet是开放源代码的最佳媒体和途径

传统的源代码传播途径是以纸介质或磁盘为媒体的，其传播速度和范围都十分有限，不能及时反馈和公开程序高手们修改与补充的代码，讨论的范围就更狭窄了。Internet的出现充分缩短了交流的时间和空间，不论在哪里，也仅是一“屏”之隔，一“点”之差，Linux就是借助于Internet发展壮大的，可以说没有Internet就没有Linux。Internet的发展壮大了开放源代码软件事业，同时也给开放源代码软件的最初原则带来挑战，开放源代码软件许可证正是在这样的条件下诞生的，许可证伴随源代码在网络上传播，为开放源代码运动保驾护航。

三、 关于开放源代码软件许可证的比较研究

 

（一）、软件许可证的由来

软件许可证的发展是随着软件产业发展而发展的，而软件产业的发展又是随着计算机技术的进化的。在20世纪80年代以前，由于计算机都是大型化的，所以软件业的市场范围比较狭小，大部分软件都是为专门的计算机定制的，对当时软件业最形象的描述就是量体裁衣般的“裁缝式”。[注17]1980年以后，随着计算机制造技术的改进，个人电脑的普及，才使得软件市场得以发展，使得软件成为产品，软件程序能够得以批量生产和销售。但是软件同普通商品有一个明显的不同就是，程序作为软件产品的核心，是复杂脑力劳动的结果，是具有知识产权特性的。所以软件产品在商业化运作中，一个典型的特点就是软件是许可而不是简单的商品买卖，更不意味着权利的卖绝。因此软件许可协议，也就是软件许可证，在软件产业中的地位非常重要，因为在许可证中约定了许可人和被许可人的权利和义务[注18]。

 

（二）、几种开放源代码软件许可证的比较研究

为了保证任何人能够得到源程序或者在需要的时候能够得到源程序，保证任何人能够修改开放源代码软件或将开放源代码软件的一部分用于新的开放源代码软件以及保证任何人知道他们能够做这些事情，所以需要开放源代码软件许可证。因为开放源代码软件许可证作出如下规定：禁止任何人不承认这些权利，或者要求其他人放弃这些权利。如果修改了开放源代码软件或者发布了软件的副本，这些规定就转化为确定的责任，这就是开放源代码软件许可证最典型的作用，也就是为什么开放源代码软件许可证必不可少的原因。

 

Ⅰ、GPL许可证

GPL 许可证（GPL是General Public License的简写）是自由软件联盟GNU的开放源代码软件许可证的一种，是开放源代码软件领域最富盛名的一种许可证，但同时，GPL许可证也是开放源代码软件领域对被许可人权利限制最严的。[注19]

 

（A）、 GPL许可证概要

Richard 在倡导自由软件联盟计划时, 从软件的版权许可协议入手, 创设了一种与其开放源代码软件发展相适应的“通用公共许可协议”( General Public License,GPL),凡想加入GNU的软件著作人都要接受这份许可协议，其宗旨就是保证用户有无限复制和修改的权利。并且在GPL的导言部分中，对自由软件和知识产权的相关问题进行了论述。

1 、“自由”的法律含义

前面已经提过, 开放源代码软件这一定义的来源是从技术角度，而自由软件这一定义本身就是版权意义上的范畴.自由软件的"自由"体现为通过版权许可给予的自由,而不是自由的没有知识产权。也就是说, 自由软件不是没有版权,它首先是承认软件的版权--软件有原始的版权所有者,然后纳入自由软件的版权许可约束,使每个人在维持该许可的条款不变的情况下,都有权复制, 修改和发布软件或其衍生的工作，这就是所谓的自由软件的自由理念。 Richard Stallman在《自由软件联盟宣言书》(《GNU Manifesto》)中有这样一段对知识产权的论述:“仔细研读过知识产权法律条款的人会发现,知识产权并不是一种固有的权利,现行的各种知识产权都是立法机构通过专门立法赋予的权利,所有的知识产权都是社会给予的许可。”这是Richard进行自由软件发展工作的法律立足点,他要取得知识产权法上的论证,并且他认为知识产权是一种社会赋权，既然知识产权是作为一种权利是立法上授予的权利，并且知识产权法也允许运用“许可”这种方法,通过契约的方式来变更和调整知识产权的权利人与使用者之间的权利义务，于是Richard从许可这一个角度着手，使自由软件的运作在不同于商业软件的运作,即扩大所谓的"自由"时, 能有自己的法律依据——在承认版权的前提下,通过软件的版权许可来实现自由软件的自由权利的要求。

2 、自由软件的版权许可

对于普通的商业软件, 软件开发商与使用者之间一般都会设立软件使用许可协议,即“一般商业许可”(General Business License,GBL). 这种许可协议一般由开发商单方拟订,用户接受协议是使用软件的前提,而获得许可的前提是支付费用购买软件产品.其许可条款一般按照版权法或专门的软件保护条例,或者通过双方合意达成略高于版权法和软件保护条例保护标准的软件许可使用条款。

面对于这种显然不适合自由软件的GBL,Richard在倡导自由软件联盟计划时, 从软件的版权许可协议入手, 创设了一种与自由软件发展相适应的" 通用公共许可协议"( General Public License,GPL),凡想加入GNU的软件著作人都要接受这份许可协议，其宗旨就是保证用户有无限复制和修改的权利。更有趣的是,相对于“著作权”(“Copyright”)这一名词,Richard新造了一个词，将这种许可协议叫做“Copyleft”[注20]。“通用公共许可协议”在导言部分就明确了这项许可协议的法律立足点:(1)承认软件的版权;(2) 提供这种许可协议以使获得授权的复制,散发和修改软件的权利。 GPL是自由软件著作人同意的保证任何人有共享和修改自由软件的许可协议,GPL有13条主要条款，其中社会公众作为被许可人享有最主要的4项权利:(1)为了任何目的的运行该程序;(2) 有自由获得源代码的权利,并在此基础上研究程序是如何运行的,并可为了个人的目的改变该程序;(3)有自由散发该复制件的权利;(4)有自由改进程序,并要求将自己的改进向公众公布的权利。由这些规定可以看出自由软件的权利人在保留权利的同时, 已经在相当程度上向社会公众许可了复制权和修改权。同时GPL也规定社会公众有以下义务: 用户在发布源代码和一切派生工作时不收费（除必要的工本费）,不附加其他条款,并必须附带GPL条款。这样任何人无论是否作了修改,都必须连带传递复制和修改这个软件的自由度,使得自由软件工作得到延续和认可。

“自由软件”是一个版权意义上的范畴。自由软件认为软件的源代码应该是属于全人类的公共知识产权，应该在编制和使用程序的人之间自由地传播，而不应该是商人谋取利益的手段。对这一知识产权的任何限制最终都将造成发展的限制和阻碍。自由软件的倡导者们不是企图将别人的软件共化，他们的做法是将自己的软件作品纳入自由软件的范畴，贡献给全世界。  

　　通用公共许可证版权协议是一种与传统知识产权概念截然不同的全新版权体系。它与传统的软件知识产权的不同在于：它保证任何人都有发布自由软件的自由（如果愿意，可以对此项服务收取一定的费用）；保证任何人能够得到源程序或者在需要的时候能够得到源程序；保证任何人能够修改自由软件或将自由软件的一部分用于新的自由软件；而且还保证任何人知道他们能够做这些事情。为了保护这些权利，通用公共许可证作出如下规定：禁止任何人不承认这些权利，或者要求其他人放弃这些权利。如果修改了自由软件或者发布了软件的副本，这些规定就转化为确定的责任。  

　　自由软件与传统的商业软件的主要区别在于：商业软件一般不提供源代码，而自由软件保证提供源代码；商业软件禁止用户将软件散布给第三者，而自由软件在法律上保证任何人有权按照许可证的规定散发软件；更为重要的是自由软件在法律上保证了任何软件作品一旦宣布为自由软件，便永远是自由软件，包括原始作者在内的任何人都无权改变。任何更新、移植、修改和增强都被定义为“导出性工作”，是不能改变原始版权说明的。  

　　当然，通用公共许可证既然是一种软件知识产权的保护方式，它并不排斥软件开发者从软件中获取利益，只是盈利的方式有所改变：从过去依赖软件拷贝的销售，转向主要提供软件及信息服务。而且，现有商业软件嫁接到GNU/Linux等自由软件上时，也不一定非要公布源代码和提供免费拷贝，这意味着，自由软件可以与商业软件共存。  

　　当我们使用商业软件时我们都会看到一个版权信息，它通常是说被许可人没有权力对被许可人买的软件进行拷贝、分销。至于理解和修改，因为根本就没有源码所以就无所谓“理解“和“修改“。毋庸讳言，在我们的身边，至今有人还未注意到有关版权的信息，因此，我们不知道我们究竟放弃了自己的哪些权力，而我们或许会为此付出代价。  

　　其实，自由软件的本质不是免费，它是赋予使用者运行、拷贝、散布、研究、改进软件的自由，并保证这些自由不会因为私有软件的介入而丧失：学习程序如何工作、修改使之适合被许可人的需要；散布，使被许可人和被许可人的邻居、朋友共享软件；改进程序，将被许可人的改进公之于众，使整个社会受益等权利。它的本质是“思想共享、知识共享、源码共享”，是非垄断，是鲜活的思想贡献。借助别人的优秀思想，加上被许可人自己独特思维使全社会受益。如果被许可人没有钱，被许可人可以通过免费的渠道，如从朋友处拷贝或通过英特网下载。如果被许可人很有钱，被许可人可以以捐赠的方式用高价购买。这一切取决于您自己。  

　　当随意使用一个软件而不必担心侵权时，深晓“自由”真谛的人们，必会感到社会的温馨和友爱，当可以随时修改程序使它更好、更适用时，一定能体验工作效率得到提高的兴奋，当把自己的辛勤劳动公之于众、供千万人使用的时候，被承认的自豪感将充分体验自由、和谐、高效的世界充满着爱！

3 、自由软件与软件专利

作为软件生产大国和专利制度比较发达的美国,软件专利的数量也是很大的，软件专利的独占权与自由软件所倡导的"自由"精神格格不入,Richard的GNU 计划书中还专门提到了这一点。他认为“自由软件面对的最大威协就是软件专利”。由于美国对软件专利这样的独占权的保护期又是长达17年,这显然与"自由"精神抵触,另外更重要的就是由于自由软件在发布、改进过程中融入了许多人的劳动，多多少少有可能涉及到自由软件所最不愿意遇到的所谓软件专利侵权诉讼。比如说,LZW 公司1983年申请的一个压缩技术的专利, 导致自由软件联盟GNU涉及生产该压缩制品的自由软件迟迟不能在网上发布,在1998年,一个生产MP3 压缩音响制品的自由软件又被停止在网上的发布,因为可能面对软件专利侵权的诉讼。目前对付这种软件专利侵权诉讼的方法也就是两个:一是申请宣告该专利无效;二就是寻找其他的替换方法去实现自由软件发布的目的，但这些又似乎都是不得以而为之的对策。

上面说的是自由软件与已存在的软件专利之间的问题，而针对自由软件本身，在“通用公共许可协议”的导言部分中, 还专门有一项关于自由软件可否申请软件专利的条款:“鉴于任何自由软件时刻处于软件专利的威胁之下,我们希望能避免这种情况:自由软件的再传播者在实施过程中使得这项软件程序获得专利独占权，正是基于此目的, 我们明确地要求承诺任何自由软件可以去获得专利授权的前提是一旦获得软件专利授权必须向所有的人以符合自由软件使用条件的标准许可使用该专利, 否则就不可去申请软件专利。”从这里可以看出GPL多少是排斥软件专利的.

从以上可以看出, 以自由软件运动GNU为代表的开放源代码软件的出现并不是要否定知识产权,它是植根于知识产权的土壤之中,去体现自己的风格,实现自己的追求, 它依赖于知识产权并谋求一种创新,因为自由软件的精神并不是与知识产权保护制度相矛盾，应当说，它属于一种权利的主动放弃。自由软件的出现是自由精神与创新精神相结合的产物，自由软件开发群体奉行自由精神，不追求个人物质利益的实现，而立足于创造、构建理想的软件产品，这样的精神是值得提倡和推崇的

综上可以看出，自由软件的出现，并不像有些人想象的那样自由软件从根本上否定了知识产权法律制度，事实上，自由软件并不同版权制度矛盾，只是由权利人向公众许可了本属于自己的修改权、发布权等一些版权权利。但是，对于专利来讲，可以看出自由软件是反对由专利形成的垄断权，因此，自由软件不提倡软件专利。

 

（B）、GPL许可证有关复制、发布和修改等权利的约定

GPL 许可证适用于任何包含版权所有者声明的程序和其他作品，版权所有者在声明中明确说明程序和作品可以在GPL许可证条款的约束下发布。GPL许可证中对源代码指的是对作品进行修改最优先择取的形式。对可执行的作品讲，完整的源码包括：所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的“原本”（原文为：“script”）。作为特殊例外，发布的源码不必包含任何常规发布的供可执行代码在上面运行的操作系统的主要组成部分（如编译程序，内核等）。除非这些组成部分和可执行作品结合在一起[注21]。下面提到的“程序”指的是任何这样的程序或作品。而“基于程序的作品”指的是程序或者任何受版权法约束的衍生作品，也就是说包含程序或程序的一部分的作品，可以是原封不动的，或经过修改的和（或）翻译成其他语言的（程序）。在GPL许可证中，翻译包含在修改的条款中，许可证条款不适用于复制，发布和修改以外的活动。运行程序的活动不受条款的限止。仅当程序的输出构成基于程序作品的内容时，这一条款才适用（如果只运行程序就无关）。

GPL 许可证规定只要在每一副本上明显和恰当地出版版权声明和不承担担保（即No Warranty条款，将在下文中讨论）的声明，保持此许可证的声明和不担保的声明完整无损，并和程序一起给每个其他的程序接受者一份许可证的副本，被许可人就可以用任何媒体复制和发布被许可人收到的原始的程序的源代码，可以为转让副本的实际行动收取一定费用，也有权选择提供担保以换取一定的费用。

可以修改程序的一个或几个副本或程序的任何部分，以此形成基于程序的作品。只要同时满足下面的所有条件，就可以按前面第一款的要求复制和发布这一经过修改的程序或作品。

a ） 必须在修改的文件中附有明确的说明：被许可人修改了这一文件及具体的修改日期。

b ） 必须使被许可人发布或出版的作品（它包含程序的全部或一部分，或包含由程序的全部或部分衍生的作品）允许第三方作为整体按许可证条款免费使用。

c ） 如果修改的程序在运行时以交互方式读取命令，就必须使它在开始进入常规的交互使用方式时打印或显示声明：包括适当的版权声明和没有担保的声明（或者被许可人提供担保的声明）；用户可以按此许可证条款重新发布程序的说明；并告诉用户如何看到这一许可证的副本。

如果能够确定作品的一部分并非程序的衍生产品，可以合理地认为这部分是独立的，是不同的作品。当将它作为独立作品发布时，它不受此许可证和它的条款的约束。但是当将这部分作为基于程序的作品的一部分发布时，作为整体它将受到许可证条款约束。准予其他许可证持有人的使用范围扩大到整个产品。也就是每个部分，不管它是谁写的。

因此，GPL许可证这项条款的意图不在于索取权利或剥夺全部由被许可人写成的作品的权利。而是履行权利来控制基于程序的集体作品或衍生作品的发布。此外，将与程序无关的作品和该程序或基于程序的作品一起放在存贮体或发布媒体的同一卷上，并不导致将其他作品置于此许可证的约束范围之内。

GPL 许可证允许以目标码或可执行形式复制或发布程序（或符合GPL许可证第2款的基于程序的作品)，只要被许可人遵守下面的条款。

a ）在通常用作软件交换的媒体上，和目标码一起附有机器可读的完整的源码。这些源码的发布应符合上面条款的要求。或者

b ）在通常用作软件交换的媒体上，和目标码一起，附有给第三方提供相应的机器可读的源码的书面报价。有效期不少于3年，费用不超过实际完成源程序发布的实际成本。源码的发布应符合上面的要求。或者

c ）和目标码一起，附有被许可人收到的发布源码的报价信息。（这一条款只适用于非商业性发布，而且只收到程序的目标码或可执行代码和按b）款要求提供的报价）。

如果采用提供对指定地点的访问和复制的方式发布可执行码或目标码，那么，提供对同一地点的访问和复制源码可以算作源码的发布，即使第三方不强求与目标码一起复制源码。除非明确按许可证提出的要求去做，否则被许可人不能复制，修改，转发许可证和发布程序。任何试图用其他方式复制、修改、转发许可证和发布程序是无效的。而且将自动结束许可证赋予被许可人的权利。然而，对那些从被许可人那里按许可证条款得到副本和权利的人们，只要他们继续全面履行条款，许可证赋予他们的权利仍然有效。每当重新发布程序（或任何基于程序的作品）时，接受者自动从原始许可证颁发者那里接到受这些条款和条件支配的复制，发布或修改程序的GPL许可证。

 

Ⅱ、LGPL许可证  

LGPL 许可证（LGPL许可证是LESSER GENERAL PUBLIC LICENSE的简写，也叫LIBRARY GENERAL PUBLIC LICENSE[注22]，中文译为“较宽松公共许可证”或者“函数库公共许可证”)。这个许可证，适用于一些由自由软件基金会与其它决定使用此许可证的软件作者，所特殊设计的软件软件包 ── 像函数库（即LIBRARY）可以使用它。

 

（A）、LGPL许可证的特点

LGPL 许可证，也是自由软件联盟开放源代码软件许可证的一种，大部分的 GNU软件，包括一些函数库，是受到原来的 GPL许可证的保护。而LGPL许可证，适用于特殊设计的函数库，且与原来的通用公共许可证有很大的不同，给被许可人较为宽松的权利，所以叫“较宽松公共许可证”。在特定的函数库中使用它，以准许非自由的程序可以与这些函数库连结。

当一个程序与一个函数库连结，不论是静态连结或使用共享函数库，二者的结合可以合理地说是结合的作品，一个原来的函数库的衍生品。因此，原来的通用公共许可证只有在整个结合品满足其自由的标准时，才允许连结。较宽松通用公共许可则以更宽松的标准允许其它程序代码与本函数库连结。

例如，在少数情况下，可能会有特殊的需要而鼓励大家尽可能广泛地使用特定的函数库，因而使它成为实际上的标准。为了达到此目标，必须允许非自由的程序使用此函数库。一个较常发生的情况是一个自由的函数库与一个被广泛使用的非自由函数库做相同的工作，在此情况下，限制只有自由软件可以使用此自由函数库不会有多少好处，故我们如用了LGPL许可证。在其它情况下，允许非自由程序使用特定的函数库，可以让更多的人们使用由软件的大部分。例如，允许非自由程序使用 GNU C 函数库可以让更多的人们使用整个 GNU 作业系统，以及它的变形

GNU/Linux 作业系统。 尽管LGPL许可证对使用者的自由是较少的保护的，它却能确保与此函数库连结的程序的使用者拥有自由，而且具有使用修改过的函数库版本来执行该程序的必要方法。

 

（B）、关于复制、散布、以及修改的规定

LGPL 许可证在关于复制、散布、以及修改的规定中特别区别了 "基于函数库的作品" 以及 "使用函数库的作品" 之间的差异：前者包含来自函数库修改过的源代码；而后者则必须与函数库结合才能执行。

LGPL 许可证适用于任何软件函数库，或其它包含了由版权所有者加入的注意事项的程序，或其它有公信力的团体宣称其程序可以在LGPL许可证的条款下散布。一个 “函数库”意指一些软件函数的集合，以及或准备好的资料以方便与应用程序 (其使用了其中某些函数与资料) 连结形成可执行的程序。 以下，“函数库”一词指的是任何在本条款下散布的这一类软件函数库或作品，一个 "基于本函数库的作品" 意指函数库或任何在版权法下的衍生作品。也就是说，一包含了本函数库或其一部分的作品，可以是原封不动的，或经过修改的，和（或）直接翻译成其它语言的(在LGPL许可证中，翻译是包含在 "修改" 的条款中)。

作品的 "源代码" 意指对作品进行修改最优先择取的形式。对函数库而言，完整的源代码意指所有模块的所有原始程序，加上有关的接口的定义，加上控制函数库的安装和编译的 “原本”（原文为：“script”）。[注23]

LGPL 许可证条款不适用于复制，发布和修改以外的活动。这些活动超出这些条款的范围。使用本函数库来执行本程序的动作不受条款的限制，而程序的输出只有在其内容所构成的作品是基于本函数库时 (与在什么工具中使用本函数库来输出无关) ，这一条款才适用。以上情况是否成立则取决于本函数库具体用来做什么。只要被许可人在每一程序副本上明显和恰当地宣告版权声明和不承担担保的声明，并保持此许可证的声明和没有担保的声明完整无损，并和程序一起给其它每位程序接受者一份许可证的副本，该被许可人就可以用任何媒体复制和发布他收到的函数库的完整源代码，也可以为转让副本的实际行动收取一定费用，也可以选择提供担保以换取一定的费用。

只要同时满足下面的所有条件，就可以按前面的要求修改函数库的一个或几个副本或它的任何部分，以此形成基于此函数库的作品，并且复制和发布这一经过修改的程序或作品:

a. 被修改的作品本身必须是一个软件函数库。

b. 必须在修改过的档案中附有明确的说明：被许可人修改了此一档案及任何修改的日期。

c. 必须让整个作品允许第三方在此许可证条款下可以免费使用。

d. 如果修改过的函数库的某个设备使用到了使用本函数库的应用程序所提供的函数或资料表格，却不是当此设备被呼叫时以参数列传入时，则必须确实做到，当应用程序不提供这样的函数库表格时，则此设备依旧能工作，且其执行的任何目的仍然有意义(例如，一个函数库的函数用来计算平方根，其目的是有完整的定义且与应用程序是无关的。因此，要求任何本函数会使用的，由应用程序所提供的函数或表格必须是选择性的：如果应用程序不提供的话，则计算平方根的函数必须依旧能计算平方根)。

这些要求适用于整个修改过的作品。如果能够确定作品的一部分并非本函数库的衍生产品，且可以合理地单独考考虑它与原作品分开的话，则当将它作为独立的作品发布时，它不受此许可证和其条款的约束。但是当被许可人将这部分与基于本函数库的作品一同发布时，则整个软件包将受到本许可证条款约束，其对于其它许可证持有人的使用范围扩大到整个产品，也就是软件包的每个部分，不管它是谁写的。因此，LGPL许可证条款的意图不在于索取权利，或剥夺完全由被许可人完成的作品的权利，而是履行权利来控制基于本函数库的集体作品或衍生作品的发布。此外，将与本函数库无关的作品和本函数库 (或基于本函数库的作品) 一起放在储存媒体或发布媒体的同一卷上，并不导致将其它作品置于此许可证的约束范围之内。

前面已经说过LGPL许可证是根据GPL许可证演变的。还有一个规定就是，开放源代码时，可以选用LGPL许可证，对于选用LGPL许可证公开的源代码，可以变更为适用GPL许可证，但却不能反向变更。LGPL许可证允许以目标码或可执行形式复制或发布本函数库，只要被许可人遵守前面的要求，并同时提供完整的相关机器可读的源代码，而这些源代码在一般习惯上用来做软件交换的媒体上散布。如果所发布的目标码是由指定的地点提供拷贝索取，那么由同一地点所提供等价的源代码拷贝索取可以算作源代码的发布，即使第三方不强求与目标码一起复制源代码。

一个程序若包含不经任何部分修改的函数库，但却是设计经由编译或连结的方式与本函数库一同工作者，称之为“使用函数库的作品”。这样的一个作品，严格地说，并非本函数库的衍生作品，因而不在本许可证的范围之内。然而，将“使用函数库的作品”与本函数库连结而产生可执行程序，则是本函数库的衍生品 (因为它包含了本函数库的一部分)，而不是 "使用函数库的作品"，因此其可执行程序包含在本许可证的范围内。当“使用函数库的作品”使用了函数库部分的标头档内容时，则此作品即使其源代码不属于本函数库的衍生品，但其目标码仍然是。这一点是否为真特别在是否本作品可以在不需要本函数库即可连结，或者是否该作品本身也是一个函数库时特别明显。

如果这样的目标文件只使用数字参数、数据结构层级与附属品、以及小宏和小内嵌式 (小于或等于十行) ，则此目标文件的使用是不受限的，不论是否它是合法的衍生作品。 否则的话，如果本作品是本函数库的衍生品，被许可人必须按规定下散布该作品的目标码。做为上述规定的例外情况，被许可人也可以将“使用函数库的作品”与本函数库结合或连结，以产生包含部分本函数库的作品，并在允许使用者自身使用时可以修改该作品，以及在对修改进行反组译除错的情况下，被许可人可以依照自己的选择散布该作品。

被许可人必须在每个作品的副本突显出如下的注意事项：本函数库在作品中被使用，以及本函数库以及它的使用是在本许可证的规范下。被许可人必须提供本LGPL许可证的副本。如果该作品在执行时显示版权声明，被许可人必须在其中包含本函数库的版权声明，以及指引使用者取得本许可证的副本。同时，被许可人必须做到以下其中一件事：

a. 必须将完整的机器可读的函数库源代码包含在该作品中，包括任何该作品使用到的改变 (这些改变必须在前述第 1 与第 2 款的要求下散布)；而且，如果该作品是一个与函数库连结的“完整的、机器可读的’使用函数库的作品’”，则要有目标码和（或）源代码，如此使用者可以修改本函数库且可以重新连结，以产生包含修改过的函数库的修改过的可执行程序。

b. 在与函数库连结时使用适当的分享函数库连结机制。一个适当的机制是： (1) 在执行时使用已存在于使用者的计算机中的函数库副本，而不是将函数库的函数复制到可执行程序里，以及 (2) 如果使用者安装了一份修改过的函数库，只要修改过的版本在接口上与该作品在编译连结时所用的版本是兼容的，则该执行程序可以与修改过的函数库运作良好。

c. 在该作品内提供书面报价，有效期不少于三年，以提供同样的使用者上述条款中的内容，费用不得超过该程序发布的实际成本。

d. 如果所发布的作品是由指定的地点提供拷贝索取，则由同一地点提供上述内容的等价拷贝索取。  

e. 确定使用者已经收到该作品的一份复制，或是被许可人已经寄给该使用者一份复制品。

对于一个可执行程序，其所需的“使用函数库的作品“的形式必须包括任何要从中再产生可执行程序时所需的资料与工具程序。然而，有一个特殊例外，其所散布的内容不需要包括任何一般与“可执行本程序的操作系统”的主要部分 (如编译器、核心等) 一起发布的部分 (不论是源代码或可执行码)，除非这些组成部分和可执行作品结合在一起。有一个可能情况是，这些要求与其它通常不与操作系统在一起的私有函数库的版权限制相抵触，这样的抵触表示被许可人不能将它们与本函数库一起用于被许可人散布的可执行程序中。

LGPL 许可证允许将使用本函数库的函数库设备，以及其它不在本许可证范围内的函数库，对等地放入一个单独的函数库中，并在基于本函数库的作品以及其它函数库在其它状态下同意可以个别散布，以及被许可人做到以下两点的情况下，被许可人可以散布此结合的函数库：

a. 将基于本函数库的作品单独不与其它函数库设备结合地，与此结合的函数库一同散布。该作品必须在上述条款的规范下散布。

b. 在此结合的函数库中明显地指出其中一部分的作品是基于本函数库，并且说明那里可以找到同样不具结合形式的作品。

 

Ⅲ、 MPL许可证

MPL(MPL 是The Mozilla Public License的简写)，最初是1998年初Netscape的 Mozilla小组为其开放源代码软件项目设计的软件许可证。MPL许可证出现的最重要原因就是Netscape公司认为GPL许可证没有好好平衡开发者对源代码需求与他们获得的利益。[注24]同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA认定的开放源代码软件许可证）。但是，相比而言MPL还有以下几个显著的不同之处：

（一）、MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。[注25]

（二）、MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。

（三）、对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。

（四）、对源代码的定义

在GPL许可证中，对源代码的定义如下：“源代码指的是对作品进行修改最优先择取的形式。对可执行的作品讲，完整的源码包括：所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的”原本”（原文为：“script”）。作为特殊例外，发布的源码不必包含任何常规发布的供可执行代码在上面运行的操作系统的主要组成部分（如编译程序，内核等）。除非这些组成部分和可执行作品结合在一起。如果采用提供对指定地点的访问和复制的方式发布可执行码或目标码，那么，提供对同一地点的访问和复制源码可以算作源码的发布，即使第三方不强求与目标码一起复制源码。

而在MPL（1.1版本）许可证中，对源代码的定义是：“源代码指的是对作品进行修改最优先择取的形式，它包括：所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的“原本”（原文为： “script”），或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”

（五）、MPL许可证中对于被许可人发布和修改的权利、义务同GPL许可证没有什么区别只是就修改的源代码以网络发布的形式有一个时间的要求，即该网页的保留时间不能少于12个月。

但是MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和怎么修改都得有描述。

 

Ⅳ、BSD许可证

BSD 许可证原先是用在加州大学柏克莱分校发表的各个4.4BSD/4.4BSD-Lite版本上面（BSD是Berkly Software Distribution的简写），后来也就逐渐沿用下来。1979年加州大学伯克利分校建立了BSD Unix，被称为开放源代码的先驱，BSD许可证就是随着BSD Unix发展起来的[注26]。BSD许可证现在被Apache和BSD操作系统等开放源代码软件所采纳。

相较于GPL许可证和MPL许可证的严格，BSD许可证就宽松许多了，一样是需要附上许可证的原文，不过比较有趣的是，它还要求将所有程序发展者的版权资料放上去，所以拿到以BSD许可证发行的软件可能会遇到一个小状况就是这些版权资料许可证占的空间比程序还大。

在所有开放源代码软件许可证中，BSD许可证可能对被许可人来说是最“宽容”的，因为它尽可能的赋予了被许可人使用源代码的权利。它的宗旨是：“这些就是源代码，做被许可人想做的任何事情，我们不会介意，只要被许可人在试用和销售与本源代码有关的产品时不要忘记标明我们的劳动。[注27]”只要标明了源代码的出处，被许可人在以下问题将不受限制：再许可问题、将这些源代码用在自己的程序中而按自己的要求进行程序的发布和软件的许可[注28]。所以说，对于要研究和借鉴源代码的软件人员来讲，能选用BSD开放源代码软件库中的软件是最合适不过的。

　

四、开放源代码软件许可证给我们的几点启示

 

（一）、开放源代码软件许可证的特点小结

前面我们分析了GPL、LGPL、MPL、BSD许可证。除此之外，还有NOKIA许可证、MIT许可证、APPLE许可证等等，通过对比研究我们可以发现，由于要达到向社会贡献源代码的目的，这些开放源代码软件许可证有许多的共同点，主要体现在以下几点：

（1）、开放源代码软件许可证都会规定在被许可人接受本许可证获得源代码之后，有将源代码再发布的义务，以促进开放源代码运动。

（2）、开放源代码软件许可证都有一个“不担保”（即No Warranty）条款。 由于源代码程序准予免费使用，在一般情况下，对程序没有担保。除非另有书面说明，版权所有者或其他提供程序的人们“一样”不提供任何类型的担保。不论是明确的，还是隐含的。包括但不限于隐含的适销和适合特定用途的保证。全部的风险，如程序的质量和性能问题都由被许可人来承担。如果程序出现缺陷，被许可人承担所有必要的服务，修复和改正的费用。

（3）、开放源代码软件许可证都会规定一些关于修改、复制和再发布的条款，目的也是在保证初始人权利的前提下，尽最大可能向社会贡献源代码。只是各许可证对授予被许可人的各项具体的权利略有一些差异，这可能与“开放源代码首创行动组织”OSIA对开放源代码软件许可证的认定只有原则性的规定有关。

至于不同点，只在于向被许可人授予的权利方面有比较细微的差异，为了便于表明几种开放源代码软件许可证之间的区别，我们用下面的表格表示出来：

 

           

 

许可证类别	是否允许可以同其他非开放源代码软件代码混合	是否可以将对源代码的修改不公开	是否可以不加任何限制的任意再许可
GPL 许可证	否	否	否
LGPL 许可证	是	否	否
BSD 许可证	是	是	否
NPL 许可证	是	是	否
MPL 许可证	是	是	否
APACHE 许可证	是	是	否

 

 

  摘自网络文章