国内首例违反 GPL 协议侵权案一审结束
2021-09-10 14:39:21 
阿炯
2021年9月消息，近日，一起关于 GPL 版权纠纷案裁判文书公示。一审判决书显示，GPLv3.0 协议是一种民事法律行为，具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。一审判定两侵权被告公司赔偿原告公司经济损失及维权合理费用共计 50 万元，并停止侵权行为。
此判例可以说是中国首个明确 GPLv3.0 协议的法律效力的案例。判决书显示，明确违反开源软件许可证的侵权法律责任，一方面可以及时制止侵权行为，防止他人对开源软件的不正当利用；另一方面能够有效保护授权人的利益，使他们保有继续创作的动力，促进源代码共享和知识的传播。
不过值得注意的是，本案中被告的侵权事实成立，是因为违反 GPLv3.0 协议导致 GPLv3.0 协议自动解除，被告失去了 GPLv3.0 协议下的源代码授权保护，进而构成侵权。
判决书中对于违反 GPLv3.0 协议的侵权责任明确如下：
关于违反 GPLv3.0 协议的侵权责任。
著作权法为了保护权利人的专有权，仅规定非权利人可以在如“合理使用”等范围内使用作品，诸如复制、修改、发行等权利则专属于权利人，任何人非经许可实施这些行为将构成侵权。
根据 GPLv3.0 协议第 8 条“终止授权”的约定，授权人许可用户在遵守许可证规定的前提下行使某些权利，但用户必须承担相应的义务。若用户违反 GPLv3.0 协议的使用条件来复制、修改或传播受保护的作品，其通过 GPLv3.0 协议获得的授权将会自动终止。
对此，我国《民法总则》第一百五十八条规定：“民事法律行为可以附条件……附解除条件的民事法律行为，自条件成就时失效”。
根据开源软件的特性，GPLv3.0 协议规定的使用条件(如开放源代码、标注著作权信息和修改信息等)系授权人许可用户自由使用的前提条件，亦即协议所附的解除条件。一旦用户违反了使用的前提条件，将导致 GPLv3.0 协议在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为，因失去权利来源而构成侵权。
本文案件相关内容整理自一审判决书。
案件概况
原告：济宁市罗盒网络科技有限公司
被告：福建风灵创景科技有限公司(以下简称福建风灵公司)
被告：北京风灵创景科技有限公司(以下简称北京风灵公司)
被告：深圳市腾讯计算机系统有限公司(以下简称腾讯公司)
原告济宁市罗盒网络科技有限公司独立开发“罗盒（VirtualApp）插件化框架虚拟引擎系统 V1.0（简称 VirtualApp V1.0）。VirtualApp 从 2016 年 7 月 8 日的版本开始引入开源协议，起初为 LGPLv3.0 协议，2016 年 8 月 12 日更换为 GPLv3.0 协议。
2017 年 10 月 29 日，原告公司在 VirtualApp 后续开源版本中删除“适用 GPLv3.0 协议”的表述。
2017 年 11 月 8 日，原告公司为 VirtualApp V1.0 取得计算机软件著作权登记证书，依法享有 VirtualApp V1.0 软件著作权的全部权利。
2017 年 12 月 30 日由 Lody（原告公司股东、VirtualApp 项目人罗迪） 提交的更新（对应 Git 码为8e6d9cd925af55b53a7e93046c469dd69676c38b）的 CHINESE.md 文件内载明“VirtualApp(中文名为罗盒)2017 年 8 月份正式公司化运作，当您需要将 VirtualApp 用于商业用途时，请务必联系 QQ1*****购买商业授权……VirtualApp 源代码将于 2017 年 12 月 31 日停止更新”。
2018 年 9 月，原告调查发现名为“点心桌面”的软件使用了 VirtualApp V1.0 的代码，将两个软件源代码进行分析比对，两者间 421 个可比代码中有 308 个代码具有实质相似性，有 27 个代码具有高度相似性，有 78 个代码具有一般相似性。因此，被诉侵权软件与涉案软件构成实质相似。
原告向法院起诉，庭审时明确诉请为判令如下：
1.被告福建风灵公司、被告北京风灵公司立即停止侵害原告的计算机软件著作权，即立即停止通过互联网提供所有版本的“点心桌面”软件的下载、安装和运营服务；
2.被告福建风灵公司、被告北京风灵公司赔偿原告经济损失 2000 万元；
3.被告福建风灵公司、被告北京风灵公司赔偿原告为制止侵权行为而支出的合理费用 50 万元;
4.被告福建风灵公司、被告北京风灵公司承担本案诉讼费用。
证据显示，被告福建风灵公司系被诉侵权软件“点心桌面”的著作权人。被告北京风灵公司亦被有关互联网平台标示为“点心桌面”的开发者，并被登记为“点心桌面”软件的著作权人。此外，提供被诉侵权软件下载、安装和运营服务的“点心桌面官网”和“应用宝”网站分别由被告福建风灵公司和腾讯公司经营。
立案之后，经查，被诉“点心桌面”App(V6.5.8)中使用了原告采用 GPLv3.0 协议发布的VirtualApp，同时被告对此亦予以确认。
法院观点
法院认为，该案系侵害计算机软件著作权纠纷,涉及开源软件的相关问题。根据双方诉辩意见及举证情况，该案争议焦点有四方面。法院已就焦点问题给出明确观点（此部分为法院观点截选，详情可查看判决书原文）。
焦点一：GPLv3.0 协议的法律效力。
法院明确 GPLv3.0 协议具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。
关于违反 GPLv3.0 协议的侵权责任，明确若用户违反 GPLv3.0 协议的使用条件来复制、修改或传播受保护的作品，其通过 GPLv3.0 协议获得的授权将会自动终止。
焦点二：原告是否有权提起本案诉讼。
一是根据代码托管网站上的上传记录及证明等，原告公司可以证明是 VirtualApp 的著作权人。
二是原告提起本案诉讼无需贡献者的同意或授权，即有权提起诉讼。原因包括：原告公司股东罗迪作为项目人已将 VirtualApp 初始版本的源代码共计 31097 行在 Github 网站上公开发布，此系原告主张权利的基础；本案项目人对“主分支”中 VirtualApp 源代码的形成起到了决定作用；贡献者选择在 GPLv3.0 协议的 VirtualApp 项目中上传自己的源代码，贡献者亦将按照 GPLv3.0 协议许可其贡献，即视为同意将贡献内容许可给项目人及其他用户使用，并且若开源项目的起诉维权需经全体贡献者一致同意或授权，实则导致维权行为无从提起。综上，原告提起本案诉讼无需贡献者的同意或授权。
三是，GPLv3.0 协议中仅限制授权人不得向用户主张任何专利权，而并未限制授权人对违反许可协议的用户主张著作权。因此，原告的诉讼行为并未违反 GPLv3.0 协议关于争议解决方式的约定。
焦点三：被诉行为是否侵害原告的著作权。
一是原告虽将 VirtualApp 分为开源版本与商业版本，并且在后续开源版本中删除“适用 GPLv3.0 协议”的影响问题。
原告在本案中系以 VirtualApp 开源版本而非商业版本作为其权利基础，故本案中不必对VirtualApp 开源版本与商业版本的关联及影响作出认定。而根据 GPLv3.0 协议，若先前版本使用了 GPLv3.0 协议，则后续版本也必然受 GPLv3.0 协议的约束，因此 VirtualApp 后续开源版本仍然受 GPLv3.0 协议的约束。
二是 GPLv3.0 协议允许用户进行商用，授权人不得对此作出限制。所以原告主张“点心桌面”App进行商用违反 GPLv3.0 协议及其附加条款缺乏理据，法院不予支持。
三是被诉“点心桌面”App(V6.5.8)本应当遵循 GPLv3.0 协议向公众无偿开放源代码，但被告福建风灵公司拒不履行 GPLv3.0 协议规定的使用条件。根据 GPLv3.0 协议第 8 条自动终止授权的约定及《民法总则》第一百五十八条的规定，被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵公司对 VirtualApp 实施的复制、修改、发布等行为，因失去权利来源而构成侵权。
焦点四：若侵权成立，被告应承担的法律责任。
被告福建风灵公司作为“点心桌面”App(V6.5.8)的开发、运营和发布者，依法应承担停止侵害 VirtualApp 著作权的行为。鉴于被告福建风灵公司系被告北京风灵公司的全资子公司的情形，原告指控两被告共同承担侵权责任合法有据，法院予以支持。
被告腾讯公司对其“应用宝官网”上可能存在的侵权行为制定了相关规则、设置了投诉渠道，且对被诉软件作了及时下架处理。原告亦未对被告腾讯公司提出具体诉请。因此，被告腾讯公司无需承担法律责任。
关于赔偿问题，原告主张以被告福建风灵公司、被告北京风灵公司的侵权获利来计算。鉴于开源许可协议缔约方式和缔约主体的特殊性，导致违约或侵权行为更具隐蔽性，相应法律责任的承担应有助于敦促缔约方诚信履行开源义务，确保开源社区规范、持久的发展。开源软件大多都是免费的，但授权人付出的开发成本是必然存在的，按照侵权获利来承担赔偿责任更为公平合理。
最终，法院酌情确定赔偿数额为 50 万元。原告为制止本案侵权行为所支出的合理费用，计算在赔偿损失数额范围之内。
关于此案的更多细节和法院观点，详情可登陆中国裁判文书网查看此案（2019）粤03民初3928号一审判决书。
一审判决书：
中国裁判文书网地址
其他网站地址
律师解读
我们邀请专注 TMT 领域的知识产权问题的邓超律师（18611123013）就此案件做相关解读。后续邓超律师将发表深度解读文章，敬请期待！
问题一：此案对后续有关开源软件版权纠纷案件有何具体参考意义？
这个案子据我所知，被告上诉了，所以现在这个判决还没有生效，最后法院怎么认定，还没有最终定论。
但毫无疑问的一点是，违反许可证的义务是会遭到权利人的侵权索赔的。
因为以往国内开源主要是拿来主义，使用国外的代码比较多，但随着国内开发者的不断成熟。将来相关的纠纷会越来越多，这就要求法务和开发人员了解开源的相关问题。
问题二：为什么此案件中，“点心桌面”未被强制开源？
没有要求强制开源是因为原告没有提出这样的要求，那么法院是一个被动的审判机关，不告不理，只被动审理原告提出的请求。
在这个案件中，原告没有选择合同，也就是许可证违约，而是选择了版权侵权这条救济途径。一般而言，版权侵权要比合同违约的救济力度要大，无论从各个方面，这在国内和在美国都是如此。
问题三：如果原告提出了开源的诉求，会如何？
如果原告选择了合同违约这条途径，法院是不是会支持被告将代码强制开源这个问题其实很值得探讨，我个人初步的观点是，法院不一定会支持这种诉请。关于这个事情，我准备近期写篇文章，但我现在初步的看法是要求代码强制开源，在法院不太可能得到支持。所以，如果违反 GPL 许可证的义务，那么将代码全部开源，更多的是一种理论上的可能。在实践中，以中国和美国的法院为例，我理解支持这种诉求的可能性都非常低。
延伸阅读
GPL 解读文章：
GPL风波录
人话解读GPLv3
BSD开发者眼中的采用了GPL授权的Linux
意大利法院判定开源协议条款可强制执行
2021年12月13日，意大利威尼斯法院在一起涉及 GPL（也许是最知名的开源许可协议）的案件中，低调地确认了开源软件许可协议的法律可执行性——这将成为其国内的一个判例(test case)。
这起案件的原告是总部设在意大利的有限责任公司 Ovation，被告是 Ovation 的两名前雇员，涉及到的项目则是 Ovation 开源的 Dynamic.oo——采用了 GPL 开源许可协议。Dynamic.oo 是用于构建 WordPress 网站的开源 Elementor 平台的插件。
根据 Ovation 的介绍，由于 Dynamic.oo 是开源软件，因此被告方及其公司在获得项目源代码的前提下重新分发了 Dynamic.oo，此操作是符合 GPL 要求的。但问题在于被告方重新分发该软件时，没有包括对原始作品的确认，没有提供有关被告对软件所做更改的信息，也没有提及该软件的版权所有者。简单来说就是被告方在没有遵守 GPL 的情况下分发了 Dynamic.oo。
Ovation 补充道，被告的非法行为还包括无视法院发出的正式终止通知。经过审判，法院除了命令被告在软件满足许可协议要求之前停止分发软件外，还规定了被告延迟执行判决结果的罚款。最后，原告的诉讼费用由被告承担，其中赔偿总额为 5.000 欧元，支出为 545,00 欧元，以及 15% 的一般费用，包括增值税和注册会计师聘请费用。
再回到案例本身，有人对法院的判决有疑问，因为按照原告的说法，法院只是命令被告从他们的产品中删除侵权代码以满足 GPL 合规，而不是命令被告通过发布修改后的源代码来满足 GPL 要求。
GPL 转闭源违规？法院判决：一日 GPL 终生 GPL
2022年1月上旬消息，接上文，在2021年一起关于 GPL 版权纠纷案的裁判文书公示引起了开源界的广泛关注。该判例出自深圳中级人民法院，明确了 GPLV3 协议的法律效力，其被告因使用 GPL 相关软件但未向公众无偿开放源代码，而被判赔偿 50 万元。
无独有偶。另一起类似案件发生在广州，这次案件的原告依旧是济宁市罗盒网络科技有限公司（以下简称：罗盒公司），案由依旧是侵害计算机软件著作权纠纷，而被告变为广州市玩友网络科技有限公司、深圳冠准航科技有限公司、深圳奥斯坦科技有限公司和祥运实业（深圳）有限公司（以下简称：玩友公司等），且被告又被判罚了 50 万元。
该案件可谓十分精彩：2019 年 3 月 4 日，广州知识产权法院立案，于 2020 年 11 月 3 日公开开庭审理。罗盒公司起诉玩友公司等侵害罗盒公司的 VirtualApp 计算机软件著作权中的复制权、发行权、信息网络传播权，要求立即停止侵权行为的同时，索赔 1500 万元经济损失。
罗盒公司给出的理由是：罗盒公司于 2017 年 11 月 8 日取得“罗盒（VirtualApp）插件化框架虚拟引擎系统[简称：VirtualApp]V1.0” 的计算机软件著作权登记证书，依法享有 “罗盒（VirtualApp）插件化框架虚拟引擎系统 [简称：VirtualApp]V1.0” 著作权的全部权利。为便于 VirtualApp 的推广和许可，罗盒公司在国际知名的软件托管平台 GitHub 上公开了 VirtualApp 的源代码，并声明任何人如需将 VirtualApp 用于商业用途，需向罗盒公司购买商业授权。罗盒公司在本案中主张权利的软件为 GitHub 上 VirtualApp 的 2017 年 12 月 30 日版本。
简单来说，原告认为 VirtualApp 是他们“私有的”知识产权，虽然我们以前在 GitHub 上是开源的，但现在不是了，商用要交钱。
被告玩友公司辩称：
首先，罗盒公司不是涉案软件的著作权人，根本无权诉讼。
罗盒公司诉称拥有著作权并提供对比鉴定的计算机软件代码，系托管在GitHub上的开源项目 VirtualApp的VirtualApp-master 版本源代码。该开源项目参与编写源代码程序的人数多达 32 位，项目人 aslody 仅为著作权人之一。
其次，VirtualApp 原项目是在 GPL 许可证之下，罗盒公司分叉出来再闭源，所谓“私有”本就存疑。
VirtualApp 项目为适用 GNU 宽松型通用公共授权许可协议第三版（GNU Lesser General Public License Version 3，以下简称 LGPLV3 协议）的开源项目，后修改为 GNU 通用公共授权许可协议第 3 版（GNU General Public License Version 3，以下简称 GPLV3 协议），VirtualXposed 即为 GitHub 上的开发者“tiann”等人，延续适用 GPLV3 协议（2016 年 9 月 10 日添加），同期在 VirtualApp 开源项目和 epic 开源项目的基础上发布的新免费开源项目。
被诉侵权软件的沙盒分身基础框架代码是在 VirtualXposed 开源项目 Xposed 分支2018年1月10日适用 GPLV3 协议开源免费发布的 VirtualXposed-ff32bb8ed7ad10022620c1fb56cfedc6b2e1b355 开源版本基础上自主研发而成。
VirtualApp 项目人 aslody （罗盒公司申请专利的项目管理者）罔顾社区其他开发者的贡献及相应著作权权利，将开源项目据为私有并进行大肆敛财，违背开源社区的基本准则。
无论 VirtualApp 项目代码还是 VirtualXposed 项目代码，均无任何质量担保，且仅可实现沙盒分身基础功能。
法院认为：
1、罗盒公司是否为涉案 VirtualApp 软件的著作权人，且有资格起诉？答案：是。
本院对此认为，首先，罗盒公司的股东罗迪作为项目管理人于 2016 年 7 月 7 日将 VirtualApp 初始版本源代码（首次提交 507 个文件，共 31097 行）上传至 GitHub 官网开源发布，这是罗盒公司主张权利的基础，也是整个涉案软件的核心基础。贡献者提交的代码是在此基础上不断升级优化，贡献者提交的代码能否并入涉案软件主分支由项目管理人决定，项目管理人提交的代码量占整个涉案软件代码量的绝大部分，因此其他贡献者提交的代码并未对涉案软件著作权产生实质影响。
其次，判断是否为合作作品应考虑以下因素：作者为两个或两个以上、主观上有共同进行作品创作的合意、客观上有共同创作作品的行为、合作作者贡献了独创性的表达。涉案软件源代码的提交者包括项目管理者和贡献者，而贡献者提交代码的流程是先由贡献者发起拉取申请，经项目管理者同意后才会并入主分支中，显然双方存在共同创作的合意，这也符合软件源代码开源的本意，即通过互联网媒介，集合全球开发者的智慧，尽可能使软件最佳化，从而促进知识的传播。实际上，涉案软件的提交者亦包括管理者和众多贡献者。
但是，玩友公司并未举证证明贡献者提交的代码是否属于有独创性表达的创作，仅根据贡献者提交的代码行数无法判断其是否有独创性。因此，就在案证据无法认定涉案软件属合作作品。
再次，涉案 VirtualApp 适用了LGPLV3 协议或 GPL V3 协议，那么其他贡献者在申请将其代码合并入主分支时默认同意适用 LGPL V3 协议或 GPL V3 协议，即同意将其代码开源贡献给项目管理者和其他用户在授权许可协议范围内自由使用。
开源软件项目的贡献者往往人数众多，互不相识且散布于全球各地，只要项目保持开源则贡献者数量会持续动态地增加。即使涉案软件属合作作品，就在案证据难以查清所有权利人的基本情况下，若开源项目要求必须经过所有贡献者的授权才能提起诉讼，那么将导致开源软件维权无从提起。因此，本院认定，罗盒公司作为提交了绝大部分代码量的项目管理者提起本案诉讼亦无需经过其他贡献者的授权，有权单独提起本案诉讼。
2、罗盒公司是否有权在 GPL V3 协议中加入商业使用限制保留？答案：没有。
本案中，罗盒公司确认其主张的涉案软件 2019 年 12 月 30 日版本与撤回 GPLV3 协议即 2019 年 10 月 29 日前的版本差别不大，因此本院认定罗盒公司主张权利的版本仍属于适用 GPLV3 协议的开源软件。
罗盒公司无权加入商业使用限制保留条款。罗盒公司的商业使用限制保留条款对于用户使用其源代码的目的进行了限制，从而也限制了用户范围，即只有非商业用途的用户才可以使用其源代码，这显然与 GPLV3 协议的“著佐权”特性矛盾。
3、被告侵权了吗？答案：侵权了，但被侵权的是 GPLV3。
即使被诉侵权软件中的被诉部分源代码来源于 VirtualXposed 开源项目 Xposed 分支 2018 年 1 月 10 日版本，但 VirtualApp 项目从 2016 年 6 月起至 2017 年 12 月的每次提交更新均有同步到 VirtualXposed 的 exposed 分支中，且 VirtualXposed 保留了 GPLV3 协议，因此本院认定，被诉侵权软件仍应适用 GPLV3 协议。
关于这个案例更多详情，大家可以访问这里详细了解，里面还有更多重点。
从开源角度看，这次案件不但再次明确了 GPL 的法律效力，而且还提出了一个“华点”：GPL 许可证之下的开源项目，可以分叉出来闭源吗？对此，《大教堂与集市》的中文译者卫剑钒发表了自己的观点：
首先，开源项目私有化，要征求所有作者同意。
这涉及的关键问题是：罗盒能不能把多人共同创作的 VirtualApp 闭源为自己的商业版？我认为，从严格意义上讲，是不可以的（虽然可能确实有超过90% 的代码都是 asLody 完成的）。
如果罗盒是 VA 的唯一作者，私有化没问题，当然可以。（参见我对“风灵案”的解读文章）但罗盒并非 VA 的唯一作者，如果要私有化，就要征得所有作者同意，而且还要把商业版收益分给所有作者。
这在我国著作权法实施条例中说得很清楚：《中华人民共和国著作权法实施条例》第九条规定：“合作作品不可以分割使用的，其著作权由各合作作者共同享有，通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让以外的其他权利，但是所得收益应当合理分配给所有合作作者。”
在VA按照GPL开源期间，有 30 多位贡献者，这些贡献者，每人都拥有部分版权（著作权）。由于罗盒与贡献者并没有签单独的协议（GitHub 上没有，也未在历次官司中出示），按照 GitHub 用户协议，贡献者们仅仅是将代码按照 GPL 授权给罗迪（罗盒）使用，而没有将著作权送出。
其次，用了 GPL，就永远是 GPL，不能加额外限制，GPL 衍生程序不能闭源。
众所周知，GPL本身就是一种授权，授予用户对开源软件的免费使用，现在罗盒又说要使用者购买授权，这不矛盾了吗？按哪个算？其实GPL在第7条里面明确说了：“如果你接收到的程序或其部分，声称受本协议约束，却补充了这种进一步的限制条款，你可以去掉它们。”
GPL 是不允许衍生程序闭源的，VA 的商业版也必须按照 GPL 继续开源。
详情可查看卫 Sir 的文章《再看中国法院是怎么对待 GPL 的》，卫 Sir 还在文章中阐述了GPL 并不限制商用、GPL 的强传染性等观点。
另外，企查查显示，济宁市罗盒网络科技有限公司涉及的司法案件共 6 起，其均是原告，且都是针对 VirtualApp 的侵权案件。另外两个被告分别为：北京链安网络科技有限公司和厦门量子堆栈科技有限公司。其中针对北京链安网络科技有限公司的诉讼已结案，被告被判赔偿 10 万元经济损失。而针对厦门量子堆栈科技有限公司的案件，因为原告提供的被告的住所等信息不具体明确，属被告不明确，被驳回。
此判例可以说是中国首个明确 GPLv3.0 协议的法律效力的案例。判决书显示，明确违反开源软件许可证的侵权法律责任，一方面可以及时制止侵权行为，防止他人对开源软件的不正当利用；另一方面能够有效保护授权人的利益，使他们保有继续创作的动力，促进源代码共享和知识的传播。
不过值得注意的是，本案中被告的侵权事实成立，是因为违反 GPLv3.0 协议导致 GPLv3.0 协议自动解除，被告失去了 GPLv3.0 协议下的源代码授权保护，进而构成侵权。
判决书中对于违反 GPLv3.0 协议的侵权责任明确如下：
关于违反 GPLv3.0 协议的侵权责任。
著作权法为了保护权利人的专有权，仅规定非权利人可以在如“合理使用”等范围内使用作品，诸如复制、修改、发行等权利则专属于权利人，任何人非经许可实施这些行为将构成侵权。
根据 GPLv3.0 协议第 8 条“终止授权”的约定，授权人许可用户在遵守许可证规定的前提下行使某些权利，但用户必须承担相应的义务。若用户违反 GPLv3.0 协议的使用条件来复制、修改或传播受保护的作品，其通过 GPLv3.0 协议获得的授权将会自动终止。
对此，我国《民法总则》第一百五十八条规定：“民事法律行为可以附条件……附解除条件的民事法律行为，自条件成就时失效”。
根据开源软件的特性，GPLv3.0 协议规定的使用条件(如开放源代码、标注著作权信息和修改信息等)系授权人许可用户自由使用的前提条件，亦即协议所附的解除条件。一旦用户违反了使用的前提条件，将导致 GPLv3.0 协议在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为，因失去权利来源而构成侵权。
本文案件相关内容整理自一审判决书。
案件概况
原告：济宁市罗盒网络科技有限公司
被告：福建风灵创景科技有限公司(以下简称福建风灵公司)
被告：北京风灵创景科技有限公司(以下简称北京风灵公司)
被告：深圳市腾讯计算机系统有限公司(以下简称腾讯公司)
原告济宁市罗盒网络科技有限公司独立开发“罗盒（VirtualApp）插件化框架虚拟引擎系统 V1.0（简称 VirtualApp V1.0）。VirtualApp 从 2016 年 7 月 8 日的版本开始引入开源协议，起初为 LGPLv3.0 协议，2016 年 8 月 12 日更换为 GPLv3.0 协议。
2017 年 10 月 29 日，原告公司在 VirtualApp 后续开源版本中删除“适用 GPLv3.0 协议”的表述。
2017 年 11 月 8 日，原告公司为 VirtualApp V1.0 取得计算机软件著作权登记证书，依法享有 VirtualApp V1.0 软件著作权的全部权利。
2017 年 12 月 30 日由 Lody（原告公司股东、VirtualApp 项目人罗迪） 提交的更新（对应 Git 码为8e6d9cd925af55b53a7e93046c469dd69676c38b）的 CHINESE.md 文件内载明“VirtualApp(中文名为罗盒)2017 年 8 月份正式公司化运作，当您需要将 VirtualApp 用于商业用途时，请务必联系 QQ1*****购买商业授权……VirtualApp 源代码将于 2017 年 12 月 31 日停止更新”。
2018 年 9 月，原告调查发现名为“点心桌面”的软件使用了 VirtualApp V1.0 的代码，将两个软件源代码进行分析比对，两者间 421 个可比代码中有 308 个代码具有实质相似性，有 27 个代码具有高度相似性，有 78 个代码具有一般相似性。因此，被诉侵权软件与涉案软件构成实质相似。
原告向法院起诉，庭审时明确诉请为判令如下：
1.被告福建风灵公司、被告北京风灵公司立即停止侵害原告的计算机软件著作权，即立即停止通过互联网提供所有版本的“点心桌面”软件的下载、安装和运营服务；
2.被告福建风灵公司、被告北京风灵公司赔偿原告经济损失 2000 万元；
3.被告福建风灵公司、被告北京风灵公司赔偿原告为制止侵权行为而支出的合理费用 50 万元;
4.被告福建风灵公司、被告北京风灵公司承担本案诉讼费用。
证据显示，被告福建风灵公司系被诉侵权软件“点心桌面”的著作权人。被告北京风灵公司亦被有关互联网平台标示为“点心桌面”的开发者，并被登记为“点心桌面”软件的著作权人。此外，提供被诉侵权软件下载、安装和运营服务的“点心桌面官网”和“应用宝”网站分别由被告福建风灵公司和腾讯公司经营。
立案之后，经查，被诉“点心桌面”App(V6.5.8)中使用了原告采用 GPLv3.0 协议发布的VirtualApp，同时被告对此亦予以确认。
法院观点
法院认为，该案系侵害计算机软件著作权纠纷,涉及开源软件的相关问题。根据双方诉辩意见及举证情况，该案争议焦点有四方面。法院已就焦点问题给出明确观点（此部分为法院观点截选，详情可查看判决书原文）。
焦点一：GPLv3.0 协议的法律效力。
法院明确 GPLv3.0 协议具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。
关于违反 GPLv3.0 协议的侵权责任，明确若用户违反 GPLv3.0 协议的使用条件来复制、修改或传播受保护的作品，其通过 GPLv3.0 协议获得的授权将会自动终止。
焦点二：原告是否有权提起本案诉讼。
一是根据代码托管网站上的上传记录及证明等，原告公司可以证明是 VirtualApp 的著作权人。
二是原告提起本案诉讼无需贡献者的同意或授权，即有权提起诉讼。原因包括：原告公司股东罗迪作为项目人已将 VirtualApp 初始版本的源代码共计 31097 行在 Github 网站上公开发布，此系原告主张权利的基础；本案项目人对“主分支”中 VirtualApp 源代码的形成起到了决定作用；贡献者选择在 GPLv3.0 协议的 VirtualApp 项目中上传自己的源代码，贡献者亦将按照 GPLv3.0 协议许可其贡献，即视为同意将贡献内容许可给项目人及其他用户使用，并且若开源项目的起诉维权需经全体贡献者一致同意或授权，实则导致维权行为无从提起。综上，原告提起本案诉讼无需贡献者的同意或授权。
三是，GPLv3.0 协议中仅限制授权人不得向用户主张任何专利权，而并未限制授权人对违反许可协议的用户主张著作权。因此，原告的诉讼行为并未违反 GPLv3.0 协议关于争议解决方式的约定。
焦点三：被诉行为是否侵害原告的著作权。
一是原告虽将 VirtualApp 分为开源版本与商业版本，并且在后续开源版本中删除“适用 GPLv3.0 协议”的影响问题。
原告在本案中系以 VirtualApp 开源版本而非商业版本作为其权利基础，故本案中不必对VirtualApp 开源版本与商业版本的关联及影响作出认定。而根据 GPLv3.0 协议，若先前版本使用了 GPLv3.0 协议，则后续版本也必然受 GPLv3.0 协议的约束，因此 VirtualApp 后续开源版本仍然受 GPLv3.0 协议的约束。
二是 GPLv3.0 协议允许用户进行商用，授权人不得对此作出限制。所以原告主张“点心桌面”App进行商用违反 GPLv3.0 协议及其附加条款缺乏理据，法院不予支持。
三是被诉“点心桌面”App(V6.5.8)本应当遵循 GPLv3.0 协议向公众无偿开放源代码，但被告福建风灵公司拒不履行 GPLv3.0 协议规定的使用条件。根据 GPLv3.0 协议第 8 条自动终止授权的约定及《民法总则》第一百五十八条的规定，被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵公司对 VirtualApp 实施的复制、修改、发布等行为，因失去权利来源而构成侵权。
焦点四：若侵权成立，被告应承担的法律责任。
被告福建风灵公司作为“点心桌面”App(V6.5.8)的开发、运营和发布者，依法应承担停止侵害 VirtualApp 著作权的行为。鉴于被告福建风灵公司系被告北京风灵公司的全资子公司的情形，原告指控两被告共同承担侵权责任合法有据，法院予以支持。
被告腾讯公司对其“应用宝官网”上可能存在的侵权行为制定了相关规则、设置了投诉渠道，且对被诉软件作了及时下架处理。原告亦未对被告腾讯公司提出具体诉请。因此，被告腾讯公司无需承担法律责任。
关于赔偿问题，原告主张以被告福建风灵公司、被告北京风灵公司的侵权获利来计算。鉴于开源许可协议缔约方式和缔约主体的特殊性，导致违约或侵权行为更具隐蔽性，相应法律责任的承担应有助于敦促缔约方诚信履行开源义务，确保开源社区规范、持久的发展。开源软件大多都是免费的，但授权人付出的开发成本是必然存在的，按照侵权获利来承担赔偿责任更为公平合理。
最终，法院酌情确定赔偿数额为 50 万元。原告为制止本案侵权行为所支出的合理费用，计算在赔偿损失数额范围之内。
关于此案的更多细节和法院观点，详情可登陆中国裁判文书网查看此案（2019）粤03民初3928号一审判决书。
一审判决书：
中国裁判文书网地址
其他网站地址
律师解读
我们邀请专注 TMT 领域的知识产权问题的邓超律师（18611123013）就此案件做相关解读。后续邓超律师将发表深度解读文章，敬请期待！
问题一：此案对后续有关开源软件版权纠纷案件有何具体参考意义？
这个案子据我所知，被告上诉了，所以现在这个判决还没有生效，最后法院怎么认定，还没有最终定论。
但毫无疑问的一点是，违反许可证的义务是会遭到权利人的侵权索赔的。
因为以往国内开源主要是拿来主义，使用国外的代码比较多，但随着国内开发者的不断成熟。将来相关的纠纷会越来越多，这就要求法务和开发人员了解开源的相关问题。
问题二：为什么此案件中，“点心桌面”未被强制开源？
没有要求强制开源是因为原告没有提出这样的要求，那么法院是一个被动的审判机关，不告不理，只被动审理原告提出的请求。
在这个案件中，原告没有选择合同，也就是许可证违约，而是选择了版权侵权这条救济途径。一般而言，版权侵权要比合同违约的救济力度要大，无论从各个方面，这在国内和在美国都是如此。
问题三：如果原告提出了开源的诉求，会如何？
如果原告选择了合同违约这条途径，法院是不是会支持被告将代码强制开源这个问题其实很值得探讨，我个人初步的观点是，法院不一定会支持这种诉请。关于这个事情，我准备近期写篇文章，但我现在初步的看法是要求代码强制开源，在法院不太可能得到支持。所以，如果违反 GPL 许可证的义务，那么将代码全部开源，更多的是一种理论上的可能。在实践中，以中国和美国的法院为例，我理解支持这种诉求的可能性都非常低。
延伸阅读
GPL 解读文章：
GPL风波录
人话解读GPLv3
BSD开发者眼中的采用了GPL授权的Linux
意大利法院判定开源协议条款可强制执行
2021年12月13日，意大利威尼斯法院在一起涉及 GPL（也许是最知名的开源许可协议）的案件中，低调地确认了开源软件许可协议的法律可执行性——这将成为其国内的一个判例(test case)。
这起案件的原告是总部设在意大利的有限责任公司 Ovation，被告是 Ovation 的两名前雇员，涉及到的项目则是 Ovation 开源的 Dynamic.oo——采用了 GPL 开源许可协议。Dynamic.oo 是用于构建 WordPress 网站的开源 Elementor 平台的插件。
根据 Ovation 的介绍，由于 Dynamic.oo 是开源软件，因此被告方及其公司在获得项目源代码的前提下重新分发了 Dynamic.oo，此操作是符合 GPL 要求的。但问题在于被告方重新分发该软件时，没有包括对原始作品的确认，没有提供有关被告对软件所做更改的信息，也没有提及该软件的版权所有者。简单来说就是被告方在没有遵守 GPL 的情况下分发了 Dynamic.oo。
Ovation 补充道，被告的非法行为还包括无视法院发出的正式终止通知。经过审判，法院除了命令被告在软件满足许可协议要求之前停止分发软件外，还规定了被告延迟执行判决结果的罚款。最后，原告的诉讼费用由被告承担，其中赔偿总额为 5.000 欧元，支出为 545,00 欧元，以及 15% 的一般费用，包括增值税和注册会计师聘请费用。
再回到案例本身，有人对法院的判决有疑问，因为按照原告的说法，法院只是命令被告从他们的产品中删除侵权代码以满足 GPL 合规，而不是命令被告通过发布修改后的源代码来满足 GPL 要求。
GPL 转闭源违规？法院判决：一日 GPL 终生 GPL
2022年1月上旬消息，接上文，在2021年一起关于 GPL 版权纠纷案的裁判文书公示引起了开源界的广泛关注。该判例出自深圳中级人民法院，明确了 GPLV3 协议的法律效力，其被告因使用 GPL 相关软件但未向公众无偿开放源代码，而被判赔偿 50 万元。
无独有偶。另一起类似案件发生在广州，这次案件的原告依旧是济宁市罗盒网络科技有限公司（以下简称：罗盒公司），案由依旧是侵害计算机软件著作权纠纷，而被告变为广州市玩友网络科技有限公司、深圳冠准航科技有限公司、深圳奥斯坦科技有限公司和祥运实业（深圳）有限公司（以下简称：玩友公司等），且被告又被判罚了 50 万元。
该案件可谓十分精彩：2019 年 3 月 4 日，广州知识产权法院立案，于 2020 年 11 月 3 日公开开庭审理。罗盒公司起诉玩友公司等侵害罗盒公司的 VirtualApp 计算机软件著作权中的复制权、发行权、信息网络传播权，要求立即停止侵权行为的同时，索赔 1500 万元经济损失。
罗盒公司给出的理由是：罗盒公司于 2017 年 11 月 8 日取得“罗盒（VirtualApp）插件化框架虚拟引擎系统[简称：VirtualApp]V1.0” 的计算机软件著作权登记证书，依法享有 “罗盒（VirtualApp）插件化框架虚拟引擎系统 [简称：VirtualApp]V1.0” 著作权的全部权利。为便于 VirtualApp 的推广和许可，罗盒公司在国际知名的软件托管平台 GitHub 上公开了 VirtualApp 的源代码，并声明任何人如需将 VirtualApp 用于商业用途，需向罗盒公司购买商业授权。罗盒公司在本案中主张权利的软件为 GitHub 上 VirtualApp 的 2017 年 12 月 30 日版本。
简单来说，原告认为 VirtualApp 是他们“私有的”知识产权，虽然我们以前在 GitHub 上是开源的，但现在不是了，商用要交钱。
被告玩友公司辩称：
首先，罗盒公司不是涉案软件的著作权人，根本无权诉讼。
罗盒公司诉称拥有著作权并提供对比鉴定的计算机软件代码，系托管在GitHub上的开源项目 VirtualApp的VirtualApp-master 版本源代码。该开源项目参与编写源代码程序的人数多达 32 位，项目人 aslody 仅为著作权人之一。
其次，VirtualApp 原项目是在 GPL 许可证之下，罗盒公司分叉出来再闭源，所谓“私有”本就存疑。
VirtualApp 项目为适用 GNU 宽松型通用公共授权许可协议第三版（GNU Lesser General Public License Version 3，以下简称 LGPLV3 协议）的开源项目，后修改为 GNU 通用公共授权许可协议第 3 版（GNU General Public License Version 3，以下简称 GPLV3 协议），VirtualXposed 即为 GitHub 上的开发者“tiann”等人，延续适用 GPLV3 协议（2016 年 9 月 10 日添加），同期在 VirtualApp 开源项目和 epic 开源项目的基础上发布的新免费开源项目。
被诉侵权软件的沙盒分身基础框架代码是在 VirtualXposed 开源项目 Xposed 分支2018年1月10日适用 GPLV3 协议开源免费发布的 VirtualXposed-ff32bb8ed7ad10022620c1fb56cfedc6b2e1b355 开源版本基础上自主研发而成。
VirtualApp 项目人 aslody （罗盒公司申请专利的项目管理者）罔顾社区其他开发者的贡献及相应著作权权利，将开源项目据为私有并进行大肆敛财，违背开源社区的基本准则。
无论 VirtualApp 项目代码还是 VirtualXposed 项目代码，均无任何质量担保，且仅可实现沙盒分身基础功能。
法院认为：
1、罗盒公司是否为涉案 VirtualApp 软件的著作权人，且有资格起诉？答案：是。
本院对此认为，首先，罗盒公司的股东罗迪作为项目管理人于 2016 年 7 月 7 日将 VirtualApp 初始版本源代码（首次提交 507 个文件，共 31097 行）上传至 GitHub 官网开源发布，这是罗盒公司主张权利的基础，也是整个涉案软件的核心基础。贡献者提交的代码是在此基础上不断升级优化，贡献者提交的代码能否并入涉案软件主分支由项目管理人决定，项目管理人提交的代码量占整个涉案软件代码量的绝大部分，因此其他贡献者提交的代码并未对涉案软件著作权产生实质影响。
其次，判断是否为合作作品应考虑以下因素：作者为两个或两个以上、主观上有共同进行作品创作的合意、客观上有共同创作作品的行为、合作作者贡献了独创性的表达。涉案软件源代码的提交者包括项目管理者和贡献者，而贡献者提交代码的流程是先由贡献者发起拉取申请，经项目管理者同意后才会并入主分支中，显然双方存在共同创作的合意，这也符合软件源代码开源的本意，即通过互联网媒介，集合全球开发者的智慧，尽可能使软件最佳化，从而促进知识的传播。实际上，涉案软件的提交者亦包括管理者和众多贡献者。
但是，玩友公司并未举证证明贡献者提交的代码是否属于有独创性表达的创作，仅根据贡献者提交的代码行数无法判断其是否有独创性。因此，就在案证据无法认定涉案软件属合作作品。
再次，涉案 VirtualApp 适用了LGPLV3 协议或 GPL V3 协议，那么其他贡献者在申请将其代码合并入主分支时默认同意适用 LGPL V3 协议或 GPL V3 协议，即同意将其代码开源贡献给项目管理者和其他用户在授权许可协议范围内自由使用。
开源软件项目的贡献者往往人数众多，互不相识且散布于全球各地，只要项目保持开源则贡献者数量会持续动态地增加。即使涉案软件属合作作品，就在案证据难以查清所有权利人的基本情况下，若开源项目要求必须经过所有贡献者的授权才能提起诉讼，那么将导致开源软件维权无从提起。因此，本院认定，罗盒公司作为提交了绝大部分代码量的项目管理者提起本案诉讼亦无需经过其他贡献者的授权，有权单独提起本案诉讼。
2、罗盒公司是否有权在 GPL V3 协议中加入商业使用限制保留？答案：没有。
本案中，罗盒公司确认其主张的涉案软件 2019 年 12 月 30 日版本与撤回 GPLV3 协议即 2019 年 10 月 29 日前的版本差别不大，因此本院认定罗盒公司主张权利的版本仍属于适用 GPLV3 协议的开源软件。
罗盒公司无权加入商业使用限制保留条款。罗盒公司的商业使用限制保留条款对于用户使用其源代码的目的进行了限制，从而也限制了用户范围，即只有非商业用途的用户才可以使用其源代码，这显然与 GPLV3 协议的“著佐权”特性矛盾。
3、被告侵权了吗？答案：侵权了，但被侵权的是 GPLV3。
即使被诉侵权软件中的被诉部分源代码来源于 VirtualXposed 开源项目 Xposed 分支 2018 年 1 月 10 日版本，但 VirtualApp 项目从 2016 年 6 月起至 2017 年 12 月的每次提交更新均有同步到 VirtualXposed 的 exposed 分支中，且 VirtualXposed 保留了 GPLV3 协议，因此本院认定，被诉侵权软件仍应适用 GPLV3 协议。
关于这个案例更多详情，大家可以访问这里详细了解，里面还有更多重点。
从开源角度看，这次案件不但再次明确了 GPL 的法律效力，而且还提出了一个“华点”：GPL 许可证之下的开源项目，可以分叉出来闭源吗？对此，《大教堂与集市》的中文译者卫剑钒发表了自己的观点：
首先，开源项目私有化，要征求所有作者同意。
这涉及的关键问题是：罗盒能不能把多人共同创作的 VirtualApp 闭源为自己的商业版？我认为，从严格意义上讲，是不可以的（虽然可能确实有超过90% 的代码都是 asLody 完成的）。
如果罗盒是 VA 的唯一作者，私有化没问题，当然可以。（参见我对“风灵案”的解读文章）但罗盒并非 VA 的唯一作者，如果要私有化，就要征得所有作者同意，而且还要把商业版收益分给所有作者。
这在我国著作权法实施条例中说得很清楚：《中华人民共和国著作权法实施条例》第九条规定：“合作作品不可以分割使用的，其著作权由各合作作者共同享有，通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让以外的其他权利，但是所得收益应当合理分配给所有合作作者。”
在VA按照GPL开源期间，有 30 多位贡献者，这些贡献者，每人都拥有部分版权（著作权）。由于罗盒与贡献者并没有签单独的协议（GitHub 上没有，也未在历次官司中出示），按照 GitHub 用户协议，贡献者们仅仅是将代码按照 GPL 授权给罗迪（罗盒）使用，而没有将著作权送出。
其次，用了 GPL，就永远是 GPL，不能加额外限制，GPL 衍生程序不能闭源。
众所周知，GPL本身就是一种授权，授予用户对开源软件的免费使用，现在罗盒又说要使用者购买授权，这不矛盾了吗？按哪个算？其实GPL在第7条里面明确说了：“如果你接收到的程序或其部分，声称受本协议约束，却补充了这种进一步的限制条款，你可以去掉它们。”
GPL 是不允许衍生程序闭源的，VA 的商业版也必须按照 GPL 继续开源。
详情可查看卫 Sir 的文章《再看中国法院是怎么对待 GPL 的》，卫 Sir 还在文章中阐述了GPL 并不限制商用、GPL 的强传染性等观点。
另外，企查查显示，济宁市罗盒网络科技有限公司涉及的司法案件共 6 起，其均是原告，且都是针对 VirtualApp 的侵权案件。另外两个被告分别为：北京链安网络科技有限公司和厦门量子堆栈科技有限公司。其中针对北京链安网络科技有限公司的诉讼已结案，被告被判赔偿 10 万元经济损失。而针对厦门量子堆栈科技有限公司的案件，因为原告提供的被告的住所等信息不具体明确，属被告不明确，被驳回。
该文章最后由 阿炯 于 2022-01-13 11:07:26 更新，目前是第 3 版。