许可兼容性和重新许可

作者：Richard Stallman

如果您想将两个自由程序合并为一个，或者将一个程序的代码合并到另一个程序中，这就提出了一个问题：它们的许可是否允许合并，或者禁止合并。[1]

如果许可证行为良好，则合并具有相同许可证的程序没有问题，几乎所有自由许可证都是如此。[2]

那么当许可证不同时会发生什么？一般来说，如果存在一种方法可以在遵守所有许可证的情况下合并这些不同许可证下的代码，我们就说几个许可证是兼容的。结果通常是一个程序包含不同兼容许可证下的部分——但并非总是如此。这种可组合性或不存在性是给定许可证集的特征，并且不取决于您提及它们的顺序。许可证集还控制着组合程序所需的许可证。

我们将许可证分为三类：宽松（也称为“允许”或“软弱”）、中间和著佐权。宽松的许可证不会干扰将代码放入专有软件中。著佐权许可证禁止这样做，它要求所有重用都必须在相同许可证下的程序中进行。中间许可证对添加专有代码施加一些条件，但不会尝试禁止它。

一般来说，宽松的允许许可证（修改后的 BSD、X11、Expat、Apache、Python 等）彼此兼容。这是因为它们对添加到程序的其他代码没有任何要求。它们甚至允许将整个程序（可能经过修改）放入专有软件产品中；因此，我们称它们为“软弱许可证”，因为当一个用户试图剥夺其他人的自由时，它们不能说“不”。

在宽松许可证下的程序组合中，每个部分都带有其附带的许可证。当代码合并到无法再区分各部分的程度时，该合并后的代码应带有所有合并部分的许可证。由于无论如何所有许可证都是宽松的，这不会造成任何实际问题，除了许可证列表会变长。[3]

同样地，宽松的许可证通常与任何著佐权许可证兼容。在组合程序中，在宽松许可证下进入的部分仍然带有它们，并且整个组合程序带有著佐权许可证。一个宽松的许可证，Apache 2.0，具有与 GPL 第 2 版不兼容的专利条款；由于我认为这些专利条款很好，我使 GPL 第 3 版与它们兼容。

一个重要的例外是原始的 BSD 许可证，因为它有“令人讨厌的广告条款”。该条件要求在任何包含根据原始 BSD 许可证发布的任何代码的产品的所有广告中都必须包含特定的通知。这过去和现在都与所有实际的著佐权许可证不兼容。对于每个发行版来说，这也是一件麻烦事，因为程序积累了类似但不同的广告要求。有一次，一个 BSD 发行版需要超过 70 个不同的通知。

我主要通过说服院长 Hal Varian 安排加州大学伯克利分校发布“修改后的 BSD 许可证”（没有广告条款）并重新发布该许可证下的伯克利系统发行版代码，从而消除了这个问题。如今，原始的 BSD 许可证（幸运的是）很少使用，但我们仍然必须注意不要谈论“BSD 许可证”。

一般来说，除非两个不同的著佐权许可证具有明确的兼容性条款，否则它们是不可避免地不兼容的。这不是由于细节上的错误造成的；它固存于著佐权的概念中。著佐权的概念是“修改和扩展的版本必须在相同的许可证下”。如果许可证 A（在程序 P 上）说扩展的程序必须在许可证 A 下，而许可证 B（在程序 Q 上）说扩展的程序必须在许可证 B 下，则它们存在不可调和的分歧；包含来自 P 的代码和来自 Q 的代码的组合程序的许可证必须是 A，并且它必须是 B。

这就是为什么 GPL 第 2 版与 GPL 第 3 版不兼容的原因；这是无法避免的。同样，CC-BY-SA 4.0 的条件将固有地与 CC-BY-SA 3.0 的条件不兼容，作者也无法避免这种情况。

有两种方法可以避免不同版本的著佐权许可证导致的兼容性问题。

FSF 采用的方法是要求人们在“GNU GPL 版本 N 或任何更高版本”下发布程序。此许可与版本 N 兼容，也与 N+1 兼容（因为它提供版本 N+1 作为选项）。当您将“GPL 3 或更高版本”下的代码与“GPL 2 或更高版本”下的代码组合时，组合的许可证是它们的交集，即“GPL 3 或更高版本”。

我们希望我们永远不需要制作 GNU GPL 第 4 版，但没有什么是完美的，我们不能假设我们已经预料到了所有问题。通过在 GNU GPL 3 或更高版本下发布您的代码，您允许您的代码在我们需要时升级到 GNU GPL 第 4 版。

另一种方法是使每个版本的许可证都明确允许升级到更高版本。Mozilla 基金会使用这种方法，PHP 也是如此。Creative Commons 对 CC-BY-SA 使用了这种方法：4.0 版（当前版本）明确允许任何用户将修改后的作品升级到 CC-BY-SA 的更高版本。

只有 GNU 许可证才允许作者选择是否允许升级到未来的许可证版本。当我在 1989 年编写 GNU GPL 的第一个版本时，我考虑过包含现在在 CC 许可证中找到的许可证升级选项，但我认为将该选择权交给每个作者更正确。因此，作者可以在“GPL 1 only”或“GPL 1 or later”下发布程序。

从那时起，我开始质疑该决定的明智性。诸如 Linux 之类的程序，仅允许一个 GNU GPL 版本并拒绝许可证升级，会导致实际的不兼容。[4]如果我们制作 GPL 第 4 版，也许我们应该包含一个升级条款，该条款自动允许重新许可为更高编号的版本，例如 5 及以上。

一些著佐权许可证允许通过明确的重新许可条款与其他著佐权许可证组合，该条款允许将代码置于不同的著佐权许可证下。例如，CeCILL 明确允许将代码重新许可为 GNU GPL 第 2 版及更高版本。如果程序 P 在 CeCILL 下，并且您想将其与 GPL 第 3 版或更高版本下的程序 Q 组合，则 CeCILL 表示您可以这样做并将组合或合并的代码置于 GPL 第 3 版或更高版本下。

明确的重新许可许可与兼容性不同（尽管重新许可代码可以使其与其他代码兼容），并且它不是对称的。例如，CeCILL 明确允许将代码重新许可为 GNU GPL，但 GNU GPL 不允许重新许可为 CeCILL。因此，您不能组合这两个程序 P 和 Q 并根据 CeCILL 分发该组合；这将违反 GPL 对程序 Q 的使用。发布该组合程序的唯一允许方式是根据适当的 GPL 版本。

同样，CC BY-SA 4.0 明确允许将修改后的版本重新许可为 GNU GPL 第 3 版，但 GPL 第 3 版不允许重新许可为 CC BY-SA。这个问题不应出现在软件代码中；Creative Commons 表示其许可证不适用于代码，并表示用于代码的许可证是 GNU GPL。但是还有其他类型作品，例如硬件设计或游戏美术，您可能需要将根据 CC-BY-SA 发布的内容与根据 GNU GPL 发布的内容合并。这可以通过 CC BY-SA 的明确重新许可许可来完成。

不幸的是，CC BY-SA 4.0 不允许重新许可为未来的 GPL 版本。当您根据 CC BY-SA 4.0 将材料重新许可给 GPL 时，您应该将自己指定为许可证版本代理，以表明该材料是否已授权使用未来的 GPL 版本。如果有一天有 GPL 第 4 版，并且 Creative Commons 决定允许从 CC BY-SA 重新许可到 GPL 第 4 版，那么作为代理，您将能够追溯授权该重新许可的材料在 GPL 第 4 版下使用。（或者，您可以要求该材料的作者立即给予许可。）

普通的 GNU 通用公共许可证和 GNU Affero 通用公共许可证是两个不同的著佐权许可证，因此它们自然是不兼容的。我们已经在它们之间建立了一种特殊的明确兼容性：您可以在单个组合程序中包含 GNU GPL 第 3 版下的源代码以及 GNU Affero GPL 下的其他源代码。这是允许的，因为这两个许可证都明确说明了这一点，并且效果是 GNU AGPL 适用于组合程序。但是，您不能简单地将来自 GNU GPL 的代码（无论是否带有“或更高版本”）重新许可为 GNU Affero GPL，反之亦然；这两个许可证都没有为此提供许可。另请注意，GNU Affero GPL 第 3 版不是普通 GNU GPL 第 2 版的“更高版本”，因为 GNU Affero GPL 和 GNU GPL 是两个不同的许可证系列。

GNU 较宽松通用公共许可证第 3 版，实际上是 GNU 通用公共许可证第 3 版加上一些额外的许可。GPL 第 3 版（第 7 节）规定，您可以随时删除添加的许可，这样做您就可以在普通的 GNU GPL 第 3 版下获得相同的代码。如果一个程序允许在 GNU LGPL 第 3 版或更高版本下使用，您可以将其重新授权为 GPL 第 3 版或更高版本；对于每个未来的 GPL 版本 N（N > 3），我们将创建一个 LGPL 版本 N，它由 GPL 版本 N 加上添加的许可组成。

至于 GNU 较宽松 GPL 第 2.1 版，它明确允许重新授权为 GNU GPL 第 2 版或更高版本。

中间许可证是对重新分发有实质性要求的许可证，但不是著作权保留许可证。例如，Eclipse 公共许可证和 Mozilla 公共许可证。中间许可证往往与任何著作权保留许可证不兼容，因为它们的要求不允许将组合程序置于著作权保留许可证之下。Mozilla 公共许可证允许重新授权为 GNU GPL，除非代码明确拒绝此权限。

最后，双重许可呢？[5] 双重许可是一种析取：它意味着同一个程序带有两种或多种不同许可的选择。例如，旧版本的 Perl 带有双重许可：艺术许可证和 GNU 通用公共许可证的析取。这意味着每个用户可以选择在一种许可证或另一种许可证下，或者像 Perl 版本本身一样在析取中同时使用和重新分发 Perl。如果析取中的任何一种许可选择与该组许可兼容，则析取与一组其他许可证兼容。

当您为您的代码选择许可证时，请选择 GNU GPL 第 3 版或更高版本，或某些与此兼容的许可证。这是使您的代码能够与几乎所有自由软件主体相结合的方法。选择 GPL 或 AGPL 的第 3 版或更高版本，也将尽最大努力捍卫您的代码所有版本的全部用户的自由。

代码组合

当一组许可证兼容时，这意味着您可以合法地组合或合并多个程序，每个程序都根据这些许可证之一获得许可。那么，组合程序是如何获得许可的呢？

每个自由软件许可证都规定您必须将许可证与它所涵盖的代码一起保留。因此，从严格意义上讲，组合程序的许可包括其所有部分的许可。但是，有时您需要一个关于组合程序如何获得许可的摘要答案。使用组合程序的人需要注意哪些许可证？

要计算它，您首先要列出所有相关的许可证。然后，您可以从列表中删除列表中被另一个许可证所包含的任何许可证。

当遵守许可证 A 意味着遵守许可证 B 时，我们说许可证 A 包含许可证 B。

例如，GNU GPL 第 N 版和 GNU Affero GPL 第 N 版都包含 GNU 较宽松 GPL 第 N 版，并且这三个许可证都包含 GNU 较宽松 GPL 第 2.1 版。

只要 N 至少为 3，任何 GNU 许可证的第 N 版都包含 Apache 2.0 许可证。

GNU GPL 第 N 版包含所有与它兼容的 Mozilla 公共许可证的版本。

Apache 2.0 许可证包含 BSD、Expat、X11、ISC 和 CC-0 许可证。BSD 3 条款包含 BSD 2 条款。BSD 许可证包含 Expat、X11 和 ISC 许可证以及 CC0。

这并不意味着这是一个完整的列表，但是如果我们被告知其他值得提及的情况，我们将添加它们。

当某个许可证被包含时，您仍然需要在组合程序的所有分发版本中包含它的副本。

脚注

关于程序的特定组合，可能会出现其他法律问题，这些问题与要组合的程序的版权许可无关，并非不可想象。我们仅讨论许可证本身的影响。
实际使用中主要的不规范许可证是 TeX 的许可证：如果两个程序的许可方式与 TeX 完全相同，则没有授权的方式来分发它们的合并版本。

TeX 许可证仅允许以原始版本加上差异文件的形式分发修改版本。如果 A 和 B 是以这种方式单独发布的，然后合并，则将合并程序作为 A 加上更改文件分发会违反 B 的许可证。将其作为 B 加上更改文件分发会违反 A 的许可证。以任何其他方式分发它都会违反这两个许可证。

TeX 于 1982 年发布并非巧合：自那时以来，我们的社区已经学会编写行为合理的许可证。
以源代码形式分发时，通常只需按原样保留源代码中的许可证声明即可；额外的许可证声明要求通常只会在分发没有源代码的二进制文件时对宽松许可证提出。
此外，GPL 第 2 版仍然允许通过拒绝所有特殊签名二进制文件的硬件来使二进制文件变得不自由，并且仍然不允许通过 Torrent 分发二进制文件。我们在第 3 版中修复了这些问题和其他问题，但我们无法更改第 2 版。
有些人使用“双重许可”一词来指代销售例外，但这是一种误称。请参阅销售例外。请注意，如果销售许可证的程序包括任何不在自由（libre）版本中的代码，那不是销售例外，那是使用非自由软件。