摘要：使用人一旦将GPL程序与其自己开发的代码合并并分发了软件，如果没有采取技术隔离措施，使用人开发的那部分代码连同GPL程序一起就要以GPL许可证进行许可，遵守GPL许可证规定的义务。对“传染性”是什么却有不同的理解。
OSCHINA
作者 | 李维朝，江苏瑞途律师事务所合伙人
引言
GPL许可证（General Public License）是应用最广泛的开源许可证，作为互惠型许可证，以其强“传染性”而著称。
软件著作权人以GPL许可证分发软件，该软件就以GPL许可证对任何人进行许可，成为我们常说的GPL程序。
使用人一旦将GPL程序与其自己开发的代码合并并分发了软件，如果没有采取技术隔离措施，使用人开发的那部分代码连同GPL程序一起就要以GPL许可证进行许可，遵守GPL许可证规定的义务。对“传染性”是什么却有不同的理解。
一、什么是“传染性”
GPL V2第2条：你发布或出版的软件作品（包括程序的全部或一部分，也包括由程序的全部或部分演绎而成的作品）整体上必须受本许可协议条款的约束，并允许第三方免费使用。这些要求适用于修改后作品的整体。
GPL V3第5条：你必须在本许可证下将整个作品作为一个整体，授权给持有副本的任何人。因此本许可证与根据第7条而附加的任何条款一起，将适用于整个作品及其所有部分，无论它们是如何打包的。本许可证不允许以任何其他方式许可该作品，但不会使您单独收到的许可无效。
“传染性”规定见于GPL V2第2条和GPL V3第5条，核心意思是如果你分发的软件（称为目标软件）包括你自己开发的程序以及GPL程序，你自己开发的程序与GPL程序作为整体成为GPL程序的演绎作品，目标软件整体上受到GPL许可证的约束，应当以GPL许可证进行许可。
当然，GPL许可证也给了例外豁免，即，如果你自己开发的程序与GPL程序在技术上采取了隔离措施，使得你自己开发的程序与GPL程序不再成为一个整体软件，而是相互独立的两个软件，那么，你自己开发的程序与GPL程序就不会作为整体认定为GPL程序的演绎作品，就不会受到GPL许可证的约束。
二、对“传染性”的误解
“传染性”这个词非常容易让人理解GPL许可证的强著佐权特点，但同时也非常容易让人误解，以为GPL程序就像病毒一样“传染”，就像病毒在人与人之间的传播，一个感染病毒的人将病毒传染给另一个人或者一群人，使得人类整体感染病毒。
对软件略有了解的人都知道，一个软件由若干个代码文件组成，代码文件之间存在各种软件技术上的关联，例如链接（link）。
有人就提出如果目标软件中包括受GPL许可证约束的A文件，就要考虑A文件与其他文件之间的关系，如果A文件与F文件不存在关联，那么A文件不会“传染”F文件；A文件与B文件、D文件、H文件存在关联，所以A文件把B文件、D文件、H文件“传染”成GPL程序，再由B文件、D文件、H文件“传染”目标软件的其他文件，直至把各个文件都“传染”。
图1-这样理解对吗
这种理解显然是错误的。GPL许可证并不关心目标软件中的各个文件本身的许可证，而是关心目标软件整体的许可证，只对整体许可证产生影响。
三、“传染性”的本质
正如我们谈论GPL等开源协议时常用的一个词“许可证”，GPL最关心的是目标软件应该怎样对使用人进行许可，以GPL进行许可，还是其他。
仍以图1为例，你自己开发的代码包括文件B-I，各文件之间不存在技术隔离措施，当你自己开发的代码链接文件A，而文件A适用GPL许可证，并且你自己开发的代码与文件A不存在技术隔离措施，那么，你自己开发的代码与文件A构成一个整体，该整体软件受GPL许可证的约束。
至于你自己开发的代码要以什么许可证单独对外许可，采用GPL以外的其他开源许可证，还是商业许可证，这对结果没有影响，GPL许可证只约束目标软件这一整体软件。
如果你在分发目标软件之后，又想对外进行商业许可，那么你完全可以重写文件A，形成与文件A相同功能的文件J，再将文件B-I与文件J链接起来形成一个新的整体软件，并以商业许可的方式对外发布。
也就是说，你自己开发的代码与受GPL许可证约束的文件A合并之后，文件A并不会把GPL“传染”给你自己开发的代码。
我们再把这一讨论设置得更复杂一些。我们都知道，今天的软件已经几乎没有完全是自己的开发的了，或多或少都会引用他人开发的代码，大多数是以编译好的文件库的形式使用。
如图2所示，在你发布的软件中，你只开发了F，A-E都来自他人，它们的许可证各不相同，甚至有来自公有领域而没有著作权的D，那么你发布的软件该怎么许可呢？
GPL的“传染性”要求我们应当以GPL许可证对外许可。当A、C-F与B之间不存在技术隔离措施，那么A-F就构成一个整体软件，受到GPL许可证的约束。
同时，Apache、MIT、BSD许可证的条款与GPL许可证条款没有冲突，GPL许可证对著作权人和使用人的限制是最多的，GPL许可证与Apache、MIT、BSD许可证相兼容，那么最终这个软件就应当以GPL许可证进行许可了。
从这个意义上讲，受GPL许可证约束的B“传染”了最终发布的软件整体。
图2-软件开发现状
当然，如果你不想以GPL许可证对外进行许可，那么你应当把B移出去，在B与剩余部分之间采取技术隔离措施，避免B与剩余部分牵连成为一个整体，这样你就可以以你想要的方式对外许可了，Apache、MIT、BSD许可证对使用人都非常宽松。
图3-技术隔离
四、开源实践之更换许可证
经过上述讲解，我们明白了GPL“传染性”的本质，它不会把你自己开发的代码“传染”成GPL，更不可能把你引用的他人开发的代码“传染”成GPL，它只会影响最终对外发布的软件整体。
正是因为“传染性”的本质，在开源实践中，软件版本迭代时更换许可证也不鲜见，例如Cygwin库从2.5.2版开始，采用LGPL许可证取代GPL许可证，LGPL许可证比GPL许可证宽松，允许在动态链接Cygwin库时保持其他部分代码闭源。
需要指出的是，更换许可证不影响在此之前已经发布的版本，这些版本仍然保持原来的许可方式不变。
相反地，也有难以更换许可证的情况。以Linux内核为例，Linux内核采用GPL v2许可证，从技术和法律角度来看，Linux内核想要更换许可证实属不易。Linux内核包括很多GPL组件，还包括很多他人贡献的代码，只有在移除GPL组件并取得其他贡献者的同意之后，才有可能更换许可证。
在（2019）粤73知民初207号案件中，法院认为根据GPLV3协议条款约定和性质，只要某个软件版本加入GPLV3协议，则无法随意删除GPLV3协议，该版本源代码将永久保持开源，即使授权方删除GPLV3协议也无回溯力，授权方只能在后续的版本中变更或删除GPLV3协议，但并不影响此前版本继续适用GPLV3协议的效力。
本案中，罗盒公司确认其主张的涉案软件2017年12月30日版本与撤回GPLV3协议即2017年10月29日前的版本差别不大，因此本院认定罗盒公司主张权利的版本仍属于适用GPLV3协议的开源软件。
即，法院认为罗盒公司2017年12月30日版本不能更换许可协议的原因在于，该版本与之前以GPL许可证发布的版本实质相同。
很显然法院的逻辑是错误的，真正的原因是，2017年12月30日版本合并有他人贡献的代码，而他人是基于GPL许可证来贡献代码的，在没有取得贡献者同意的情况下，罗盒公司不能独立更换许可证。
也就是说如果你对全部的代码享有完整的权利，在不同版本中采用不同的许可方式就没有那么多的限制了。
五、总结
GPL“传染性”并不是像病毒那样传染，而仅仅是对最终发布的整体软件的许可证的选择造成影响，本质上是多个许可证之间的兼容性问题，需要从多个许可证里面选择一个能够兼容其他许可证的许可证。
如果各个许可证之间存在冲突，不能兼容，那你就无法从这些许可证中选择了，如果可能的话你需要创设一个新的许可证，从而把这些不兼容的许可证统一起来，如果这也做不到的话，那你就只能把某些代码移除了。
我们要正确理解开源许可证的本质，使用开源软件推动软件产业的发展，为社会大发展提供效率工具。
↓分享、在看与点赞~Orz
来源：寂寞游戏人
