给开源游戏做 mod 也会被传染其 GPLv3 协议吗

[RainZack]

详情 https://www.v2ex.com/t/943895 分发的 mod 是不含开源游戏本体的

我有一位网友（确实不是本人）在游玩 Github 上的一款开源游戏，并通过该游戏提供的方法进行扩展（ extension ，或者通常称为 mod ）开发。该扩展以脚本（即代码源文件）和图片等素材文件打包成压缩包的形式，在他管理的内部聊天群里提供免费下载。

该网友禁止他人将其扩展文件发布在聊天群以外的其它渠道，或在其它渠道提供收费下载（二道贩子）。但由于屡禁不止，所以在论坛发布消息进行谴责并宣布停更。

随即游戏的现 Github 维护者也发布消息，声明游戏遵循 GPLv3 协议，要求所有的扩展也必须遵循协议在 Github 进行开源，且不得禁止他人转载或收费。

我对开源协只能算是一知半解，所以想请教一下：

1. 开源游戏的 MOD 是否也需要遵循游戏本身的开源协议？ MOD 本身不会替换源游戏的任何文件。
2. 扩展文件已经包含了扩展的源代码，这种情况下是否已经相当于开源？
3. 本文的场景下，MOD 作者有无禁止他人转载 /收费的权力？

以上，提前感谢大家

游戏被认出来感觉没必要藏着了，仓库
https://github.com/libccy/noname

[blinue]

我的理解是只有直接引用或修改了源代码才会传染，就 GPL 协议来说，mod 无需开源。但既然维护者声明了 mod 必须在 Github 开源，还是需要遵守的，和 GPL 无关。

[qrobot]

不会但是不能使用开源游戏提供的 sdk, 并且不能自动安装, 需要用户手动进行安装

[ysc3839]

首先建议把上述帖子原文 append 到本帖下面。

关于问题本身，建议看看 GPL 的 FAQ ，正好就有关于插件的解释
https://www.gnu.org/licenses/gpl-faq.zh-cn.html#GPLAndPlugins

[litchinn]

以我对 gpl 的理解，这要看这个 mod 是如何发生作用的，但是感觉大部分 mod 加载机制会造成传染

[RainZack]

对前端不太了解……这个游戏是基于 nodejs 。mod 是通过 api 里提供的 load 方法加载，安装需要准备好扩展文件夹然后在游戏内进行导入

[hez2010]

直接引用 /修改了 GPL 代码或者静态链接了从 GPL 代码编译出来的东西都需要遵守 GPL 代码开源。
除此之外的话就看代码作者自己要不要求你开源了。

[westoy]

看情况吧

比如你要调用它的 api ， 就算你只调用了一行 init_plugin(name)， 也要以 GPL 协议开源， 除非程序开发者把 sdk 抽出来以其他协议发布

但是如果主程序只是遍历扩展目录， 比如判断有没有 xxxxx/.IS_PLUGIN 这个文件， 有就调用 xxxxxx/hook ， 而且 xxxxx/hook 一行主程序都没引入， 这个是可以规避的

[hez2010]

@hez2010 说的不太对，间接引用也算。应该说只要使用了 GPL 的代码（无论是代码层面的使用，还是因为静态链接导致的二进制层面的使用）都算。
动态链接的话不算。

[Trim21]

反正游戏本身是 GPL 开源的，你不如直接说游戏名字我们看看他的插件到底是怎么加载的。。。

[iceg]

无名杀是吧

[Esec]

如果 mod 因为个人原因想停那随便停，特意强调了因为有人倒卖才停的有一定程度上是在暗示准备商业化，原作者发出声明实际上一堆方案可以绕过，只是不想和这个 mod 扯上太多关系，各自精彩吧

[RainZack]

@iceg 好家伙

[muzuiget]

如果分发的不是来自游戏的任何文件，不需要开源。

比如我搞了一个可以在 Unreal 引擎里使用的 3D 模型，我本意是开发给 A 游戏用，而一个 GPL 的 B 游戏也能使用，B 游戏开发者有什么权力要求我开源？

类比 Linux 相当于游戏本体，能在 Linux 上运行的程序相当于 MOD ，那么是不是要所有程序都要开源呢？

实际上的操作就是可以用一个中间层来隔开 GPL 的传染的。

也就是这个 MOD ，其实最差就是把调用游戏 API 那一层的代码开源就完事了，可能就是那个 MOD 的配置文件。

[Mithril]

如果你的 Mod 引用了游戏本身的源文件，比如头文件，那是会被传染的。
不过看你这好像就是个 js ，不直接用官方的文件应该没问题。
另外 GPL 也不能阻止其它人转载，并且拿它收费。GPL 只是要求转载人继续保持开源，并且使用 GPL 协议。想要做到这一点需要的是 EULA ，或者找个 Elastic 这种被认为非 OSI 的 license 。

[Trim21]

@Mithril 看了一下，这个游戏的扩展调用了主程序提供的 API 。

[Trim21]

看了一眼插件和插件加载方式，按我对 GPL 的理解，插件是要被传染的。

所以针对你问题的答案：

1. 在这个情况下是的。
2. 前提是你的 js 不能经过混淆，压缩或打包。
3. 无禁止转载的权力，有收费的权力，但是无禁止别人收费的权力。同时售卖者有义务在购买扩展的用户索取的时候免费提供源码。

[westoy]

@muzuiget

3d 模型本身不涉及 GPL 资源的引用

你最后说的这个是 LGPL ，GPL 不行的

linux 不需要开源程序一是因为 glibc 是 LGPL 协议开源， 二是 GCC 本身不是纯 GPL ， 它对 runtime 的引用给了个例外

[secondwtq]

首先目前 Gamedev “开源”的实践典型是，引擎代码 GPL ，美术音乐素材专有。IMNAL ，不过我觉得有个问题是 GPL 要求发布的东西是“all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work”，它关心的一直在 executable 层次，也就是说它明确保证的只有：你能 build 出 executable ，你能修改代码之后再 build 出（改过的） executable 。GPL 原文并没有定义什么是“executable”，而从技术层面理解的话这个词对不同场合的 applicability 是有区别的，比如天然最适合 C/C++ 等编译型语言。

从 executable 到一个完整的游戏（产品）中间是有很大的空间的，这中间包括但不限于素材，本地化文本，关卡地图，脚本等。很多简单的 mod 就是改个素材或者改个数值，从软件开发的角度理解，这些属于“配置”或者“输入数据”的范围，我 GPL 了我的网站前后端源码，但是几乎没人 GPL 数据库里的用户数据。这个是可以理解的。

但是作为程序员都知道，“代码”和“数据”并没有明确的分界线，所以这里我觉得是个灰色地带。就算配置不具备图灵完全的能力，一些比较复杂的配置也能“模拟”简单程序的效果，我该不该开源我的“配置”？

以上是主要从游戏的角度出发来分析，因为游戏里面，除引擎核心之外的东西实在是数量巨大种类繁多，因此我觉得这个问题是比较复杂的。传统的软件产品反倒是比较单纯，我比较了解的一个是 Blender ，Blender 本身是 GPL 的，而因为它是个用户群很大的 DCC ，它的第三方二次开发社区也很活跃。其中有一个做插件商店的网站 BlenderMarket ，算是圈内有一定影响力的。在该网站上发布内容需要选择 license ，网站只提供有限的选项：support.blendermarket.com/article/54-available-licensing-options 其中对“asset”类和“code”类是分开处理的，“code”类只允许选择 GPL 或 MIT license 。能用 MIT 应该是因为 MIT 是 GPL-compatible 的（可以直接 relicense 成 GPL ），但是具体的原因网站也并没有给出解释，我觉得区别大概在于用 MIT 的话，其他和 Blender 无关的非 FOSS 项目也可以引用其中的代码。（最神奇的是这些东西虽然法律上是开源的但是还是很多人去付费）
类似的项目还有很多比如 WordPress ，不过这些项目的具体情况我就不怎么了解了。
（现在又出现了新的风暴了：AI 模型的权重、数据集等 ...）

[Mithril]

@Trim21 按官方的说法，用 API 也要看是调个函数等返回，还是调一堆函数并且共享很多数据结构。
主要这个纠结起来很麻烦，而且对于 OP 的问题也没什么帮助。毕竟他那 JS 不打包压缩的话也就算分发代码了。
但是就算是 GPL ，他也没法阻止别人拿去收费。
所以在开源协议上想要阻止别人二次分发和收费基本都是无用功，除非像 ElasticSearch 那样自己定制一个协议，但那没准又和 GPL 不兼容了。

[muzuiget]

@westoy 当然行，了解一下 Android 的 HAL 层，这就是解决 GPL 传染的经典案例。甚至把改过的 GPL 程序放在服务器上运行，都不需要开源，作为服务端使用就是一个“中间层“，所以才有 AGPL 来针对这个情况。再说，并不是所有 Linux 程序都是 GCC 编译，LLVM 一样能编译，而 LLVM 是 BSD 的。

[Trim21]

@Mithril 这里的情况是扩展直接调用了主程序提供的 API 操作程序行为，所以不是那种主程序只调用扩展提供的函数的情况。

我觉得按照前面 @secondwtq 提到的，弄个自己做的专有素材就能绕过 GPL 了。毕竟你代码总不能传染到我的画上面吧，缺了我的美术素材你的程序又跑不通顺

[ly841000]

@hez2010 #8 GPL 的话动态链接也算，LGPL 才不算

[ysc3839]

@muzuiget 用 Linux 对比不恰当，首先一般认为 GPL 不管进程隔离的，其次 Linux 的协议中可能有豁免条款。我前面发的链接提供了 FSF 官方的解读。

[iceg]

这个游戏的原开发者就是不支持楼主朋友那种做法的，但是很多扩展开发者都各自划分山头，搞 qq 群小圈子，新人入坑一头问号，想玩一下大部分拓展要加十几个群，而且群里可能问下问题就被称为爷新，游戏的现任维护者看不惯这种情况，脾气又有点暴躁，导致火药桶被点燃了，结果进行了 qq 贴吧大战，总之结论可以看这个帖 https://tieba.baidu.com/p/8434743761 。

[muzuiget]

@ysc3839 这么说的话，这是不是还要细分“带豁免条款的 GPL”和“不带豁免条款的 GPL“？或者说，“豁免条款“就是一个中间层。

[RainZack]

主程序加载 mod 是属于“动态链接”吗？

——“如果主程序动态连接了插件，而且它们之间互相调用函数并共享数据结构，那么我们认为它们构成了一个单一的组合程序，主程序和插件必须被当作一个扩展来对待。如果主程序动态连接了插件，但是它们之间的通信限于调用插件的‘主’函数及其参数并等待其返回，那么这就是个可以算单一组合程序也可以算两个独立程序的临界情况。”

[choury]

@RainZack 我觉得这里的关键不在于是否动态链接，因为作为插件使用（区别于作为服务提供），不管上层是怎么实现的，底层就只有这个文档里面列举的 fork 然后 exec ，和动态链接两种方式。所以是否认为是单一程序，只需要看是否有数据结构交互，以及函数互相调用

[choury]

在这种 mod 场景中，隔离 gpl 的思路是，分为两个组件，一个是 server ，暴露 rpc 接口，mod 本身实现为 server 的 client 端，这样的话，只需要开源 client 端源码，而不用开源 server 端，但是能这样做的前提是
1. server 端实现不需要请求游戏提供的接口
2. server 端需要请求游戏接口，但是游戏的接口也是通过 rpc 服务方式提供（ Android 的实现方式）