新趋势下GPL、Apache等协议的商用及二次发布问题，从罗盒侵权案说到华为HMS

在这篇文章中，作者将从开源协议的本质出发，将协议整体分类为两大协议族，通过对相关侵权案例与近期事件的分析，深入浅出地为开发人员讲解当下GPL、Apache等主要开源协议商用及二次发布的核心问题，希望这篇文章能成为国内开发者在新趋势下的开源明灯。

1. 开源协议的本质

截止目前，有被声明的开源协议大概有100多种，这些协议中有大家熟知的GPL/LGPL/Mozilla/Apache/BSD/MIT等，也有一些小众协议比如之前的RL(react license)、EPL(eclipse public license)，还有些大家可能连名字都没听过。

面对五花八门的开源协议，要分成两类难度还是蛮大的，因此必须要了解协议的本质。那么开源协议的本质到底是什么呢？其实就是开源者发布开源项目的目的和原则，也就是我作为发布者究竟想干啥，大家的游戏规则是啥。

目前，虽然开源协议在国内已经“普及”了很长时间，但依然有诸多不同程度的侵权行为，究其原因还是西方开源的兴起实际上是建立在契约规则上的，对开源协议的遵从原则上需要参与者具备契约精神，不能违背发布者的意愿。那么从这个意义上讲，对开源协议的侵权实质上也就是违背了开源协议的原则和意愿。

2. 开源协议的分类

国外普遍认同的两大协议族归类标准是NonPermissive licensing（简称NPL，非宽松协议）和Permissive licensing（简称PL，宽松协议）；有很多文章也称CopyLeft协议（严格协议）和Non-CopyLeft协议（非严格协议）。这里作者在本文中采用NPL和PL分类，两者在某种意义上所涵盖的要稍广一些。

3. NonPermissive licensing（非宽松协议）

国外著名的开源服务OpenLogic对NonPermissive licensing的定义如下：

Software that comes with nonpermissive licenses enforces freedom with software.

字面意思就是使用该开源软件必须保证用途是自由软件。很明显NPL发布者的目的就是为了推广自由软件，怎么个推广法？就是你的软件使用了我的软件，那大家都成了自由软件（同时必须开放源码）。这种推广具有传染的特性，对三方软件（如商用软件）也不友好，但这就是GNU先辈们自由精神驱动的游戏规则，目的就是为了做大自由软件，也是NPL协议的本质，GPL/LGPL/Mozilla都属于NPL协议。

4. NPL侵权案例（商用问题）

NPL侵权事件很多，当年最有名的就是暴风影音、QQ影音等GPL侵权事件。

历史案例：暴风影音等几款影音软件GPL侵权事件（2009年）

事件过程大体是当年这几款影音软件在日常使用中出现了一些同质bug，用户深入分析后发现这些软件都使用了ffmpeg的核心代码和解码器，于是他们各自向ffmpeg组织进行了举报，ffmpeg查清后这几款软件最后都一起上了GPL耻辱柱。

近期案例：罗盒网络GPL转闭源案例（2021年7月）

此案是最新的GPL侵权案例，判决也具有风向标的作用。

案件如下：

原告：济宁市罗盒网络科技有限公司

被告：福建风灵创景科技有限公司(简称福建风灵公司)

被告：北京风灵创景科技有限公司(简称北京风灵公司)

原告济宁市罗盒网络科技有限公司独立开发“罗盒（VirtualApp）插件化框架虚拟引擎系统 V1.0（简称 VirtualApp V1.0）。VirtualApp 从 2016 年 7 月 8 日的版本开始引入开源协议，起初为 LGPL3.0 协议，2016 年 8 月 12 日更换为 GPL3.0 协议。2017 年 10 月 29 日，原告公司在 VirtualApp 后续开源版本中删除“适用 GPL3.0 协议”的表述。

2017 年 11 月 8 日，原告公司为 VirtualApp V1.0 取得计算机软件著作权登记证书，依法享有 VirtualApp V1.0 软件著作权的全部权利。

2017 年 12 月 30 日由 原告公司股东、VirtualApp 项目人罗迪（Lody）提交更新，声明VirtualApp将于2017 年 8 月份正式公司化运作。

2018 年 9 月，原告调查发现名为“点心桌面”的软件使用了 VirtualApp V1.0 的代码，于是向法院起诉，庭审时明确诉请为判令如下：

1.被告福建风灵公司、被告北京风灵公司立即停止侵害原告的计算机软件著作权，即立即停止通过互联网提供所有版本的“点心桌面”软件的下载、安装和运营服务；

2.被告福建风灵公司、被告北京风灵公司赔偿原告经济损失 2000 万元；

3.被告福建风灵公司、被告北京风灵公司赔偿原告为制止侵权行为而支出的合理费用 50 万元。

法院立案后，经查被诉“点心桌面”App(V6.5.8)中使用了原告采用 GPL3.0 协议发布的VirtualApp。将两个软件源代码进行分析比对，两者间 421 个可比代码中有 308 个代码具有实质相似性，有 27 个代码具有高度相似性，有 78 个代码具有一般相似性。因此，被诉侵权软件与涉案软件构成实质相似。

据本案的判决书显示，GPL3.0 协议是一种民事法律行为，具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。

本案的判决书明确了违反开源软件许可证的侵权法律责任，一方面可以及时制止侵权行为，防止他人对开源软件的不正当利用；另一方面能够有效保护授权人的利益，使他们保有继续创作的动力，促进源代码共享和知识的传播。

此案的宣判，实际上标志着GPL协议在国内已经成为某种意义上的法律性著作合同，既然已经上升到了民法高度，其约束性就无需多言了。以前商业软件的发布，可以将GPL软件分割成完全独立的部分来嵌入并绕过协议，比如将GPL软件打包成独立运行库。目前看来，这种打擦边球的方式可能会逐渐失效。

5. Permissive licensing（宽松协议）

下面再来看Permissive licensing，OpenLogic的定义如下：

Permissive licensing is a form of open source licensing that allows a person or company to use that software to create products that require a paid license。

明面意思就是说PL发布者允许个人或公司使用该开源软件开发付费产品。这里指的产品就是大量来自商业的、知名的、闭源的产品，所以PL发布者的目的其实就是为了让自己的软件被更多产品使用，希望自己的软件嵌入到大量产品中，是对三方产品友好的。因此无论你怎么修改代码都行，我也不要你改的东西，只要在你的产品里为我留个名就行了，当然重点也就在最后一句话。这也是PL协议的本质，Apache/BSD/MIT都属于PL协议。

6. PL侵权事件（商用及二次发布问题）

历史事件：绿坝“盗用”OpenCV事件（2009年）

2009年，上网过滤软件“绿坝-花季护航”(简称绿坝)名声大噪后，引起了国际社会的关注。美国密歇根大学的一位教授称绿坝侵犯了开源协议，另外一家名为Solid Oak的美国公司则表示绿坝侵犯了其知识产权。

同年6月12日，美国密歇根大学计算机科学与工程系J. Alex Halderman教授发表了一份绿坝分析报告，指出绿坝违反了开源协议。Halderman在报告中分析，绿坝主要用于不良图像过滤的文件cximage.dll、CImage.dll、xcore.dll和 Xcv.dll均来自OpenCV。OpenCV是Intel资助的一个开源的计算机视觉库，它有一系列C函数和少量 C++ 类构成，实现了图像处理和计算机视觉方面的很多通用算法。

OpenCV中国的项目负责人此前向媒体表示，他检测后发现，绿坝的核心识别程序文件XFImage.xml完全来自OpenCV的 haarcascade_frontalface_alt2.xml，绿坝只是将源文件中的版权信息删除，内容跟OpenCV提供的文件完全相同。

当年OpenCV采用的是BSD许可证，后来变更为Apache2。这两种协议，当商业软件使用其开源程序时，都需要在软件版权信息中加上许可证声明，绿坝并未在其软件中加入这一声明。（事后做了更正）

这里，Apache2协议是目前PL协议族中应用最广泛的，许多高质量的开源项目都采用了Apache2，而这些开源项目也特别受商业应用的青睐。国内很多大公司的项目都不同程度集成有使用Apache2协议的代码，而在集成过程中像绿坝这种事件也多是由于使用者对Apache2协议不了解导致的，进而忽略了许可声明，因为如果是故意盗用的话，必然会篡改文件名，甚至修改代码，这对于绿坝来说完全没必要，没人会相信你为了开发个绿坝应用，自己从头开始去做套OpenCV。

与应用软件不同的是，目前国内公司出现了很多基于开源并对外发布的开发组件，这些组件包括各种SDK、运行库、服务等等，大部分都是闭源或半闭源的。这主要来自近几年国内公司对自研技术需求的增长，从而越来越依赖那些高质量的开源项目。于是，基于可闭源这个特性，PL协议项目就成了不二之选（NPL协议项目必须开源），而名义上大家都是“参考”，其实很多都只是改头换面，二次发布而已。

此前有媒体报道过一些互联网大厂非法二次分发基于Apache2协议的运行库，但大部分其实都是在大项目中嵌入了修改的开源组件，性质上和绿坝事件区别不大，被发现后也就大方承认，一般做个道歉并补份声明就行了，还能彰显大厂风范。甚至在某些商业应用中，使用的外围组件也只需在相关开发者间声明一下就可以了。因为上面说过，PL协议项目的发布者是希望外围产品使用自己软件的，本质上并不会为难大家，条件是需要附上许可证声明。

7. PL协议族真正的威胁

通过以上分析，大家已经明白PL协议项目确实是对产品友好的。然而，如果有三方直接拿Apache2协议的运行库进行二次修改后独立发布呢，那还是友好的么？那完全就是另一回事了。

根据目前开源协议日趋等同于著作权协议的特性，这种行为实质上也等同于侵犯了软件著作权，是一种演绎作品侵权，这种侵权对PL协议族可以构成实质性的威胁。

这里的演绎作品，是指“从原作品中派生出的新作品。这种派生作品中虽然有后一创作者的精神成果，但又并未改变原作创作思想的基本表达形式。”，按照我国的著作权法，如果其他人未经原作的著作权人许可而改编其作品，该行为已经违反了著作权法，是对原作著作权人专有权利的侵权行为。

目前无论国内还是国外，对软件演绎侵权的共性基本可描述为：在知晓他人程序代码的情况下，不改变他人程序的设计，而将其程序中的变量（函数）、顺序、处理流程加以改变或者用另一种编程语言改写，导致俩软件之间的程序相似而代码不同，实质上后一程序是前一程序改头换面的复制品。尽管改头换面后的程序代码与原作似乎有很多不同甚至完全不同，但其行为依照国内外法规关于演绎作品的规定（在我国是著作权法）已经构成了对他人软件程序版权的侵害。

这里必须要重点讲述上个月的一个事件，事件涉及到华为HMS Core中一个“开发”了近三年的Kit，在新版发布后不久就整体下架。

近期事件：华为"下架"CGKit事件（2022年4月）

事件经过大概是这样的，今年3月底，有开发团队在编写代码时发现接入的HMS CGkit与自家基于gameplay开源引擎的项目产生了二义性冲突，深入后挖出CGKit接口与gameplay存在很大程度的相似性。到了4月份，一名资深游戏开发人员，在某开发群发了一篇分析文章链接，并希望代发到官方论坛，之后消息不胫传入华为内部，为规避风险，华为随后将CGKit“下架”（实际是改名）。

这篇分析文章的重点部分原文如下：

“ 大家好，我要说下这个CGKit的Rendering框架明显是在gameplay framework上抄改的，vulkan部分也是参照了Khronos官方的vulkan-sample。

看下CGKit与gameplay核心3d类的对比，上边来自CGKit Rendering Framework的官方文档，下边来自gameplay framework src, 加了两个vulkan-sample的component，看一眼就知道像不像了。

类名大多是直接搬砖的，也有增删后缀、还有英文同义词。下边的aabb和BoundingBox，sub_mesh和MeshPart是一个意思，小写的来自vulkan-sample，大写的来自gameplay。

CGKit团队好像改了不少gameplay代码，类成员函数名基本被改了，但类名却大量保留，很多Class Summary没给出的gameplay类名，比如Frustum和Texture，在其他类的成员方法中都有。还有那个所谓的CGMAT格式也是gameplay的material脚本改改格式符而已。

反正无论咋改吧，抄作业终究还是会露马脚的，在Plane类中有个方法CGKit和gameplay就几乎一样，看一眼就知道了。gameplay标志特征就是这个Set，这种直接拿Set命名方法的除了gameplay没谁了。

还有就是CGKit团队完全没搞懂啥是SubMesh，强行将gameplay的submesh(meshpart)改成mesh集合，去年很后面才改回来。SubMesh在业内是有定义的，指的是Mesh顶点集的某个索引区间。”

至此，gameplay作为黑莓知名的开源产品，使用Apache 2.0协议，而且官方特别声明了这是个framework，也就是说，原则上哪怕你仅仅参考了gameplay的框架，也必须遵从apache2协议，而不声明又想极力掩盖却做不到更好的行为叫什么，那就是剽窃。

据了解，之前华为CGKit项目的"负责人"叶仲正，曾于蚂蚁金服任职了大半年时间，职级P7，期间接触过当年Buy+基于gameplay二次开发的引擎代码。阿里前就职于腾讯，据腾讯相关人士确认，叶在腾讯只是某游戏项目组一名普通的开发工程师。而从2019年开始，有猎头注意到此人在领英等平台上持续更新的假简历，自称“领导”过腾讯游戏引擎等开发，并且还坎掉了阿里工作经历，后被多方举报。

这个事件中，其他的我们不说，实际上开发团队已经修改了很多代码，然而为什么最后还是出了问题？原因就在于哪怕你看明白了原作的思路和结构，想要用自己的表达再重新“创作”一遍，那难度也是很大的，除非你能从更高维度来理解作品，不然久而久之还是会绕回到原作的森林中；要想不陷入原作的漩涡，就需要做到在理解的基础上，通过分析问题本质进行必要创新，那这样还需要演绎么？直接创作出新作超越就可以了。

因此这里也希望国内的开发人员对于优秀的开源项目，必须时刻抱有学习的态度，不要太急功近利，毕竟没拿到金刚钻，是揽不了瓷器活的。当然更不能钻空子使坏，虽然版权著作权只保护作品表达，并不保护作品构思，但当你看了原作想重新表达时，就很有可能到最后变成了演绎侵权。而侵犯软件著作权上升到刑事高度的话，最高是可以判七年以下有期徒刑的。

8. 总结

最后，拿一张10年前国外大佬的开源协议流程图，稍加说明做个总结。

这里左边三个协议（许可证）修改源码后必须开源，就是NPL协议（CopyLeft协议）；而右边三个协议是可以闭源的，就是PL协议。也就是说左半图对商业软件实质上并不友好；而右半图对商业软件则是友好的。对于开发者而言，无论是商业软件还是开发组件，亦或是二次开源，违反了不友好的协议产生的后果可能很严重，而隐藏更深的是，如果有目的地把别人的友善当成自己肆意的资本，那后果或许更严重。