兰迪研究 | 开源协议专题三：GPL协议的传染性分析

作者 | 黄克、周庆越

在上篇文章《开源协议专题二：GPL协议的法律解析（上）》中，我们对GPL v3协议的框架及主要条款进行了介绍，GPL协议的主要特点之一就是其传染性，同时GPL协议也是目前国内诉讼所涉及最多的一种开源协议。本文将针对GPL协议的传染性，结合其条款含义，以及当前司法实践中相关案例，进行更为深入、全面的研究。

“传染性”本身并不是GPL协议中的文本术语，而是用户及业内同行根据其特性概括的名称。GPL的传染性是指在GPL协议的约束下，基于该协议授权的软件进行修改、扩展或结合其他代码形成衍生作品时，衍生作品也必须遵守GPL协议，以GPL许可方式发布和分发源代码。这种特性被称为“传染性”或“Copyleft条款”。

GPL协议第一版、第二版、第三版均包含传染性条款，其中第二版与第三版协议（以下简称GPL v2、GPL v3）是实务中最为常用的两个版本，GPL v2中涉及传染性的条款为第一条至第三条，GPL v3中涉及传染性的条款为第四条至第六条。协议中与传染性有关的条款内容分析如下：

1. 传播完整的源代码副本

GPL v2与GPL v3的共同点在于都赋予了用户复制和分发程序源代码的权利，允许用户在任何介质中逐字复制源代码；同时要求在每个副本中显著且适当地公布版权声明，并包含免责声明，表明程序不提供任何明示或暗示的担保；都要求保持与许可证相关的通知完整无损；在分发程序时，要求将本许可证的副本与程序一起提供给所有接收者。

两个版本内容不同点在于，GPL v3特别指出了非许可条款（即第七条附加条款）的适用，如果开发者在符合GPL v3第七条的条件下添加了某些限制，这些限制必须被遵守，并在分发源代码时通知接收者。其次在用语上有些许差异，第三版将原来“复制和分发（distribute）”改为了“传递（convey）”，不过二者并没有实质意义上的区别。自由软件基金会（FSF）在问答中指出GPL v3中的“convey”与GPL v2中的“distribute”含义相同^[1]。在执行GPL v2的过程中，由于了解到一些司法管辖区在自己的版权法中使用了“分发”一词，但赋予了它不同的含义，因此发明了一个新术语，以明确意图，避免这些差异可能造成的任何问题。

2. 传播修改后的源代码

GPL v2与GPL v3都允许用户修改原程序并创建衍生作品，不过衍生作品必须遵循相同的许可证进行分发；都要求修改后的作品必须显著标明已对原程序进行修改，在作品中注明修改的日期或修改内容；都要求修改后的作品必须且只能根据GPL许可证进行授权，对所有接收者提供该许可证的副本，在无例外情形下不得以其他方式授权。

两个版本在本部分内容之间的区别在于GPL v3特别提到第7条中的附加条款，要求修改后的作品必须在遵守GPL许可证的同时，遵循任何根据第7条添加的附加条件。

3. 传染性例外情形的规定

GPL v2和GPL v3都明确指出，若作品中的某些部分是独立的、不衍生自程序的内容，且独立部分与程序的其他部分没有合并形成一个更大的作品，则这些部分不受本许可证的约束。只有当这些独立部分与衍生作品一起作为整体分发时，整个作品才需遵循本许可证。

二者不同的是，GPL v3更为明确地定义了“聚合”概念，指出将受保护作品与其他独立作品编排在一起（但不合并成一个更大的程序）时，不会使这些独立作品也受到该许可证的约束，因此这些独立作品不会自动适用该许可。

纵向传染性指的是若代码受GPL协议约束，任何对该代码的修改或衍生作品必须继续遵循GPL协议发布，是从原始代码到修改后的代码之间的传染。例如根据GPL v3协议第五条的规定，该协议不允许以其他形式授权修改后的作品，即衍生作品必须继续遵循GPL的条款进行发布。这种传染性具有递进性和层级性，即每个新版本或新衍生作品都必须遵循相同的许可证，确保软件的自由性得以延续。纵向传染性强调的是从源代码到修改后的代码之间的关系，无论修改的程度如何，软件的派生版本必须遵循GPL协议，确保每一层的代码都继续对外开放。

横向传染性则是指当不同软件之间发生结合时，与GPL代码结合使用的其他代码，若形成“衍生作品”或“紧密结合”，也必须受GPL条款的约束。这种传染性通常发生在软件的集成过程中，例如通过静态链接、动态链接或其他方式将GPL代码与非GPL代码结合形成一个整体。如果这种结合导致代码之间形成了“衍生作品”，则整个软件必须遵循GPL协议，无论原始的非GPL部分是否经过修改。横向传染性确保的是，当GPL代码与其他代码（无论是开源还是专有）结合时，整个软件的开放性不会被封闭，避免了只将GPL部分开放而将非GPL部分封闭的情况发生。

如果在开源软件的基础上进行修改并形成了衍生作品，那么在分发该衍生作品时也需要公开整个衍生作品的源代码。

在福建风灵创景科技有限公司等与济宁市罗盒网络科技有限公司侵害计算机软件著作权纠纷案（以下简称罗盒诉风灵案）^[2]中，涉及早期作品采用GPL协议开源，而后续作品试图闭源的问题。由于早期作品适用了GPL v3开源协议，按照该协议要求，一切在开源版本基础上形成的后续版本都需要保持开源，公开其源代码。原告罗盒公司的软件 VirtualApp 在2016年9月10日将其原先采用的LGPL v3协议变更为GPL v3协议，并于2017年10月29日删除了GPL v3协议，意图将软件从开源状态转为闭源。然而，对于已选择开源并适用GPL v3协议的代码，任何后续版本如果是在这些代码基础上进行修改而形成的，则该后续版本同样受GPL v3协议约束。本案中法院依据GPL v3协议第二条、第四条和第五条的约定认定，只要后续版本使用了先前开源版本中的源代码，且先前版本适用了GPL v3协议，则后续版本也必然受到同一协议的约束。因此，即使罗盒公司尝试删除GPL v3协议以将软件转为闭源，涉案软件的后续版本仍然必须遵循GPL v3协议的规定，这体现了GPL协议的纵向传染性。

在济宁市罗盒网络科技有限公司诉广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案^[3]（以下简称罗盒诉玩友案）中，也体现了GPL协议的纵向传染性。该案被诉侵权软件的沙盒分身基础框架代码是在开源项目适用GPL v3协议发布的开源版本基础上研发而成。尽管被告玩友公司主张其投入了大量的人力财力，并在沙盒分身功能基础上自主研发创新，开发出涉案微信视频美颜APP，该APP的主要功能为微信视频美颜，而非沙盒分身功能本身，但是由于沙盒分身是在使用了GPL协议的开源代码的基础上研发而成，构成衍生作品，因此受到GPL协议的约束。另外沙盒分身构成了被诉侵权软件的一部分，从而导致被诉侵权软件整体也应当公开源代码。法院最终认定被诉侵权软件应整体适用GPL v3协议，玩友公司应开源整个被诉侵权软件的源代码。

如果将适用GPL协议的作品与其他自主研发的作品合并，二者紧密结合形成一个整体，那么形成的新软件作品也同样落入GPL协议传染性条款的约束范围，需要公开整个新软件作品的全部源代码。

在南京未来高新技术有限公司、江苏云蜻蜓信息科技有限公司等侵害计算机软件著作权纠纷案^[4]中，既涉及主程序被传染的问题，又涉及主程序与预览程序之间的独立性问题。本部分主要针对主程序因与开源软件之间存在函数调用关系而被传染展开。其中传染的过程（即具体调用过程）为：涉案软件的主程序中的主文件，在第14084行调用了一次压缩函数，这一函数是由开源代码编译生成的文件中的压缩函数。对此原告主张主程序可以独立运行，其仅通过一次函数调用来获取一个简单的返回值，二者之间的交互非常简单，因此不会受到GPL协议的传染。尽管如此，法院最终认定虽然主程序中的主文件仅调用一次函数，主程序与函数之间数据结构传递关系亦较为简单，但是在主程序与涉案GPL开源代码存在函数调用关系的情况，涉案GPL开源代码实现的压缩功能系投标文件上传前不可或缺的功能，因此，主程序系涉案GPL开源代码的衍生作品，受GPL协议的约束，应当公开源代码。由此可见，即便两个软件之间的交互极为简约，若它们之间达到了不可分割的程度，以至于在功能上构成了一个统一的整体，则适用GPL协议的代码将触发该许可证的传播条款，进而影响与之结合使用的其他代码，使其同样需遵守GPL的规定。

此外在罗盒诉风灵案中，被告福建风灵公司的被诉侵权软件“点心桌面”的部分代码使用了原告软件开源版本的代码，在审理过程中被告福建风灵公司也确认其被诉侵权软件中使用了罗盒公司依照GPL v3协议发布的VirtualApp开源代码。此时开源代码成为被诉侵权软件代码中的一部分，二者成为一个整体。法院在审理过程中指出，依据GPL v3协议的规定，对于逻辑上与开源代码相关联且作为一个整体发布的衍生作品，只要其中一部分是基于GPL v3协议发布的，那么整个作品都必须遵循GPL v3协议的条款。最终法院裁定被诉侵权软件应按照GPL v3协议的要求向公众开放其源代码。

如前所述，GPL 传染性条款的例外情况主要体现在“独立作品”上。如果两个程序在同一个存储介质上分发，但它们是相互独立的作品，没有通过修改、链接或合并形成一个单一的衍生作品，那么它们不受 GPL 许可证的传染性约束。即使其中一个程序是 GPL 授权的，另一个程序也可以使用不同的许可证，只要它们之间没有直接的依赖关系或共享源代码。

例如，在罗盒诉玩友案判决^[5]中，法院指出谷歌公司为了解决GPL协议过于严格的问题，发布的安卓移动操作系统通过将系统分为多个独立的不同层级框架，并对每个层级适用不同的开源授权许可协议。谷歌公司在安卓操作系统的内核使用了遵循GPL许可协议的开源Linux内核，那么个人或企业为安卓系统开发的应用软件也必须遵循GPL进行公开，这将严重降低企业和个人开发者参与安卓系统开发的积极性，妨碍了整个开源操作系统生态环境的建立。谷歌公司为了解决该问题，通过将GPL的适用局限在安卓系统独立的底层Linux内核空间中，而在上层的类库和应用框架以及用户空间部分则适用较为宽松的ASL开源软件许可协议。由于上层的类库和应用框架以及用户空间部分并不视为底层Linux内核的衍生产品，因此避开了GPL许可协议传染至整个安卓系统，那么安卓系统上层的硬件驱动和应用框架程序就是独立的，其开发者适用ASL进行开发，可以自由选择是否公开其源代码。

自由软件基金会在回答“聚合”和其他类型的“修改版本”有什么区别时指出：“两个独立的程序和一个包含两部分的程序之间的界限在哪里？这是一个法律问题，最终由法官决定。我们认为，适当的标准既取决于通信机制（执行、管道、rpc、共享地址空间内的函数调用等），也取决于通信的语义（交换什么样的信息）。如果模块包含在同一个可执行文件中，它们肯定会合并到一个程序中。如果模块被设计为在共享地址空间中链接在一起运行，这几乎肯定意味着将它们组合成一个程序。”

GPL协议的主要特点在于传染性和强制开源，基于该特点不少案件中被告均以开源协议作为其合法来源提出抗辩，虽然这些案件本质上是计算机软件著作权侵权诉讼，但是法院对于开源协议的抗辩均非常重视，一方面是对于开源秩序的尊重，另一方面传染性的认定对于侵权定性有着决定性的作用。

目前国内已经出现了一些涉及开源的诉讼案例，但是整体来看对于开源协议条款，尤其是传染性的认定仍然有需要提升的空间，其主要原因在于：

第一，GPL协议的传染性认定是一个非常复杂的问题，需要结合不同软件之间的隔离技术手段、通信方式、通信内容等考量因素，对软件的代码结构以及功能实现方式进行综合考量。因此在诉讼案件中想要对GPL协议的传染性进行准确的认定，不仅需要充分理解传染性判定标准，还需要投入大量的时间理解软件的交互及运行方式。

第二，目前国内开源案例中，有原告自己违反了GPL协议导致其诉权的合法性受到挑战，有原告认为其主张的软件代码不受GPL传染但法院未予支持，也有被告认为其基于开源协议合法获取源代码但难以举证仍被认定构成侵权，说明很多案件的诉讼当事方对于开源协议的理解是不足的，导致其对于权利基础的稳定性、合法性做出了错误的判断。

因此，提前聘请专业团队进行开源审查及治理是非常有必要的。开源审查不仅仅是针对开源协议本身的审查，而是需要结合研发过程、商业模式、市场定位、软件代码结构进行全面审查，对研发方向给出指导性的预先审查建议，同时对开源路径进行日志记录及证据留存，才可以更好地防范侵权风险。