开源协议软件代码传染性的认识与防治——以GPL协议为例

作者：蒋一凡 白南丁 | 2021.11.12

一、会传染的代码

在笔者服务的软件科技企业中，会大量使用GPL、LGPL、BSD、MIT、Apache等开源协议。所谓开源协议，其实本质上还是软件的原作者和用户之间签署的“合同”。原作者通过默示约定的方式和用户定下了契约，原作者们放弃掉一些法定意义上的权利，来换取他们心目中代码的自由更迭和商业上更美好的世界。况且这些“原作者”还都是些大厂，出的免费工具和代码包都很好用。

程序员们当然喜欢这种不要授权费又可以随便修改的免费代码包了，但天下哪里有免费的午餐，在各种各样的许可协议中，往往埋伏了相当多的限制与麻烦，代码传染就是其中之一。

如果处理不当，其可怕性简直与乐高宣布“基本款积木免费拿，但是搭建出来的任何造型和设计大家也都可以免费拿哦！”相当。

二、开源代码极简史——以GPL为例

1989年，美国自由软件运动的倡导人理查德·马修·斯托曼（Richard Mattew Stallman，RMS) 与一群律师起草了世界上第一个开源软件协议[1]——GNU通用公共协议证书 (GNU General Public License, GNU GPL)。证书序言传达出如下“Copyleft”（著佐权）的思想：一是承认软件的著作权；二是提供许可协议，来获得复制、发布、修改的法律许可。用户可以获得权利人通过许可证放弃的权利，但也必须遵守许可证的规定才能行使，如果不遵守开源软件规定，便是侵犯了开源软件著作权，著作权人有权要求对方停止相关行为。[2]这一份“古早”协议试图在作者著作权与开发者修改发布权中寻求平衡，也成为了当下开源许可协议的思想奠基。

三、GPL——会“传染”的开源许可证

1989年，GPLv1版本发布，明确约定了传染性条款：“作品的发行/分发方应当保证将本程序或其任何部分的全部或部分内容（包含已修改）免费授权。”[3]这意味着，一旦某企业开发的软件代码中使用了GPL代码，在未做任何技术处理的情况下，这个软件整体也要免费向社会开放了。

两年后（1991年）发布的GPLv2版本作出修订：“任何发行或者发布的作品，如果派生于开源软件或包含开源软件的全部或部分，则在允许第三方在遵守本协议的情况下，该发行/分发方应将作品免费、整体授权。[4]”更重要的是，GPLv2还进一步明确了开源软件派生作品中独立部分的“传染性”认定：“前述要求（开源“传染性”）适用于派生作品整体。但若这一派生作品中存在可区分部分，而非全部派生自开源软件，并且可以被合理视为独立作品，这一独立部分在被单独发布时能够不受本协议的限制。[5]”

2007年发布的GPLv3一改上一版本中对开源软件派生作品中独立部分不具“传染性”的认定，而是扩大了“传染性”的认定范围，规定“依据开源作品修改的开源软件（无论是否包含独立部分）视作不可分割的完整作品，在传输、分发这样的作品时，无论其中开源部分与独立部分是分开发布还是统一发布，这一发布后的作品整体均应遵守开源协议。”[6]

历经多年迁移，GPL协议规定的传染途径仅发生了字义的转变：由分发(distribute)转为传输、传播(convey)，但传染标准始终在动态变化：由严格的“分发或发布的全部作品”(GPLv1)至“派生作品中独立部分”的取消(GPLv2)，兜转回至严格标准(GPLv3)，认为无论开源部分与独立部分如何组合或如何发布，均应整体适用开源协议，对软件科技企业而言，这样的变化无疑是不稳定且趋向严格的，那么针对“传染性”，开源软件是否存在始终保有排除与豁免态度的免责空间呢？

事实上，无论在目前我们能够看到的哪一版本GPL协议中，都包含了对“聚合体”的豁免条款[7]，以GPLv3为例，其规定了“聚合体是指开源程序和其他独立程序的特殊组合，在这一组合方式既非该开源程序的扩展、也非为在某个媒介上与开源程序结合，而是仅为生成规模更大的程序，并且这一组合对使用者的访问限制不超过独立作品对使用者的访问限制。”能够看出，聚合体似为将前述开源软件的“独立部分”与开源软件进行的结合，而对这一结合，GPL认为属于代码“传染性”未触及的区域。以软件的迭代更新为纵向量、以对软件的使用（形成包含关系）为横向量，GPL的传染是以二维形式延展铺开的。聚合作为特殊形式的“横向传输”，GPL一直对其保持着统一的豁免态度，并在修订过程中逐渐明确了聚合概念及与普通组合形式的区分。

图1 GPL各协议内容对比

四、司法案例中划定的代码传染性边界

1. GPL中代码传染性条款是否有效？

有关GPL的诉讼最早出现在判决书中的时间是2017年7月5日，在“天津市某科技有限责任公司、天津市某科技股份有限公司等与温岭市某复工业有限公司等侵害计算机软件著作权纠纷”中，被告认为原告主张被告侵权的ShopNC软件系由开源软件PHP+MYSQL编写，PHP软件使用基于GPL开源协议的PHPCCPL开源协议，MYSQL使用标准GPL开源协议，以“无论是根据哪一项开源协议的规定，使用PHP和MYSQL软件编写的ShopNC软件，作者均不能禁止其他方改编、使用、复制、发表该软件，也不得向其他方收取软件使用费”为由作出抗辩。然而面对这片中国法律还未正式耕耘的荒土，该法院未对开源协议性质、效力及使用开源代码后果进行直接论述。认为经合法登记著作权的主体应作为著作权人，在证据不充足的情形下，应保护相关著作权。

其后不久的2018年4月12日，被称为“中国GPL诉讼第一案”的“某（北京）网络技术有限公司诉某（北京）科技有限公司、某（北京）移动技术有限公司侵犯计算机软件著作权纠纷”一审判决中，法院虽仍未直接明确GPL许可证的法律效力，但以默认GPL许可证的法律效力为前提，对涉案软件HBuilder中实际被使用的三插件是否受GPL许可证限制进行了论述。由此，我国出现的为数不多的GPL相关案例，均以认可协议效力为前提，对相关条款进行说明，从一定程度上回应了开源许可协议在司法实践中的法律效力认定难题。

2. 代码传染性无法鞭及的区域

如前所述，GPLv3.0存在明确约定的“聚合体”例外情形，在所谓的“中国GPL诉讼第一案”中，一审法院认为涉案软件HBuilder中实际被使用的三插件：（1）分别存放在三个独立的文件夹中，（2）三个独立文件夹中无GPL许可证，且（3）HBuilder软件根目录下不存在GPL开源协议文件。据此，涉案三个插件属于GPL的例外情形，不受GPL许可证限制。诚然，法院对以文件夹作为独立性区分依据的观点是否合理仍待商榷，但上述司法观点已经体现出我国对开源协议的接受与引用。

2019年12月，针对“北京某时尚信息技术有限公司、某电子商务（北京）有限公司侵害计算机软件著作权纠纷”，二审法院进一步明确传染性边界：GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。虽然软件前端代码中使用了GPL协议下的开源代码，但权利人主张保护其后端代码的，因后端代码是独立于前端代码的程序，并不受GPL协议的约束，无需强制开源。对于如何综合判断涉案程序属于“衍生（修改）”还是“聚合（独立）”，最高人民法院再次提供了总体思路。

发布GPL修订版的自由软件基金会曾就“GNU许可证常见问题”对“聚合”和“修改”的区别作出解答：“聚合版包含有多个独立的程序，并在同一个CD-ROM或其他媒体上发行。合理的标准既依赖于通信的机制（exec, pipes, rpc, 共享地址空间的函数调用等等），也依赖于通信的语义（交换了什么样的信息）。这是一个法律命题，最终会由法官来决定。”[8]而当真的置身于司法实践，上述判决尽管已经正式回应对开源代码传染性的构成作出分析，但显然无法对实务作出有效回应——简单的文件夹或前后端代码的隔离对处理各情形下的代码交互而言杯水车薪。事实上，自由软件基金会的回复也并未在技术上将“聚合”与“修改”的界限完全厘清，代码之间是否存在实质上的通信、交互甚至依赖，仍停留在以个案为单位的分析。

3.受代码传染后，违反开源协议的行为如何定性？

复习一下，文首曾提到过，GPL认为，用户可以获得权利人通过许可证放弃的权利，但也必须遵守许可证的规定才能行使，如果不遵守开源软件规定，便是侵犯了开源软件著作权，其著作权人就有权要求对方停止相关行为及其他。此时的难题是，若代码已受感染，应遵守开源协议的开发者若对代码进行闭源，意味着其将同时面临侵犯著作权与合同违约的两项考验。

早在2008年，美国法院在判例中[9]确认条款构成可执行的版权条件，从而在违反该许可证的条款时构成版权侵权。权利人可据此行使更优于权利救济的权利：例如诉前禁令、惩罚性赔偿等。近十年后，2017年，美国法院一改过往的裁判思路[10]，认为开源协议已包含合同成立的各个要素（要约、受要约及相关对价），由此认可了开源协议的合同性质，即主张违约责任有可能获得支持。

视线收回于我国，在2021年4月30日刚刚作出的《济宁市某网络科技有限公司诉被告福建某科技有限公司、被告北京某科技有限公司、被告深圳市某计算机系统有限公司侵害计算机软件著作权纠纷（下称济宁网络科技案）一审民事判决书》中，法院则支持了构成侵权的说法，认为GPL若因违反开源协议终止授权，符合民事行为的附条件解除规定，进而明确了违反开源软件许可证的侵权法律责任（法院同时认定构成违约，但原告诉请中主张的是侵权责任，故而认定侵权）。

对此，笔者认为，该一审判决存在商榷/改判空间。首先，若各法院在判决同类型案件时沿用这一判决思路，则对处于竞争中的互联网企业而言，一旦察觉对手企业可能存在违反开源协议的行为即提起相关诉讼，对手企业亦同，几个回合后，不但可能影响公司的正常运行（企业信用、股价稳定性等影响），若这一情形蔚然成风，更可能引发广大互联网企业人人自危；其次，假设违反开源协议的行为构成侵权行为，侵权损失该如何计算呢？——开源意味着共享，也即开源软件的权利人已经选择不对此收取回报，所谓的“侵权”行为也就并没有造成实质侵害，以此为基础上的侵权判赔计算更是空中楼阁。一审法院认为在计算赔偿时需要综合考虑侵权软件的平台下载量、对外授权许可收费标准（却同在判决书中认为济宁某网络科技公司无权在GPL协议中加入商业使用限制保留条款）及原告维权的合理费用等，而这一标准能否作为侵权判赔计算标准，尚待司法实务中出现的更多判决支撑。

五、相关结论

尽管在济宁网络科技案中，深圳中院认为：明确违反开源软件许可证的侵权法律责任，一方面可以及时制止侵权行为，防止他人对开源软件的不正当利用；另一方面能够有效保护授权人的利益，使他们保有继续创作的动力，促进源代码共享和知识的传播。但一方面，在目前的互联网市场中，推崇开源主义的仍以海外人士居多，对开源及传染性的高度认可不利于对本土创新型企业的保护，另一方面，开源协议自身也难对纷繁复杂的互联网软件产品属于开源代码的“衍生（修改）”还是“聚合（独立）”之问作出有力答复。更进一步，对违反开源协议行为的责任承担亦尚存探讨空间，相关的损失计算也难以明确，上述的一道道围墙都可能成为开源代码传染过程中的桎梏。因此，对代码传染性的传播力认可及相关违约责任的主张在我国司法中仍旧“道阻且长”。

六、笔者建议

1、由于GPL代码传染认定的行为标准是“分发”或“传输”，对使用开源代码的企业而言，亦应对相关代码的使用限度作出调整，通过以“网络服务分发(SaaS)”的模式替代电子邮件、U盘、网页链接、私有化部署等分发/传播方式，在源头切断代码传染的萌芽。

图2 代码的自用与分发[11]

2、学习Android的运行模式，将开源的服务运用到自己进行的开源服务封装，最后输出封闭的代码产品。确保输出作品中不包含开源软件任何有意义的部分（例如A开源部分是一个程序编辑器，B封闭代码部分是使用A编写完成的程序，即使B简单的调用和触发A，也不影响B的封闭性）。

图3 目前尚还难遭传染的代码运行模式

本文仅供参考，不构成具体的法律建议。