姚敏
中国律师
北京魏启学律师事务所
 
GPL协议是开源软件广泛使用的许可证之一。GPL协议要求基于GPL开源代码的衍生代码或者修改版也必须采用GPL协议发布，开放源代码。GPL协议的这一特点被称为“传染性”。GPL协议的“传染性”对利用GPL开源代码进行软件开发有重要影响，因此受到软件开发者的广泛关注。本文将结合GPL协议的规定和实务案例探讨和总结GPL协议“传染性”的司法判断规则，希望对软件开发者合规使用GPL开源软件、合理规避传染提供一些思路。  
 
一、GPL协议“传染性”内容及其例外
 
GPL协议未直接使用“传染性”一词，实践中将GPL协议不仅适用于基于GPL协议发布的原始作品，还适用于基于原始作品的衍生作品的这一特点形象的总结为“传染性”。
 
GPL协议有V1、V2、V3三个版本，V2、V3两个版本占主流，本文主要分析V2、V3两个版本的相关规定。
 
GPL协议V2版本允许使用者修改GPL开源代码或者其部分代码，基于此形成的作品在发布时必须遵循GPL协议。GPL协议V3版本要求使用者在发布基于GPL开源代码的作品或者修改后的作品必须遵循GPL协议。　
 
GPL 协议V2、V3两个版本都规定了“聚合作品”不受GPL协议“传染”。GPL协议V2版本规定，仅将非基于受保护程序的另一作品与受保护程序（或基于受保护程序的作品）聚合（mere aggregation）在存储或分发介质上，不会导致其他作品收到本许可协议的约束。GPL协议V3版本规定，本授权下的受保护作品（covered work）和其他与之分离的独立作品（separate and independent works）组成的一个汇编作品（a compilation of a covered work）中，后者（独立作品）并非前者（受保护的作品）的自然延伸，与前者并未混合在一起，也未意图在某种存储或分发媒介上组成一个更大的程序，如果这种汇编作品及其产生的著作权并非用于限制独立作品给予汇编作品用户的访问及其他合法权利时，则它被称为“聚合作品”（aggregate）。在“聚合作品”中含有本授权项下的作品，不会导致“聚合作品”中的其他软件作品也适用本协议。     
 
二、GPL协议“传染性”的司法判断规则
 
GPL协议“传染性”内容及其例外在司法实践中是如何适用的？下面将通过以下几个案例总结和说明目前司法实践中GPL协议“传染性”的判断规则。
 
案例1：(2019)粤73知民初207号一案中，原告济宁市罗盒网络科技有限公司对“罗盒”软件享有著作权，该软件使用了GPLV3协议发布。被告玩友公司开发的四款美颜相机软件中的沙盒分身功能部分的源代码经鉴定与原告涉案软件代码相似，但是被告未根据GPL协议的许可条件公开被控软件的源代码。广州知识产权法院经审理认定，被控侵权软件是开源代码的衍生作品，被告未向用户提供被诉侵权软件源代码下载违反了GPLV3协议规定，则其对涉案软件源代码的复制、发布行为因失去权利来源而构成侵权。
 
上述案例中，被控侵权软件的沙盒分身功能部分使用了原告的GPL开源代码，被控侵权软件被认为构成原告开源软件的衍生作品，法院认定被控侵权软件整体受到GPL协议的约束。
 
案例2：(2015)京知民初字第631号案件中，原告数字天堂公司是HBuilder开发工具软件的著作权人，原告认为被告发布的APICloud软件抄袭了原告涉案软件中三个插件（代码输入法功能插件、真机运行功能插件、边改边看功能插件）的源代码。被告以原告软件使用了GPL（V3）开源代码，其软件整体受GPL开源协议约束，亦构成开源软件，其使用原告开源代码的行为不构成侵权进行抗辩。北京知识产权法院经审理，认为原告的三个插件均处于独立的文件夹中，该文件夹中并无GPL开源协议文件。且，HBuilder软件的根目录下亦不存在GPL开源协议文件。尽管HBuilder软件其他文件夹中包含GPL开源协议文件，但该协议对于涉案三个插件并无拘束力。基于此，法院认定被告的抗辩理由不能成立，其行为构成侵权。北京高院在上述案件的二审（2018）京民终471号中亦认可了一审法院的判断。　
 
上述案例中，原告软件的三个插件位于独立的文件夹中，三个插件可以独立运行，原告针对三个插件分别进行了著作权登记，法院认可了三个插件构成独立作品，不受GPL协议约束。　
 
案例3：（2016）京73民初1111号案件中，原告不乱买公司对“不乱买时尚海淘软件”享有著作权，该软件由前端代码和后端代码共同组成，原告明确其在本案中主张权利的代码为后端代码。被告在该案中以原告的软件使用了GPL许可协议下的开源代码，因此原告无权对整个软件主张著作权进行抗辩。北京知识产权法院审理查明，原告软件的前端代码使用了GPL开源代码，而后端代码并未使用开源代码。法院认为，前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式，后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现，二者展示方式不同、所用技术不同、分工亦有明显区别，属于可独立的程序。原告主张权利的后端代码未使用开源代码，其后端代码程序并非其前端程序的衍生品或修订版本，故根据GPL协议的相关规定，该协议对涉案权利代码并无拘束力。基于此，法院认定被告的抗辩理由不能成立，其行为构成侵权。最高院在上述案件的二审(2019)最高法知民终663号中亦认可了一审法院的判断，指出前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体。
 
上述案例中，法院基于前端代码和后端代码的展示方式不同、所用技术不同、分工亦有明显区别，可以分别独立打包、部署，认为二者属于两个独立的程序。虽然前端代码使用了GPL开源代码，但是后端代码构成独立程序，因此不受开源代码GPL协议的约束。　
 
案例4：（2021）苏01民初3229号案件中，原告南京未来高新技术有限公司基于“未来网上投标文件制作工具软件”作为权利基础，对其自行撰写的专有代码部分主张著作权。原告主张被告江苏云蜻蜓信息科技有限公司的被控侵权软件“云蜻蜓软件—投标文件制作工具”使用了其专有软件代码，构成著作权侵权。被告以原告软件使用了GPL开源代码，因此其软件整体受GPLv2协议约束，原告未开源其代码，属于违反诚实信用原则，不应该支持其侵权诉讼请求进行抗辩。
 
南京中院经审理查明原告软件情况如下：

（1）原告涉案软件包括主程序（FutureTBTool.exe）和预览程序（ViewnNTF.exe）两部分，主程序用于制作投标文件，预览程序用于查看投标文件。
（2）原告将其自行编写的FutureZR.cs代码（包含CompressZip()函数）与开源软件SharpZipLib（适用GPL v2.0 或更新的版本with Classpath Exception许可证）一同编译成FZR.dll文件,主程序对CompressZip()函数进行调用，CompressZip()函数对开源代码进行调用，最终实现文件压缩功能，该压缩功能系投标文件上传前不可或缺的功能；
（3）预览程序独立于主程序，且不调用开源软件SharpZipLib。
 
原告软件与开源软件的调用关系总结如下：


 
本案中，法院对GPL协议“传染性”判断进行了详细的论述和说理，具有较高的实务参考价值。法院首先从整体上概括了其对GPL协议传染问题的观点。在逻辑上与开源代码有关联性且整体发布的衍生作品，只要其中有一部分适用了GPL协议发布，那么整个衍生作品都必须适用GPL协议而公开。但是如果能够确定作品的一部分并非程序的衍生作品，是独立的，则这部分独立的程序发布时可以不受GPL的约束。判断GPL协议所能传染的衍生软件或修订版本，区分开源代码与自有代码，即确定自有代码是如何与开源代码结合或交互是前提。其次应结合代码的使用场景，即结合代码的功能及其在软件中所起的作用进行判断。最终确定被传染的部分应当是与原开源软件形成密切通信使得二者高度牵连融合成一体的程序，而非只要有数据交换就会构成传染。 
 
为确定原告自有代码与GPL开源代码的交互方式，法院要求原告针对涉案投标软件梳理出了涉案软件处理流程图和使用编程工具导出函数调用关系图。法院对涉案软件的主程序和预览工具是否受到GPL协议传染分别进行了论述。
 
1.关于主程序
 
原告认为其涉案软件主程序脱离FZR.dll（包含涉案开源代码）可以独立运行，两者之间只是一个简单的单向函数调用并且只返回true/false,因此主程序与FZR.dl1是两个独立程序。涉案开源代码的GPL协议中添加了Classpath Exception例外声明，涉案软件的FutureZR作为一个独立模块，与主程序进行链接，适用开源代码中的例外声明，从而阻断GPL开源许可协议的传染，因此涉案软件不受GPL协议的约束。
 
法院认可涉案软件主程序中的主文件RibbonMainForm.cs仅调用1次FutureZR.cs中的CompressZip()函数，主程序与CompressZip()函数之间数据结构传递关系亦较为简单，但是法院认为在主程序与涉案GPL开源代码存在函数调用关系的情况，涉案GPL开源代码实现的压缩功能系投标文件上传前不可或缺的功能，因此，主程序系涉案GPL开源代码的衍生作品，受GPL协议的约束。

关于原告主程序对开源代码的调用符合Classpath Exception例外声明的主张，法院认为，原告将自行编写的FutureZR.cs文件与SharpZipLib开源代码一同编译成FZR.dll文件,并由主程序对其进行调用的方式，不符合“例外声明”中“一个独立的模块是一个不从本库衍生或基于本库的模块”关于独立模块的约定（即原告编译的FZR.dll文件是开源代码的衍生作品，而非独立模块），因此“例外声明”对其不适用，对原告的上述主张不予采信。
 
2.关于预览程序

法院查明预览程序实现独立的查看投标文件的功能，并非用户制作、上传投标文件所必需。预览程序文件脱离主程序后在新目录下能够独立运行。主程序目录下删除预览程序文件后，主程序亦能独立运行。基于此，法院认定预览程序不是涉案GPL开源代码的衍生作品，未被GPL开源代码传染，故不受GPL协议的约束。
 
上述案例中，法院对自有代码是否受到GPL开源代码“传染”的判断可以总结为两个方面：一、判断自有代码与开源代码之间是否存在交互关系及其交互内容，以确认二者是否形成密切通信；二、判断开源代码在软件整体中所起的作用。从法院的分析来看，法院认可了主程序（自有代码）与开源代码之间的交互关系和通信内容较为简单，从这个方面而言似乎法院认可二者虽然存在交互关系，但是未形成密切通信；但是法院又进一步认为，在主程序（自有代码）与开源代码存在交互关系的前提下，二者是构成两个独立的程序还是一个程序的两个部分，还需要考虑开源代码在软件整体中所起的功能和作用。 由于开源代码所实现的文件压缩功能是涉案软件不可或缺的功能，因此认定主程序构成开源代码的衍生作品，受GPL协议的约束。而预览程序（自有代码）不调用开源代码，且独立于主程序，法院认定预览程序不构成开源代码的衍生作品，不受GPL协议的约束。
 
案例4中法院的判断规则与自由软件基金会（FSF）所持观点基本一致。究竟怎么区分是两个独立的程序，还是一个程序的两个部分？FSF在常见问题（FAQ）中答复：这是一个法律命题，最终会由法官来决定。合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）。如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。反过来，pipes、sockets和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。
 
案例4中法院对于GPL协议“传染性”的判断规则与案例2、3的判断规则存在明显不同，案例2、3中法院主要是根据软件模块之间的部署方式、展示方式、功能用途等考察自有代码与开源代码是构成独立作品还是衍生作品，而未对模块之间的交互方式和通信内容进行详细的调查。目前未发现案例4的二审判决，被告是否提起上诉不得而知。从本案一审判决内容来看，法院的判断规则对软件开发者合规使用开源软件提出了更高的要求。
 
本案还有一点值得关注的是法院对软件权利人违反GPL协议的行为的态度。对于原告违反GPLV2协议要求未履行提供源代码义务的情形，法院认为原告的行为导致开源代码授权人与原告之间的授权自动解除，原告对原GPL开源代码的继续使用系无权使用。如果基于原告的该权利认定其他行为人构成计算机软件侵权，即会保护原告的不当行为带来的利益，势必赋于其特殊法律地位和特别商事利益，不符合公平、诚信原则。对原告违反GPL协议的行为给予侵权法上的保护，势必虚置GPL协议关于源代码持续开源的相关规定，对于通过GPL协议让源代码持续开源传播产生不利影响。基于此，法院未采纳原告被控侵权软件主程序构成侵权的主张，仅支持了被控侵权软件预览程序构成侵权的主张。
 
本案还有一点比较特殊的地方在于，本案原告此前曾对同一被告的同一款被控侵权软件在同一个一审法院南京中院提起过软件著作权侵权诉讼（一审案号：（2018）苏01民初2523号，二审案号：（2021）最高法知民终406号），而在此前的案件中，被告并未以原告软件使用GPL开源代码进行抗辩，该案一审法院南京中院和二审法院最高人民法院亦未主动对原告主张权利的软件是否使用GPL开源代码进行查明。而本案中，被告以原告的权利软件使用了GPL开源代码提出抗辩，法院也支持了被告的部分抗辩理由。在涉案软件使用GPL开源代码的情况下，无论是对于软件著作权权利人还是被控侵权人，在启动软件著作权侵权诉讼或者应诉时，应当考察GPL开源代码可能对案件产生的影响，事先对案件做全面评估。
 
三、总结

中国目前仅有个位数以内的民事诉讼案件涉及GPL协议的传染判断问题，裁判规则还处在建立和完善过程中。案例4是涉及GPL协议传染性问题的最新判决，法院的判断规则对软件开发者合规使用开源软件提出了更高的要求。以不同文件夹部署软件模块、对软件模块分别进行著作权登记等形式可能难以做到有效隔离GPL协议“传染性”。如果软件开发者不希望自有代码受GPL协议传染，则在软件开发之初需要深入研究是否能够以合理的技术手段避免自有代码受GPL协议传染。合理的技术手段应当不止于软件模块独立打包部署，还应充分考虑自有代码与开源代码之间的交互方式和交互内容。