LWN: Copyleft-next 许可证与 Linux 内核！

关注了就能看到更多这么棒的文章哦～

Copyleft-next and the kernel

By Jake Edge
July 13, 2021
DeepL assisted translation
https://lwn.net/Articles/862611/

Linux 内核整体是采用 GPLv2 license（许可证）的，但其中有一些部分则采取的是其他的兼容 license，或者是双重许可（dual-licensed）的。几年前，内核项目中推广的 SPDX 通过在文件中直接指定 license 的名称而不是模板文本，来清理了大部分内核源代码中的 license 信息，这样一来情况就变得更加不那么清晰了。最近人们想在这里加入另一个 license，碰到了一些阻力，但其实有关的 license 已经在一些内核文件中使用超过四年时间了。

SPDX 更正式的名称是 Software Package Data Exchange，它是 Linux 基金会旗下项目，目标是创建一个 "交流软件清单信息的开放标准，包括它们的来源、许可证、安全以及其他相关信息"。在内核中就使用了 SPDX 标识符来声明 license，会放在源文件顶部的注释里。例如下面这样：

// SPDX-License-Identifier: GPL-2.0-only

由于工具相关的原因，.c 文件中的 SPDX 头文件使用了 "/" 形式的注释，而.h 文件则使用传统的 "/* … *" 形式。两者指定的许可证标识符都必须是存储在内核源代码目录的 LICENSES 目录下的许可证之一。

7 月 7 日，Luis Chamberlain 发布了一组 patch set，将 copyleft-next 0.3.1 许可证加入内核，并清理了内核树中四处引用到了该许可证的地方。copyleft-next 项目可以追溯到很久以前。早在 2012 年就从 GPLv3 分叉出来，起名为 GPL.next，但很快就改用了一个更中性的名字。它的目标是创建一个强大的 copyleft license，以 GPL 为模式，但语言更简单，因此比 GPLv3 更容易理解。它明确写出来是与 GPL 兼容的，所以对内核贡献的代码可以选择只遵照 copyleft-next 许可。但是，至少到目前为止，所有使用了 copyleft-next 的内核代码都是采用了 GPLv2 和更高版本（GPLv2+）的双重许可。

Backstory

Chamberlain 的这组 patch 并不是突发奇想写出来的。此前他提出了一个针对 sysfs 的 kernel self-test。和他写的其他测试代码一样，这个测试采用了 GPLv2+ 和 copyleft-next（0.3.1）的双重许可。但是 Greg Kroah-Hartman 说，代码中的 GPLv2+ 模板字样其实是没有必要的，"只需要 spdx 一行就够了" 。他还要求删除 copyleft-next 许可证。"请不要用它，这是一个完全不同的许可证 :("。

但是，正如 Chamberlain 所指出的，早在 2016 年就已经讨论过在内核中使用 copyleft-next 的问题；Linus Torvalds 并不反对使用它，而且当时的注释内容文本模版是 Alan Cox 和 Ted Ts'o 一起制定出来的。2017 年，test_sysctl 被合入 mainline，就使用了这个文本模版，用来说明该代码遵守双重许可。在讨论中 Kroah-Hartman 对其中一个 patch 给出了 ack（赞同意见），这个 patch 会在 kernel 代码中增加 copyleft-next 这个可选项。

然而，copyleft-next 许可证并没有列在内核的 LICENSE 目录中，所以 Chamberlain 的 test driver 中的 SPDX 行只提到了 GPLv2。这不是正确的做法，Kroah-Hartman 指出了这一点，但他还更加反对另一个问题：

考虑到这是直接与 sysfs 进行交互的代码，而 sysfs 是只适用于 GPLv2 的，因此试图在对 sysfs 进行测试的代码上要求使用另一个许可的话，这对于今后关注到这个问题的律师来说都将是一个大麻烦。建议让这里简单一些。

然而，张伯伦对许可证的兼容性（license compatibility）有不同的看法：

我添加的 fault injection 代码完全遵循 sysfs 的许可。test_sysfs 和 sysfs 之间的唯一交互是一个关于 completion structure 结构的 exported symbol。内核中已经存在的其他 gpl 或 copyleft-next 双重许可的 test driver 也使用 exported symbol，所以我认为这里并不是什么新的做法。

Adding copyleft-next

copyleft-next 不在内核的许可列表中，就导致了一个问题，SPDX 描述信息未能正确描述这四个已经添加进来的文件（lib/test_kmod.c，lib/test_sysctl.c，以及 tools/testing/selftests 中的相应 shell 脚本）的 license 状态。对于 C 文件，Chamberlain 的 patch 删除了原有的描述信息，并将 SPDX 描述更新如下：

// SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next-0.3.1

shell 脚本也进行了同样的改动，当然，采用了 "#" 作为 SPDX 的注释符号。

Christoph Hellwig 回复时，提出了一个问题：是否需要在内核代码里添加一个 "随机的奇怪的许可证"。Chamberlain 指出，该 license 早已经在内核代码上使用过了。在添加许可证文本的 patch 中，他还给出了一个清单，列举了他认为的使用 copyleft-next 的十几个好处。

• 更短、更简单
  

• 它有一个明确的专利许可授权，比 GPLv2 要好
  

• […]
  

• 对上游的贡献有一个内置的 inbound=outbound 政策（参照 Apache License 2.0 p 5）。
  

• 不鼓励参与有争议的 copyleft/ proprietary dual-licensing 的做法
  

• copyleft 在 15 年之后会过期，这利于管理历史遗留代码。
  

• 有明确的措施来抑制针对此作品的专利侵权索赔（见 10b）。
  

• 对于不遵守 license 规定的被许可人有一个补救期（GPLv2 中没有补救机会）
  

• copyleft-next 有一个 "built-in or-later" 条款
  

但是 Kroah-Hartman 对在内核中增加更多的许可证表示担忧，实际上他认为："我们应该把许可证的数量缩减得越少越好，因为这样会使事情更简单、更直接"。他指出，Chamberlain 可以改变那四个文件的 license，来避免增加 copyleft-next 的必要性。他还重申了他对 test_sysfs 的双重许可的论点，但他说他对 copyleft-next 的支持者也感到同情：

[……]我不希望看到你的 "test_sysfs.c" 采用双重许可，因为这没有任何意义。它是用来直接测试 GPL-v2-only 的代码，所以试图双重授权在我看来毫无意义。人们拿着这段代码，又声明自己仅遵循 copyleft-next license 的话，他能做什么呢？用来测试什么东西呢？

我理解 copyleft-next 的吸引力，因为它解决了 gplv2 的许多 "灰色" 地带，但是鉴于没有人很着急希望我们把内核所有代码都改成 copyleft-next license，那么就没必要鼓励它的传播，因为在我们的已有组合中再增加另一个 license 只会导致更多的复杂性和混乱。

copyleft-next 项目的主要组织者是 Richard Fontana，但 Bradley M. Kuhn 也参与了这项工作，他在回复 Kroah-Hartman 的时候首先表明了这个身份。Kuhn 指出，内核中已经有一堆代码是双重许可的，其中很多都是 two- or three-clause 的 BSD license 许可版本，这对内核开发者来说一直都不是一个问题，因为 "我没有看到任何有说服力的论据说'（仅 GPLv2|{2,3}-Claus-BSD）是如此的特殊，以至于它应该比其他形式的双重许可更受重视'。" 除此之外，既然之前没有人这样做过，Kuhn 想成为第一个建议内核社区将内核许可转为 copyleft-next 的人，尽管他也承认这项任务几乎是不可能完成。

Tim Bird 指出，加上 BSD 的双重许可才能使得 "许多代码可以在 BSD Unixes 和 Linux 之间互相流动，不加这个 license 的话这一切就不可能发生了"。他说，这非常符合 Torvalds 的 "（tit-for-tat compact）"，用来允许代码的改进可以双向流动。Kuhn 同意 Bird 的观点，并希望看到同样的情况发生在以 copyleft-next 方式发布的项目上，尽管这种情况要少得多。

归根结底，只要想要使用的 license 是与 GPLv2 兼容的，比如 copyleft-next 就是满足这个条件的（当然 BSD 和其他一些 license 也满足这个要求），那么，正如 Joe Perches 所说，就应该由代码贡献者来决定使用哪种（或者哪些）许可证。这种情况类似于 12 月在内核中加入 CC-BY-4.0 license 的情况，当时这么做是因为一个文档贡献者想对他们写的文档文本进行双重许可。这次的代码贡献者 Chamberlain 本人强烈地认为他的代码最适合 copyleft-next license。他知道像 Linux 这样的大型项目还需要考虑一些其他因素，所以他采取了一种缓慢的方法来改变，同时也尽量配合其他人和整个项目的需要，他说："我的个人目标是，后续所写的任何新代码都会使用 copyleft-next，只有在确有必要时才使用 GPLv2 或其他 license。"

在他列出的那些好处中 “明确的专利授权” 这一条对 Chamberlain 来说是最重要的。如果未来没有这种保证的话，他感到很担忧：

该许可证是仅有的几个可以与 GPLv2 兼容、且有明确专利授权的许可证之一（如果不是唯一的话）。我有理由相信，如果我们不通过明确的专利授权来继续演进我们的代码，那么我们整个社区今后将面临严重的挑战。因此，我创建的任何新项目都会采用这样的 license。这只是我的偏好，如果我可以在一些 "安全的地方" 贡献 Linux 代码，慢慢地推动它往这个方向走，那就太棒了。

鉴于该 license 自 2017 年以来就存在于内核中了，而且它不是偷偷摸摸进来的，因此 Chamberlain 提出的改动应该相对来说没有什么争议了。当然，对于这个 license 的不断扩张，无论是在内核社区还是其他社区，都对此有一些合理的担忧。但对于内核社区来说，主要问题似乎可以通过 GPLv2 的兼容性得到解决。有可能其他兼容的许可证也会时不时地添加到 LICENSES 目录中来，但这对于获取那些有价值的贡献来说，似乎只是一个很小的代价。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～