看看中国法院是怎么对待GPL协议的

Posted 2021-12-15 vigor2323

深圳市中级人民法院于2021年6月30日发布的那篇判决书¹可真是太好看了。

之所以我觉得好看，是因为里面连篇累牍地、深入细致地分析了GPL3.0协议，并给出了很多论断。

建议对GPL感兴趣的都看一看。

此案原告是罗盒网络科技公司（以下简称“罗盒”），被告是风灵创景科技公司（以下简称“风灵”）。

原告和被告之间的较量，针锋相对，一波三折，几乎把所有常见对GPL的误解都展现出来了。

判决书有几个地方让我印象深刻：

1、法院使用的GPL中文译本出处令人困惑。

2、法院明确认可GPL是合同。

3、法院认定风灵用的是开源软件，原本可以不赔钱的，但风灵反而败诉。

4、明确了贡献者的角色定位。

5、法院认定“作者不能在后续版本更换作品所用的GPL协议”，但我觉得不对。

下面仔细看一下。

注：在本文中，GPL3.0和GPLv3等义，有时简单以GPL指代。

一、关于判决书引用GPL翻译版本的问题

显然，大家都知道GPL3.0是用英文写的，但判决书引用GPL原文的时候，都是中文。

GPLv3有多个中文翻译版本，深圳法院引用的是哪个版本呢？

判决书第三章中说，原告委托公证处登录www.fsf.org并点击“GNU GPL”进入相关页面，得到GPL中文翻译。

但这有两个问题：

1、FSF明确说了：“FSF不批准许可证的翻译正式有效²。”，那么法院用的这个就是FSF并不认可有效的版本，不过我觉得这没关系，FSF根本没有认可的翻译版本，而我们在中国，判决书总要用中文的嘛！既然FSF官网上放了中文版翻译的链接，就表明“认为它的内容应该基本是正确的”。

这个中文翻译链接是阮坤良在2007年翻译的那个版本³。FSF说：“为了强调这些翻译并非正式有效，我们只是放了翻译的链接，而不会将其内容放在我们的网站上。”

2、最让人想不明白的的是，判决书列出的GPL中文翻译和FSF所放链接中的中文翻译并不完全一致，但相似度非常高。我看来看去，觉得法院所用版本是在阮坤良版本的基础上修改而得，但不知为什么要改。

二、关于对GPL的认可

判决书上这段说的非常明白了，写得非常好，一句话说：GPL就是合同！

判决书说：“开源软件依赖于现有著作权及相关法律体系的保护，授权人只在享有著作权的情况下，其通过许可证将权利有条件进行许可或让渡才有法理依据。关于GPL3.0协议的法律性质。其一， 协议的内容具备合同特征。GPL3.0协议属于发生私法上效果的意思表示，而意思表示是民事法律行为的核心要素，因此GPL3.0协议是一种民事法律行为。该协议授予用户复制、修改、再发布等权利，实际上在授权人和用户间形成了权利变动，属于设立、变更、终止民事权利义务关系的民事法律行为。授权人许可的权利符合我国著作权法的相关规定;其采用开源许可证发布源代码，将自己的大部分著作权授予不特定用户，完全是出于自愿。用户在许可证下复制、修改或再发布源代码，通过行为对许可证作出承诺，也是出于自愿。用户在对源代码进行复制、 修改或发布时许可证成立，同时许可证发生法律效力。其二，协议的形式亦具备合同特征。GPL3.0协议以电子文本方式表现其内容，而电子文本是一种有形的表现形式，属于以书面形式 订立的合同。综上所述，GPL3.0协议具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。”

三、法院认定风灵用的是开源版本，但风灵违规了

这里要说一下案情了：

罗盒在GitHub上开源了软件VirtualApp（以下简称VA），使用GPL许可证。但是后来，罗盒删除了GPL授权，同时又声明，不得用于商业用途，除非购买商业授权。

风灵使用了VA，做了一个“点心桌面”APP。罗盒控告风灵侵权，要求赔偿2050万元。起诉的理由是风灵没有付款，就将代码用于商业用途。

风灵为自己辩护，宣称自己使用的是VirtualApp的GPL开源版本，不是商业版本，而GPL是允许商用的，所以没有侵权。

罗盒认为，VitualApp已经不再是开源软件了，因为已经不再使用GPL了。

法院认为：即便删了GPL，VA还是开源软件。

对于这个判决，风灵是高兴的，但没想到，由于风灵没有把“点心桌面”开源，违反了GPLv3的第8条，所以GPL授权失效。

GPL第8条：你必须严格遵守本许可证，才能传播和修改本作品，如果违反本许可证，本许可证授予你的权利全部自动中止。

所以，风灵得到的授权又没了。

判决书是这么写的，我觉得写得很好，一句话：该开源你不开源，所以你的GPL授权没了，你还是侵权！

以下是判决书原文：

经查，被诉“点心桌面”App(V6.5.8)中使用 了原告采用GPL3.0协议发布的VirtualApp，被告对此亦予以确认。根据GPL3.0协议第5条第1款c 项、第7条和第10条规定的相关内容及“强传染性”特征，对在逻辑上与开源代码有关联性且整体 发布的派生作品，只要其中有一部分是采用GPL3.0协议发布，那么整个派生作品都必须受到 GPL3.0协议的约束。一项遵循GPL3.0协议的源代码不能同非自由的源代码合并。因此，被诉“点心桌面”App(V6.5.8)应当遵循GPL3.0协议向公众无偿开放源代码。被告福建风灵公司辩称未实质性修改所使用的开源代码，故无需公开“点心桌面”App(V6.5.8)的源代码缺乏理据，本院不予支持。综上，被告福建风灵公司使用了附带GPL3.0协议的开源代码，却拒不履行GPL3.0协议规定 的使用条件。根据GPL3.0协议第8条自动终止授权的约定及《民法总则》第一百五十八条的规 定，被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵 公司对VirtualApp实施的复制、修改、发布等行为，因失去权利来源而构成侵权。

四、一日GPL，终生GPL？

有一点，我觉得深圳市中级人民法院对GPL的理解是有问题的。

罗盒和风灵最重要的争执焦点在于：罗盒认为github上的那个VA不是开源的，但风灵认为是开源的。

判决书支持风灵，判决书说：

针对原告在VirtualApp后续开源版本 中删除“适用GPL3.0协议”的影响。经查，VirtualApp从2016年7月8日的版本开始引入开源协议， 起初为LGPL3.0协议，2016年8月12日更换为GPL3.0协议。2017年10月29日，原告在VirtualApp后续开源版本中删除“适用GPL3.0协议”的表述。根据GPL3.0协议第4条、第5条的规定，只要后续版本中有使用先前开源版本中的源代码，并且先前版本使用了GPL3.0协议，则后续版本也必然受GPL3.0协议的约束。因此，VirtualApp后续开源版本仍然受GPL3.0协议的约束。授权人与用户在行使权利、履行义务时均应遵循诚实信用原则，恪守协议的约定。 

我认为，这个理由显然不成立。

GPL第4、5条大致说的是，你用我的代码，不管你改还是不改代码，你都必须还是用GPL发布。

合同，是甲方（作者）和乙方（使用者）签的。

GPL协议就是一个合同，这里面的“你”，就是甲方给乙方说的话。

甲方说“你必须干什么，你不能干什么”，是约束乙方的，怎么会成为约束自己的东西呢！

作者最大，作者可以授权别人，作者也可以决定从某个版本开始不再授权他人。（先不考虑贡献者的问题，假设代码都是作者的）

如果说作者用了GPL，作者就不能改别的协议，那还有哪个作者愿意用GPL呢，再说，我们常见的双重授权：“GPL授权、商业授权并存”，岂不是也违背GPL要求了？

更严重的是，如果这么说，罗盒把VA改成商业协议，也是不对的咯。

我认为，如果罗盒在2017年10月29日之后发布了有实质性新增功能的新版本，那么风灵确实不能把新版本当GPL开源软件来用了。

但，罗盒在2017年10月29日之后并没有发布什么新版本，查看其github上的代码⁴，可以看到，自2017年10月29日，虽然还有一些零星的bug修补，但基本没有什么实质性的代码新增了（2018年6月8日之后，代码就再没有任何更新了）。

所以，这些改动只能看作是对VA开源版本的一些修修补补，并没有什么新版本。

五、曾经的授权，不可撤销。

罗盒在VA项目github的首页上明确说到：

“Github上代码已在2017年12月份停止更新，商业版代码在持续更新中，如需授权获得最新代码，请联系微信：10890 ”

根据这句话，结合其代码差异，可以看出，目前Github上的VA就是当年使用GPL开源的版本，商业版本根本就是不给公众开放的。

所以，Github上那个人人都可以看到的VA，就是那个用了GPL后来又取消了的VA。

而GPL第2条规定：

GPL的授权不可撤销。

GPL全文解读详见《人话解读GPLv3》

“不可撤销”（irrevocable）就是一旦给了你授权，我想反悔都不行的，给了就是给了，我反悔也没用。

这是GPL对甲方（作者）的几乎唯一约束，别的都是说“你不能”，这个是说“我不能”。

说的直白明了一点，罗盒虽然把VirtualApp的GPL授权声明撤下，但曾经给出的授权还是有效的。

风灵说自己用的是Github上2017年8月16日的版本。所以风灵获得的授权不可撤销。

所以，法院用第2条说明这个问题是比较好的，而不是用第4、5条。

六、关于贡献者的权利

还有一点比较有趣，就是风灵认为，罗盒提起诉讼，需要VA的其他贡献者授权。

风灵说：“该软件显名的作者达到34人。……大量使用了他人的开源代码。原告没有提供任何证据证明这34个作者都将著作权转让给其行使，也没有提供任何证据证明其他开源代码的作者允许原告将代码整合并进行商业化使用”。

判决书先分析了谁是VA的贡献者：

“Github网站的注册用户或者游客皆可以获得该软件的源代码，而网站的注册用户有机会根据自己的意愿将修改内容上传“提交”，并向项目人发出“拉请求”，此时“提交”的有关源代码只存在于用户的“分支”中， 而并不能直接对项目人发布源代码的“主分支”产生修改，若这样的“提交”被项目人认可则项目人可以进行“合并”操作，将“提交”的修改内容用于“主分支”中并形成新的项目源代码版本。借此“提交”被项目人执行“合并”操作的注册用户，成为该项目的贡献者。”

然后，法院认为：

“对此，本院认为:其一，原告股东罗迪作为项目人已将VirtualApp初始版本的源代码共计31097行在Github网站上公开发布，此系原告主张权利的基础。其二，Github网站的用户对涉案源代码作出修改、补充后，若要将相关内容并入项目人的“主分支”中，则需符合项目人的开发意图并由其做出取舍。本案项目人对“主分支”中VirtualApp源代码的形成起到了决定作用，贡献者的内容未对原告享有涉案软件著作权产生实质性影响。其三，贡献者选择在GPL3.0协议的VirtualApp项目中上传自己的源代码，贡献者亦将按照GPL3.0协议许可其贡献，即视为同意将贡献内容许可给项目人及其他用户使用。最后，开源项目的贡献者往往人数众多、互不相识又身居世界各地;且随着项目内容的不断修订完善，贡献者的数量亦处于持续增加、变动之中。若开源项目的起诉维权需经全体贡献者一致同意或授权，实则导致维权行为无从提起。综上，原告提起本案诉讼无需贡献者的同意或授权。 ”

简单地说，法院认为，罗盒作为项目人，可以告，无需所有贡献者同意，因为罗盒对项目源代码起决定作用，而且让所有贡献者都同意并不现实。（最起码罗盒可以就自己写的的代码发起诉讼。）

这里面也有些难缠的问题：

1、从现有信息看，罗盒和贡献者之间并没有签CLA（贡献者许可协议），那么，就只能认为贡献者是按照GPL贡献其许可的，因为GitHub的Terms of Service有说：

“每当您对含有许可证的仓库作出贡献时，您将按照相同的条款许可您的贡献，并且您认可您确实有这样的权利。如果有一个单独的协议来说明这点，例如贡献者许可协议，那么该单独的协议将会取而代之。”

2、如果是这样的话，VA中含有了很多贡献者按照GPL授权给罗盒的代码，根据判决书所认可的“强传染性”，现在的商业版VA，也应该用GPL开源。

有了这个判决，如果以后某个贡献者跳出来，控诉罗盒没有把VA继续用GPL开源，我觉得罗盒可能会败诉。

虽然，贡献者一般不会跳出来。

所以，罗盒如果有先见之明的话，应该早点和贡献者签订这样的CLA：“贡献者同意罗盒可以将代码转为其他协议（包括商业协议）。”甚至可以签这样的CLA：“贡献者同意将所贡献代码的著作权转让给罗盒。”

而本文的第四章，则需要重新审视，因为在这种场景下，罗盒不是甲方了，成了贡献者许可协议的乙方。

七、关于最终判决

简单说，就是三条（非原文，我简写了一下）：

一、风灵立即停止侵害罗盒关于VA的著作权，对使用了VA的“点心桌面”软件立即停止提供下载、安装和运营服务; 

二、风灵赔偿罗盒经济损失及维权合理费用共计50万元; 

三、驳回罗盒的其他诉讼请求。

附录：VirtualApp是个什么软件？

VA是一款运行于android系统的沙盒产品，可以理解为轻量级的“Android虚拟机”，或者理解为一部手机上的“虚拟手机”。VA有这些主要功能：

1、可在VA中安装多个APP。

2、可以实现App双开（多开），就是手机上本来有一个微信，可以在VA里面再开一个（多个）微信。

3、VA对于其内部安装的App具有完全的监控和控制能力，相当于在内部有Root的能力，可任意读写APP进程的内存。可以通过VA清楚的掌握APP访问了哪些系统API，哪些敏感数据，哪些设备信息等。

专家观点

我的朋友知识产权专家孙振华说：

“根据判决中的分析，国内法院认可开源协议的法律效力，权利人可以依据开源协议进行维权和诉讼。随着国家在十四五规划中强调完善开源知识产权和法律体系，企业应当重视开源协议的合规，而个人开发者也应当了解开源协议的基本要求。遵守开源协议，一则可以避免因纠纷产生的经济及名誉损失，二则有助于更高效合规的使用开源软件和参与开源项目。”

文｜卫剑钒

关注本公众号，回复“wenshu”，获取判决书全文pdf版。

---

1. 济宁市罗盒网络科技有限公司诉被告……民事判决书 (https://wenshu.court.gov.cn) 

2. 许可证的非官方翻译(https://www.gnu.org/licenses/licenses.html) 

3. 阮版GPLv3翻译(https://jxself.org/translations/gpl-3.zh.shtml) 

4. VA项目(https://github.com/asLody/VirtualApp)