开源软件促进了软件智力成果的共享，越来越多的企业将开源软件（代码）直接或再开发后用于商业用途。免费自由使用开源软件给企业带来便利的同时，也要求企业履行开源许可协议项下的义务。如未能履行开源软件协议项下义务将使企业面临巨大的法律风险。下文将对GPL开源软件项目法律合规业务中需要重点关注的几个问题进行分析。

企业需要明确自身使用的GPL开源软件适用的开源协议版本。例如后文提及的最高院审理的开源协议案件，适用的开源协议为GPL第三版本，其中对于“聚合体”软件有特有的论述，从而能够成为法院认定的依据。

需要注意的是，虽然同为GPL开源协议，其三个版本均为共存、独立有效状态，而非法律修订的新旧替代关系。因此，确定GPL开源协议的版本为GPL开源软件合规业务需要关注的首要问题。

如果GPL开源软件系通过开源社区进行下载，那么开源社区通常会标注该开源软件适用的GPL开源协议的版本号。如果并非从规范的开源社区下载，由于开源协议通常会要求在分发复制件时原封不动地附上开源协议的文本。因此在开源代码的文本中，也能够找到对应的开源协议版本。

对商业企业来说，商业软件的开发者下载GPL开源代码之后，通常都会将GPL开源代码或修改后的开源代码和其他自研软件代码整合进企业自己的商业软件之中，并一同分发和使用。因此商业企业需要审查评估其自研软件与GPL开源软件之间的关系，即GPL开源软件／基于开源软件的衍生作品与其他自研软件作品是否互相为独立的软件。如果GPL开源软件和自研软件属于独立软件，则自研软件并不会被GPL协议所传染；如果GPL开源软件和自研软件不属于独立软件，则自研软件会被GPL协议所传染。

如何判断软件独立性需要结合技术与法律，下文将从就自由软件基金会对软件独立性问题的解答、开源软件实例和我国的司法判例进行介绍。

1、自由软件基金会对软件独立性问题的解答

根据自由软件基金会发布的GPL相关问题的解答，“聚合体”包含有多个独立的程序，并在同一个CD-ROM或其他媒体上发行。GPL.v3允许开发者制作并发布一个聚合体，即使其中其他软件的许可证不是自由许可证或不是GPL兼容的许可证也可以。唯一的条件是聚合体的许可证不能禁止用户行使每个独立程序的许可证允许的权利。区分软件究竟是两个独立的程序，还是一个程序的两个部分的合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息），具体判断的工作则应交由法院完成[1]。

2、“OpenHarmony”开源项目中对开源软件独立性的说明

近期，华为公司自行研发的“OpenHarmony”开源项目也公开了相应的软件结构和代码说明，其中就有开发者针对软件独立性的特别说明。举例而言，“OpenHarmony”中包含一个名为“third_party_mtd_utils”的开源软件，该软件适用GPL.v2，“OpenHarmony”的开发者对该开源软件进行了如下说明：“third_party_mtd_utils用于编译生成jffs2文件系统镜像的打包工具，该工具用于打包jffs2格式的rootfs和userfs镜像，代码不会编译打包到kernel_liteos_a内核中，故kernel_liteos_a内核不受GPL影响”；又例如，“OpenHarmony”开源项目中有一名为“vendor_hisi_hi35xx_thirdparty_uboot_src”的开源软件，开发者对其的说明是：“uboot是作为独立进程，不会导致boot外的软件受到GPL许可证的影响”[2]。由此可见，华为公司在开发“OpenHarmony”开源项目时，已经注意到开源义务，从而在软件的结构上，维持开源软件的独立性，从而规避开源软件的传染性。

3、我国司法实践中对软件独立性的认定思路

（1）柚子（北京）移动技术有限公司与数字天堂（北京）网络技术有限公司侵害计算机软件著作权纠纷案

该案的原告数字天堂公司主张被告柚子公司侵犯了原告的软件著作权，被告柚子公司主张原告的涉案软件中使用了GPL开源代码，对应的GPL协议的版本为第三版。一审法院审理认为，因原告主张被告使用的是涉案软件中的三个插件，而该三个插件属于独立的软件作品，因此，需要判断的是该三个插件是否是受GPL协议限制。一审庭审中，被告认可该三个插件均处于独立的文件夹中，该文件夹中并无GPL开源协议文件。据此，一审法院认为：“涉案三个插件的文件夹中并无GPL开源协议文件，而涉案软件的根目录下亦不存在GPL开源协议文件的情况下，尽管涉案软件其他文件夹中包含GPL开源协议文件，但该协议对于涉案三个插件并无拘束力，涉案三个插件并不属于该协议中所指应被开源的衍生产品或修订版本，被告柚子公司认为原告数字天堂公司软件为开源软件的相关抗辩理由不能成立。被诉行为构成对著作权人复制权、改编权及信息网络传播权的侵犯”[3]。

被告柚子公司在二审中提出GPL协议的“传染性”问题，被告主张涉案软件中既然已经采用了GPL开源代码，那么无论是否仅涉及插件，GPL的传染性也会导致整个涉案软件均应适用GPL协议从而成为可以供他人自由使用的开源软件。但是二审法院依然没有对GPL协议的文本进行研究，在二审判决中依然强调没有在涉案软件的根目录中发现GPL协议文件，从而不认可被告主张的GPL协议传染性观点，进而否认涉案软件已经成为开源软件的观点[4]。

该案为我国司法实践中涉及GPL开源协议的第一案，但是从法院的审查严谨性上，似乎并不尽如人意。该案实际上已经触及了GPL开源协议最关键的“传染性”问题，就判决书中查明的案件事实来看，原告主张权利的涉案软件的部分代码确实是用了开源代码，其软件整体的确存在已经被传染成为开源软件的可能性。但是一、二审法院都并没有对涉案软件和插件的通信机制和通信语义进行审查，而是仅凭软件目录中没有开源协议文本就认定了涉案软件不受开源协议的规制，直接排除了涉案软件整体已经被传染称为开源软件的可能性。事实上，假使原告在开发涉案软件的过程中有意没有遵循开源协议的义务放置开源协议的文本，抑或是第三方开发的过程中，规避开源的义务而没有放置开源协议的文本，均有可能导致该案的结果截然相反。本案作为开源协议“传染性”的第一案，在认定是否适用“传染性”的问题上，法院没有结合开源协议传染性条款相关内容和软件技术细节进行深入审查讨论，判断依据简单，得出结论仍有进一步商榷讨论的空间。

（2）北京闪亮时尚信息技术有限公司、不乱买电子商务（北京）有限公司侵害计算机软件著作权纠纷案

本案中，原告不乱买公司主张被告闪亮公司侵犯原告的软件著作权。原告同样抗辩涉案软件已经被GPL开源协议传染从而整体成为开源软件。本案涉及的是GPL.v3开源协议。本案中，被告举证证明了原告的网站的前端代码中采用了开源代码，如果能够进一步证明前端代码和后端代码构成一个整体软件进行分发，那么涉案软件可能已经受到“传染性”的影响。本案的一审法院认为，原告的网页仅有前端代码明确使用了开源代码，原告主张权利的是其后端代码。前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式，后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现，二者展示方式不同、所用技术不同、分工亦有明显区别，属于可独立的程序[5]。因此一审法院认为，不乱买公司虽在其前端代码中使用了开源代码，但其后端代码程序并非其前端程序的衍生品或修订版本，故根据GPL协议的相关规定，该协议对涉案权利代码并无拘束力。

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

最高院的在该案中的二审判决引用了GPL.v3开源协议中对开源传染性的例外条款。当开源代码与软件的中的其他独立程序组成“聚合体”时，开源协议不会对其他程序进行传染。最高院参考了自由软件基金会判断软件独立性的标准，考虑了通信的机制和通信的语义，得出后端代码具有独立性的结论。最高院的前述判断依据更为科学合理，得出结论也更准确。

开源协议合规的落脚点必然是履行协议要求的开源义务。对于GPL开源协议项下的义务，在开源软件合规项目中应当注意审查企业是否不折不扣地全面履行了相关开源义务。否则极有可能自动触发著作权许可合同的解除或终止条件，随之面临巨大的软件著作权侵权法律风险。

如果发生开源义务要求与企业商业软件的保密要求之间的矛盾确实无法调和时，可以建议企业在阻断GPL传染性的基础上，采用自研软件进行替代。