当前位置: 教科文卫委员会

软件领域内自由与权利的博弈

——开源软件及其许可证问题分析

全国人大教科文卫委员会文化室 孙雷

中国人大网 www.npc.gov.cn日期: 2005-11-08浏览字号: 打印本页 关闭窗口

自上个世纪末,以Linux、Firefox和Apache为代表的开源软件的不断涌现和日益普及逐渐掀起了一场软件革命的浪潮。开源软件运动所倡导的“Copyleft”理念不仅改变了软件的消费市场,也对软件的开发和传播体制产生了直接的影响。在信息技术时代,如何应对开源软件已经成为我国民族软件产业当前所面临的一个日趋紧迫的课题。本文在对开源软件及其许可证进行介绍、分析和评论的基础上,提出我国民族软件产业在适当利用开源软件的同时,要充分注意开源软件许可证的约束,处理好与发展民族软件自主知识产权的关系。

一、源代码之于软件发展的重要性

源代码是软件编程技术发展到一定阶段的产物。它是用汇编语言或高级编程语言所编写的程序的原始表现形式。源代码是与目标代码相对应的概念。两者的区别在于后者表现为一系列“0”和“1”组成的机器可读的语言形式;而源代码则是特定领域的技术人员可“读和用”的语言形式。源代码在运行过程中由计算机编译器自动转换为目标代码。现有的技术手段也可将目标代码反向编译为源代码。

许多程序的源代码不仅包含陈述和运行指令,还包括记载程序开发过程以及反映程序设计人员观点和思路的评注。评注并不起到驱动计算机运行的作用,编译器在将源代码转化为目标代码的过程中自动将评注滤出。但评注可以帮助源代码阅读者了解程序开发人员曾经尝试过和放弃的方法、遇到和所解决的技术难题、程序设计人员以及程序运行的记录等内容。

如果将程序的运行结果比做制作一道英国菜的话,那么源代码就是这道菜英文的“菜谱”(见图例1)。对消费者而言,无论菜谱是用英文还是中文所写都没有什么意义,他们所希望得到的就是最终摆上餐桌的那道菜。同样,大部分程序的最终使用者也不会理会什么源代码或者目标代码,而是关心使用软件的运行是否会产生所希望得到的结果。但是,对英语国家的本土厨师而言,如果拿到了英文的菜谱,就可以依该菜谱做出这道菜,并且找出其中需要改进之处,从而使这道菜更加美味可口。相似的情况也发生在软件领域,如果程序员拿到了某一程序的源代码,就可以了解该程序设计的思路,找到其中存在的问题,排除故障,改进程序,使该软件在技术上更加完善。如果将改进后的软件推向市场,则必然会具有相当的竞争优势,对在先软件的销售构成威胁。所以,对在先软件权利人而言,公开了源代码也就是公开了软件的核心秘密,就会面临丧失市场优势的危险。这也正是许多软件开发商一直拒绝将软件的源代码公开的主要原因。

(图例1) 软件程序运行与菜肴制作之比较

英文菜谱→翻译(英译汉)→中文菜谱→厨师、厨用设施和调料→菜→  消费者

↓      ↓       ↓     ↓       ↓    ↓

源代码 → 编译器 →  目标代码→ 处理器和操作系统→运行结果→程序使用者

程序的源代码是开发设计人员智力劳动的结晶,它总是表现为文字和数字的有序排列组合,在形式上与文字作品极为相似。此外,对源代码最大的危害来自于未经授权的“复制”和“发行”,而这两种行为主要由版权法来进行规范。因此,版权法一直被认为是适合保护软件程序的知识产权制度。尽管计算机程序的“工具”特征以及版权保护时间过长等因素使利用版权制度保护计算机程序的做法不断受到质疑,但不可否认的是,版权体系逐渐接纳了计算机程序这一客体。随着Trips协议(Agreement on Trade-Related Intellectual Property rights,与贸易有关的知识产权协议)以及WCT(Wipo Copyright Treaty,世界知识产权组织版权条约)的出台,将计算机程序作为文字作品纳入版权保护体系已经在国际上形成共识。按照Trips协议和WCT的相关规定,计算机程序的源代码和目标代码都必须作为伯尔尼公约1971年文本所指的文字作品加以保护。我国著作权法一直将软件作为保护的客体,国务院发布的“计算机软件保护条例”明确将计算机源程序和目标程序都列为保护对象。

二、对开源软件概念的理解

开源软件是自由软件的一个分支。它是针对商业软件开发者为保持其市场优势而不公开其源代码的状况所提出的关于软件开发与传播的理念。其核心在于通过规范软件许可证来要求软件开发者将源代码公之于众,使受众能够获得源代码并自由地使用、修改和再传播。目前,软件业界把在经OSI(Open Source Initiative, 开源软件促进会,下简称OSI)认证过的许可证下发布软件认定为开源软件。

自从将Bruce Perens所撰写的“在Debian自由软件纲领”(the Debian Free Software Guidelines)作为开放源代码第一个版本(version1.0)的定义以来,OSI不断根据形势的发展对开放源代码的定义进行”升级”。目前OSI已经推出10个版本的开放源代码的定义。根据最新版本(version1.9)的规定,发布软件时必须符合如下条件,才能获得使用OSI关于开源软件的证明商标(斜体字部分为OSI关于开放源代码的定义原文,正常字体部分为笔者所加的评析):

(1)、自由发布。许可证不得限制任何人以包含在整体软件中一个部件的形式对软件进行出售或者分发(综合软件包含不同来源的程序)。许可证不得索取版税或者出售的费用。

值得注意的是,OSI在其官方网站明确表示如果“通过提供服务、打印的文件、或便捷的媒介以及对经测试符合质量的软件提供认证等方式对代码添加了额外的价值”,则可以收取费用。直白地讲,就是不得对授权使用代码进行收费,但如果将代码与其他服务相结合则可以对整个“服务包”收取费用。此外,OSI针对开源软件作为某个软件子程序的情况也提出了要求。即,子软件的许可证不得“另立山头”,妨碍“母软件”的发行。

(2)、源代码。(发布的)程序必须包括源代码,必须允许源代码与其编译形式一同发布。如果某种形式的产品在发布时不包含源代码,则必须有种众所周知(well-publicized)的方式使他人能够在不高于合理复制费用的条件下获得源代码,通过internet网免费下载是比较理想的方式。源代码必须以程序员能够修改的方式提供,不得故意使源代码变得模糊。通过预处理器或者翻译器输出等借助于媒介形式都是不允许的。

“封闭源代码”的行为是开放源代码运动所要攻击的“靶子”。因此,加入开源社区、成为开源软件的基本前提就是要使公众获得,或者能够获得软件的源代码。而且,源代码必须以程序员能够读懂和修改的方式提供。当然,对于那些以机器代码编写程序的程序员提出此项要求则失去了意义。

(3)、衍生作品。许可证必须允许修改和产生衍生作品,同时必须允许修改后的作品和衍生作品在原软件许可证条款下发布;

使公众能够获得源代码并进行修改从而促使软件不断完善是开源软件运动的宗旨之一。因此,开源软件的许可证必须要“允许修改和产生衍生作品”,否则,开源软件运动的目标也就无法达到。同时,为使开源软件这种传播方式能够继续下去,而不是仅停留在第一次修改,许可证要允许原创软件许可证继续适用于所有衍生作品。这是开源运动最为突出的一个特点。

(4)、作者源代码的完整性。除非许可证允许在构建软件时为修改程序而与源代码一同发布“补丁文件”,否则许可证不得限制软件以修改版的形式发布。许可证要明确许可基于修改后的源代码所产生的软件的发布。许可证可以要求衍生作品采用与原软件不同的名称或者版本号。

开源软件运动鼓励作者尽早公布软件(即使该软件不完善),通过开源社区公众的共同努力来使该软件不断变得完善,而不是让作者个人绞尽脑汁来耗费许多时日来推出一个相对完善成型的软件。所以,开源社区不允许作者保留作为版权人所享有的许可或禁止他人修改代码的权利。但从另外一个角度来看,对软件中存在的问题毕竟是原创作者比较了解,具有一定修改上的优势,因此开源运动还要使作者对其软件享有一定的优先性修改性权利,允许其在发布软件时同时附带一些补丁文件,而排除社区内他人的修改。为便于将修改后的软件与原创作品进行区分,可以对衍生作品使用不同的版本和名称。

(5)、不得对任何人或者组织有所歧视。

(6)、不得对任何应用领域有所歧视。许可证不得限制任何人将程序用于特定的领域。例如,许可证不可限制将程序应用于商业或者基因研究。

开源软件运动旨在尽可能地拓展开源社区的智力资源以不断提升软件的质量,所以不能将某些人员和组织排除在开源社区之外。同时,开源软件的应用并非仅局限于某个行业,而是要覆盖所有领域,所以许可证也不得将特定的领域排除在外。

(7)、许可证的发布。附于程序上的权利必须适用于所有再发布的程序,而毋须执行由其他组织制定的附加许可。

(8)、许可证不得针对某一产品。附于程序上的权利不得依赖于其作为某一特定软件的组成部分(的“身份”)。如果一程序从发布(的软件)中分离出来并依据该程序的许可证使用和发布,那么所有该程序再发布时的受众都应当具有与原软件一同发布时相同的权利。

为防止软件的版权人在软件传播过程中主张权利,打断开源软件传播的链条,必须要对原作者和软件受众间不断延伸的“传播链条”的安全进行保障。

(9)、许可证不得限制其他软件。许可证不得对与其辖下软件一同发布的软件进行限制。例如,许可证不得主张在相同媒介上发布的软件必须是开源软件。

开源软件并非是软件行业目前单一的开发与传播模式。如果开源软件只是在封闭的圈子中开发和交流,那么它的受众范围和影响力就必然受限制。所以,为推广开源软件的应用,开源软件的许可证不得对软件发行媒介上的其他软件的形式进行限制。

(10)、许可证必须保持技术中立。许可证的任何条款都不得基于个别的技术或接口的设计。

技术方式不得成为开源软件运动发展的阻碍。也就是说,不得以点击-完成(click-wrap)形式为代表的许可证授权形式来妨碍开源软件的传播。

从OSI组织所提出的开源软件的定义来看,开源软件并非仅仅是对源代码的公开方式进行限定,它还对软件的发行、修改以及技术等问题进行了规定。开源软件运动实际上是要建立一整套软件开发与传播的体制,彻底改变以往商业软件的流通模式。

三、开源软件许可证问题分析

(一)开源软件许可证与商业软件许可证的区别及主要特点

在20世纪80年代以前,计算机软件对硬件具有很强的依赖性,往往要根据硬件的特点来设计专门的软件。对当时软件开发模式最形象的描述就是量体裁衣般的“裁缝式”。但随着计算机硬件标准化的推广和个人电脑的普及,软件能够得以批量生产和销售,在不同的计算机上得以应用。这使得软件可以被无限地复制和被不特定的人同时所使用的特性充分地表现出来。软件的流通也逐渐形成了有别于有形商品流通的模式。一般情况下,有形商品的买卖往往是在钱货两讫后出售人对该物品彻底失去所有权,但受众在获得软件时并不导致软件版权人对版权的丧失。在许多情况下,软件的受众只是获得了被许可使用的权利,这种权利可以同时被许多人享有。实践中,软件版权人都会通过发放许可证对被授权人所享有的权利、需履行的义务以及违约责任做出明确的规定,从而在授权人所保留的权利和被授权人的权利之间划出一道清晰的界限。

一般而言,对普通商业软件(GBL General Business Licenses)发放许可证的目的在于实现商业利益。而达到这一目的有效方式之一就是保证充足的用户数量。所以GBL许可证都把严禁被授权人对所购买的软件进行未经许可的复制和传播作为一项重要内容。同时,为减少竞争压力而保持市场优势,版权人也会封闭其源代码,禁止他人对软件进行修改和再传播。但开源软件所追求的却是促进软件的共享和重复利用,从而推动软件技术的不断进步和完善。而实现这一目标的有效方式就是让程序中存在的问题充分地暴露出来,然后让开源社区的民众进行解决。所以,开源软件的许可证在承认作者版权的基础上,强调源代码的公开以及不受版权人约束的复制、修改和传播。本文列表将开源社区最为常用的GPL许可证与WINDOWSXP软件许可证进行比较分析。(见附表1)

得到OSI的证明商标使用权是成为开源软件的象征。OSI对开源软件所必须具备的10项要求全部针对软件许可证而言。实际上,开源运动正是抓住了许可证这一决定软件流通的根本性因素,将其作为带动开源运动列车前进的动力车头。

目前,经OSI认证的符合开源软件标准的许可证已达58个(截止于2005年8月)。这些许可证在对软件受众的权利和义务的规定上存在着一定的差异,但同为开源社区的许可证,它们之间存在着许多共同的特点。这主要体现为以下几个方面:

承认版权。实际上,开源软件许可证是基于版权制度上的一种对抗普通商业许可证的授权表现形式,它并非是对版权制度的叛逆。GPL、LGPL,MPL等众多许可证的起始语中明确表示:对程序或者程序库提供版权保护;一些许可证还明确将授权人定位于版权人(例如,BSD许可证)。

内容主要集中在软件的复制、发行和修改上。大部分许可证都允许被授权人对软件进行复制和再发行;允许对软件进行修改,并对修改后的作品进行再发行。

软件发行时要提供源代码或通过一定的方式使受众能够得到源代码;

具有免责条款。不对软件质量进行担保,也不对因使用软件所造成的任何后果承担责任。

交互式的许可。一般意义上的商业软件许可采取的都是单向式许可,基本不涉及使用者向原作版权人发放许可的问题。但一个开源软件投入到开源社区后,社区内该软件的受众都可以对其进行修改并产生衍生作品。对这些在后软件,原软件版权人也有权进行合理使用,自然获得许可。

免费许可。在商业软件领域,能够获得许可的一个关键条件是版权人的经济要求能否得到满足。但在开源社区,软件许可证是否单独对软件代码索取版税或者出的费用是判断某一软件是否是开源软件的一个显著标志。

一般商业软件的许可中使用者“不得之行为”占很大比重,开源软件许可证侧重于限制版权人的权利而非规定使用者的义务。这实际上也是“Copyleft”理念在开源社区得到贯彻的一个最好印证。

(二)主要开源软件许可证

开源社区中,被使用较多的是GPL、BSD、以及MPL许可证;使用GPL和BSD许可证的软件数量更是达到了所有开源软件的70%。 通常认为:LGPL是GPL类别的许可证,两者同属自由软件许可证;MIT是BSD类别的学院派开放许可证;而MPL则是商业开放许可证的代表。

1、GNU GPL(General Public License,下简称GPL)许可证

GPL是开源社区使用最多的一个许可证,也是Free Software Foundation(下简称FSF)所极力推祟的一个许可证,FSF的精神领袖Stallman甚至认为所有的自由软件都应当采取这一许可证。GPL仅对软件作品所涉及到的复制、发布与修改的权利做出了规定,并未涉及软件版权人其他方面的权利。它旨在通过确保源代码的公开使软件受众能够自由地复制、修改软件以及发布“基于原程序的”作品。它的主要内容实际上并非是阐述版权人的授权,而是讲对其权利的限制和软件受众的权利和义务。因此,与其说GPL是版权许可协议,还不如说是受众对软件的合理使用协议或是版权人进入开源社区时对其权利进行限制的声明。综合而言,GPL主要包括以下几方面的内容。

1)自由发布程序。条件是在所发布程序的副本上都必须明显和恰当地做出完整无损的版权声明和质量不担保声明,并和程序一起给每个其他的程序接受者一份许可证的副本。(section 1)

2)自由修改程序。条件是:a)明确说明修改了文件并注明修改日期;b)允许第三方按许可证条款免费使用所发布和出版的基本程序的作品;c) 如果修改的程序在运行时以交互方式读取命令,则必须使它在开始进入常规的交互使用方式时打印或显示声明:包括适当的版权声明和没有担保的声明(或者你提供担保的声明);用户可以按此许可证条款重新发布程序的说明;并告诉用户如何看到这一许可证的副本。(例外:如果原始程序以交互方式工作,它并不打印这样的声明,你的基于程序的作品也就不用打印声明)。(section 2)

3)“传染”其他程序。包含衍生作品的程序(基于修改和翻译GPL许可证辖下的程序所产生的作品)要置于GPL规则下。这就是所谓的GPL规则的“病毒效应”。但如果将整体作品中的非衍生产品独立发布时,该部分程序可以不受GPL规则的约束;将基于程序的作品(衍生作品)同其他程序一起放在存贮体或发布媒体的同一卷上,其他作品也不会置于GPL规则之下。(section 2)

4)采取“使用”生效。只要软件受众修改或发布程序(或任何基于程序的作品),就表明其接受了GPL许可证。(section 5)

5)不对质量和使用软件的后果进行担保。(section 11)

2、BSD许可证

BSD(Berkely Software Distribution)许可证是开源社区使用较为广泛同时也是对软件的开发者和使用者约束最少的许可证之一。它的问世与UNIX系统在上个世纪70和80年代的广为应用有着直接的渊源,在一定程度上反映出在当时软件商业化的大环境下自由软件与商业软件的异化与分裂。1977年,California大学(位于Berkely) 一个名为Bill Joy的学生开发出第一版BSD软件(UNIX的衍生作品)。随后,各种版本的BSD软件不断涌现,并获得了广泛的支持。但由于早期的BSD软件中包含UNIX的源代码,所以BSD源代码的分发要从UNIX当时的版权人AT&T获得许可。随着AT&T索要的许可证费用不断增加,一些希望能够使用BSD代码为PC生产基于TCP/IP联网的厂商产生了将AT&T代码从BSD中分离出来的市场需求。1992年,一个完全没有AT&T UNIX代码的386/BSD发布,标志着BSD软件正式“无牵挂”地进入开源社区。

BSD许可证的条款很少。其核心内容在于允许被授权人以源代码或者二进制代码的形式发布修改过的或者未被修改过的程序代码;但是要发布致谢声明和不担保声明。此外,BSD许可证为防止开源社区对基于同一原始代码的各种不同版本的软件产生混淆,做出了禁止被授权人在衍生作品上署组织和贡献者的名称或利用这种方式对衍生作品进行促销的规定。BSD许可证于1998年被修改。修改后的BSD许可证取消了致谢声明的要求。

BSD许可证问世后即在开源社区得到广泛使用。BIND、APACH以及SENDMAIL等软件都采用了该许可证进行发布。这主要是因为该许可证为被授权者设定的义务很少,相对营造了一个自由的空间。尤为值得一提的是,BSD许可证具有Non-Copyleft的特性。即,BSD许可证并没有象GPL许可证那样要求所有基于其辖下代码的作品也必须成为自由软件,必须回归开源社区。这就为BSD辖下代码的商业性利用大开了方便之门。但因此引发的一个问题是:如果衍生作品不回归开源社区,就会在开源社区形成一种“只出不进”的现象,长此以往,开源社区的智力资源就会逐渐枯竭。Apache的奠基者之一Brain Behlendorf曾呼吁使用Apache软件的公司Apache进行再投资以帮助Apahce的成长。

3、MPL许可证

MPL是the Mozilla Public License的缩写。该许可证原是Netscape下的Mozilla小组为一个开放源代码软件项目设计的软件许可证。MPL在不对软件质量进行担保、发布版权声明以及生效和终止条件等方面借鉴了GPL许可证的内容,但同时也充分考虑了开源软件的商业用途,做出了一些与GPL规则相异但受到商业软件使用者欢迎的规定。它与GPL许可证的区别主要体现在以下几个方面(修改后的MPL许可证version 1.1):

1)发布者可以有选择性地公开源代码范围。MPL规则所约束的仅是“以源代码方式发布的文件”,这就意味着软件发布者可以控制程序代码的公开程度,有权决定公开多少程序的源代码。在实践中,不想将代码完全贡献给开源社区的人就可以在源代码代码库上加一个接口,除了接口程序的源代码以MPL许可证的形式贡献给开源社区外,源代码库中的代码则不置于MPL规则下。(section 3.4(b) and Exhibit A)

2)允许被许可人将经过MPL辖下代码同其他类型的代码混合从而形成更为强大的软件,但其他类型的软件仍然可以不受MPL规则的约束。例如,Netscape 6 and 7就是在Netscape组件下作为私有软件发布的。(section 3.7)

3)不明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。(section 3.4(a) and 2.1(b))

上述三种许可证的主要区别可见附表1。

是否可与非自由软件结合

是否可以修改软件而不将其返送至原作者

是否允许被他人重新发布

是否许可原软件的版权人在他人修改版上享有特权

GPL

BSD

MPL

(改编自:www.perens.com/articles/osd.html)

(三)、开源软件许可证泛滥所引发的主要问题及反许可泛滥行动

OSI在开源社区的地位和作用不言而喻。在一定程度上讲,某一许可证能否获准使用OSI的认证标记(证明商标)已经成为该软件是否是开源软件的一个判断标准。近期以来,OSI在其官方网站上不断发布反对“许可证泛滥”(License Proliferation)的政策性文件,针对开源软件许可证泛滥所引发的一些问题提出了初步的解决方案。这意味着OSI在成立7年后准备着手对开源软件许可证的发放政策进行一次调整,而这无疑会对开源社区产生直接的影响。

1、背景

在成立之初,OSI为把开源软件开发者和使用者更好地团结在一起并尽可能多地在开源社区和其他社会群体之间搭建桥梁,在开源软件认证标记的审核发放上采取了较为宽松的政策。只要符合开放源代码定义的许可证认证申请基本都能够获得该组织的批准。其直接后果就是经OSI认证的开源软件许可证的数量迅速增加。如前所述,目前经OSI认证的开源软件许可证已经达到58份。

经OSI认证的许可证虽然都打着开源社区的旗号,但在具体内容上存在着一定的差异。它们的区别主要体现在对软件原始版权人和修改者的权利限制、作品(包括衍生作品)发布的条件以及与其他许可证的关系等问题的规定不同。GPL、BSD以及MPL许可证间的差异在各种许可证中较有代表性。一般认为,GPL许可证是开源社区中最正统也是对版权人权利限制最为严格的许可证。它侧重于保护软件传播过程中使用者复制、发行和修改代码的自由,要求所有基于程序的作品发行时仍然必须GPL许可证。其目的就是使“衍生作品能够继续保持自由的状态,从而在整体上促进软件的共享和再利用”。BSD许可证条款很少,其实质性内容仅包括“允许(使用者)分发和修改软件并以源代码和目标代码的形式对修改后的软件再发行”以及“发布‘版权声明’和‘对软件质量不担保声明’”等。它没有对衍生作品发行时适用何种许可证以及作品是否可以同其他软件代码结合进行限制。相比较而言,BSD许可证为软件的修改和传播营造了更为自由的空间。MPL许可证允许软件的开发者和修改者将源代码有选择地贡献给开源社区,对不希望公开的代码可以按其意愿进行保留。该许可证还允许使用者将其辖下的代码与其他代码相结合开发出更强大的软件,而且对结合后的作品使用何种许可证进行发布没有限制;但结合后作品中原适用MPL许可证的代码仍然要符合MPL规则。可以看出,MPL许可证在限制代码传播和结合的问题上没有象GPL许可证那样严格,但也没有象BSD许可证那样给予软件原始开发者和修改者以高度的自由。OSI认为MPL许可证是个“中间路线”执行者。

2、许可证泛滥所引发的一些问题

促进代码的充分结合从而产生更强大的软件是推进开源运动的一个重要技术手段。但开源社区内部分许可证间“不兼容”的特性却为代码的再结合和利用造成了很大的妨碍。对某些许可证而言,如果将它们辖下的代码进行结合,就会违反其中某个许可证的规定。例如,将GPL辖下的源代码与MPL辖下的源代码结合就可能造成两个许可证间的冲突。因为MPL许可证允许将其辖下的代码与其他许可证辖下的代码结合,但结合后的作品中原适用MPL许可证的代码仍然要适用MPL许可证;而根据GPL规则,与GPL许可证辖下代码相结合产生的作品在发布时必须要适用GPL许可证。这就产生以下的问题:结合后的作品是否可以采用GPL以外的许可证进行发布?结合后的作品中原处于MPL辖下的代码是适用MPL还是GPL许可证?MPL与GPL许可证间的这种冲突使那些倾向于MPL许可证同时又畏惧严厉的GPL许可证的软件使用者对GPL辖下代码望而却步,不敢将这种两种许可证辖下的代码进行结合。而这就会直接影响开源软件的共享和进步。

此外,有相当数量的开源软件许可证要求代码再发布时必须附加致谢声明。例如,Apache Software License(Version 1.1)许可证就要求软件代码再分发时必须含有“这一产品包含由Apache Software Foundation开发的软件”的致谢条款。修改前的BSD许可证(Version 1.0)也曾做出类似的规定。实践中,软件的再分发者往往将被致谢人改为自己,然后与原致谢声明一起随同软件代码进行发布。这就造成了开源软件在传播一段时间后经常包含多个致谢条款的现象。FSF工作人员就曾经在1997版的NETBSD软件中发现了75个不同版本的致谢声明条款。这实际上为软件的传播增加了一种不必要的负担。

还有,一些不能重复使用的许可证也开始在开源社区出现。开发者为软件特制一份许可证在商业软件发行领域是一个普遍的现象。这种许可证仅对该软件或者该开发者所发行的软件适用。现在这种做法也被一些软件公司引入到开源社区。IBM公共许可证就是一个好的例证。该许可证将其使用范围仅限定在该公司所发布的软件和基于该公司软件的作品上,开源社区的其他软件无法适用该许可证。如果对这种做法不加干预的话,开源软件许可证的数量就很有可能随着进行开源社区的软件公司数量的增多而持续上升,在开源社区内就会形成越来越多的封闭的小社区。

3、FSF和OSI的反许可证泛滥行动

许可证泛滥所引发的上述问题已经引起了开源社区的关注。历来将GPL规则视为开源社区“宪法”的自由软件基金会(Free Software Foundation,下称FSF)已经开列出与GPL许可证不兼容的许可证清单,Apache(Version 1.0、1.1、2.0)、IBM、MPL以及修改前的BSD许可证都“榜上有名”。在这份清单中,FSF还注明了它认为不符合自由软件标准(Non-Copyleft)的许可证。但由于FSF并没有象OSI那样获得对“自由软件”或者“开源软件” 认证标记(证明商标)的批准使用权,所以FSF在对许可证约束问题上显能有些无力,只能对许可证的使用进行倾向性推荐,而不能象OSI那样通过认证标记对许可证的发放进行控制。

OSI已经拟定出初步的方案,准备开展一次“反许可证泛滥”行动。该方案的主要内容是成立专门委员会对其认证过的许可证排列等级。所有已获OSI认证的许可证将会被分为“首选的”(Preferred)、“推荐的”(Recommended but not Preferred)和“未获推荐的”(Not Recommended)三个等级。但OSI并不是想通过此次行动收回某些许可证使用其认证标记的权利。所以,即使被归为“未获推荐”等级的许可证也仍然可以继续使用OSI的认证标记。此外,OSI还将进一步严格认证标记的核发标准和程序,并引入“公众评判”机制。那些仅仅符合开源软件定义(OSI所提出)的许可证认证申请将不会得到批准。按照OSI的方案,以后获得OSI认证的许可证必须符合以下条件:

具有非重复性。对那些仅仅符合开源软件定义但并没有真正解决问题的许可证将不会获得认证。

必须书写清楚、简单易懂。许可证是为普通民众而非律师服务,那些虽然在技术上没有问题并且符合开源软件的定义,但特别复杂、让人感到困惑甚至是专业人士亦不知其所云的许可证将不会获得认证。

能够重复使用。如果许可证包含个人、组织或者软件项目的名称,则必须在附件中注明:发布者和其他组织的名称可以在不改变许可证条款的情况下被更改。该许可证不能只为某一公司或者销售商服务。

利于促进代码的再利用。

4、MPL的命运

MPL是开源软件许可证中的后起之秀。从1998年起,使用该许可证的开源软件数量显著增加。这主要是因为该许可证在源代码的公开程度以及与其他代码结合的问题上给予开发者和修改者以一定选择的自由。而且,该许可证还要求软件开发者和修改者即使在取得软件专利的情况下也必须允许被许可人按MPL规则使用其源代码,而不得以专利权对抗使用者。这就避免了开源软件的使用者卷入专利纠纷,从而增加了使用软件的“安全系数”。

但是,MPL许可证在近期却遭到了OSI的敌视。OSI在其发布的一份关于“许可证泛滥”的文件中,多次以反对的语气提到该许可证。该文件还明确提出新的OSI认证标记发放政策将不会支持MPL类许可证。可以推断,OSI的分级制度出台后,MPL许可证很有可能被列为“未获推荐”的许可证。这就意味着今后与MPL相类似的许可证在申请使用OSI的认证标记时将不会被批准,MPL所代表的软件传播模式将不会被OSI所接受。而这背后的原因极有可能是因为它与GPL规则所谓的不兼容。

OSI对MPL的这种态度引发了不同的声音。有的学者指出,BSD对代码的放任程度要高于MPL,OSI并没有对其采取敌视态度,因为BSD与GPL兼容;而以MPL与GPL不兼容为由反对MPL是个骗局,其目的就是想让GPL规则“一统天下”,取缔MPL及其他与GPL不兼容的开源软件许可证。CA(Computer Associates)等组织在解决开源软件许可证泛滥这一问题上的思路也与OSI产生了分歧。CA提议建立一个适用于所有开源软件的标准化许可证模板,而不是象OSI那样推荐一些许可证,打击另一批。

四、结论

如果说OSI过去的工作侧重于不断扩大开源社区的对外开放程度,让更多的人加入开源社区,壮大开源社区的力量;那么现在OSI工作的重中之重是加强内部整顿,治理各种许可证“诸候割据”的现状,清除各种许可证辖下软件代码的流通障碍。从目前OSI所采取的政策上看,许可证数量上升的趋势将会得到一定的抑制,但同时也会使人们在进入开源社区时失去许多选择的机会。在OSI所进行的这次“反许可证泛滥”行动中,GPL规则在FSF的支持下会发挥出一定的“宪法”作用;而MPL类许可证则会被OSI列为整顿的重点。应当注意的是,MPL许可证问世后得到了一定的支持并被开源社区所接受。这说明开源社区对这种代码流通模式在一定程度上是给予肯定和支持的。笔者认为,在现阶段采取措施解决许可证泛滥所引发的问题是必要的,但OSI在开展这次行动时应当思考这样一个问题:是让软件在符合开源软件定义的前提下拥有更多的、可选择的流通模式,还是让时间回到1998年以前?那时,只有GPL没有MPL。

不得对软件代码的许可使用收取费用(服务包作为整体可收费,但价格相对商业软件还是相当的便宜)的要求以及公开源代码的规则使开源软件具有商业软件所无法比拟的“诱人之处”。社会公众作为使用者(非修改者和再次开发者)可以从使用开源软件的过程中获得许多便利(低廉的价格、相对稳定的性能等)。但应当看到,在开源社区,并不是只有使用软件的自由而勿需承担义务。进入开源社区意味着“入乡随俗”,而这个“俗”不单单是为自身的需要自由使用和修改软件程序,同时意味着基本这些程序所产生的新的智力成果往往要贡献给开源社区,允许其他开源社区成员进行自由的使用和修改。这给一直提倡“自主知识产权”的我国民族软件产业这样一个警示:不能过度指望在开发开源软件的基础上获得私权,“自主知识产权”的获得主要还得依靠自身的努力。但这并不意味着我国的民族软件产业应当对开源软件“敬而远之”。笔者认为:以LINUX为代表的开源软件已经在“WINDOWS”之外为软件业的发展提供了另一个“平台”,如何充分利用这个平台发展我们的工具软件和系统软件是我国民族软件产业所应侧重考虑的一个问题。同时,国内民族软件产业在开发利用开源软件时,要认真研究并慎重选择许可证,BSD和MPL等相对宽松的许可证辖下的软件应当作为列为考虑的重点。


附表:                 GPL与WINDOWS XP家庭版最终用户许可协议部分条款比较

比较内容

GPL

WINDOWS XP

适用客体

程序及所有基于程序的作品。

产品:包括计算机软件,还可能包括相关介质、材料、联机或电子文档及基于INTERNET的服务。

授权范围

复制、发行和修改(含翻译)。

安装、使用、限制性转让和提供服务等方面。

主要授权

内容和

所附条件

复制和发布。受众可以用任何媒介复制和发布收到的原始程序的代码,只要他在每一拷贝上明显恰当地做出版权声明和不担保声明,并且保持此许可证和不担保声明完整地提供给其他软件受众。

修改。受众可以修改程序或其中的部分,只要他在附件中声明了修改的行为并注明了修改的日期;并且允许他人对其作品(程序的全部或一部分,或衍生作品)按许可条款自由使用;同时还要保证他人以交互方式使用程序时能够得到此许可证的拷贝而且能看到版权声明和无担保声明、可按此许可证证重新发布程序的说明。

在单一计算机上安装、使用、访问、显示和运行产品的一个副本。不得允许任何“设备”使用、访问、显示或运行“工作站计算机”上的其它可执行软件。唯一的例外是:如果为获得文件和打印服务、INTERNET信息服务和远程访问,可以允许最多5台计算机连接到计算机上使用产品服务。

生效条件

修改或发布了程序或者基于程序的作品。单独的程序运行并不启动GPL。

安装、复制或以其他方式使用产品。

公开源代码

程序和基于程序作品的发布者要提供软件源代码。

不得对产品进行反向工程、反编译或者反汇编。法律另有规定的除外。

终止条件

未按GPL条款的规定复制、修改和发布程序。但该终止仅是对特定的行为者而言,不影响其后继者,只要他们继续履行GPL条款。也就是说,不会因为某一环节的脱节而影响某个GPL规则约束下的的软件的传播。

未遵守协议的各项条款。

授权模式

所有的受众都直接从原始许可证发布者处、而非程序的直接提供者处得到许可。也就是说,按GPL规则,对程序和基于程序作品进行复制、修改和发布的授权许可始终呈一对多的扇形模式。

扇形模式。软件购买者从MS处得到许可。

免责条款

程序的质量和性能所引起的一切问题由受众来承担。在任何情况下,版权所有者和任何按GPL规则修改和发布程序的人都不至受众的损失承担责任。

有限保证。在中国,MS只对下列行为做出保证:1、收到产品后90日内产品符合随附材料所述功能;2、提供有关书面材料所述的支持服务。

客户所享有的补偿有两种:1、退还已付价款;2修正或更换不符合MS有限保证的产品。

补偿金额以5$或者为软件产品实际支付的价款中的高者为准。

修改与升级

可以在GPL规则的约束下使用修改后的版本以及原始程序。

要先获取由MS升级产品的使用许可,但不得继续使用使您具备原产品。

Copyleft是针对Copyright所提出的概念,一般翻译为“反版权”、“版权属左”、“版权属无”、“公共版权”或“版责”。它是将一个程序成为自由软件的全局方法,同时也使得这个程序的修改和扩展版本成为自由软件。

也有一种观点认为:无论以何种语言编写的源程序,都是源代码;如果源程序系直接以机器可读的代码编写,则源代码与目标代码相同。(Ferris 法官在John Richardson Computers Ltd vs Flandersg一案中就提出过此种观点。见,Rowland D and Macdonald E,“Information Technology Law”,宋连斌 林一飞 吕国民译,“信息技术法”,武汉大学出版社,第2版,第15页)。笔者认为,在源代码和目标代码都以机器可读形式存在的情况下,讨论源代码的问题已经失去了意义。在现阶段,绝大部分源程序的编写都采取了汇编语言或者高级语言,所以应当将源代码的概念限制在使用非机器可读的汇编语言或者高级语言之内。

Greg R Vetter,“The Collaborative Integrity of Open Source Software”,Utah Law Review, 2004,P584.

同上注,P580。该文用在日本烹饪德国“巴伐利亚风味鸡”(Bavarian-style Chicken)为例来阐述源代码和目标代码的关系。本文用图示的方法加以说明,并结合程序源代码是由英文编写的实际状况将该例改编。本段以下部分论述完全脱离了该文。

对软件进行版权保护并不意味着软件不能享有其他知识产权制度的保护。实践中,在美国等软件技术领先的国家,对软件进行专利保护已经初露苗头。此外,采取合同及商业秘密也经常作为软件保护的手段。韩国为代表的一些国家还通过专门立法来保护计算机软件。本文集中讨论源代码的版权保护问题,所对专利、商业秘密、专项保护等问题将不予讨论。

见Trips协议第10条第1款和WCT第4条。

我国修改后的计算机软件保护条例第三条第(一)款规定:计算机程序,是指为了得到某种结果而可以由计算机等具有信息处理能力的装置执行的代码化指令序列,或者可以被自动转换成代码化指令序列的符号化指令序列或者符号化语句序列。同一计算机程序的源程序和目标程序为同一作品。

自由软件联盟的精神领袖Stallman认为,自由软件中所指的自由是指使用者使用、复制、散布、研究、改写、再利用软件的自由。具体而言是指:

不论目的为何,有使用该软件的自由(自由之零)。

有研究该软件如何运作的自由,并且得以改写该软件来符合使用者自身的需求(自由之一)。取得该软件之源码为达成此目的之前提。

有重新散布该软件的自由,所以每个人都可以藉由散布自由软件来敦亲睦邻(自由之二)。

有改进再利用该软件的自由,并且可以发表改写版供公众使用,如此一来,整个社群都可以受惠。如前项,取得该软件之源码为达成此目的之前提(自由之三)。

见自由软件联盟网站,http://www.fsf.org/philosophy/free-software-for-freedom.html.

OSI在成立后即成功地将open source及图案注册为证明商标。想使用open source这一标志的软件都必须向OSI提出申请。欲使用该标志的软件可以使用已经被OSI认证过的许可证,也可以由作者自行拟定许可证然后经OSI批准。OSI将通过委员会审查和公众审查相结合的形式来对该软件许可证是否符合开源软件的定义进行评判。经批准的软件可以使用OSI Certified的标志,同时必须要在软件发布时不加修改地附加上以下声明中的一种:(1) 此软件是经OSI认证过的开放源代码软件。(2)经OSI认证过的开放源代码软件。如果不选用上述两个文字声明,也可以选择使用

data src=

这一标志。

见OSI官方网站中“FAQ”栏目,http://www.opensource.org/advocacy/faq.php

OSI,“The Approved Licenses”,http://www.opensource.org/licenses/.

OSI,“License Proliferation”,http://opensource2.planetjava.org/docs/policy/licenseproliferation.php,section: Background.

Terry J.Ilardi, “Mass Licensing-Part2:Open Source Software Licensing”, Patents, Trademarks, and Literary Property Course Handbook  Series, “Practicing Law Institute 2005”,P291,292.

Maureen O’Sullivan, “Making Copyright Ambidextrous: An Expose of Copyleft”, Journal of Information, Law and Technology, Issue 1 2002, P9.

GNU General Public License, version 2, section 10.

Mozilla Public License, version 1.1, section: 1.10(Original Code) & 1.11(Source Code) and section: Exhibit A.

Mozilla Public License, version 1.1, section 3.7(Larger Works).

同上注12, section: Towards a Solution.

一种例外的情况是,MPL(version 1.1)辖下的代码同时适用了GPL许可证。修改后的MPL(Version 1.1)增加了Multiple-License Code条款(section 13)。即,允许软件的原始开发者对MPL辖下的部分代码设定多重许可。即,原始软件开发者可以在Exhibit A中指定NPL或者其他许可证供被许可人选择,被许可人在指定的许可证范围内可以选择一许可证对MPL辖下的部分代码进行使用。这就可以使MPL和GPL辖下代码的结合不冲突。

Mozilla Public License, version 1.1, section 3.7(Larger Works)

GNU General Public License, version 2, section 2.

Free Software Foundation, “The BSD License Problem”, http://www.gnu.org/philosophy/bsd.html.

根据IBM公共许可证(version 1.0)定义部分的规定,“原始程序” (Original Program)是指IBM公司在此许可证下所发布的原版软件,包括源代码、目标代码以及文档。

Free Software Foundation, “Various Licenses and Comments about Them”,

http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses.

OSI,“License Proliferation”, http://www.opensource.org/docs/policy/licenseproliferation.php。在年初一份同名文件中,OSI表示准备将已认证的许可证分 “Preferred”、 “Ordinary” (or Approved) or “Deprecated” 三类。

同上注12,section: Towards a Solution.

同前注。

Mozilla Public License, version 1.1, section 2.2.

同前注12, section: Executive Summary.

“‘Failed’ as in 'succeeded wildly”, http://blogs.sun.com/roller/page/webmink/20050415

Vaughan-Nichols .J .S, “Open-Source License Battles Are Brewing”, Apr 11, 2005, http://www.eweek.com/article2/0,1759,1784415,00.asp

Bruce Perens等人于1998年掀起了“开源软件”(Open Source)运动,并于同年组织成立了OSI。MPL许可证也于1998年提出。

  来源:
责任编辑: 系统管理员
相关文章