许可证兼容性和再次授权

Richard Stallman 著

如果你要把两个自由程序合而为一，或者把其中之一的代码并入另一个，那么就会有一个它们的许可证是否允许/禁止这样做的问题。[1]

如果两个软件使用同样的许可证，应该没有问题，假定该许可证象几乎所有的自由软件许可证一样顺理成章。[2]

那么如果许可证不一样会如何呢？一般来说，如果有方法可以合并代码而又能同时遵循各个代码的许可证，那么我们就说这些许可证是 兼容的。其结果经常是一个由各个部分使用不同许可证的组合程序——但也不尽然。具有这个兼容性，或者没有此兼容性，是许可证组合在一起的特点，这个特点并不依赖于你使用它们的顺序。该许可证组合还决定着该合并程序需要哪个许可证。

我们把许可证分为三类：松散型（也即 “纵容型” 或者 “顺从型”），中间型和 copyleft 型。松散型许可证不介意专有软件使用其代码。copyleft 许可证禁止专有软件使用其代码，它明确要求所有使用其代码的程序都要使用同样的许可证。中间型许可证限制但并不禁止专有软件使用其代码。

一般地，松散型许可证（修改版 BSD、X11、Expat、Apache、Python 等）是互相兼容的。这是因为它们对添加到程序里的代码并无要求。它们甚至允许把整个程序（或许带有修改）添加到专有软件之中；因此，我们称之为 “顺从型许可证”，理由是它们在用户的自由被否定时没有说 “不”。

在把使用松散型许可证的代码合在一起时，组合程序的每个部分都带有自己的许可证。当这些代码交织在一起无法分辨时，组合程序应该带上所有代码的许可证。由于这些许可证都是松散型的，所以全都带上除了太长之外也没有别的问题。[3]

同理可知，松散型许可证通常也和 copyleft 许可证兼容。在组合程序中，使用松散型许可证的代码仍然带着松散型许可证，而组合程序整体使用 copyleft 许可证。有一个松散型许可证，Apache 2.0，带有和 GPL v2 不兼容的专利条款；由于我认为这些专利条款还不错，所以我让 GPL v3 与之兼容了。

因其 “令人反感的广告条款”，原始 BSD 许可证是一个重要的例外。该广告条款要求包含任何使用原始 BSD 许可证代码的任何产品的所有广告都要带有一个特定的声明。这种做法过去和所有已知的 copyleft 许可证都不兼容，现在也是。当程序里积攒了越来越多相似而又不同的广告声明时，每个发行版都忍受着一种如芒在背的痛苦。有段时间，一个 BSD 发行版需要包含 70 多个不同的声明。

我说服 Hal Varian，UC Berkeley 的一位校长，促使他们发布 “修改版 BSD 许可证”（没有广告条款）并将 BSD 代码按照此许可证发布。这样就基本上根除了上面所说的问题。现在，原始 BSD 许可证（所幸）已经很少被使用了，但是我们还是必须小心避免讨论 “该” BSD 许可证。

一般来说，两个不同的 copyleft 许可证是无可避免地不兼容，除非两者之间有明确的兼容条款。这不是因为细节有误；这是 copyleft 理念与生俱来的特点。copyleft 的理念是 “修改和扩展的版本必须延用同样的许可证。”如果使用许可证甲的扩展程序 A 必须延用许可证甲，使用许可证乙的程序 B 必须延用许可证乙，那么它们之间就是不可调和；如果合并程序包含 A 和 B 的代码，那么合并程序的许可证必须是甲，也必须是乙。

这就是为什么 GPL v2 和 GPL v3 不兼容；这个无法避免。同样地，CC-BY-SA 4.0 的条件也天然不兼容 CC-BY-SA 3.0 的条件，其作者也无法避免这一点。

有两个方法来摆脱不同版本 copyleft 许可证带来的先天不兼容性。

FSF 使用请求人们按照 “遵循 GNU GPL 版本 N 或任何以后版本” 来发布程序这一方法来解决此兼容性问题。这种授权兼容版本 N，也兼容版本 N+1（因为它确认版本 N+1 是可选项）。当你将遵循 “GPL 3 或以后版” 的代码和遵循 “GPL 2 或以后版” 的代码合并时，组合代码的许可证是它们的交集，就是 “GPL 3 或以后版”。

我们希望我们再也不会有 GNU GPL v4，但是人无完人、世事难料，我们无法预见所有的情况。通过按照遵循 GNU GPL 3 或以后版本来发布程序，你就允许你的代码许可证升级到 GNU GPL v4，一旦我们发布了 v4。

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

只有 GNU 许可证给了作者选择是否允许升级到未来许可证版本的权利。当年我编写第一个 GNU GPL 版本的时候，那是 1989 年，我曾经想过包含一个许可证升级的选项，就像现在的 CC 许可证一样，但是我觉得把选择权交给作者更正当。这样，作者就可以把其程序按照 “只用 GPL 1” 或者 “用 GPL 1 或以后版” 来发布。

从那时起，我就在思量当时的决定是否明智。像 Linux 这样的程序，只允许一个版本的 GNU GPL 并拒绝升级许可证，这就导致实际上的不兼容。[4]或许我们应该在 GPL v4 的时侯包含一个自动升级条款，如果我们需要版本 4 的话。

有些 copyleft 许可证有一个明确的再次授权条款，该条款允许将代码按照不同的 copyleft 许可证授权，这样就允许了 copyleft 许可证之间的交叉授权。例如，CeCILL 许可证明确许可将代码按照 GNU GPL v2 或以后版再次授权。如果程序 P 使用 CeCILL 许可证授权，而你想把它和按照 GPL v3 或以后版授权的程序 Q 合并在一起，那么 CeCILL 许可证允许你这么做，合并或组合的代码使用 GPL v3 或以后版授权。

明确的再次授权许可和兼容性并不是一回事（虽然再次授权后的代码可以和其他代码兼容），二者也不对称。例如，CeCILL 许可证明确允许将代码再次授权给 GNU GPL，而 GNU GPL 并不允许将代码再次授权给 CeCILL。因此，你不能合并 P 和 Q 两个程序并把它们按照 CeCILL 许可证发布；那样就违反了 Q 程序使用的 GPL 许可证的要求。它们的合并程序只允许使用适当的 GPL 版本来发布。

类似，CC-BY-SA 4.0 明确允许修改版再次授权可以使用 GPL v3 许可证，但是 GPL v3 并不允许再次授权到 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 v4 并且 Creative Commons 许可证决定允许从 CC-BY-SA 再次授权到 GPL v4，那么你作为代理就能够返回来用 GPL v4 对该材料再次授权。（另外，你也可以直接请该材料的作者立即授予你许可。）

GNU GPL 和 GNU Affero GPL 是两个不同的 copyleft 许可证，所以它们自然是不兼容的。我们为此设计了专门的兼容方案：你可以在同一个程序里包含使用 GNU GPL v3 的源代码和使用 GNU Affero GPL 的源代码。因为两个许可证都明确说明可以这么做，所以这个没问题，其效果就是合并的程序适用于 GNU AGPL 许可证。不过，你不能简单地把使用 GNU GPL（有或没有 “或以后版本”）的代码再次授权到 GNU Affero GPL，反过来也是一样；两个许可证都没有允许这样做。请也要注意，GNU Affero GPL v3 不是一个 GNU GPL v2 的 “以后版本”，因为 GNU Affero GPL 和 GNU GPL 是两个不同系列的许可证。

GNU LGPL v3 真的就是 GNU GPL v3 加上额外的条款。GPL v3（第 7 节）表明你总是可以去掉那些额外的条款，这样做了之后同样的代码就遵循了常规的 GNU GPL v3。如果一个程序允许使用 GNU LGPL v3 或以后版本，那么你就可以把它再次授权到 GPL v3 或以后版本；对将来的每个 GPL 版本 N（N > 3），我们都会做一个 LGPL 版本 N，它由 GPL 版本 N 加上额外的条款构成。

对 GNU LGPL 版本 2.1 来说，它明确允许再次授权到 GNU GPL v2 或者以后版本。

中间型的许可证是指对重新发布有重要的要求但是又不是 copyleft 的那些许可证。Eclipse 公共许可证和 Mozilla 公共许可证都是中间型许可证。由于中间型许可证的要求不允许组合程序使用 copyleft 许可证，所以它们一般都不兼容 copyleft 许可证。Mozilla 公共许可证允许将代码再次授权到 GNU GPL，除非该代码明确拒绝这样做。

最后，双重许可证怎么办呢？[5]双重许可证是一种或的关系：它的意思是同一个程序可以选择两个或多个许可证中的一个或几个。例如，老版本的 Perl 就带有双重许可证：或者是 Artistic 许可证，或者是 GNU 通用公共许可证。这意味着每个用户都可以选择并按照其中一个许可证或者就按照 Perl 原来的方式再次授权 Perl。如果双重许可证中的一个许可证和一组许可证兼容，那么该双重许可证就和该组许可证兼容。

当你选择许可证时，请选择 GNU GPL v3 或者以后版本，或者是与之兼容的许可证。这是使你的代码能够和几乎所有自由软件集合的代码组合的正确方法。选择 GPL 或 AGPL，v3 或者以后版本，也会最大程度地保护所有使用你各个版本代码的用户的自由。

合并代码

当一组许可证兼容时，这就意味着你可以合法地合并或融合一系列按照其中某个许可证发布的程序。那么，合并后的程序该怎样授权呢？

每个自由软件许可证都说你必须保持其代码原有的许可证。所以严格来讲，合并程序的许可证要包含其所有组成部分的许可证。不过，有时你想要一个 总结性 的回答来解决合并程序该如何授权的问题。究竟哪一个许可证是使用合并程序的人 要关注的呢？

为了计算，你要从所有直接相关的许可证列表开始。然后你可以把列表中一些能够被另外一些许可证包含的许可证删除。

如果遵循许可证甲意味着也遵循许可证乙，那么我们就说许可证甲包含许可证乙。

例如，GNU GPL 版本 N 和 GNU Affero GPL 版本 N 都包含了 GNU Lesser GPL 版本 N，而它们三个都包含了 GNU Lesser GPL 版本 2.1。

任一版本 N 的 GNU 许可证，如果 N 不小于 3，那么它就包含了 Apache 2.0 许可证。

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

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

此处并非要提供一个完整列表，但是如果我们发现还有其他值得说明的例子，我们还会添加。

当某些许可证被包含时，你仍然需要在发布组合程序时包含该许可证的拷贝。

脚注

可以想象还可能有关于合并程序的其他法律问题，这些问题可能和合并程序的许可证无关。我们只讨论和许可证本身有关的问题。
实际当中用到的不那么顺理成章的许可证主要是 TeX 的许可证：如果两个程序都按照 TeX 的方式授权，那么你就没有办法发布两个程序的组合程序。

TeX 许可证允许发布的修改版只能是原来的版本加上一个差异文件。如果甲和乙两个程序分别按照 Tex 许可证发布，然后再合并，那么按照甲程序加上一个差异文件来发布合并程序就违反了乙程序的许可证。反过来，发布乙程序加上差异文件的话又违反了甲的许可证。按照其他方式发布的话就违反了甲乙两个程序的许可证。

这个并不意外，TeX 早在 1982 年就发布了：社区从此逐渐学会了撰写顺理成章的许可证。
当发布源代码时，在源代码里加入许可证声明通常就足够了；只有象使用松散型许可证的仅发布二进制而不带源代码的程序才需要额外的许可证声明。
另外，GPL v2 仍然允许非自由的二进制——硬件只运行特别签名的二进制而拒绝其他二进制文件，而且仍然不允许使用 torrent 发布二进制。我们在版本 3 中修复了这些问题，还修复了其他问题，但是我们不能改变版本 2。
有人使用 “双重许可证” 来兜售许可证例外，但是词不达意。请参看兜售例外。请注意，如果某个许可证兜售的程序包含了任何非自由的代码，那么它就不是在兜售例外，它就是非自由软件。