HIT 19: 开源软件（GPL）传染性问题探讨-电子发烧友网

作者：高玉光北京市信利（深圳）律师事务所 2023/09/10于深圳#本文仅代表作者观点，未经作者许可，禁止转载#

GNU通用公共许可协议（General Public License，GPL）是一种适用于软件和其他各类作品的自由且不可加以限制的COPYLEFT许可证。根据GPL3.0规定，被许可人享有复制、修改（署名）及转发源代码的权利，但同时需承担相应的法律义务，即GPL3.0要求被许可人在转发经其修改后的软件作品时，必须具有显著的声明：说明对该作品进行了修改并提供修改相关的日期，说明该作品是依据本许可证以及根据第7条附加的条件进行发布的；并且根据本许可证将整个作品作为一个整体授权给任何拥有副本的人；本许可证将与任何适用的第7条附加条款一起，适用于整个作品及其所有部分，无论它们是如何打包。

而GPL的核心原则就是它的“传染性”。“传染性”可以通俗定义为：如果是转发修改后的源代码，新修改的代码也必须遵循GPL协议；以保证无论他人是否修改源代码，都可以享有继续复制、修改、转发的权利，以使得这种自由的权利继续延续下去。这种"传染性"确保了开源软件的自由传播、开源共享和开放合作。

下面结合最高人民法院的一则司法案例进行GPL“传染性”的探讨[1]。

一、案件背景

2014年3月原告不乱买公司成立。2014年8月10日，不乱买公司网站（××）上线。2016年8月23日，国家版权局颁发计算机软件登记证书，显示软件名称为“不乱买时尚海淘软件（ＰＣ版）”，著作权人为不乱买公司，开发完成日期为2015年3月27日，首次发表日期为2015年3月27日。不乱买公司提交了（2016）京中信内经证字第72865号公证书，2016年8月30日对不乱买公司网站（××）页面信息、网页源代码及脚本源代码进行了公证。该公证书显示，不乱买公司网站页面底部标有“2013-2016不乱买电子商务（北京）有限公司”字样。同时，不乱买公司亦提交了其网站源代码电子文件及用以证明涉案软件的研发过程的证据。

一审庭审中，不乱买公司确认其主张权利的代码为其后端所有代码，不包括数据库。被告闪亮时尚公司对不乱买公司软件源代码权属不予认可，但未提交相反证据。为证明闪亮时尚公司对不乱买公司享有著作权的软件具有接触可能性，不乱买公司提交了微信记录、邮件截图、劳动合同及闪亮时尚公司工商登记信息等。

二、关于双方源代码获取及比对情况

不乱买公司对闪亮时尚公司网站页面信息、网页源代码及脚本源代码进行了公证，并提交了自行比对的结果，闪亮时尚公司对此不予认可。

一审中，不乱买公司向原审法院提交了调查取证申请，依据不乱买公司申请，原审法院于2018年3月向阿里云计算有限公司调取其服务器中闪亮时尚公司网站后台全部软件代码。技术调查官对不乱买公司提交的后端代码进行了筛查，排除了开源代码的使用。因闪亮时尚公司不同意向不乱买公司及案外人提供其网站代码文件，仅同意在原审法院的主持下进行比对，且由于双方代码文件数量庞大，双方当事人均同意采用抽样方式进行比对，故原审法院确认在其主持下采用抽样比对的方式对不乱买公司和闪亮时尚公司网站代码文件进行比对，抽样比对结果将推及全部代码。抽样及比对过程如下：

在原审法院主持下，不乱买公司明确有版权的权利文件3922个。经双方当事人一致同意，原审法院确认以5%的比例从中挑选20个文件作为不乱买公司的抽样比对文件，再以关键词等方式确定闪亮时尚公司的对应文件，最后用比对软件进行比对。在技术调查官的监督下对原审法院调取的闪亮时尚公司网站源代码压缩文件进行全盘解压，共计1086万个文件。不乱买公司针对其选取的20个核心代码文件在已解压的闪亮时尚公司源代码文件中进行查找，最终确定对应文件13个。针对上述13个文件使用双方确定的ultracompare软件与不乱买公司对应源代码文件进行逐一比对，最终由该比对软件输出13份比对结果。比对结果显示：二者有些许差异，总体上实质相似。

三、GPL3.0部分相关规定

定义部分，“本程序”指任何在本许可下批准的受版权保护的程序。“修订”程序是指从软件拷贝或者做出全部或一丁点儿的修改，这不同于逐字逐句的拷贝，是需要版权许可的。修订成果被称为先前程序的“修订版本”或者“基于”先前程序的程序。

第5条，发布修订过的源码版本，您可根据第4条的条款，以源码形式发布一个基于本程序的程序，或者从本程序中制作该程序需要进行的修订，但是您必须同时满足所有以下条件：c)…本许可以及第7条中的任何附加条款适用于整个程序及其所有部分，无论该等程序以什么形式打包。d)…如果一个受保护程序和其它独立程序的联合作品，则若该联合作品并非该程序的自然扩展，也不是为了在某个存储或发布媒介上生成更大的程序，且如果联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时，这样的联合作品就被称为“聚合体”。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分。

四、一审法院观点

在不乱买公司已就其享有涉案软件著作权提交初步证据且闪亮时尚公司并未举出反证的情况下，原审法院对不乱买公司的权利予以认可。不乱买公司有权就涉案侵权行为提起诉讼。闪亮时尚公司提交的公证书显示，不乱买公司网站的前端代码中使用了GPL许可协议下的开源代码，不乱买公司对此亦予以认可。闪亮时尚公司认为，不乱买公司使用了适用于GPL软件许可协议下的开源代码，根据GPL许可协议相关内容，不乱买公司无权对其网站整个软件主张著作权。对此，原审法院认为，不乱买公司明确其主张权利的代码为后端代码。前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式，后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现，二者展示方式不同、所用技术不同、分工亦有明显区别，属于可独立的程序。根据GPL协议的相关规定，GPL协议的许可客体是在GPL协议许可下批准的受版权保护的程序以及基于该程序的衍生产品或修订版本。就该案而言，不乱买公司主张的权利的后端代码中已排除开源代码，不乱买公司虽在其前端代码中使用了开源代码，但其后端代码程序并非其前端程序的衍生品或修订版本，故根据GPL协议的相关规定，该协议对涉案权利代码并无拘束力。据此，闪亮时尚公司的相关抗辩理由不能成立。

著作权侵权案件中判断被诉侵权作品是否使用了享有著作权作品的方法一般适用“接触加实质性相似”。综合本案证据，原审法院认可闪亮时尚公司具有接触到不乱买公司涉案权利软件的可能性。

关于实质性相似。基于比对结果及技术分析可知，抽样比对的绝大部分程序文件在程序逻辑和结构方面实质相同，函数变量命名特点相同或相似，且闪亮时尚公司不同文件的代码中多次出现与不乱买公司程序中相同的注释错误，该现象难谓巧合。据此，可以确定闪亮时尚公司与不乱买公司的上述程序文件实质相似的比例较高，闪亮时尚公司的该行为落入不乱买公司的复制权及修改权的保护范围。故闪亮时尚公司未经不乱买公司许可使用涉案软件的行为已侵犯不乱买公司就其软件享有的署名权、复制权及修改权，应承担停止侵权、赔偿损失及赔礼道歉的法律责任。

五、二审法院观点

闪亮时尚公司上诉称不乱买公司前端代码与后端代码存在交互且没有进行有效隔离，不是相互独立的，根据GPL协议的相关内容以及极强的传染性特性，不乱买公司的前端文件和后端文件共同构成的其主张著作权的软件，整体软件都可以视为前端程序的修订版本，应当遵循GPL协议向所有第三方无偿开源。对此，二审法院认为，第一，前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。同时，前端代码与后端代码是可以分别独立打包、部署的。因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，原审法院认定前端代码与后端代码相互独立并无不当。第二，不乱买公司作为权利人在本案中明确放弃以前端代码主张权利，仅以后端代码主张权利，因此涉案软件仅为后端代码而非闪亮公司所称前端文件和后端文件共同构成涉案软件。第三，根据2007年6月29日发布的GPL协议第3版第5条关于“一个受保护程序和其它独立程序的联合作品，在既不是该程序的自然扩展，也不是为了生成更大的程序，且联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时，被称为聚合体。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分”的规定，闪亮时尚公司所称GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。本案中，虽然不乱买公司认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需强制开源。综上，闪亮时尚公司的上诉理由不能成立。

六、本文作者观点

最高法院在二审中确认了涉案软件前端代码和后端代码的区别，即前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。前端代码与后端代码可以分别独立打包、部署。前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体。笔者认为，上述观点尽管基本符合GPL的相关规定，但感觉仍有很大的探讨空间。即在前端代码与后端代码之间存在交互配合的情况下，哪些情形可以认定构成一体，哪些情形不构成一体？

我们假设一种情形，后端代码尽管可以独立打包并实现相关逻辑功能，但后端代码只能且唯一依赖该前端代码才能运行，否则后端代码不能独立运行，即后端代码只能依靠该前端代码才能实现其功能和价值，或者后端代码与前端代码之间存在调用代码或者函数的关系，亦或者前端代码直接影响后端代码的结构，此时前端代码仍然不能传染给后端代码吗？答案可能是否定的。与之相反的情形，当后端代码通过程序接口可以与多种前端代码交互配合或者反之亦然，即前端代码和后端代码都可以独立运行且具有兼容性，则该种情形下认定前端代码不具有传染性应该不会有太大的争议。

进一步而言，在软件开发实践中，广泛存在开源软件与专有软件进行组合的情形。GPL软件与专有软件形成的组合软件是否需要开源，应取决于GPL软件与专有软件的交互方式。例如，Linux开发环境下的应用程序，如果一个为Linux系统编写的专有软件仅运行于Linux内核的常规系统调用中并保留在“用户区（UserLand）”，则该专有软件应该无须遵守GPL。另一个例子，如果利用GPL下的软件工具创建专有软件，GPL软件工具中的代码没有合并到创建的专有软件中，则该专有软件应该无须遵守GPL，此种情形下，GPL软件工具仅用作创建专有软件的辅助工具[2]。另外，关于用户单独分发Linux内核模块，及GPL下访问软件库的程序等情形是否需要遵守GPL，还有开源软件应用程序接口（API）的侵权风险等问题，目前还缺少相关的司法案例，笔者将继续关注并研究。

参考文献：

[1] 最高人民法院民事判决书（2019）最高法知民终663号。

[2] 张平，徐美玲：《开源规则：案例、许可证及开源组织》，知识产权出版社，2022年11月第1版，第15页。

如果对此话题感兴趣，欢迎扫码加入“共熵大家庭”，共同推动产业与标准进步！