全国首例认定GPL开源代码不侵权案？

全国首例认定GPL开源代码不侵权案？

一、案情介绍

1.一审案情简介

原告数字天堂公司起诉被告柚子公司侵犯其计算机软件著作权纠纷一案，由北京知识产权法院于2015年4月13日受理，并于2018年4月12日作出判决[1]。数字天堂公司诉称柚子公司发布的APICloud软件抄袭了数字天堂公司HBuilder软件中的三个插件（代码输入法功能插件、真机运行功能插件、边看边改功能插件，以下简称“涉案三个插件”）的源代码，该举侵犯了数字天堂公司对HBuilder软件享有的复制权、修改权和信息网络传播权，并据此要求法院判令柚子公司在公开网站赔礼道歉，消除影响，并赔偿经济损失及合理费用。柚子公司辩称HBuilder软件属于应遵循GPL协议开放源代码的软件。对于GPL协议的开源软件，任何第三方有权不经另行取得著作权人的许可，直接遵循GPL协议使用源代码，构建衍生软件作品，而不构成对著作权的侵犯。北京知识产权法院认定：

数字天堂公司的HBuilder软件属于《中华人民共和国著作权法》下的计算机软件作品，数字天堂公司是该软件作品的著作权人。

数字天堂公司是HBuilder软件中涉案三个插件的著作权人。

根据工业和信息化部软件于集成电路促进中心知识产权司法鉴定所（以下称“鉴定机构”）对APICloud软件与HBuilder软件同一性鉴定出具的鉴定意见[2]，柚子公司APICloud软件中对应插件源代码部分与数字天堂公司的涉案三个插件构成同一性。

根据鉴定机构对数字天堂公司涉案三个插件的源代码与在先第三方及开源软件源代码同一性鉴定出具的鉴定意见[3]，涉案三个插件的源代码仅有一小部分与第三方或开源软件的源代码相同。

涉案三个插件处于独立的文件夹中，且文件夹中均未包含GPL协议。

HBuilder软件的根目录也不存在GPL软件协议。

尽管HBuilder软件中包含的其他文件夹中含有GPL协议，但GPL协议对涉案三个插件并无约束力。

涉案三个插件不属于应根据GPL协议开放源代码的衍生软件作品。

柚子公司认为数字天堂公司涉案三个插件属于开源软件的抗辩理由不成立，其被诉行为构成侵犯数字天堂公司享有的著作权。

2.二审案情简介

柚子公司不服北京知识产权法院的判决，向北京市高级人民法院提起上诉。北京市高级人民法院于2018年7月20日受理本案，并于2019年11月6日作出终审判决。[4]上诉人柚子公司诉称数字天堂公司的HBuilder软件（包括涉案三个插件）应整体受到GPL协议的约束，必须依据GPL协议的规定承担开放源代码的义务，并针对三个插件的独立性认定问题再次提出司法鉴定申请。[5]二审法院以柚子公司在一审程序中怠于行使举证责任，在二审诉讼中再次提出第三次鉴定申请有违司法程序公正和司法程序效率，且司法鉴定申请内容与本案待证事实之间并无直接关联性为由，驳回了司法鉴定申请。同时，二审法院承继了一审法院对于涉案三个插件不应受到GPL协议约束的论述，仍然维持柚子公司的行为构成侵犯数字天堂公司著作权的判定，仅对一审法院侵权代码的数量、侵权行为个数和赔偿金额的认定做出修正。

二、法律分析

1.本案法院判决的积极意义

本案作为中国第一个涉及GPL协议的诉讼案件，对开源软件协议在中国司法程序中的效力认定具有积极意义。开源软件起源于二十世纪八十年代从美国兴起的自由软件和开放源代码运动，是对当时大行其道的商用软件传统模式的反叛，旨在打破商业软件的垄断，加强技术的自由交流与合作。

尽管开源软件推崇开放、自由和共享的理念，使用开源软件也通常无需支付费用或另行获取著作权人的许可，但并不意味着使用开源软件无需承担任何责任。开源软件基于著作权法下“版权许可”的方式，通过附随的许可协议约定使用该等软件应遵循的条款条件。遵循开源软件许可协议使用该开源软件，即已遵守著作权利人的版权许可，不侵犯著作权。也就是说，一旦使用开源软件，即视为已同意接受该开源软件附随的许可协议，遵守其中规定的条件或限制。反之，如果不遵守开源软件许可协议，则构成对开源软件著作权的侵犯。

由于开源软件的概念和绝大部分的开源协议都来源于国外，部分人士对于英文的开源软件许可协议在中国的法律效力问题始终存在疑虑。本案一审法院虽然没有明确论述GPL协议的法律效力，但其大篇幅引用GPL v3.0协议的原文，并论述GPL协议对涉案三个插件是否具有约束力，相当于已经默认GPL协议在中国同样具有法律约束力，二审法院也同样接受了一审法院有关GPL协议是否对涉案三个插件具有约束力的论述。本案法院默认了GPL协议的法律约束力，从一定程度上消除了未来有关开源软件许可协议在中国诉讼中法律效力认定的不确定性。

2.本案法院对GPL协议的解读存在争议

本案法院虽然认可了GPL协议的法律效力，但未深入探讨或阐述对GPL协议“传染性”的理解，对涉案三个插件是否构成独立作品，是否应受到GPL协议约束的判断规则也存在争议。

究竟为什么本案法院对于涉案三个插件是否受GPL协议约束的判断引发国外知识产权律师的质疑？[6]我们需要回到本案法院引述的GPL v3.0协议原文进行分析，下面摘录了部分协议原文做展示：

根据GPL v3.0协议的要求，一旦使用以GPL v3.0协议许可的开源软件，被许可人在传播GPL开源软件或其修订版本时，都应当遵守GPL协议的要求开放源代码，并同样使用GPL v3.0协议对外提供许可，允许其他人根据GPL v3.0协议条款使用GPL开源软件或其修订版本，这就是在开源业界经常提到的GPL协议的“传染性“。但是，GPL v3.0协议也明确规定了一个例外情形。即对于与GPL开源软件聚合（Aggregate）在一起的独立的程序，如果其本质不属于GPL开源软件的衍生，也不是与GPL开源软件结合成一个更大的程序，那么GPL协议并不会“传染”此类独立的程序，GPL协议条款对其不具有约束力。

GPL协议允许被许可人制作并发布一个聚合版，即使其中包含非开源软件或与GPL协议不兼容的其他开源协议也可以，只要被许可人制作的聚合版许可协议不禁止用户行使每个独立程序许可协议允许的权利。

由此可见，本案柚子公司提出的涉案三个插件属于应遵守GPL协议开放源代码的程序是否成立，应取决于涉案三个插件是属于独立的程序，还是属于GPL开源软件的衍生作品。根据Free Software Foundation（GPL协议的作者）对“聚合版”和“修改版”的对比分析[8]：“‘聚合版’包含有多个独立的程序，并在同一个CD-ROM或其他媒体上发行。究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个法律命题，最终会由法官来决定。

我们相信合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）。如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。反过来，管道（pipes）、套接（sockets）和命令行参数通常都是两个不同程序通信的机制。

因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。也就是说，判断一个程序是需要遵守GPL协议的衍生作品，还是不需要遵守GPL协议的独立程序，应该基于对程序之间通信关系、依赖关系、调用关系的深入分析。

而本案一审法院仅以“处于独立的文件夹”和“文件夹中没有GPL开源协议”认定涉案三个插件属于独立的程序，不受GPL协议的约束的判断过于简单粗暴，不符合开源社区和其他国家司法实践中的主流思路和方案，难免引起外界争议。尤其是“文件夹中是否包含GPL协议”不应当成为认定该程序是否受到GPL协议约束的因素。

因为从逻辑上来讲，一个程序需要遵循GPL协议时，附随GPL协议对外分发是一个必须履行的义务，没有按照要求将GPL协议包含在程序中对外分发则构成对GPL协议的违反，进而构成对原著作权人的权利侵犯。如果文件夹中不包含GPL协议是认定不受GPL协议约束的因素之一，那是不是被许可人在再次分发GPL软件时都会选择不要随附GPL协议，以此规避GPL协议对某个程序的“传染性”？

此外，本案二审法院在其认定侵权行为个数时提到“数字天堂公司现有证据不足以正面涉案三个插件可以独立于HBuilder开发工具软件中的其他程序独立运行”，既然涉案三个插件不可独立于其他程序独立运行，是否更应该深入分析其与其他程序之间的关系，并进而分析涉案三个插件是否应当受到GPL协议的约束？正由于涉案三个插件的独立与否是柚子公司在本案唯一的突破口，柚子公司才在二审伊始即对涉案插件的独立性提出第三次司法鉴定。遗憾的是，二审法院基于程序正义的原因驳回了柚子公司的鉴定申请，其对涉案三个插件不具独立性的认定与涉案三个插件不应受到GPL协议约束的原因分析也似乎存在矛盾。

三、相关开源软件应如何风控？

商业软件公司使用开源软件时如何开展风险防控？本案有以下启示：

1.如何规避GPL协议的“传染性”

在众多开源软件许可协议中，GPL协议无疑是最负盛名的一种，从第一版到第三版，协议条款随开源理念的发展在不断更新演进，还发展出“传染性”相对较弱的LGPL协议（GNU Lesser General Public License），和“传染性”更强的AGPL协议（GNU Affero General Public License）。

这些GPL家族的开源协议是开源软件中应用最为广泛的许可协议。相比于MIT、BSD、Apache等宽松开放的开源软件许可协议，GPL协议的宗旨在于保障每个人对GPL开源软件拥有同等的复制、修改和创建衍生作品的自由。因此使用、修改GPL开源软件或创建其衍生作品均需根据GPL协议条款，对外开放整个程序的源代码。

随着开源软件的盛行，越来越多的商业产品也有需要用到GPL开源软件，但是又对GPL协议的“传染性”闻者色变，担心其“传染性”导致整个商业软件产品被迫要求开放源代码，造成商业利益的损失。那么如何能在商业产品中使用GPL开源软件，并避免GPL协议的传染性？

首先，GPL协议的触发点是“分发distribute（GPL v2.0协议）”或“输送convey（GPL v3.0协议）”[9]。也就是说，被许可人使用GPL开源软件，但不对外分发或输送GPL开源软件或其衍生作品的副本，则不需要受到GPL协议的约束。使用电子邮件、U盘、网页链接、私有化部署等方式提供给用户下载或安装GPL开源软件都视为构成分发或输送，但是通过“软件即服务（SaaS）”的模式，即在后端服务器部署GPL开源软件，而用户无需进行任何安装，直接通过网络远程接入服务的方式即可避免GPL协议的“传染性”，这也是当下迅猛发展的公有云服务厂商经常采用的一个规避措施。

其次，根据本文之前的分析，GPL协议明确规定了一个例外情形，即GPL协议并不会“传染”仅仅与GPL开源软件聚合在一起，本质不属于GPL开源软件的衍生，也不是与GPL开源软件结合成一个更大的程序的独立程序。Free Software Foundation对“聚合版”和“修改版”的对比解释说明进一步提供了规避GPL协议“传染性”的解决方案，即不要将GPL开源软件和商业软件产品存放于共享地址空间，而通过管道（pipes）、套接（sockets）和命令行参数等方式达成独立程序之间的通信或调用，以此实现商业软件产品与GPL开源软件的隔离，避免商业软件产品被GPL协议传染，被迫开放源代码。

值得注意的是，动态链接的方式能否规避GPL协议的“传染性”仍然存在争议。Free Software Foundation认为不可以，把GPL开源软件与其他作品动态链接就是基于GPL开源软件合成了一个作品，而这个“组合”就是GPL开源软件的衍生品[10]。Free Software Foundation这一观点与目前主流商业软件公司的观点存在冲突，也还从未在法庭上进行过验证。

2.中国法院是否倾向于保护对GPL协议的违反行为？

署名为You Yunting的作者曾在Bridge IP Law Commentary网站发表一篇题为《为什么中国法院保护违反GPL许可协议的行为？》的文章[11]，试图分析为什么中国法院的判决倾向于保护违反GPL协议的行为。

其中提到一个现实的原因是绝大部分开源软件都是由国外开发者贡献，国内企业鲜少参与，因此即使对开源软件权利的保护不足也不会对国内企业产生很大的影响。同时，中国法院采取的立场是更多地鼓励创新，即便违反了开源软件许可协议，但在开源软件基础上产生的衍生作品也属于一种创新，需要得到保护。

姑且不论这篇文章的观点是否正确，从数字天堂公司诉柚子公司的GPL中国第一案可以看到中国法院对于GPL协议条款的解读确实暂未达到专业和精准的程度，那是不是意味着中国能成为GPL协议违反行为的避风港？显然不是的，毕竟著作权侵权诉讼可以在侵权作品传播的地点提起。也就是说，即便是一家中国公司在中国使用GPL开源软件开发其商业产品，只要这个违反GPL协议的商业产品在美国存在分发，比如权利人在美国可以下载到不遵守GPL协议的商业软件产品，权利人完全有可能选择在美国提起著作权侵权诉讼。

【宣城文广知识产权】秉持尊重创新、崇尚法治的原则，为企业提供从知识产权获取、维护到争议解决的全流程服务，助其在市场竞争中充分利用知识产权这一重要武器。安徽文广知识产权代理有限公司为你解决烦恼，我们有丰富的驳回复审经验，如有需要，可以随时联系我们13965191860(微信同号)。