“完全自由开源的 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 基金会与相关律师一起审查了这个许可证后，同意以下条款：
- 建议的修改不会影响 rustc 的许可，除非它是用 gcc 后台构建的，在这种情况下，GPLv3 将适用于产生的二进制。该二进制文件的分发将受到GPLv3条款的约束。
- rustc_codegen_gcc可以根据Rust项目许可证（MIT & Apache v2）进行授权，因为它们与GPLv3兼容。
但是发现了一些问题：
- rustc_codegen_gcc repo 包含一个文件夹[5]，是对libgccjit的补丁，这是一个GPLv3授权的作品。GPLv3的第4条要求在分发源代码形式的修改时要做到以下几点。
- 包括一份 GPLv3 许可证的副本。
- 包括补丁修改 libgccjit 的 "显著通知"，以及 "相关日期"。(补丁文件中的信息可能已经足够了。)
- 包括 "醒目的通知"，说明该作品（即补丁集）是根据GPLv3许可的。顶层的NOTICE文件看起来是个合适的地方。
- 有一个邮件列表主题[6]询问libgccjit的开发者，该库是否受GCC运行时库例外规定的约束。开发者把这个问题交给了自由软件基金会（Free Software Foundation，FSF），FSF显然没有回答。只有当libgccjit本身的代码被编译到目标二进制文件中时，这才是一个问题，可能不是这种情况，但可能值得与开发者一起探讨。
为了解决许可证上述问题，Rust 编译器团队成员提出解决方案：
- 对于问题一，应该从 rustc_codegen_gcc 仓库中删除任何 GCC 补丁，并且将这些补丁放到单独的仓库。这个单独的仓库用来遵循 GPL 的所有要求。避免在 Rust 源码仓库中出现这样的补丁。
- 对于问题二，libgccjit不是一个运行时库，也不会被链接到目标二进制文件中；它生成的代码会调用libgcc来实现。libgccjit 是 GCC 的一部分，体现了 GCC 的代码生成，所以 GCC 的 版权 非常适用于它，没有例外。
然后，libgccjit 的作者也来回复：
- FSF 始终都拥有 libgccjit 的版权（作者坦言，之前对这件事毫无意见，但现在要重新考虑对 FSF 的看法了。。。）
- Libgccjit 遵循 GPLv3，它本质是对 GCC 实现的一个轻量级包装，只是以共享库方式实现，而不是命令行工具。
- 任何直接与 libgccjit 链接的主机代码都需要遵循 GPLv3，但是由 libgccjit 生成的目标代码不受 GPLv3影响。这种用法类似于 GCCC作为命令行工具。
- FSF 可以接受 GCC 被用来开发其他许可证下的代码，而 GCC 许可证只影响到它与目标 libgcc 运行库链接的代码。也许值得让律师检查一下该许可证。
- 作者坦言是 Rust 语言的粉丝，希望这个项目成功。
- 作者只是个人言论，不代表律师，不代表雇主（红帽），不代表 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
