GPL开源协议是否有传染性？国内法院最新认定有突破

作者 | 游云庭  上海大邦律师事务所高级合伙人、知识产权律师

编辑 | 布鲁斯

最近开源软件出了个大新闻[i]，无锡中院在一起批量维权的案件中支持了被告开源协议传染性的抗辩，认定使用了一个GPL插件的原告软件全部内容都被传染，导致必须开源，虽然该一审判决结果有待二审最高人民法院确认，但这确确实实是GPL开源协议传染性问题在国内的一次突破，今天就和大家聊聊该案，以及之前国内法院怎么认定的。

案情简介

根据判决书[ii]，原告卓卓公司享有织梦商业网站内容管理系统软件（以下称“织梦软件”）的著作权，起诉被告在其网站上未经授权使用了该软件的源代码，被告辩称涉案软件为开源软件，不应收取授权费用。法院审理后认定：涉案软件包含了使用GPL许可证的库，因此整个软件应当遵循GPL协议，软件许可协议中的商业使用限制条款与GPL协议相抵触。故被告有权免费使用涉案软件。

但被告使用涉案软件，却未在网站主页上保留原告署名，违反了GPL协议中关于署名要求，侵犯了原告的署名权，故支持了原告合理维权开支800元。被告还需刊登声明，消除侵权影响。本案是一审判决，效力还有待二审法院审理后确定。

一、一审判决如何认定GPL开源软件的传染性？

开源软件的传染性指的是什么？通俗来说，软件分源代码和目标代码，源代码是可以由人读取的文本文件，目标程序是由机器读取的由0和1组成二进制文件，软件公司通过控制源代码控制软件。如果其他人拿到了源代码，就也能控制软件了。但软件公司如果在软件中使用了具有传染性的开源代码，比如本案中的GPL V3.0版软件的代码，那就必须把软件全部开放源代码。此时，软件公司对软件就失控了，因为大家都可以拿到源代码，并可以根据开源协议，在无需软件公司许可的情况下自由使用。

开源软件的传染性对大公司杀伤力非常大，比如大名鼎鼎的思科就吃过大亏。思科的路由器技术本来比同行先进很多，但因为被其收购的Linksys公司使用了基于GPL开源协议的Linux系统，导致其多款路由器均涉及开源问题。美国自由软件基金会于2008年起诉了思科，后思科不得不开源了一百多款路由器的芯片源代码和产品源代码，此后其在中小型路由器市场的技术优势被削弱不少[iii]。 

本文开始介绍的案件中，法院也认定如果软件包含了GPL许可的代码，那么整个软件在分发时也必须遵循GPL协议。涉案软件至少包含了一个使用GPL许可证的名为Sphinxclient的库，该库与织梦商业网站内容管理系统软件的其他部分形成了连接，因此整个软件应当遵循GPLV3.0协议，该协议规定了“程序的派生作品”必须以GPL协议发布，这意味着其余软件代码均需开源。

对于涉案软件许可条款效力的问题，法院认为，GPL协议允许收取软件拷贝费、技术支持费等，但不允许对软件的使用施加额外的限制，尤其是与授权费用相关的限制，这种收费会实质上改变GPL软件“自由软件”的本质。因此卓卓公司在涉案软件的许可协议中添加的“商业用途需获得授权”的条款与GPL协议相抵触，无权就涉案软件向第三方主张授权费用。

二、本案之前，法院如何认定开源协议传染性？

在本案之前，我国法院其实也认定GPL协议的有效性，但对于GPL代码的传染性认定，比较保守。本案中软件中只有一个库涉及GPL V3.0，却导致软件其他部分都要开源，和之前的案件比，可以说是很大的突破。

 案例一  数字天堂诉柚子移动案

数字天堂公司起诉柚子移动抄袭了其拥有著作权的HBuilder软件的三个插件的源代码。柚子移动抗辩称，HBuilder的代码包含了GPL V3.0代码，根据开源软件传染性，该三个插件均应开源。

一审法院认定：涉案三个插件所处文件夹中并无GPL开源协议文件，而HBuilder软件的根目录下亦不存在GPL开源协议文件，尽管HBuilder软件其他文件夹中包含GPL开源协议文件，但该协议对于涉案三个插件并无拘束力（这里其实直接否认了开源代码的传染性）。据此，涉案三个插件并不属于该协议中所指应被开源的衍生产品或修订版本，柚子移动公司认为数字天堂公司软件为开源软件的相关抗辩理由不能成立。二审法院审理案件时，回避了直接讨论GPL协议的传染性问题，但依然认定柚子移动构成侵权，只是调低了赔偿金额。

 案例二  苏州某公司诉浙江某公司案

该案笔者在《最高院不认可对开源协议的传染性了？》[iv]一文中介绍过：苏州公司起诉浙江公司软件侵权，被诉软件与涉案软件非开源源代码相同率高达90.2%，二者实质相似。浙江公司则基于GPL V2.0协议认为苏州公司软件中有GPL代码，所以软件代码均应开源，提出了不侵权抗辩。

但判决却认定本案不适用开源代码传染性：涉案软件适用GPL V2.0开源协议，苏州公司声称其在底层系统软件与上层功能软件之间建立了隔离层，且二者之间通信内容不涉及内部数据结构信息，由此使得上层功能软件构成GPL V2.0协议项下“独立且分离的”的程序。故涉案软件具有独创性且可以复制，构成著作权法项下的作品，依法应当获得保护。

 案例三  最高人民法院知识产权法庭在指导案例（（2019）最高法知民终663号）。

该案也是一个以开源软件传染性进行抗辩但未遂的案件。最高院却认定软件前后端分离，所以不适用开源代码传染性。该案裁判要旨[v]：“本案中网站前端代码与后端代码在展示方式、所用技术、功能分工等方面均存在明显不同，属于既相互独立又互相联合的独立程序，即便前端代码使用了GPL协议项下的开源代码，后端代码也不受GPL协议约束，未经许可复制后端代码仍构成侵害软件著作权。”

三、本案二审哪怕不认开源软件传染性，原告仍可胜诉吗？

本文讨论的案件，根据判决书，原告其实还有补救措施。法院查到Sphinxclient库的官方发布网站上有记载，该软件为采用 GPLV2.0及以后版本作为许可协议(即GPLV2.0和V3.0)的自由软件，如果对程序进行分发或修改需要在GPL许可的条款下进行。但如果不想被GPL条款约束，比如想用Sphinx，但不想开源的，可以联系作者获得商业许可。

这个让案件二审多了个变数。如果本案二审仍认可开源软件的传染性，但二审期间，卓卓公司联系Sphinxclient作者购买了商业使用的授权。许可时间为从其十多年前开始使用Sphinxclient时就生效，也就是倒签授权时间，那法院会认定被告侵权卓卓公司吗？这里有两种民法理论可以适用：效力待定和交易安全。前者对原告有利，后者对被告有利，笔者偏向后者。

根据效力待定理论，类似未成人与他人交易是否有效，取决于家长的追认：卓卓公司对织梦软件的权利，取决于Sphinxclient作者的授权方式，所以卓卓公司在获得商业授权之前使用Sphinxclient，实际处于效力待定状态。如果其没有获得了Sphinxclient作者的商业授权，就是依据GPL开源协议获得的授权，其软件的其他部分应当开源；如果获得了作者的商业授权，就可以不再适用开源协议的要求，其软件的其他部分就可以不开源。连带的，被告的侵权状态也受原告是否获得商业授权的影响。

而根据交易安全理论，法律应当保障本案被告使用织梦软件时的权利是合法、确定、连续的。既然本案的被告开始使用软件时，卓卓公司未获得Sphinxclient库的授权，所以其使用的软件就应当是开源的，其使用行为是合法且不构成侵权应当是确定的，即便后期原告拿到了Sphinxclient库的商业授权，也不应当危害到被告初始使用织梦软件的合法状态。

最后，笔者非常认同本案中无锡中院对本案的判决，我国法院之前不支持开源协议传染性，主要还是出于对于国内企业竞争秩序的保护：基于开源软件做二次开发的企业，如其没有开源，代码却被他人使用，其起诉维权法院若对其不予保护，可能不利于维护竞争秩序。法院的做法，在我国软件产业发展的早期，产业还没那么成熟的时候是可以理解的。

但开源协议其实背后是一种开源文化和生态，如果只使用开源软件的内容，却不尊重开源文化，不维护开源软件的生态，时间久了，对我们自己的产业发展是不利的，随着我国改革开放的深入，我国的软件产业已经趋向成熟，所以现在的判决，除了考虑保护竞争秩序的短期利益，也应当开始考虑通过保护开源规则来建立开源生态这样的长远利益了。

注释

[i] https://new.qq.com/rain/a/20240227A07S8800

[ii] https://report.oschina.net/api/files/jhim80u9qm1ofsw/79ci47r1rrt9yqm/2023_02_482_cEvUNytTpS.pdf

[iii] https://baijiahao.baidu.com/s?id=1702782250274636703

[iv] https://mp.weixin.qq.com/s/cFgJPP1GVDOsnjtGs0OsSg

[v] https://ipc.court.gov.cn/zh-cn/news/view-307.html

（本文仅代表作者观点，不代表知产力立场）

封面来源 | Pexels