从著作权看开源软件

开放源代码软件(以下简称开源软件)作为一种新的软件开发、传播和发行模式，近年来在国际和国内软件行业迅速发展起来，并逐渐能够和商业软件相抗衡。例如，目前由Linux系统、Apache Web服务器、MySQL数据库软件、和Perl编程语言组成的所谓LAMP组合已形成了成熟的开源软件开发平台；而且，正在更进一步的逐渐向CRM、ERP、BI、中间件等关键企业应用领域渗透；在软件行业中已经占有了自己的一席之地。
但是开源软件作为一个新鲜事物，其所涉及的法律问题纷繁复杂，如何能够帮助企业在享受开源软件的便利时，充分避免可能存在的法律风险。这是各种软件企业经常咨询笔者的一个问题，但是由于涉及内容较多，因此在本文中，笔者想仅仅从著作权的角度对开源软件进行简单剖析。
到底什么是开源软件？
开源软件，简单理解，就是开放源代码的软件。由于开放源代码的软件开发模式可以激发世界各地的软件开发人员投入到开源软件的开发中，软件开发人员的集体智慧得到充分发挥，软件开发人员可以及时发现并解决开源软件中存在的各种影响运行稳定性、兼容性、安全性等问题，减少大量不必要的重复劳动；因此开源软件在近些年蓬勃发展起来。
但是，由于“开源软件”一词应用的越来越广，因此，其含义也越来越模糊。而从“开源软件”的字面含义上，可以看出其最根本的技术要求就是：发布者在发布软件时需要同时发布源代码。
开源软件作为一个作品，依据著作权法的相关规定，开发人员必然会对自己所开发的源代码部分享有一定的著作权。而一个大型开源项目的开发和发布过程，需要大量开发人员的参与，因此，当后续的开发人员对之前开发人员发布的源代码进行复制、修改和重新发布时，就会出现侵犯已发布源代码的著作权问题。
因为开放源代码的行为并不能从法律上构成开发人员对源代码著作权的放弃，所以，为了避免后续开发人员的侵权，开发人员在初次发布源代码的时候，会采用一些法律手段对其享有的著作权进行一些限定。
笔者根据对著作权的不同开放程度，将开源软件大致分为以下三类：
（1）仅仅开放源代码的软件。
例如，微软在2003年声称对自己的某些软件开放了源代码，但微软开放源代码的软件是不允许用户修改和自由使用的。该类软件实际上只是将原来微软认为是技术秘密的源代码进行了开放，对于该软件相关的著作权丝毫没有开放。
（2）开放源代码，并通过许可证方式对其相关著作权加以限制的软件。
例如，Linux就是遵循自由软件基金会（Free Software Foudation，FSF）发布的GPL许可证协议的软件。该类软件在开放源代码的基础上，同时对著作权中的复制权、修改权、发行权等进行了限制。
采用开放源代码倡议组织OSIA（Open Source Initiative Association）认证的软件许可证，进行开源软件的发布是目前的一个主流选择。经OSIA认证的开源软件的软件许可证已增加到约60余种，GPL就是其中的一种。经OSIA审查符合要求的许可证，就能获得OSIA证明商标“OSI Certified”的使用权，可以在其发放的软件上使用OSI的标志，这些软件构成了主流意义上的开源软件。
（3）开放源代码，并放弃著作权中所有财产权的软件。
例如，公有领域软件（Public Domain Software）。该类软件与第2类软件的区别在于该类软件上的著作权几乎被完全放弃（当然可能会保留一定的身份权）。而第2类软件上的著作权仍然由其权利人享有，受到著作权法的保护，只不过在许可证规定的情况下对其加以限制；如果不属于许可证规定的情况，则源代码的权利人仍然有权行使其著作权。
对于第1类开源软件（或许根本不应该称之为开源软件，在此只是为了分析方便），由于没有开放著作权，本文在此就不加以讨论了。对于第3类开源软件，由于权利人放弃了著作权中的所有财产权，可以由公众自由使用，与企业利益基本没有冲突，所以本文在此也不加以讨论了。
下面主要针对第2类的开源软件加以讨论，并以OSIA认证通过的许可证为分析对象。
开源软件的许可证
（1）许可证的效力
从形式上看，开源软件许可证就是一份格式合同。从合同法的角度而言，只要合同各方自愿签订，并且不不违反法律的强制性规定，则其就是有效的，可以依据其中的具体条款来约束合同中各方当事人，当事人需要依据合同的具体条款行使权利和义务。
但是其中有一个问题需要讨论，OSIA认证通过的许可证一般都是自动生效的，并且适用于该开源软件漫长的传播过程，在此过程中可能涉及多个开发主主体，但是在此过程中无需附加各个开发主体签字盖章。
这样的情况是否符合我国合同法的相关规定？因为其实际上意味着，后续的各个软件版本的发布，可以直接适用最初的许可证，而无需授权方和被授权方的直接意思表示（签字盖章）。但是从默示许可的角度，可以认为其是符合相关规定的。
具体的，如GPL第二版第5条规定如下：
因为您并未在本授权上签名，所以您无须接受本授权。然而，除此之外您别无其他修改或散布本程序或其衍生著作的授权许可。若您不接受本授权，则这些行为在法律上都是被禁止的。因此，藉由对本程序（或任何基于本程序所生的著作）的修改或散布行为，您表示了对于本授权的接受，以及接受所有关于复 制、散布或修改本程序或基于本程序所生著作的条款与条件。（原文出处: http://www.gnu.org/copyleft/gpl.html）
其他的一些许可证也有类似的规定。
也就是说，许可证要求当事人要么全部接受协议内容、要么不使用
开源软件；因此，如果当事人使用了开源软件或者进行了再发布，则可以推断授权方和被授权方之间存在默认许可证效力的意思表示。即，虽然没有签字盖章，但是仍然是一有效的合同。
（2）几种典型许可证的介绍
由于经过OSIA认证通过的许可证在权利义务上的规定大体一致，所以下面仅仅对几个常用的、典型的许可证进行介绍，并主要介绍各自的独特之处。
GPL
GPL V2是1991年发布的，其最大特点就是：如果在一个软件的源代码中，其整体或者部分来源于遵循GPL的开源软件，则该软件就必须也遵循GPL进行复制、修改和传播，并不得对GPL许可证的条款进行修改，甚至不可以翻译为另一语言的演绎作品(derivative work，又称衍生作品)。总之，GPL许可证不容许在所发布的软件中一部分源代码开源，而另一部分源代码闭源的情况出现。
在GPL v3（2007年发布）中，除了继承上述特点，更进一步，还要求公布相关硬件的源代码，以取消对用户的限制。在GPL v3的导言中提及“某些设备被设计成拒绝用户安装或运行其内部软件的修改版本，尽管制造商可以安装和运行它们。这从根本上违背了通用公共授权保护用户能修改软件的自由的宗旨。… … 因此，我们设计了这个版本的通用公共授权来禁止那些产品的侵权行为”。
LGPL
LGPL的具体条款基本与GPL相同，但是LGPL是专门针对类库（函数库）设计的，允许商业软件通过类库引用(link)的方式使用LGPL类库而不需要开放商业软件的代码，也就是说，如果一软件对遵循 LGPL 的软件进行任何连接、调用而不是包含，则允许封闭源代码。
在LGPL v2的导言中提及：“在少数情况下，可能会有特殊的需要而鼓励大家尽可能广泛地使用特定的函数库，因而使它成为实际上的标准。为了达到此目标，必须允许非自由的程式使用 此函数库。一个较常发生的情况是一个自由的函数库与一个被广泛使用的非自由函数库做相同的工作，在此情况下，限制只有自由软体可以使用此自由函数库不会有多少好处，故我们采用了较宽松通用公共许可证。”
BSD许可证
BSD许可证是对商业软件很友好的协议，只要尊重原作者，合理恰当的表明源代码的出处，被授权方就可以对其进行修改或二次开发等等，并可以依据自己的需求采用开源或闭源的方式进行发布。但是，一般的，在再发布的产品中需要包括原来开源代码的BSD许可证；并且，不可以采用开源代码的作者名称或原开源产品的名称作市场推广。
MPL许可证
MPL是The Mozilla Public License的简写，MPL的第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序，并可作为自己的软件产品进行发布。即，MPL对商业软件也是非常友好的。
开源软件的一些实际问题
（1）开源软件是否可以收费
一般常用的许可证都会规定，授权方不能就之后的发布行为收取额外的费用，但是可以就本次发布行为收取复制成本或服务费。也就是说，开源软件本身只能针对复制行为收取一定的成本；但是具体到商业模式上，企业可以由服务、支持环节收费或者相关商业软件收费等模式实现盈利。
（2）开源许可证是否可以更换？
由于开源软件最初的发布者可选择的许可证很多，那么在选择一个许可证之后，在之后改进版本的发布过程中，发布者是否可以选择另外一个许可证？
正如前文所示，不仅不同的开源许可证在具体条款的规定上存在差别，即使同一许可证不同版本之间也会存在细微差异。而由于许可证的排他性，不能出现一次发布同时遵循两个许可证的情况。下面，笔者将从两个应用情况进行简单说明：
第一种情况，如果最初的发布者选择了一个许可证，则后续对该源代码进行修改的发布者（后续开发人员）就不能选择另外一个许可证，否则，就侵犯了最初发布者的意思表示。
第二种情况，如果最初的发布者针对1.0版本选择了许可证A，而其在没有引用其他开源软件的源代码的情况下独立开发出了2.0版本，则该发布者针对2.0版本可以选择许可证B，因为1.0版本中的这些源代码著作权仍然归该发布者所有，该发布者可以选择采用任一许可证对2.0版本的著作权进行限制。但是这并不影响1.0版本的源代码在许可证A下的复制、修改和传播。
上述情况的另一应用情形，就是企业对一软件进行开源的首次发布时，可以提供两种授权模式；例如，MySQL就提供了一种是GPL模式，一种非GPL商业授权模式。其他企业如果希望应用该开源软件的源代码，则可以选择自己能够接收的许可证方式。当然，上述许可策略下，可能对开源企业的市场运营会带来一定的影响，如竞争关系等。
（3）企业建议
应用开源代码进行开发，确实对企业的软件开发过程有较大的好处，但是如果应用不当，依据相关许可证的条款而导致公司的私有代码也要被迫公之于众，恐怕是任何企业都难以接受的。为了避免上述情形的出现，笔者建议如下：
1、在企业内部建立完善的开源代码使用规范。公司针对不同的许可证制定不同的使用规范，例如，在本公司软件中的什么地方可以使用开源代码？具体应该采用什么方式使用开源代码？如果开发人员希望使用开源代码，则需要首先阅读相应的使用规范，并提交上级领导审核，以免埋下隐患。
2、尽量对开源代码按照独立提供的方式进行使用，并尽量不修改。将开源代码独立提供的方式可以采用独立目标代码的方式或者独立数据包的方式；该方式主要可以用于证明其他程序作品的独立性，以及如果需要时，可以很方便的替换和删除开源代码。如果需要采用函数库连接的方式使用开源代码，则只能遵循LGPL许可证，或者更宽松的许可证，如BSD等。