MPL 2.0、著作权共有和许可证兼容性

在我的 Mozilla 公共许可证 文章的第一部分中，我提到了许可证兼容性作为 MPL 2.0 的一个主要特性。事实上，这是一个非常重要且复杂的问题，值得单独解释。

首先，免责声明

两个开源许可证兼容到底意味着什么是一个复杂的话题；非常复杂，以至于最资深的自由和开源许可证专家也常常在细微之处存在分歧。本文只能提供一个简短的概述，并且不可避免地会有一些并非所有人都同意的观点。预先致歉！

那么，什么是兼容性？

当谈论开源许可证时，说“兼容”的人通常指的是“单向”兼容性，即来自更宽松许可证的代码可以用作整体许可证更严格的项目的一部分，但反之则不然。例如，如果 Mozilla 项目切换到 MPL 2，Firefox 可能会很快包含 Apache 代码（因为宽松的 Apache 许可证将与 Firefox 的整体 MPL 许可证兼容），但您的 Apache 网络服务器不会很快包含任何 Mozilla 许可的代码（因为 MPL 仍然比 Apache 项目的整体 Apache 许可证更严格）。

为了更精确一点，可以说当以下情况发生时，宽松许可证 P 与严格许可证 R 是单向兼容的：

1. 任何遵守许可证 R 所有要求的人也将遵守许可证 P 的所有要求。
2. 许可证 P 允许的一切也都被许可证 R 允许。

换句话说，如果只要你遵守许可证 R 设定的更严格的规则，你也将遵守更宽松的许可证 P 设定的规则，那么许可证 P 和许可证 R 就是兼容的。因此，使两个许可证兼容是一项使这些规则对齐的工作。

这些细微不兼容性的一个很好的例子是 MPL 1.1 和 Apache 2.0 之间。在某些情况下，专利诉讼者可能会触发 Apache 2.0 的专利和平条款，而不会触发 MPL 1.1 的类似（但略有不同）的专利和平条款。这使得这两个许可证在本文使用的意义上不兼容。对齐这些触发条件使我们更有信心 Apache 2.0 和 MPL 2.0 是兼容的。换句话说，遵守 MPL 2.0 的专利要求将使人们确信他们也遵守了 MPL 许可项目中所包含的任何 Apache 许可代码的专利要求。

为什么著作权共有许可证之间的兼容性很困难？

著作权共有许可证之间的兼容性很棘手，因为使用著作权共有许可证的一个主要原因（在某种意义上，*最*主要的原因）是，基于原始软件的新软件也必须在相同的著作权共有许可证下可用。这最初是为了防止专有许可证，但它也具有“防止”其他著作权共有许可证的副作用。GPL 通过要求用户必须“在本许可证的条款下”传达整个程序的源代码来实现这一点。同样，MPL 1.1 说修改“受本许可证条款管辖”。这些要求是这些著作权共有许可证的核心特征，并且它们是矛盾的——如果 GPL（或类似的著作权共有）要求程序的所有组件都根据 GPL 的条款分发，而 MPL 要求 MPL 下的所有文件都保留在 MPL 下，那么（至少在对 GPL 的最常见解释下）你不能将 MPL 文件放入 GPL 程序中。任何两个范围重叠的著作权共有许可证都会出现相同的问题，这是任何想要使著作权共有许可证兼容的人都必须解决的挑战。

我们能做得比双重许可更好吗？

著作权共有许可证之间兼容性的传统解决方案是对代码进行双重许可，允许人们根据需要使用任一许可证。这种方法显然有效，但它允许任何人通过仅在其中一个许可证下（而不是在两个许可证下，或者在 Mozilla 的情况下，所有三个许可证下）分发更改来轻松创建不兼容的代码。一旦发生这种情况，瞧——无论是有意还是无意，您都创建了原始项目无法使用的代码，这违背了著作权共有许可证的全部意义，并使新代码更难使用。这无法完全避免，但我们想找到一种不同的方法来限制这种情况发生的可能性。

那么 MPL 2 如何处理这个问题呢？

我们的解决方案是 MPL 2.0 第 3.3 节的第二句话：

如果“大型作品”是“受保护软件”与受“次要许可证”约束的作品的组合，并且“受保护软件”不是“不兼容软件”，则您可以根据该“次要许可证”的条款额外分发此类“受保护软件”，以便“大型作品”的接收者可以选择根据本许可证或该“次要许可证”的条款进一步分发“受保护软件”。

此条款允许某人组合 MPL 和 GPL（“次要许可证”）代码，并在另一个许可证下分发该组合（“大型作品”），但具有两个关键功能，有助于尽可能长时间地将代码保持在 MPL 下：

1. 首先，“大型作品”必须是““受保护软件”与受“次要许可证”约束的作品的*组合*”。所以你不能只是说“我真的更喜欢 GPL”——你必须与另一个现有的 GPL 作品结合。将此与传统的双重许可证进行比较，后者不要求您组合——您可以刚起床就说“我已决定只使用 GPL”。

2. 其次，您可以“*额外*地”在 GPL 下分发。换句话说，您还必须遵守 MPL，并且必须在 MPL *和* GPL 下向您的接收者提供。您下游的某人可以“选择”仅在 GPL 或仅在 MPL 下“进一步分发”——正如 GPL 所要求的那样——但您没有该选项。这确保了一次分发是在两个许可证下完成的，因此这些更改至少有一些机会被合并回上游版本。同样，这优于双重许可证，后者无法保证任何在兼容许可证下的发布。

这些条款给了我们两全其美。MPL 用户的利益通过确保仅在必要时使用它来得到保护，并且至少一个初始分发必须在 MPL 下——因此可以集成回原始项目。同时，GPL 用户的利益通过确保在必要且合理时，仍然存在在 GPL 项目中重用的有用途径来得到保护。

为什么这一切都很重要？

MPL 作为一种许可证继续发展壮大，并且许多 MPL 代码与自由和开源开发者越来越感兴趣的技术有关——Javascript、网络安全等等。让自由软件社区的人们更容易使用该代码对我们所有人来说都是双赢的。与此同时，许多有趣的工作也在 Apache 许可证下完成，让 MPL 用户更容易整合这些工作也具有同样的益处。考虑到这一点，这种新的兼容性是 MPL 2.0 的最大特性之一，我们希望它能被广泛理解——并被广泛使用。