内容提要:开源软件并不排斥着作权保护,开源协议实质是权利人将其复制权、发行权、修改权等附条件地许可给不特定公众的着作权许可使用合同。因此以权利软件使用了开源协议或包含开源代码而无权禁止复制、发行、修改为由进行的抗辩并非针对权属的抗辩,而是获得许可的合法使用抗辩。在此基础上,开源协议的适用范围就成为了审查重点。同时,开源协议具有明显的双务性,被许可人违反适用条件可能导致授权终止而构成侵权。准确认识开源软件和开源协议的性质,能有效避免法律风险,使得我国能够更好适应开源软件所带来的开放环境。
关键词:侵权抗辩开源软件GPL协议
一、基本案情
不乱买电子商务(北京)有限公司(以下简称不乱买公司)主张其享有自主开发的“不乱买”网站的着作权,北京闪亮时尚信息技术有限公司(以下简称闪亮时尚公司)旗下“闪亮时刻”网站未经许可使用了与其网站源代码实质性相同的源代码,构成着作权侵权,诉请法院判令闪亮时尚公司承担停止侵权、赔偿损失等责任。北京知识产权法院一审判决,闪亮时尚公司构成侵权,应停止侵权并赔偿损失等。闪亮时尚公司提起上诉,认为不乱买公司软件代码因使用了大量开源软件代码导致权属存在争议,并且不乱买公司适用GPL协议的前端代码文件未与后端代码文件有效隔离,且二者存在数据交互调用配合,前端代码和后端代码共同构成权利软件,该权利软件是前端代码的修改版本,根据GPL协议及GPL协议具有极强“传染性”的特性,权利软件整体均应遵循GPL协议向所有第三方无偿开源,因此闪亮时尚公司不构成侵权。
二、裁判理由
最高人民法院审理认为,前端代码一般是关于用户可见部分的编码,用以实现操作界面如页面布局、交互效果等页面设计;而后端代码一般是涉及用户不可见部分的编码,用以实现服务端的相关逻辑功能。因此,前端代码与后端代码在展示方式、所用技术、功能分工等方面均存在明显不同,不能因前端代码与后端代码之间存在交互配合就认定二者属于一体,前端代码与后端代码其实是相互独立的。因此,当权利人明确放弃以前端代码主张权利仅以后端代码主张权利时,权利软件仅为后端代码而非前端文件和后端文件共同构成权利软件,并无证据证明其中存在开源代码。根据涉案GPL协议内容,可以看出GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身,还包括受保护程序的衍生程序或修改版本,但不包括与其联合的其他独立程序。由此可见,GPL协议要求开源的是本身接受其协议的软件代码及针对这些软件代码的修订或者根据这些软件代码开发的延伸程序,而不包括与这些代码有数据交换等联合的其他独立程序。虽然不乱买公司认可其前端代码中使用了GPL协议下的开源代码,但其主张权利的是后端代码,其后端代码是独立于前端代码的其他程序,并不受GPL协议的约束,无需开源,闪亮时尚公司的相关抗辩不能成立。
三、法理分析
开源软件因其自由、共享的精神,为软件技术的创新发展注入了活力,使得软件行业的知识创新和产品创新保持高速发展,为我国软件技术发展提供了一个开放的环境,也带来一定的法律风险。由于我国目前尚未形成较具规模的开源社区和较权威的开源软件行业自律组织,我国司法实践中尚未出现直接以违反开源协议为由起诉的案件,但出现了部分以权利软件使用了开源协议或包含开源代码而无权禁止被诉侵权人复制、发行、修改为由进行抗辩的案件。此种抗辩与传统软件着作权侵权抗辩事由存在着明显区别,需要对开源软件和开源协议的性质、开源协议的适用范围、该抗辩的审查要点进行了解和分析,才能在准确适用法律以适应并推进软件行业的发展。
(一)开源软件和开源协议的性质
与专有软件强调独占性保护不同,开源软件是以用户为中心的。着名开源软件组织Free Software Foundation指出软件不应限制其用户,每个用户都应该有按自己的意愿使用软件的自由、把软件分享给友邻的自由、按自己的需要修改软件的自由、分享自己对软件的修改的自由四项基本自由。当一个程序为其用户提供所有这些自由就是开源软件。软件自由是目标,开源则是手段。同时,为使得开源软件始终保持“自由”,避免有人利用开源代码后将代码封闭,保证修改或衍生的软件仍能如原始作者所期待的那样给予用户“自由”而不会返回专有软件,开源软件并未选择放弃着作权直接使软件进入共有领域,而是选择采用copyleft的方式。Copyleft是一种让软件成为开源软件并要求其所有修改版本和衍生软件也成为开源软件的通用方式。Copyleft从其本质上看并非排斥着作权(copyright),而是在着作权制度框架内通过许可方式对后续使用者持续开源,并通过附条件许可的方式使得使用者及修改者也持续开源,这是开源软件能够存在并发展的重要保证。开源软件强调的自由并不否认知识产权的存在,而是依赖于现有着作权法律体系的,因此,开源软件及其衍生软件或修改版本的着作权仍然存在,且权利类型也没有缺少。开源软件的着作权人仍享有复制权、发表权、修改权、署名权、保护作品完整权、获得报酬权等权利,不过其通过许可的方式将其中的某些权利如复制权、修改权等授权给不特定公众。
使用开源协议是软件开发者将其软件开源最常见的方式,而在众多开源协议中,GNU General Public License(以下简称GPL协议)是最受欢迎且应用范围最广的,本案中所涉及的也是该开源协议,因此以其作为典型进行论述。开源协议的性质决定了开源协议的适用范围及相关抗辩的定性。我国尚未出现直接以违反开源协议为由起诉的案件,司法实践中缺乏对开源协议性质及其法律适用的认定。但近年来,美国、德国等开源软件规模庞大的国家,相关案件却并不鲜见。因美国合同法与版权法分属州法和联邦法的法律体系,与我国差距较大,其关于GPL协议的争议对我们认定GPL协议的性质意义不大。而德国法院的认定则集中体现在Welte诉D-Link一案中。该案中,法院认为GPL协议条款的法律性质是特定的一般交易条款,即预先拟定,由着作权人向使用人提出的合同条款。同时,开源软件着作权人无需接受使用人的承诺声明,双方即可构成法律关系。GPL协议中的许可条件是合同的组成部分,其中关于软件程序使用人必须附上协议的正文、发布原作者着作权标示和无担保声明、附上完整的源代码等规定未不适当地损害使用人的利益,是有效的。如果被许可人违反上述许可条件,根据GPL协议规定则不得对开源软件进行复制、修改、再授权或发布。任何试图以其他方式进行复制、修改、再授权或者散布本程序的行为均为无效,并且将自动终止基于本授权所享有的权利。在此情况下,被许可人所获得的授权意味着自动终止,其将为自身未经授权发布或复制软件的行为承担侵权责任。从该案的审理中可以看出,德国司法实践倾向于将GPL协议认定为附解除条件的合同,其中许可使用条件为解除条件,当被许可人未按许可使用条件使用时,合同解除、终止授权,被许可人继续使用则构成侵权。
我国《计算机软件保护条例》第八条规定,软件着作权人可以许可他人行使其软件着作权,并有权获得报酬;第十八条规定,许可他人行使软件着作权的,应当订立许可使用合同。GPL等开源协议属于公开可自由取得的文件,着作权人在公开源代码时明确声明并附加GPL等开源协议的行为可被视为要约,不特定主体复制、运行、修改、传播附有开源协议的源代码的行为应为承诺,承诺做出即产生法律效力,合同成立。因此,开源协议是着作权人将其复制、发行、修权利授权给使用者的着作权许可使用合同。与一般着作权许可使用合同不同,其面向的是不特定的主体。开源协议在内容上具有明显的双务性,在对权利人许可的范围、方式等进行详细规定的同时,也对被许可人接受许可的行为等进行了规定,并对终止授权的情形和后果进行了规定。综上,开源协议是软件着作权人将其复制权、发行权、修改权等附条件地许可给不特定公众的着作权许可使用合同。
(二)开源协议的适用范围
鉴于开源协议的本质是软件着作权人将其复制、发行、修改等权利授权给不特定公众的许可合同,相应开源协议仅适用于同意受到协议约束发布的程序,即如果原始版权人在声明中说明其软件置于开源协议下发布,则适用开源协议。同时,从许可行为来看,开源协议有着严格限制,如GPL协议就不适用于复制、发行和修改以外的行为,因为超越了许可范围。
同时,保持源代码持续的公开性是开源软件的要求之一,因此,开源协议在保障被许可人自由的分享、使用、修改并分享其修改的版本时,对其分享、使用自身修改版本或衍生软件往往也会做出约束,以避免修改后和衍生的软件在之后的发布程序中封闭源代码进行发布和销售。以GPL协议为例,其第5条发布修订过的源码版本规定,被许可人可以源码形式发布一个基于开源软件的软件或修改版本,但是须满足的条件中包括按照GPL协议将整个软件许可给想要获得许可的人,GPL协议及符合第7条的附加条款适用于整个软件及其所有部分,无论该等程序以什么形式打包;一个受保护作品和其他分离的单体作品的联合作品,在既不是该受保护作品的自然扩展,也不以构筑更大的程序为目的,并且自身及其产生的版权并非用于限制单体作品给予联合作品用户的访问及其他合法权利时,称为“聚合版”。在聚合作品中包含受保护作品并不会使GPL协议影响聚合作品的其他部分。上述内容即GPL协议的传染性及例外情形的规定,该规定保证了开源软件修改版本和衍生版本的持续开源,并将部分与开源软件结合为一体的软件代码纳入到开源软件范围内,扩张了开源协议的适用范围,在拓展增加开源软件的数量的同时为开源软件与专有软件的共存划定了界限。这一界限的划分看似清晰,但聚合体与修改版或衍生版的区别到底如何判断,确实是一个司法实践难点。目前我国出现的以权利软件使用了开源协议或包含开源代码而无权禁止被诉侵权人复制、发行、修改为由进行抗辩的案件中,几乎均涉及到了权利软件是否被GPL等开源协议感染的问题。对此,Free Software Foundation在GUN许可协议常见问题“‘聚合版’和其他‘修改版’有什么不同?”中回应:“聚合版”包含有多个独立的程序。如何区分是两个独立的程序还是一个程序的两个部分,是一个法律命题,最终会由法官来决定,但其认为合理的标准既依赖于通信的机制(exec、pipes、rpc、共享地址空间的函数调用等),也依赖于通信的语义(交换了什么样的信息)。关于“何时一个程序和其插件会被认为是一个结合在一起的单一程序”,Free Software Foundation也有类似的回应:如果主程序与插件之间通过共享或交换复杂数据结构而建立了密切的通信,他们就是一个结合在一起的程序;如果并没有建立起密切的通信,插件就是一个单独的程序。由此可见,GPL协议所能传染的衍生软件或修订版本,应当是与原开源软件形成密切通信使得二者高度牵连融合成一体的程序,而非只要有数据交换就会构成传染。结合本案,前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式,后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现,二者展示方式不同、所用技术不同、分工亦有明显区别,显然属于独立的程序。前端代码中存在的部分开源代码可能传染部分前端代码,但在权利人整体放弃前端代码仅主张后端代码的情况下,其权利代码并未被纳入GPL协议的适用范围内,并不受GPL协议的约束,也未被许可给公众进行复制、发行、修改。
(三)开源协议对软件着作权侵权判定的影响
开源软件和开源软件的修改版本或衍生软件跟专有软件一样,都享有着作权。而开源协议的本质是软件着作权人将其复制权、发行权、修改权等附条件地许可给不特定公众的着作权许可使用合同。因此,以权利软件使用了开源协议或包含开源代码而无权禁止被诉侵权人复制、发布、修改为由提出的不侵权抗辩,其本质是被诉侵权人获得着作权人许可的抗辩而非针对权属的抗辩。本案中,因权利人主张的权利软件与开源代码之间的隔离使得GPL协议对涉案权利代码并无拘束力,即权利代码并未根据GPL协议被许可给第三方,许可的获得也就无从谈起。
同时,在分析我国相关案件中被诉侵权人的抗辩时,还可以看到一个现象,被诉侵权人往往仅强调GPL等开源协议中权利人的开源义务(许可他人修改、复制等)而忽视被许可人的义务(保留声明、注明修改信息等),这其实是对开源软件和开源协议的一种误解。开源协议具有明显的双务性,被许可人在行使复制、发布、修改开源软件的权利时,也需要按照开源协议要求承担相应义务,否则可能导致其权利被终止。以GPL协议为例,第4条规定被许可人在发布完整副本时须每份复制件上均附有明显且恰当的版权声明,完整保留GPL协议及附加条款,完整保留不含担保声明,将GPL协议与程序一同移交接受者;第5条规定被许可人发布的修改版本须带有醒目的修改声明及相应的日期;第8条规定被许可人未获得GPL协议明确授权时,不得传播和修改受保护作品。任何试图以其他方式进行复制、发布、修改受保护作品的行为都是无效,且将自动终止被许可人通过GPL协议获得的权利。被许可方复制、发布、修改相关开源软件的唯一权利来源是开源协议的许可,一旦被许可方违反GPL协议其权利即告终止,但其复制、发布、修改软件的行为通常会处于持续状态,在此期间,被许可方复制、发布、修改软件而无合法权利来源可能构成侵犯他人着作权。因此,违反GPL等开源协议可能存在违约责任和侵权责任竞合的问题,二者在法律依据、侵害对象、产生前提、举证责任范围、责任内容等方面不同,从德国、美国司法实践看,多数法院将被许可方未履行开源协议约定的义务的行为认定为着作权侵权。因此,以权利软件使用了开源协议或包含开源代码而无权禁止复制、发布、修改为由提出的不侵权抗辩,除需证明权利软件受将其复制权、发行权、修改权许可他人使用的开源协议的约束外,被诉侵权人还需证明其行为符合相应开源协议的要求而非随意使用,否则仍有可能因其行为不符合开源协议约定导致许可终止而构成侵权。
四、法官建议
随着信息通信技术的发展,开源越来越成为一种主流的开发模式。认清开源的本质、了解开源的游戏规则,对于我国企业发展开源软件、规避开源软件风险至关重要。我国虽尚未出现直接以违反开源协议为由起诉的案件,但出现的以权利软件使用了开源协议或包含开源代码而无权禁止复制、发行、修改为由进行抗辩的案件,暴露出我国部分企业对开源软件和开源协议认识上存在的不足和误区。开源不是免费的午餐,开源软件不是公共领域软件,其享有着作权并受着作权法保护,不可以任意使用。开源软件的着作权人通过开源协议将开源软件的复制权、修改权、发行权等部分权利许可给了使用人,但这种许可是附条件的,被许可人只有在遵从开源许可协议规定的前提下,才可以行使这些权利。如果企业没有按照开源许可协议的规定使用开源软件,则存在很大的着作权侵权风险。现代社会中机遇与挑战并存,在享有开源带来的福利时,必须对其法律风险予以高度关注,这样才能更好适应开源软件所带来的开放环境。
(本文转载于《中国版权》第5期总第113期)