Rust 与 开源 | GPL 许可证引发的问题

“完全自由开源的 Rust 语言项目，现在却被自由软件基金会的 GPL 许可证给阻拦了，是什么情况呢？

给 Rust 编译器 merge rustc_codegen_gcc 后端的 MCP[1] ( Merge rustc_codegen_gcc backend as compiler/rustc_codegen_gcc issues#442[2] ) 遭遇了开源许可证的问题。

提案

`rustc_codegen_gcc`[3] 是 由 antoyo[4] 实现的新的 Rust 编译器后端，基于 rust_codegen_ssa 开发 和 来自于 GCC 的 libgccjit 库。有了 rustc_codegen_gcc ， Rust 可以通过 GCC 生成代码，在某些场景可以享受 GCC 产生的优化。

rustc_codegen_gcc 目前通过了整个核心测试套件；其余测试套件的工作正在进行中。rustc_codegen_gcc 受益于现有的基础设施，将测试注释为需要特定的后端，这样它就不会试图通过 LLVM 特定的测试。本来打算在 MCP 通过以后提交 PR，但是现在许可证上出现了问题。

许可证问题

rustc_codegen_gcc 使用与rustc相同的许可：双MIT / Apache-2.0。rustc_codegen_gcc所依赖的libgccjit库使用与GCC相同的许可。GPLv3-or-later。最初认为，这完全不会影响 rustc 的用户，也不会影响不构建或发布 GCC 后台的 rustc 的分销商。

但是经过 Rust 基金会与相关律师一起审查了这个许可证后，同意以下条款：

1. 建议的修改不会影响 rustc 的许可，除非它是用 gcc 后台构建的，在这种情况下，GPLv3 将适用于产生的二进制。该二进制文件的分发将受到GPLv3条款的约束。
2. rustc_codegen_gcc可以根据Rust项目许可证（MIT & Apache v2）进行授权，因为它们与GPLv3兼容。

但是发现了一些问题：

1. rustc_codegen_gcc repo 包含一个文件夹[5]，是对libgccjit的补丁，这是一个GPLv3授权的作品。GPLv3的第4条要求在分发源代码形式的修改时要做到以下几点。
   • 包括一份 GPLv3 许可证的副本。
   • 包括补丁修改 libgccjit 的 "显著通知"，以及 "相关日期"。(补丁文件中的信息可能已经足够了。)
   • 包括 "醒目的通知"，说明该作品（即补丁集）是根据GPLv3许可的。顶层的NOTICE文件看起来是个合适的地方。
2. 有一个邮件列表主题[6]询问libgccjit的开发者，该库是否受GCC运行时库例外规定的约束。开发者把这个问题交给了自由软件基金会（Free Software Foundation，FSF），FSF显然没有回答。只有当libgccjit本身的代码被编译到目标二进制文件中时，这才是一个问题，可能不是这种情况，但可能值得与开发者一起探讨。

为了解决许可证上述问题，Rust 编译器团队成员提出解决方案：

1. 对于问题一，应该从 rustc_codegen_gcc 仓库中删除任何 GCC 补丁，并且将这些补丁放到单独的仓库。这个单独的仓库用来遵循 GPL 的所有要求。避免在 Rust 源码仓库中出现这样的补丁。
2. 对于问题二，libgccjit不是一个运行时库，也不会被链接到目标二进制文件中；它生成的代码会调用libgcc来实现。libgccjit 是 GCC 的一部分，体现了 GCC 的代码生成，所以 GCC 的 版权 非常适用于它，没有例外。

然后，libgccjit 的作者也来回复：

1. FSF 始终都拥有 libgccjit 的版权（作者坦言，之前对这件事毫无意见，但现在要重新考虑对 FSF 的看法了。。。）
2. Libgccjit 遵循 GPLv3，它本质是对 GCC 实现的一个轻量级包装，只是以共享库方式实现，而不是命令行工具。
3. 任何直接与 libgccjit 链接的主机代码都需要遵循 GPLv3，但是由 libgccjit 生成的目标代码不受 GPLv3影响。这种用法类似于 GCCC作为命令行工具。
4. FSF 可以接受 GCC 被用来开发其他许可证下的代码，而 GCC 许可证只影响到它与目标 libgcc 运行库链接的代码。也许值得让律师检查一下该许可证。
5. 作者坦言是 Rust 语言的粉丝，希望这个项目成功。
6. 作者只是个人言论，不代表律师，不代表雇主（红帽），不代表 FSF。

小结

就在上个月， GCC 指导委员会也宣布将放弃长期以来要求所有代码贡献的版权转让给 FSF 的政策[7]。GCC 指导委员会表示，GCC 将继续在 GPLv3 下开发，但不再需要 FSF 的版权转让。相反，贡献者可以在他们的 Git 信息中使用带有 Signed-off-by 标签的 Developer Certificate of Origin（开发者起源证书）。

自由软件基金会成立于1985年。那时，Amiga 1000[8]计算机已经问世，C++ 成为了那时主宰计算机的编程语言，Aldus 的 PageMaker[9] 刚刚发布，计算机网络开始萌芽。同一年，Wham! 的 Careless Whisper[10] 风靡各地。

时光一晃，三十年过去了。FSF 代表的开源的旧世界观，能否和现代化的开源社区完美融合呢？这是一个问题，毕竟 捍卫 GPL 的法律工作已经做的足够完善了。

你怎么看待这个问题？请留言。

参考资料

[1]

MCP: https://forge.rust-lang.org/compiler/mcp.html

[2]

Merge rustc_codegen_gcc backend as compiler/rustc_codegen_gcc issues#442: https://github.com/rust-lang/compiler-team/issues/442

[3]

rustc_codegen_gcc: https://github.com/antoyo/rustc_codegen_gcc

[4]

antoyo: https://github.com/antoyo

[5]

文件夹: https://github.com/antoyo/rustc_codegen_gcc/tree/master/gcc-patches

[6]

邮件列表主题: https://gcc.gnu.org/legacy-ml/jit/2017-q3/msg00014.html

[7]

GCC 指导委员会也宣布将放弃长期以来要求所有代码贡献的版权转让给 FSF 的政策: https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html

[8]

Amiga 1000: https://en.wikipedia.org/wiki/Amiga_1000

[9]

Aldus 的 PageMaker: https://en.wikipedia.org/wiki/Adobe_PageMaker

[10]

Careless Whisper: https://www.youtube.com/watch?v=izGwDsrQ1eQ