GPL许可协议及其传染性风险规避研究

陈思谷

(中南大学 法学院，湖南 长沙 ,410083)

1 GPL许可协议及其传染性

1.1 GPL许可协议的概述

General Public Licence简称GPL许可协议，是开源界常用的一类开放源代码许可协议，是源代码的著作权人基于自由、开放和共享的理念，通过附条件许可的方式，允许其他使用者在遵守协议限制的条件下，对其源代码进行自由使用、复制、改编、再发布。开放后的源代码能吸引来自不同地方、素不相识的开发者们在免费下载、自由使用、复制、改编、再发布的过程中，协助提高开源项目的质量，共同完成开源项目的开发[1]。

开放源代码许可协议虽然是将源代码授权给其他使用者免费使用和修改，但协议条款会明确授权条件并以此规范使用者的使用和修改行为。当前，经过国际开放源代码促进会( Open Source Initiative , OSI)审批认证的开源软件许可协议种类超过100多种[2]，而GPL许可协议作为开源界最常用的一类许可模式，其条款内容除了涵盖其他协议都有规定的“适用范围”“责任约束”“权利授予”“免责声明”等条款外，甚至部分条款还具有“开源传染性”(或称“开源传递性”)[3]。这里的“传染性”主要体现在协议内容对修改后的产品具有一定的限制：基于开源代码修改后的代码或派生作品需要再次开源，即继续向社会公众免费开放。

1.2 GPL许可协议的传染性

GPL许可协议的条款既赋予了不特定使用者权利但也规定了相应的义务，在允许使用者改编、使用、发布其基于GPL协议开源的代码背景下，亦要求使用者继续公开其成果，依据开源许可的方式向社会公众公开其后续生成的修改版本与派生作品。当然，基于GPL源代码生成的修改版本和派生作品的开源模式可以与原GPL模式相同，即修改版本或派生作品延续使用GPL协议；但也可以不同，但必须都是开源许可。根据其是否要求修改后的代码需再次公开大致可以分为开放型许可(MIT、BSD)、弱传染型许可(LGPL、MPL、EPL)、传染型许可(GPL)、强传染型许可(AGPL)4类[4]。其中，GPL开源协议一直是最经典的一种具有传染性的开源协议，以GPL协议为例，该协议的“传染性”主要表现在“纵向”和“横向”两个维度。

1.2.1 “纵向传染”中“再开源”义务

在“纵向”维度上，基于GPL协议开放的源代码会“传染”自身的修改版本或派生作品。例如使用者虽然可以基于GPL协议的授权，在源代码的基础上进行再创作，但是基于创作产生的代码新版本或派生作品则应继续依照GPL协议的要求进行再开源，向社会公开。因此，判定开源协议的纵向传染问题就转换成了对源代码派生作品的界定。派生作品又称演绎作品，实务中对软件源代码实行演绎主要包括改编、翻译和整理。改编是指对源代码的结构、顺序与组织根据用户的不同需求进行修改和改变。翻译是指把源代码从一种应用程序语言改变为另一种应用程序语言。整理是指将分立的各模块的目标文件中所含的源代码整理成可执行文件，计算机软件的代码规模常常难以估量，经常需要将这些代码整理分类到各模块，并将这些互相依赖但又相对独立的部分组合运行。综上，对源代码进行改编、翻译、整理后形成的派生作品均需要承担传染型开源协议中的“再开源”义务。

1.2.2 “横向传染”中“再开源”义务

在“横向”维度上，基于GPL协议开放的源代码还有可能会“传染”自身及修改版本以外的一同分发、传输的其他软件、程序的其他部分。例如，GPL V3规定，如果利用源代码编写的软件与其他软件之间组合的目的是为了生成一个更大的算法或程序，则其他软件也受到相应的GPL协议传染条款的约束，需要公开其源代码。若企业在宣传“独立研发具有自主知识产权”的软件中混入了GPL协议项下的开源代码，且被发现软件整体具有被传染至“再开源”的风险，而企业又并没有履行开源义务，亦对企业的商誉造成负面影响。例如，华硕曾因其产品Eee PC违反Linux 源代码的GPL授权而向公众道歉，并随后公开了Eee PC项目下的所有源代码。

2 GPL许可协议的法理分析

2.1 GPL许可协议的法律属性

根据上文分析可知，虽然GPL许可协议秉持的是开放、自由和资源共享的理念，使用这些开源代码都是无需向著作权人支付费用或者另行获得著作权人授权，但并不代表用户在使用这些开放的源代码时无需承担任何责任。当前，国内公众版权意识普遍较弱，很多人认为开放的源代码意味着可以免费使用，想怎么用就怎么用。这其实是混淆了著作权权利许可行为与好意施惠行为。对于后者而言，施惠者是基于良好的道德品行实施了使得另一方受恩惠的行为，双方之间没有建立任何权利义务关系。但是在对著作权许可中，源代码的著作权人对合同相对方行使其权利的行为必定是会有限制的，会在著作权授权合同中明确约定合同双方当事人的权利与义务，以此约束被授权人的行为[5]。在GPL许可协议中亦是设立了制约使用者使用源代码行为的内容，无论是署名义务、再公开义务或是禁止闭源等条款，都可以看出开源许可协议不是好意施惠，使用者们只有严格遵守许可协议中的义务，才能合理享有无偿使用、复制、修改等权利。

依据《中华人民共和国计算机软件保护条例》第八条(1)《计算机软件保护条例》第八条：“软件著作权人可以许可他人行使其软件著作权，并有权获得报酬。”与第十八条(2)《计算机软件保护条例》第十八条：“许可他人行使软件著作权的，应当订立许可使用合同。许可使用合同中软件著作权人未明确许可的权利，被许可人不得行使。”，GPL许可协议是著作权许可合同，并且是附条件解除的著作权许可。GPL许可协议作为向社会大众公开的文件，源代码著作权人在其代码中附上GPL开源协议并整体公开其作品的行为构成要约，其他不特定主体对该源代码进行使用、复制、改编并生成新的修改版本或派生作品的行为构成承诺，承诺做出就具有法律效力，该软件著作权许可合同成立[6]。此外，GPL许可协议在尊重源代码著作权人对自己著作权权利让渡的基础上，亦规范了用户使用该源代码的方式。因此，GPL协议条款有明显的双务性，例如条款既规定了权利人许可的范围、方式等，还限制了被许可人接受许可的行为，明确了被许可人的义务，声明了终止授权的情形和后果，并且GPL许可协议的“传染性”，其本质上是源代码的著作权许可对其派生作品的著作权许可的规范，因为其要求基于GPL协议开源的代码生成新修改版本或派生作品必须“再开源”，且开源的模式必须符合GPL协议的要求。

简而言之，GPL许可协议是源代码著作权人将其就该代码作品的改编权、翻译权、复制权、汇编权、发行权等财产权，附条件地许可给他人的著作权许可合同[7]。与其他著作权许可合同相比，GPL许可协议面向的是不特定的主体。

2.2 违反GPL许可协议及其传染性条款的法律后果

2.2.1 著作权侵权与合同违约

GPL许可协议是著作权许可合同，被许可方一旦违反GPL协议将直接导致其通过GPL许可协议获得著作权许可无效和被终止，被许可方对源代码传播、使用或修改则属于无合法权利来源的侵犯他人著作权的行为。(3)以GPL协议第二版为例，第4条规定：在本协议授权之外，您不能复制、修改、再授权或分发开源软件。任何用其他方法复制、修改、再授权或分发开源软件的企图都是无效的，并使您从本协议获得的权利自动终止。例如，如果开发者在独自研发的软件中混入了使用GPL协议开源的代码，且没有依据GPL协议的要求对软件整体履行再开源义务，则可能会导致其独自研发的软件整体侵犯他人著作权的风险。因为依据GPL协议的规定，若开发者违反本协议规定，则导致通过开源协议获得的著作权许可无效和被终止。由于被许可方的传播、使用、修改、改编源代码的行为往往处于一种持续的状态，在这种情况下，被许可方对源代码传播、使用或修改则属于无合法权利来源的侵犯他人著作权的行为[8]。开发者将会面临来自源代码著作权人的侵权索赔以及停止使用的知识产权行为禁令。并且GPL许可协议作为一种著作权许可合同，还具有一般合同和著作权许可合同的双重属性，就必然会出现违约责任和著作权侵权责任之间的竞合[9]。

2.2.2 成为他人的侵权抗辩是由

除此以外，开发者在自研代码中混入GPL协议项下的开源代码且违反“再开源”义务，也将成为其他用户使用、复制、传播其自研代码的侵权抗辩。在使用基于GPL开源的代码进行再创作形成修改作品或派生作品后，若使用者违反GPL协议或传染性条款中规定的“再开源义务的行为”，可能成为他人就该修改作品或派生作品侵权的抗辩是由。基于GPL协议的传染性，导致基于其源代码后续生成的所有修改版本和派生作品都需要进行“再开源”并延续GPL许可模式。这里体现的是GPL许可协议及其传染性条款对软件著作权侵权判定的影响。

在司法实践中已经出现了原告因商业软件作品被部分开源代码“传染”，成为被告使用、复制其商业软件的抗辩理由(4)详见(2016)京73民初1111号：北京闪亮时尚信息技术有限公司、不乱买电子商务(北京)有限公司侵害计算机软件著作权纠纷一审判决书。。虽然权利人享有基于GPL协议的源代码创作的修改版本或派生作品的著作权，但是由于GPL协议的属性是附条件的著作权许可使用合同，即源代码的著作权人附条件地将源代码的复制权、发行权、修改权授予不特定公众[10]，并且GPL协议的传染性条款明确规定了权利人基于源代码的修改版本或派生作品需继续基于GPL协议实行“再开源”，向社会公众公开。因此，当权利人的权利作品中若使用或包含了GPL项下的源代码，则其再无权禁止他人或组织对其修改版本或派生作品进行复制、修改、使用或发布。究其本质，这种抗辩不是针对于源代码修改版本或派生作品本身权利归属的争议，而是针对被诉侵权人或社会其他个体是否有重新获得其新修改版本或派生作品的著作权许可的抗辩。

3 GPL许可协议“传染性”的规避

GPL许可协议有利于集结更多用户资源打造自身生态，快速获取大量反馈资源，以此进一步优化模型算法，实现重要的反哺。随着开源的盛行，越来越多的商业产品都需要用到GPL许可协议项下的代码，根据上文分析，GPL许可协议在“纵向”和“横向”两个维度上都具有很强的传染性，因此，很多企业都会对LGPL、GPL、AGPL协议闻者色变，担心使用这些具有“传染性”的源代码研发自身产品会导致整个商业产品被迫开源，从而造成商业秘密被迫公开，产生不可挽回的利益损失。事实上，GPL许可协议对其传染性仍有例外条款规定：“仅将源代码(或其派生作品)与另一项独立作品聚合到一定数量的存储或分发介质上，并不会将独立作品归入协议的管辖。”那么如何能在商业产品中使用传染型开源代码，并避免开源协议的传染性呢？通过具体分析传染性条款与司法实践中的情况，规避GPL许可协议的“传染性”可以从以下几个方面入手。

3.1 避免分发和输送

以GPL许可协议为例，GPLVersion 2与GPL Version 3中分别规定了通过“分发”与“输送”后的新修改的代码及其派生作品会被“传染”[11]。简而言之，被许可人只要不对外进行分发或输送其基于GPL开源代码生成的修改版本或其他派生的作品，就可避免被“传染”。目前，常见的代码分发、输送的途径包括使用电子邮件、U盘、网页链接等手段，提供给用户进行下载和安装。因此，为了规避“传染性”，公有云服务厂商通常采取的规避措施就是将修改后的开源代码部署在后端服务器中，不需要用户进行任何安装，就可以直接通过互联网远程连接提供服务。例如，以 Google 为主要代表的“不分发软件，为客户提供网络服务”的这种商业模式是完全不被 GPL协议所限制和约束的，所以这类公司在设计和构建他的网络搜索引擎的过程中，就可以随心所欲地使用现有的传染型开源代码，并且不需要开源他的修改成果。

综上，不对外传播基于GPL许可协议开源的代码及其派生作品，即可避免诸如LGPL、GPL这类开源协议的传染性。值得注意的是，AGPL协议为了防止这种情况的出现，在 GPL 协议的基础上又添加了一个约束：“如果其许可授权下的软件与用户通过网络进行交互，那么亦需要向用户提供修改后的源代码。”[12]因此，这类避免分发和输送的措施并不能规避AGPL开源协议的传染性，仍然需要承担“再开源”义务。

3.2 维持开放源代码的独立性

传染性的例外条款即开源协议不会“传染”仅和开源代码集合到一起本质上不属于开源代码的作品。也就是说，独立的作品不受GPL许可协议的管辖，即如果使用的开源代码和企业自研软件属于独立软件，则自研软件并不会被源代码所属的GPL许可协议所传染；但如果使用的开源代码和自研软件之间不具有独立性，则自研软件会被源代码所属的开源协议所传染。开源代码与自研代码的独立可以表现为三个方面：一是保持开源代码自身的独立性；二是维持企业自研代码的独立性；三是两者之间相互独立。

在软件结构的设计上，保持开放源代码的独立性是避免其他部分代码被GPL开源协议传染的有效手段。例如，Android规避GPL“传染性”的路径是把GPL 协议局限在内核空间。 Android 内核是在Linux 基础上开发的，而Linux 是GPL协议项下的开源代码，因此，Android 的内核模块作为Linux 的派生产品，需要严格遵守 GPL协议进行开源发布。为了手机生产商的利益及其商业秘密的保密要求，Android在内核空间与用户空间之间引入HAL 层，将商业软件产品与开源软件分别存放在不同的地址空间，通过各种技术手段来达成独立空间之间的通讯与调用，以此实现商业软件产品与开源软件的隔离。将GPL 协议限制在一个局限于内核的空间，以此来绕过GPL许可协议并且保证了其他部分的独立性，避免了其他的软件产品受到GPL协议的传染。近期，华为公司研发的智能操作系统“OpenHarmony(鸿蒙)”这一开源项目亦是在软件结构的设计上保证了开源代码那一部分的独立性，从而规避其源代码所属的GPL协议的传染性。

3.3 维持自研代码的独立性

对商业企业来说，商业软件的开发者下载了基于GPL许可协议开源的代码之后，通常都会在该源代码的基础上进行再创作，形成适用于企业自身的新修改版本或派生作品，再并入自己研发的商业软件中，并一同分发和使用[13]。根据前文分析，自研代码的“独立性”是抵抗“传染性”的重要标准。目前对于代码“独立性”的判断在我国司法实践中并未形成统一的标准。

2018年数字公司诉柚子公司著作权侵权案是我国司法实践中涉及开源协议“传染性”的第一案。该案一审法院认为，涉案的三个插件可以各自独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无开源协议文本，据此认定涉案三个插件不属于 GPL 协议中所指应被开源的派生产品或修改版本。(5)详见(2015)京知民初字第631号：数字天堂(北京)网络技术有限公司与柚子(北京)移动技术有限公司等一审民事判决书。二审判决仅对赔偿数额进行了调整，直接回避了可能对 GPL 传染性问题的讨论。(6)详见(2018)京民终471号 ：柚子(北京)移动技术有限公司等与数字天堂(北京)网络技术有限公司二审民事判决书。在2019年不乱买公司诉北京闪亮公司计算机软件著作权纠纷案(7)(2019)最高法知民终663号：不乱买电子商务(北京)有限公司与北京闪亮时尚信息技术有限公司侵害计算机软件著作权纠纷案二审民事判决书。中，最高人民法院认为，权利人的网站分为前端代码与后端代码，两部分代码之间是相对独立的关系。虽然前端代码中混入了基于GPL协议开源的代码，但不会传染与之相对独立的后端代码，即网站的后端代码无需继续依据GPL协议的要求履行再开源义务，因此，被诉侵权人未经许可复制使用权利人后端代码的行为构成著作权侵权[14]。

类比在公司法中，法人的人格是否独立性的判断标准，判断在东部地区的 a 公司和其在西部地区拥有一个独立办公场所的b子公司是否完全独立，需要从 a和 b之间的财务关系、人事关系、业务关系等方面来判定b公司法人人格是否独立。结合开源协议的条款，判断软件项目中模块 A 与模块 B 之间是否独立，也绝对不能以A和B是否位于独立的文件夹中来判断，而是需要从 A 和 B 之间的功能关系、通信关系、调用关系、依赖关系等来判断[15]。现阶段，对于代码独立性的判断在我国司法实践中尚未形成统一的判定标准，在不乱买公司与闪亮时尚公司案中，最高人民法院对代码“独立性”的认定方式对解决开源软件“传染性”问题具有一定启示意义，开发者在使用传染型开源代码时，即便将其与其他商业产品放置在不同空间，仍然需考量开源代码与自研代码在实现方式、技术引用、功能区分等方面的关联程度[16]，不然也无法规避被传染的风险。

4 结束语

开放创新一直以来都是推动人工智能产业发展的重要途径，人工智能技术的蓬勃发展也离不开先进代码的开源，科技巨头诸如 Google 、华为等都加大了资金和人力投入积极拥抱开源，甚至把原本闭源产品转为了开源项目，如对外开放其专有的机器学习框架等。与此同时，GPL许可协议这类具有“传染性”的开源协议也给开源代码的商业使用造成了著作权侵权的法律风险。因此，商业用户在使用开源代码进行自身研发时，首先需要确认源代码涉及的开源协议的具体版本，判断其是否为传染型开源协议。其次要审查评估其自研软件与传染型开源代码之间的关系，即传染型开源代码(或其派生作品)与其他自研软件作品是否互相独立，若存在被传染的可能还需审查是否全面履行相应的开源协议义务。如果发生开源义务要求与商业软件的保密要求之间的矛盾确实无法调和时，应在采取阻断传染性的基础上，用自研软件进行替代，否则极易自动触发著作权许可合同的解除或终止条件，面临著作权侵权的法律风险。