目前，业内亦开发了不同的许可证选择工具，如ChooseALicense[3]、LicenceDifferentiator[4]等，这些选择工具能够较为直接地帮助开发者理解不同许可证的权属限制和授权范围，为开发者提供简单场景下的许可证推荐，但这些工具一般是对许可证规则的简单归纳，难以适应复杂的开发环境和开发需求。因此，要理解不同许可证的传染性规则并加以利用，一方面需要回归开源许可证本身的性质和条款，另一方面需要了解在中国的司法实际效果。

（choosealicense网站截图）

根据开源许可证的历史发展和自身性质，大体而言，目前的开源许可证可以分为三类，一类是Permissive free software license（下译为宽松自由软件许可协议），一类是Copyleft License（或译著佐权许可证、反版权许可证；下译为反版权许可证），一类是Weak Copyleft License（下译为弱反版权许可证）。

宽松自由软件许可协议对软件的使用、修改、加工等的限制较低，通常只要求被许可方承认原始作者，衍生软件可以成为私有软件，BSD系列许可证、MIT、Apache-2.0和木兰宽松许可证均属于此列；反版权许可证则顾名思义，由于其诞生理念即是为了促进软件开发合作和共享，因此往往要求对软件的修改和扩展，必须按照获得该软件的许可证进行开源，且不得违背原作品的限制条款，如OSL系列许可证即属于此类；弱反版权许可证则采用了折中方法，要求对软件的修改、重新分发必须按照获得该软件的许可证进行开源，但合并这些软件代码的大型作品可以成为私有作品，此类许可的代表是LGPL、MPL等。[5]

在宽松自由软件许可协议中，以木兰宽松许可证第二版为例，其中1、2条即规定：

这意味着使用木兰宽松许可的开源软件在保证原作者版权的前提下，可以进行修改和再发布，也被用于闭源软件，并且不强制要求使用该许可证。因此，木兰宽松许可证传染性较弱。

而作为反版权许可证的代表，GPL系列许可的强传染性一向使其最具争议。根据GPL3.0条款第四条、第五条：

您可以在收到程序的源代码后，以任何媒介传递其逐字副本，但您必须在每份副本上醒目地、适当地发布适当的版权声明；保持所有说明本许可证和根据第7条添加的任何非许可条款适用于代码的声明完整无缺；保持所有关于没有任何保证的声明完整无缺；并将本许可证的副本与程序一起交给所有接收者。[6]

您可以根据第4节的条款，以源代码的形式传递基于本程序的作品，或根据本程序进行的修改，但您必须满足以下所有条件：a）该作品必须有醒目的通知，说明您对其进行了修改，并给出相关的日期。b）作品必须有醒目的声明，说明它是根据本许可证和根据第7条增加的任何条件发布的。这一要求修改了第4节中关于"保持所有通告完整"的要求。c）你必须将整个作品作为一个整体，根据本许可证授权给任何拥有副本的人。因此，本许可证将与任何适用的第7条附加条款一起，适用于整个作品及其所有部分，无论它们是如何包装的。本许可不允许以任何其他方式许可该作品，但如果你已经单独收到了这种许可，它不会使这种许可失效。d）如果作品有交互式用户界面，每个界面都必须显示适当的法律声明；但是，如果程序有交互式界面而不显示适当的法律声明，你的作品不需要使其显示。

如果一个受许可保护的作品与其他独立的作品的汇编，该汇编性质不是该受保护作品的延伸，且在存储或分发该作品的某一媒介上亦没有与之结合形成一个更大的程序，且该汇编及其产生的版权，没有被用来限制单独作品给予汇编作品用户的访问及其他合法权利，则该汇编被称为“聚合”。将一个受保护的作品包含在一个总体中并不导致本许可适用于总体的其他部分。

由上述条款可见，GPL3.0作为反版权许可类型，其具有的强传染性主要体现在：使用了GPL作为开源许可的软件在修改、使用、复制之后生成的衍生作品，必须依然适用GPL作为开源许可，若违反了这一条件，则许可证失效，衍生作品将会被判断为侵权。这些衍生作品既包括开源软件自身的修改版本，也包括由开源软件自身或其修改版衍生出的新的作品。

针对传染性规则，GPL3.0中亦规定了例外条款，即当使用GPL的开源软件同其他独立作品汇编时，在其非是该作品延伸、也并没有形成更大的程序的情况下，可以被视为一种横向的聚合体，GPL可以不传染至该总体汇编的其他部分，这一规定对突破GPL传染性的情况进行了相当严格的解释和界定，也给实务界处理相应纠纷带来了挑战。

正如我们此前文章中介绍，目前司法实践当中，对于使用开源软件引发的纠纷，法院往往从计算机软件著作权合同或计算机软件著作权侵权角度进行分析和论证，将此类纠纷放置在计算机软件著作权保护的框架下进行裁判。[7]针对GPL这类强传染性的反版权许可类型，对其衍生作品的传染性的司法实践已经形成了较为稳定的惯例。实务裁判中，各方当事人主要争议的焦点，往往在于如何界定其是否符合传染性规则的例外，从而判断是否构成违约或侵权。通过下述具有代表性的案例，我们能管窥其中的主要争议焦点和裁判的裁量尺度。

以柚子（北京）科技有限公司（简称柚子科技公司）、柚子（北京）移动技术有限公司（简称柚子移动公司）与数字天堂（北京）网络技术有限公司（简称数字天堂公司）纠纷一案为例，在二审当中，柚子科技公司、柚子移动公司辩称，一审判决中法院对数字天堂公司涉案软件的名称、数量和同一性代码文件的数量认定等方面存在事实认定错误，数字天堂公司开发的Hbuilder软件整体上应受到GPL协议约束，Hbuilder软件三个涉案插件中包含大量开源或第三方代码，因此应依照GPL协议的规定承担开源义务，因此其开发的软件APICloud并不构成侵权。

法院在裁判当中对被认为抄袭的三个插件是否适用GPL协议限制进行了判断，根据三个涉案插件分别处于三个独立文件夹，三个文件夹中均不具有GPL协议文件，涉案插件所属软件的根目录下亦不存在GPL开源协议文件这一事实，认定该软件其他文件夹中的GPL开源许可效力不能及于此三个插件，三个插件不受GPL协议限制，因而不能被认定为开源软件，从而认定侵权。

可以看到，这一裁判思路并未对涉案软件是否能视为独立作品汇编而非为开源软件延伸进行实质判断，也并未从法律角度认证或判断涉案软件与主体结构软件构成之间的结构关系，而仅通过插件所定义的外在形式解决传染性的问题，因此，判决在准确认定GPL许可的传染性这一问题上仍有一定的讨论空间。

在不乱买电子商务（北京）有限公司（以下简称不乱买公司）与北京闪亮时尚信息技术有限公司（以下简称闪亮时尚公司）计算机著作权纠纷一案中，闪亮时尚公司上诉称，原审法院对GPL开源协议内容认定存在错误。原审法院认为前端文件与后端文件由于展现方式不同、所用技术不同、分工亦有明确区别，应属于独立程序。但不乱买公司所使用的遵循GPLv2协议的前端代码文件前端代码文件不能独立工作，必须和后端PHP软件进行配合。因此，不乱买公司的前端文件和后端文件共同构成了其主张著作权的软件。而GPL协议明确规定只要软件在整体上或者某个部分使用了来源于遵循GPL代码的文件，整个软件源码就必须无偿向所有第三方提供公开整套软件的源代码，因此不乱买公司的整体软件必须遵循GPL协议，向任何第三方无偿进行开源。同时，原审法院认为后端代码并非前端程序的衍生品及修订版本，因此GPL协议对权利代码无约束力的事实认定和逻辑存在错误。不乱买公司所使用的GPLv2的代码文件与后端文件没有做任何有效隔离，因此根据GPL协议的相关内容以及极强的传染性特性，包括前端文件和后端文件在内的整个软件实质上都可以视为其GPL协议前端程序的修订版本。不乱买公司则辩称原审法院认定无误。

针对争议焦点之开源使用的前端代码与后端代码是否有效隔离，使得GPL传染性无法及于后端代码而否定开源的问题，最高法院通过“前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同”，认为前端代码与后端代码是相互独立的，且由于不乱买公司仅主张其对后端代码的权利，后端代码属于独立于前端代码的其他程序，因此判决不乱买公司主张的后端代码不受GPL许可的约束，无需强制其进行开源。

在本案当中，最高法院没有限于从合同角度对开源许可进行，而是对程序和代码的应用边界进行了事实的判断和认定，明确从展示方式、所用技术、功能分工三个标准区分前后端代码的独立性。最高法院的上述认定结果，体现出来审判思路和分析可能突破开源许可约定规则，从事实认定的角度进一步阐述开源许可应用的边界，这对于目前尚处于起步阶段的开源许可司法实践增加了相当程度的不确定性，需要在梳理和总结实践判例中不断地归纳司法机关的判断标准，从而进一步总结各许可的实际效果。

回归到本案中，不乱买公司通过对后端代码而非完整软件的权利要求，使得其成功规避了GPL许可的强传染性约束，因而本案对GPL传染性的隔离方式，并非适用GPL的传染性例外规则，而是通过代码自身的性质的不同，来将整体软件区隔为两部分代码，由此阻断GPL的传染性，其实质仍取决于后端代码是否构成对前端代码的借鉴、衍生、修改或重述，这也为解决传染性问题提供了新的思路。

总体而言，目前我国司法实践当中，对GPL传染性例外规则当中的聚合体和衍生作品之间的界定的裁判标准尚需要在个案中加以甄别，法院主要通过对代码的形式或实质性的审查，来判断GPL的效力是否能及于其他代码。

针对GPL传染性例外规则，根据自由软件基金会（Free Software Foundation，简称FSF）官方的GNU操作系统对常见问题的解释，“聚合版”和其他“修改版”的不同在于：“聚合版”包含有多个独立的程序”。“究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个事实命题，也是一个法律命题，最终会由法官来决定。我们相信合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）。如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。反过来，pipes、sockets和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。”[10]可见，对GPL聚合体的判断，同样仰赖司法实践对代码的实质审查，同目前我国的判断模式略有不同的是，通过独立性审查判断为一个聚合体，则整个聚合体都不必受到GPL传染性的影响；而目前我国实务中的判断模式，则对代码进行逐个审核和区隔，尚未构筑对整个聚合体隔离GPL的裁判理路。

在互联网程序著作权纠纷日益丰富的今天，面对GPL的传染性问题，依然需要司法实践不断探索，不断创新，对目前面对的新情况作出回应。

针对使用开源代码的合规问题，如何隔绝如GPL一类反版权许可的强传染性，从而成功实现对具有强传染性的开源代码的商业性利用，对于基于强传染性开源代码开发的商业软件风险控制而言非常重要。

以谷歌解决安卓作为开源平台传染性问题的方案为例：众所周知，安卓中包含了Linux内核，而Linux这一操作系统本身采用的许可证是GPL；然而，谷歌在发布安卓时采用的是传染性弱的宽松自由软件许可协议Apache-2.0。两者看似颇有抵牾之处，但实际上，安卓仅仅采用的是Linux内核而非Linux的整个操作系统，这一内核仍然采用GPL2.0作为许可证，但其在安卓中是一个独立的操作程序。利用GPL2.0的规则例外，如一些调用目录例外，建立GPL和非GPL许可的分界，隔绝Linux内核的GPL许可。通过将这一内核独立，谷歌成功打造了隔绝GPL传染性的生态系统，绕开了GPL的强制开源要求。[11]

利用GPL一类许可中的强传染性规则例外，将使用GPL的开源软件独立出来，是解决开源代码使用合规问题的一个重要的技术方向。而通过上文对我国司法实践的探讨，针对国内对GPL传染性的裁判思路，结合GPL的传染性例外规则，开发者在使用以GPL作为许可的开源代码时，应当注意自编代码同该开源代码的区隔，以及底层代码逻辑是否真实地并未基于该部分具有强传染性的开源代码作为修订的出发点，以绕开GPL传染性的约束。

对于原创性的开源项目，开发者和社区在选择开源许可时需要根据未来主要用户的类型、使用场景等考虑使用具体许可的传染性，尽量减少未来可能产生的争议。而对于基于开源项目或代码而进行的商业性开发，首先需要根据不同开源项目和代码的既有许可情况判断其传染性，从而进一步判断在原有框架下继续开发使用的合规风险。其次，如果因商业化需要等需要改变原有的许可，则需要充分的考虑原有许可框架的空间，以及具体的操作实施路径的可能性，尤其与司法实践相互印证。本团队也将持续跟进开源项目的司法实践，继续为各类开源从业人员提供具体的判断标准和操作建议。