8月26日，2022第二期“心寄源”开源法律沙龙成功召开，本期主题演讲围绕热点案例《济宁市罗盒网络科技有限公司与广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案》展开。开放原子开源基金会特别邀请了本期沙龙主讲嘉宾周丹丹律师团队，根据演讲内容整理了《从“玩友案”看GPLv3协议核心法律问题》，以飨读者。感谢大家对本沙龙的关注和支持，有任何建议、意见或参与意愿，欢迎随时与我们交流（legal@openatom.org）。

2021年9月，广州知识产权法院就罗盒网络科技有限公司（以下简称“罗盒公司”）诉玩友网络科技有限公司（以下简称“玩友公司”）等侵害软件著作权纠纷一案作出一审判决[1]，该案因涉及GPLv3协议的法律性质、开源软件的著作权归属及权利行使、GPLv3协议“传染性”范围判定、在GPLv3协议增加限制商业使用条款的效力、违反开源软件协议法律后果等使用开源软件所涉纠纷的核心法律问题，而引起业内的广泛关注。也因该一审判决对上述问题都进行了充分且深入的法律分析和论证，也对开源开发者如何规范使用开源软件给予了一定的引导和建议，该案被评为“2021年中国法院10大知识产权案件”。深入研究本案所涉及的开源许可协议核心法律问题，有助于广大的开源开发者用户更好地理解并遵守开源许可协议，一方面利用好开源软件的技术优势和共享开发模式，一方面也有效避免可能的法律风险。

一、 “玩友案”案情简介

2016年7月，罗盒公司的股东罗迪在GitHub网站上传了其开发的VirtualApp软件初始源代码并引入LGPLv3.0开源许可协议（后更改为GPLv3协议），随后声明任何人如需将该软件用于商业用途需向其购买商业授权。2017年12月，罗盒公司转为开发不开源的商业版本，并停止了开源版本的更新。

玩友公司开发了四款被诉侵权的微信视频美颜相机APP并上传于各平台供用户下载，但并未提供源代码。罗盒公司认为四款被诉侵权软件中的沙盒分身功能与原告于2017年12月30日在GitHub网站上发布的VirtualApp开源版本（下称“涉案软件”）构成实质性相似，玩友公司不提供开源代码且收取会员费的行为违反GPLv3开源许可协议，侵害其涉案软件著作权，遂诉至法院。广州知识产权法院认为，玩友公司收取被诉侵权软件的会员费并不违反GPLv3协议的规定，但是，使用涉案软件开发的商业软件需遵守GPLv3协议公开其全部源代码，玩友公司未向用户提供被诉侵权软件源代码下载，违反了GPLv3开源许可协议的约定，侵害了涉案软件著作权。广州知识产权法院依法判令玩友公司停止提供含有沙盒分身功能源代码的四款软件的下载、安装和运营服务，并赔偿罗盒公司经济损失及维权合理支出共计50万元。一审宣判后，双方当事人均未上诉。

二、涉及开源协议的核心法律问题

本案有软件著作权侵权案件审理的常规思路，如软件著作权归属问题的判定、被诉行为是否构成著作权侵权（包含被诉侵权软件与权利软件软件代码是否实质性相似），各被告应承担的法律责任等。同时，因罗盒公司VirtualApp软件是适用GPLv3协议的开源软件，所以本案在著作权归属问题判定时，还涉及VirtualApp软件是否为罗盒公司与GitHub上其他贡献者的合作作品，罗盒公司提起本案诉讼是否需要其他贡献者的授权？在是否构成著作权侵权行为判定时，还涉及GPLv3协议的法律性质和效力、罗盒公司是否有权在GPLv3协议中加入商业使用限制保留条款，玩友公司收取被诉软件会员费是否违反GPLv3协议、玩友公司未提供被诉软件源代码下载是否违反GPLv3协议及违约侵权竞合等问题。

（一）VirtualApp软件是否为罗盒公司与GitHub上其他贡献者的合作作品，罗盒公司提起本案诉讼是否需要其他贡献者的授权

玩友公司认为 ，VirtualApp开源项目为不可分割使用的合作作品，贡献者有32人，罗迪仅为著作权人之一，故罗迪无权单方将其权利转让给罗盒公司。

罗盒公司认为 ，项目人罗迪与其他贡献者不存在创作合意，贡献者提交的修改内容是否为项目接受，由项目人单方决定；罗盒公司完成实质开发工作，实质性相似代码超过90%由罗迪完成，其他贡献者仅作出少量、不具有独创性的修改，故涉案VirtualApp软件不属于不可分割的作品。

法院认定 ：罗盒公司作为提交了绝大部分代码量的项目管理者，提起本案诉讼无需经过其他贡献者的授权，有权单独提起本案诉讼，理由主要有如下三点：

①罗迪作为项目管理人上传了VirtualApp初始版本源代码，代码量占整个涉案软件代码量的绝大部分，其他贡献者提交的代码未对涉案软件著作权产生实质影响；

②被告并未举证证明贡献者提交的代码是否属于有独创性表达的创作，仅根据贡献者提交的代码无法判断其是否有独创性，就在案证据无法认定涉案软件属于合作作品；

③即使属于合作作品，开源项目的贡献者往往人数众多、互不相识又身居全球各地，且贡献者数量持续动态增加，若开源项目要求必须经过所有贡献者的授权才能提起诉讼，那么将导致开源软件维权无从提起。

关于VirtualApp软件是否为罗盒公司与GitHub上其他贡献者的合作作品，罗盒公司提起本案诉讼是否需要其他贡献者的授权，及罗盒公司未与其他贡献者协商的转让行为是否有效力等问题，笔者认为还是有可深入探讨的空间。

1、VirtualApp软件是否为罗盒公司与GitHub上其他贡献者的合作作品

根据《著作权法》第十四条、《著作权法实施条例》第九条、《计算机软件保护条例》第十条的规定，合作作品的构成要件如下图：

法院基于“玩友公司并未举证证明贡献者提交的代码属于有独创性的创作”而未认定其所贡献的代码具有独创性，进而未认定合作作品，还是会存在一定争议的。首先，举证责任分配存在不合理，代码是贡献者写的，玩友公司没有能力证明其独创性到底体现在哪里，软件侵权案件，通常都应该由否定代码独创性一方举证，如该代码来自第三方软件或者属于有限表达等，自证独创性很难实现。罗盒公司不需要证明就认定其最初提交的源代码具有独创性，但贡献者后续提交的源代码就需要证明才能认定具有独创性，也具有不合理性；其次，对代码独创性的判断标准也不应太高，贡献者基于开源项目管理者创建的主分支创建自己的分支并自行进行代码修改，其代码并入主分支是需要提起“创建拉取请求”的，项目管理者的同意也能证明贡献者所编写的代码具有功能价值，在没有反证的情况下，应认定贡献者代码具有独创性。

开源软件的开发中，项目管理者和贡献者都参与代码编写还是普遍存在的，不应太轻易否认贡献者编写代码的独创性，也不应把构成合作作品的标准提的过高。司法实践中，明确代码独创性标准、独创性举证责任分配、合作作品的构成要件等还是非常有必要的，有利于有效指引项目管理者和贡献者明确彼此的权利义务关系，避免不必要的纷争。

2、如构成合作作品，是否可分割使用？如不可分割使用，罗盒公司未与其他贡献者协商的转让行为是否有效力？

假定VirtualApp软件为罗盒公司与GitHub上其他贡献者的合作作品，我们在此基础上探讨软件转让行为的效力问题。根据《计算机软件保护条例》第十条规定，合作开发的软件可以分割使用的，开发者对各自开发的部分可以单独享有著作权；但是，行使著作权时，不得扩展到合作开发的软件整体的著作权。合作开发的软件不能分割使用的，其著作权由各合作开发者共同享有，通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让权以外的其他权利。可分割软件作品的著作权行使一般不会有太大争议，在此我们仅讨论VirtualApp软件（2017年12月30日版本）为不可分割使用的软件，罗迪未与其他贡献者协商将VirtualApp软件转让给罗盒公司，其转让行为是否有效？笔者认为，判断民事法律行为是否有效力应基于《民法典》第一百五十三条、第一百五十四条的规定，只有恶意串通、违反强制性规定及违背公序良俗的民事法律行为才应认定无效，而本案涉及的转让行为不应认定为恶意串通（罗迪先研发，后成立公司并将软件入股，符合一般市场行为，不具有串通损害其他贡献者权益的主观恶性），也不违反强制性规定或公序良俗，所以该转让行为应认定有效。但因该转让行为违反了《著作权法》《计算机软件保护条例》的相关规定，会涉及侵犯其他贡献者著作权问题，其他贡献者应可以以侵犯共有著作权为由向罗盒公司主张权益。

基于以上讨论可见，无论本案中是否认定VirtualApp软件（2017年12月30日版本）为合作作品，都不影响罗盒公司独立提起本案诉讼，这符合法院基于开源项目贡献者众多，且贡献者数量持续动态增加，若开源项目要求必须经过所有贡献者的授权才能提起诉讼，那么将导致开源软件维权无从提起的价值判断；也符合法院特别强调，涉案软件的贡献者可以向罗盒公司主张分割赔偿款，以保障贡献者合法权益的用意。

（二）GPLv3协议的法律性质和效力

前述已说明，因本案权利软件VirtualApp为适用GPLv3协议的软件，所以本案是否构成著作权侵权，需先行判断我国法律是否承认GPLv3协议的效力及认定其为什么法律属性的文件。

法院参考美国、德国等域外判例对GPL开源授权许可协议性质的认定，并结合我国涉合同相关法律的规定，最终认定：GPLv3协议具有合同性质，是授权方和用户订立的格式化著作权协议，属于我国合同法调整的范围。

第一，GPLv3协议的内容具备合同特征，属于广义的合同范畴。开源软件协议属于软件权利人和用户之间订立的合同，开源软件的发布视为发出要约，用户使用视为承诺，在用户使用开源软件时合同成立。

第二，GPLv3协议是非典型合同。该协议是开源软件的作者向不特定的使用者让渡其著作权的部分人身权利和全部财产权利，权利授予的对象是不确定的，以换取使用者承诺遵守开源许可协议的许可条件和义务，开源软件许可协议并没有权利转让的对价或许可使用付酬等典型著作权许可合同的主要条款。

第三，GPLv3协议是格式合同。GPLv3协议是为特定开源项目开发而预先拟定，由著作权持有人向软件程序使用者提供的合同条款。……格式化条款保持承继性，且不属于格式合同条款无效的情形，其授权内容符合我国著作权法的规定，合法有效。

第四，对协议的承诺是通过行为作出的。GPLv3协议第9条规定，一旦修改和传播一个受保护作品，就表明你接受本协议。

（三）罗盒公司是否有权在GPLv3协议中加入商业使用限制保留条款，玩友公司收取被诉软件会员费是否违反GPLv3协议

既然GPLv3协议属于格式合同，罗盒公司是否有权在GPLv3协议中加入商业使用限制保留条款，玩友公司收取被诉软件会员费是否违反GPLv3协议？罗盒公司在项目中声明：当您需要将VirtualApp用于商业用途时，请务必联系购买商业授权，所以罗盒公司在本案中主张，玩友公司在被诉软件中使用了VirtualApp中的开源代码，并基于被诉软件收取会员费违反GPLv3协议。法院经审理认定：

① GPLv3协议序言规定[2]，所谓自由软件，我们强调的是自由，而非价格免费，GPLv3协议设计用于确保你享有发布自由软件副本的自由（如果你愿意，你可以为此服务收费）。这说明开源软件可以用于商业运作模式。

② OSI对开源软件的10个定义中也包含“不能歧视任何领域”，比如不得规定软件不能用于商业目的。

③ 罗盒公司的商业使用限制保留条款不属于第7条规定[3]的可以添加的6种补充附加条款之一，应属于非许可性附加条款，属于第10条[4]中的“进一步限制”，因此罗盒公司无权在适用GPLv3协议的涉案VirtualApp项目中添加商业使用限制保留条款。

④如果软件可以视作下列组成等式，即：软件＝程序＋文档＋支持＋培训＋服务，虽然代表“软件形态”的程序、文档可以免费，但作为“软件服务”的支持等环节可以收费。玩友公司收取被诉软件的会员费并不违反GPLv3协议的规定。

判决通过对GPLv3协议序言及相关条款的解读，明确了罗盒公司无权在适用GPLv3协议的涉案VirtualApp项目中添加商业使用限制保留条款，玩友公司收取被诉软件的会员费也并不违反GPLv3的规定。开源技术应用领域，软件开发人员经常有一个误区，即使用开源代码开发的软件，不可以商用，不可以收费，本案对此误区给予了明确的厘清和指引。

（四）玩友公司未提供被诉软件源代码下载的行为是否违反GPLv3协议的规定

GPLv3协议属于严苛型许可证，根据其条款规定，只要一个软件中使用了GPL许可协议的开源代码，修改的源代码或者衍生代码软件都必须公开源代码。法院经审理认为，GPLv3协议有三个重要的限制[5]：

①用户不可以在使用一个受GPL许可协议保护的软件基础上加入一些闭源软件构成一个更大的软件，也就是说一个GPL软件的所有部件都必须遵循GPL的规定公开；

②用户不可以将一个GPL软件加以修改(比如加上了自己创造的软件)然后将修改的部分变成闭源软件，也就是说用户的创造或增值软件也应该遵循GPL的规定公开；

③如果能够确定作品的一部分并非程序的衍生产品，与程序并未混合在一起，也未意图在某种存储或分发媒介上组成一个更大的程序，而是独立的，则这部分独立的程序发布时可以不受GPL的约束。不过，当将这部分作为程序的一部分发布时，因它是程序整体的一部分将受到GPL约束。

根据GPLv3协议第5条的规定，只有“聚合体”中独立程序可以不受GPL协议的约束。法院认为，对于在逻辑上与开源代码有关联性且整体发布的衍生作品，只要其中有一部分适用了GPLv3协议发布，那么整个衍生作品都必须适用GPLv3协议而公开。本案中，玩友公司并未举证证明沙盒分身功能部分源代码是独立的，因此被诉侵权软件应整体适用GPLv3协议，玩友公司应开源整个被诉侵权软件的源代码。即玩友公司未向用户提供被诉侵权软件源代码下载已经违反GPLv3协议的规定。

有关GPLv3许可证下源代码“传染范围”及避免传染的阻断方式，其具体判断会具有非常大的难度，有必要基于GPLv3协议条款及国内相关判例深入探讨。

1、“聚合体”中的独立程序可以不受GPL协议的约束

需要先明确GPLv3许可证下“聚合体”的定义，GPLv3协议第5条的规定，在一个存储或分发媒介上的、由一个受保护作品和其他与之分离的单独作品所组成的联合作品，这些单独作品既不是该受保护作品的自然扩展，也没有与受保护作品一起构建出一个更大的程序，并且该联合作品及其产生的版权相对于单独作品而言，没有给用户的访问及其他合法权利带来额外的限制，该联合作品称为“聚合体”。在聚合作品中包含受保护作品，并不会使本协议适用于聚合作品的其他部分。

即GPL协议并不会“传染”仅仅与受GPLv2或GPLv3许可证约束的开源软件（以下简称“GPL开源软件”）聚合在一起，本质不属于GPL开源软件的衍生，也不是与GPL开源软件结合成一个更大的程序的独立程序。在笔者代理的“数字天堂诉柚子科技案”[6]中，北京高级人民法院终审认定，尽管HBuilder软件其他文件夹中包含GPL开源协议文件，但该协议对于涉案三个插件并无拘束力，涉案三个插件并不属于该协议中所指应被开源的衍生产品或修订版本，即认定涉案三个插件为不受GPL协议传染的独立程序。

2、内部服务器、云端服务器部署GPL开源软件，不受GPL协议的约束

GPL协议第2条规定[7]，你可以无条件地制作、运行和传播那些你并不发布的受保护作品。这里对“发布”的定义是，指让他方能够制作或者接收副本的传播行为，仅仅通过计算机网络与用户进行交互，而没有传输副本，不算发布。即用户可以自由修改开源代码并私下使用，内部服务器部署GPL开源软件，不受GPL协议的约束。进一步，在后端服务器、云端服务器部署GPL开源软件，因用户无需进行任何下载、安装，直接通过网络远程接入服务，应也不属于GPL协议定义的“发布”行为，亦不受GPL协议的约束。

3、架构隔离，避免独立程序被GPL协议传染

根据GNU许可证常见问题[8]答复，独立程序的合理标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用等等），也依赖于通信的语义（交换了什么样的信息）。基于该答复，为避免独立程序被“传染”，不要将GPL开源软件和独立程序放在同一共享地址空间，通过管道(pipes) 、套接字(sockets)和命令行参数等方式达成独立程序之间的通信或调用，以此实现独立程序（商业软件）与GPL开源软件的隔离。

（五）违反GPLv3协议的法律后果

GPLv3协议第8条“终止授权”规定，除非在本协议明确授权下，你不得传播或修改受保护作品。其他任何传播或修改受保护作品的企图都是无效的，并将自动终止你通过本协议获得的权利。

据此，法院认定，GPLv3协议属于附解除条件的著作权合同，许可条款是版权许可的条件，如果用户违背条款规定，那么许可的前提条件已不复存在，则GPLv3协议终止适用，用户获得的授权也将自动终止。玩友公司未向用户提供被诉侵权软件源代码下载已经违反GPLv3协议规定，则玩友公司对涉案软件源代码的复制、发布行为因失去权利来源而构成侵权。即对违反开源协议的行为存在违约救济和侵权救济两种，守约方可以自行选择。本案罗盒公司选择主张追究玩友公司的著作权侵权责任。法院最终认定，玩友公司未向用户提供被诉侵权软件源代码下载，违反了GPLv3协议的约定，侵害了涉案软件VirtualApp软件发行权和信息网络传播权，承担停止侵权和赔偿损失的法律责任。

三、“玩友”案的误区厘清及启示

《2021中国开源发展蓝皮书》显示，不论是在全球范围还是中国国内，开源正在推动深度信息技术（机器学习、人工智能、自动驾驶、区块链、神经网络、量子计算等）的创新发展，广泛应用于互联网、电子商务、电子竞技、智能家居、消费电子以及现代服务业等领域，同时开源技术正在快速被金融、能源、通讯、教育、医疗等产业采用。在《“十四五”规划和二〇三五年远景目标纲要》文件中，也明确提出“支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”。但与开源技术的深入推广和发展相对应的是，中国国内的开源软件开发者用户对开源许可证还普遍缺少认识，广泛存在认知误区。本案对于开发者用户了解开源协议中涉及的基本法律问题，如何遵守开源协议，如何选择开源许可证，如何避免被强制开放源代码等问题，都给予了明确的分析和引导。笔者总结，本案判决对如下常见误区都给予了厘清和启示：

误区1——中国法院不承认开源软件的效力，不规制违反开源协议的行为

在笔者代理的“数字天堂诉柚子科技案”，及最高院审理的“不乱买诉闪亮时尚案”[9]中，被告均提出原告权利软件为开源软件的抗辩，两案都认定了权利软件并不受GPL开源协议的约束。由此，产生了中国法院不规制违反开源协议的错误认知。本案判决明确承认了在中国法下开源许可证的合同属性，并认定了违反GPLv3协议的行为构成著作权侵权。

误区2——开源软件没有著作权、可以任意免费使用

法院指出，开源软件的“自由”体现为通过著作权许可给予的自由，而不是自由得没有著作权，开源软件的权利人不但没有完全放弃著作权，而且还可通过开源软件许可协议寻求著作权保护。

误区3——复制、分发和修改开源代码不能收取任何费用

法院指出，开源软件不等于不能有商业开发，商业软件一般通过控制软件源代码、出售软件许可来获益，而开源软件盈利模式多样，主要通过商业化服务模式来获得商业利益，如硬件捆绑、增值产品、技术支持、广告业务等，即使用开源代码开发的软件，可以商用，可以收费。

误区4——在开源代码基础上“研发创新”部分可以作为闭源软件进行商业许可

法院指出，对于在逻辑上与开源代码有关联性且整体发布的衍生作品，只要其中有一部分适用了GPLv3协议发布，那么整个衍生作品都必须适用GPLv3协议而公开。即在开源代码基础上“研发创新”部分也需要开放源代码，不可以闭源发布。

误区5——删除了“适用GPLv3协议”的表述，就可以自此闭源了

法院指出，根据GPLv3协议的规定，只要后续版本中有使用先前开源版本中的源代码，并且先前版本使用了GPLv3协议，则后续版本也必然受GPLv3协议的约束。因此，后续开源版本仍然受GPLv3协议的约束。

[1] 参见(2019)粤73知民初207号民事判决书

[2] 参见GPLv3许可证序言

[3] 参见GPLv3许可证第7条 附加条款

[4] 参见GPLv3许可证第10条 对下游接收者的自动授权

[5] 参见GPLv3许可证第5条 发布修改过的源码版本

[6] 参见(2018)京民终471号民事判决书

[7] 参见GPLv3协议第2条 基本许可

[8] 参见GNU许可证常见问题 “聚合体”和其他“修改版”有什么不同

[9] 参见(2019)最高法知民终663号民事判决书

本文作者：

周丹丹

dandan.zhou@fairskylaw.com

周丹丹律师从事知识产权法律行业近二十年，尤其擅长商标疑难案件、互联网领域不正当竞争案件、计算机软件著作权案件、网络游戏案件等。其代理的多起案件在业内获得广泛关注，多次入选最高院、北京法院等各地法院的知识产权十大案例。

曹阳

yang.cao@fairskylaw.com

曹阳律师拥有计算机和法律交叉学科背景，自进入知识产权法律行业以来，在计算机软件著作权纠纷、互联网领域不正当竞争纠纷等类型案件中积累了丰富的经验。

声明：沙龙嘉宾的发言仅代表个人观点，除非特殊说明不代表其所在单位的观点或开放原子开源基金会的观点。