去年,一起关于 GPL 版权纠纷案的裁判文书公示,引起了开源界的广泛关注。该判例出自深圳中级人民法院,明确了 GPLV3 协议的法律效力,其被告因使用 GPL 相关软件但未向公众无偿开放源代码,而被判赔偿 50 万元。有关详情可查看:《首例!违反 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 万元经济损失。而针对厦门量子堆栈科技有限公司的案件,因为原告提供的被告的住所等信息不具体明确,属被告不明确,被驳回。
从最近Kaker.js删库的案例来说,如果有其他人员一起开发,也是不太合法的,除非全部由他个人全程开发。
比较费事一些。
如果一开始想留一点后手,有后续的开源不开源反悔余地,那一开始就不要选择带有传染性的 GPL 授权协议,应该用 MIT、BSD、Apache 授权协议。