混合作品的版权归属与许可证兼容性

请不要被这个标题吓到！我们会使用尽量简单的语言，解释一些在协作软件项目时，常常会遇到的版权与许可证问题。本文使用了问答的形式来组织，这样你就可以只阅读你需要了解的部分。

目录

我能将软件 A 的源代码并入软件 B 吗？

这主要取决于 A 的许可证是否兼容 B 的许可证。一般来说，自由软件许可证的兼容性有如下的关系：

宽松型许可证 -> 中间型（弱 copyleft）许可证 -> copyleft 许可证

这里的箭头，代表前者的代码可以并入后者的代码，但反过来不成立。如果你还不理解这些类别的涵义，请阅读软件许可证的基础知识。

例如，LGPLv3 是一份中间型许可证；GPLv3 是一份 copyleft 许可证。所以，你可以把 LGPLv3 下的代码并入 GPLv3 下的代码之中。同理，宽松型许可证下的代码，也可以并入中间型许可证或 copyleft 许可证下的代码。例如，MIT 许可证或 Apache 许可证 2.0 下的代码，可以并入 LGPLv3 或 MPL 2.0 下的代码，也可以并入 GPLv3 或 AGPLv3 下的代码。

但是请注意，这只是通常的情况。有时候，一些许可证的老版本会导致不兼容：例如，Apache 许可证 2.0 不兼容 GPLv2，但兼容 GPLv3；MPL 1.1 不兼容 GPL，但 MPL 2.0 兼容它（但有一个例外，见下句）。还有一些其他的原因也会导致不兼容：例如，MPL 2.0 允许分发者附加一份声明，以禁止将该许可证下的软件并入 GNU 许可证，这样的话它就与 GPL 不兼容。详见完整的许可证兼容性表格。

软件 A 的许可证不兼容软件 B 的许可证，就代表着 A 的源代码不能并入 B 的源代码吗？

不一定。这只代表着在 B 的许可证不变的情况下，A 的源代码不能并入 B 的源代码。更换 B 的许可证之后，你就可能可以将 A 的源代码并入 B 的源代码。详见完整的许可证兼容性表格以及如何更换软件许可证。

将软件 A 的源代码并入软件 B 时，我需要做什么？

这取决于软件 A 的许可证。

如果软件 A 的许可证是宽松型许可证，那么一般只需要在软件 B 中保留软件 A 的署名信息。例如，当软件 A 使用 MIT 许可证或 BSD（2-Clause 或 3-Clause）许可证时，只需要在软件 B 的适当位置保留软件 A 的版权声明和许可证声明。当软件 A 使用 Apache 许可证 2.0 时，则有以下的要求：附带一份许可证的副本；标注修改过的文件；保留源代码中的版权、归属信息等声明；在适当位置保留随软件分发的 NOTICE 文件中的归属声明。

如果软件 A 的许可证是 copyleft 许可证，以 GPL 为例，那么主要需满足的要求如下：附带一份许可证的副本；标注作品经过修改，并给出修改日期；保留版权声明、免责声明等法律声明；以同样的许可证提供该软件的源代码。对 AGPL 而言，则就是在 GPL 的基础上，将通过网络提供服务也视为一种分发的形式。也就是说，并未得到该软件副本，而仅通过网络服务使用该软件的用户，AGPL 也将其视为软件的接收者，前述的要求对这些接收者也适用。

如果软件 A 的许可证是中间型许可证（即弱 copyleft 许可证），典型的是 MPL 和 LGPL，那么你需要以同样的中间型许可证提供 A 或其修改版的源代码，但 B 的分发条款可以自己任意选择。话虽如此，分发组合作品 B 时也至少需要在 B 中满足这些条件：声明组合作品使用了软件 A；保留 A 的版权和许可证声明；提供 A 的许可证副本获取方法。此外，LGPL 还要求你允许接收者使用 A 的修改版来组合一份 B 的重组版本。

以上是我们对一些常见许可证的义务进行的简单概括。如果你想要准确地了解某个许可证的具体内容，这里有一些资源，是一些自由软件许可证的（非官方）中文翻译。

我可以更换软件许可证吗？

可以。我们将这种行为称为再许可（relicensing）。

如果该软件完全由你编写，没有来自其他人的代码，那么你可以直接对软件进行再许可。

如果你的软件包含了并非由你写的代码，那么你需要确认你是否有权这么做。对于这部分代码，我们分为以下几种情况：

  1. 如果这部分代码所使用的许可证兼容你想要将你的软件更换至的许可证，那么你可以直接这么做。
  2. 如果这部分代码的作者在向你贡献这部分代码时，已经提前签署了一份 CLA 或类似的协议，其中明确同意将再许可的权利授予给你，那么你可以直接这么做。
  3. 如果以上都不是你的情况，那么你必须向这部分代码的原作者索取授权，才能这么做。

请注意，如果你对软件进行再许可，新的许可证只会应用于软件的后续版本。在旧的许可证下发布的软件版本，其旧许可仍然有效。

我可以升级到新版本的许可证吗？

同一许可证的两个不同版本实际上是两份不同的许可证，所以升级到新版本的许可证也相当于更换一份许可证，这是需要有权才能做的。请参看上一个问题，了解能这么做的前提。

有些项目要求我在对其贡献之前签署一份 CLA。那是什么？

CLA 即贡献者许可协议（Contributor License of Agreement）。部分项目要求贡献者签署一份 CLA 或者类似的文档，才能接受贡献者提交的贡献。

这类文档的的内容可能因项目的不同而不同。有些只是为了确保贡献者是这些贡献的原作者，或有权提交这些贡献（例如内核 Linux 的 DCO）。然而，有一些却要求你授予甚至转移你的版权或其他权利给他们，这样的话他们可能就有权更换你的贡献的许可证，甚至是将它并入专有软件。

如果你要贡献的项目要求你签署这类文档，那么一定要读一读它的内容。如果你认为它是不可接受的，那么你可以创建你自己的分支，而不必遵守该项目的 CLA 或类似文档，只需遵守其许可证。

我可以收回我的许可吗？

不能。自由软件的许可是不能撤销的。只要用户接收到了你分发的软件，那么他们就永久获得了在其许可证下使用该软件的权利，即使你停止分发该软件或删除该软件的公共仓库。

我可以修改一份许可证，或编写一份新的许可证吗？

修改一份许可证实则就是在编写一份新的许可证。我们强烈不建议这么做。如果你的目的是附加更多许可，那么请阅读这个问题；如果你的目的是附加更多限制，那么请阅读这个问题。如果你执意要编写一份新的许可证，那么要注意以下问题：

首先，你不能将你的许可证命名为诸如“GNU 禁止商业用途许可证”、“Apache 禁止修改许可证”或“Mozilla 仅个人使用许可证”。GNU、Apache 和 Mozilla 等名字是有商标的。如果你这么做，会造成商标侵权。

其次，如果你要在你编写的新许可证中，改编来自其他许可证的文本，那么你可能还要获得这些许可证文本的版权许可。就我们所知，GNU、Mozilla 和 Apache 允许了其许可证文本的再使用，但如前所述，禁止了其商标的使用。此外，GNU 还禁止其序言和附录的再使用。

最后，编写一份新的许可证还需要考虑它的法律效力和兼容性等问题。法律问题通常会影响其他项目对该项目的复用欲望。

我可以为一份许可证添加附加许可吗？

可以。如果你希望某个许可证的限制条件不要生效或不要在某种情况下生效，那么你可以随软件的许可证声明再附带一段法律声明，说明你对这个许可证附加了怎样的例外情况。

附加许可通常发生在软件使用了 copyleft 许可证的情况，用来在豁免某些情况下 copyleft 的适用性。例如在这种情况、这种情况或（稍微复杂的）这种情况。

为许可证添加附加许可，也就是把软件的许可证条款变得宽松了一些；这就类似于更换许可证，也是需要有权才能做的。请参看这个问题，了解能这么做的前提。

我可以为一份许可证添加附加限制吗？

通常不能以你预期的方式。

许可证是有完整性（integrity）的。一般地，如果你对某个许可证添加了附加限制，那么你就不能再说你的软件“以 [原许可证的名字] 授权”了。有时，说某软件“以 [原许可证的名字] 授权，并带有某些限制”也是不可行的。例如，如果你使用 (A)GPLv3 发布某软件，并声称禁止用于商业用途，那么 (A)GPLv3 的第 7 节就会直接使这条限制失效。

不过，有些许可证确实允许存在一定的附加条款，但能添加的条款十分有限，并不能达到你想要的任意的限制条款。例如，MPL 2.0 允许作者禁止将软件并入 GNU 许可证下的软件中；(A)GPL 允许添加的代码附带一些条款来保护名誉权或添加附加的免责声明。但这些许可证都不允许直接添加任意的限制。实际上，GNU 许可证允许这些合理的限制，只是为了让一些现有的许可证与之相兼容。

综上，为一份已有的许可证添加自己想要的任意限制，基本是不可行的。你需要编写一份新的许可证。

我可以为我的软件使用多份许可证吗？

可以。我们将这种行为称为双重许可（dual licensing）。

你可以在软件的许可证声明中，声明“该软件以 [许可证 A] 或 [许可证 B] 许可”，这样的话，接收者就可以要么在许可证 A 下接收该软件，要么在许可证 B 下接收该软件。

一些开发者有时会选择使用条款类似的多份许可证，来对软件进行双重许可。这么做通常是因为有些许可证条款类似，但兼容的许可证不同，而通过双重许可，可以扩大软件的许可证兼容范围。不过，这种行为已经很少见了。

我可以让他人付费来豁免某个许可证的要求吗？

可以。我们将这种行为称为出售例外（selling exceptions）。

出售例外与附加许可类似，只不过他方是付费购买了这样的许可。以及，这种许可一般是授予至独家，而不是授予至公众的。

这种许可模式并不少见。例如 Qt 框架是使用 GPL 许可的，这使得使用了 Qt 的程序必须同样使用 GPL 发布为自由软件。但开发者可以购买一份例外，从而有权将自己使用了 Qt 的程序发布为专有软件。

能否详细地解释哪个许可证兼容哪个许可证？

针对 GNU 许可证与 GNU 许可证的之间的兼容性，请参看 GNU 许可证兼容性表格。针对非 GNU 许可证与非 GNU 许可证、GNU 许可证与非 GNU 许可证、非 GNU 许可证与 GNU 许可证之间的兼容性，请参看以下我们总结的表格。

阅读下面的表格前，请先注意：

  1. “BSD”包括了 BSD 2-Clause 和 BSD 3-Clause 许可证。
  2. “MPL 2.0 (!)”是我们临时创建的一个代号，它表示“以 MPL 2.0 许可，但是不兼容次级许可”。根据 MPL 2.0，如果软件分发者在其许可证声明中，附加了一份 MPL 2.0 附录 B 中的内容，那么该软件就不能和一些许可证相组合。
  3. “某许可证+”表示分发者声明了接收者可以“某许可证或其任何后续版本”接受许可。
  4. 当我们说“可以：组合遵循某许可证”时，则表示当前项目必须要更换成那份许可证，组合才能进行。当我们只说了“可以”时，那么则无需更换许可证。

（1）非 GNU 许可证与非 GNU 许可证的兼容性表格。纵列表示要并入的代码使用的许可证，横列表示当前项目的软件许可证。

↱ MIT / BSD 许可证 Apache 许可证 2.0 MPL 2.0 MPL 2.0 (!)
MIT / BSD 许可证 可以 可以 可以 可以
Apache 许可证 2.0 可以：组合遵循 Apache 2.0 可以 可以 可以
MPL 2.0 可以：组合遵循 MPL 2.0 可以：组合遵循 MPL 2.0 可以 待研究
MPL 2.0 (!) 可以：组合遵循 MPL 2.0 (!) 可以：组合遵循 MPL 2.0 (!) 待研究 可以：组合遵循 MPL 2.0 (!)

（2）GNU 许可证与非 GNU 许可证的兼容性表格。纵列表示要并入的代码使用的许可证，横列表示当前项目的软件许可证。

↱ MIT / BSD 许可证 Apache 许可证 2.0 MPL 2.0 MPL 2.0 (!)
LGPLv2.1 可以：组合遵循 LGPLv2.1 不行 可以：组合遵循 LGPLv2.1 不行
LGPLv2.1+ 可以：组合遵循 LGPLv2.1 或 LGPLv3 可以：组合遵循 LGPLv3 可以：组合遵循 LGPLv2.1+ 不行
LGPLv3 可以：组合遵循 LGPLv3 可以：组合遵循 LGPLv3 可以：组合遵循 LGPLv3 不行
LGPLv3+ 可以：组合遵循 LGPLv3 可以：组合遵循 LGPLv3 可以：组合遵循 LGPLv3+ 不行
GPLv2 可以：组合遵循 GPLv2 不行 可以：组合遵循 GPLv2 不行
GPLv2+ 可以：组合遵循 GPLv2 或 GPLv3 可以：组合遵循 GPLv3 可以：组合遵循 GPLv2+ 不行
GPLv3 可以：组合遵循 GPLv3 可以：组合遵循 GPLv3 可以：组合遵循 GPLv3 不行
GPLv3+ 可以：组合遵循 GPLv3 可以：组合遵循 GPLv3 可以：组合遵循 GPLv3+ 不行
AGPLv3 可以：组合遵循 LGPLv3 可以：组合遵循 AGPLv3 可以：组合遵循 AGPLv3 不行
AGPLv3+ 可以：组合遵循 AGPLv3 可以：组合遵循 AGPLv3 可以：组合遵循 AGPLv3+ 不行

（3）非 GNU 许可证与 GNU 许可证的兼容性表格。出于页面宽度限制，横列表示要并入的代码使用的许可证，纵列表示当前项目的软件许可证。

⬐ MIT / BSD 许可证 Apache 许可证 2.0 MPL 2.0 MPL 2.0 (!)
LGPLv2.1 可以 不行 可以 不行
LGPLv2.1+ 可以 可以：组合遵循 LGPLv3 可以 不行
LGPLv3 可以 可以 可以 不行
LGPLv3+ 可以 可以 可以 不行
GPLv2 可以 不行 可以 不行
GPLv2+ 可以 可以：组合遵循 GPLv3 可以 不行
GPLv3 可以 可以 可以 不行
GPLv3+ 可以 可以 可以 不行
AGPLv3 可以 可以 可以 不行
AGPLv3+ 可以 可以 可以 不行

后记

当我们最初起草这篇文章的，我们的希望是它越短越好。然而，随着我们逐步完成这篇文章，我们发现要解释某个东西，常常要先解释另一个东西。随着要解释的东西越来越多，我们无奈地令本文如此之长。实际上，本文基本每一个问题，都可以用一篇完整的长文来回答。

尽管如此，我们还是有一些东西没有清楚地解释。这其中最重要的一点是，许可情况的分别不完全等同于许可证的分别，同一份许可证也可以产生不同的许可情况（用 SPDX 标识符来解释就是，举例来说，MPL-2.0 != MPL-2.0-no-copyleft-exception 或 GPL-3.0-only != GPL-3.0-or-later）。可能你目前不理解这段话，但我们希望在后续的修订中将它解释清楚。

最后，尽管本文一直在使用“我们”一词，本文及本系列的其他所有文章都是由一个人撰写的。出于此，本文难免会有一些不足之处。如果你对我们的文章有任何的问题或建议，欢迎通过这里列出的方式联系我们。