新的 MPL

上周，Mozilla 基金会发布了 Mozilla 公共许可证 2.0 版本。MPL 2.0 立即被自由软件基金会认可为自由软件许可证，并被开源促进会批准为开源许可证，它是一个精心制作的现代许可证，任何希望采用弱 copyleft 许可策略的开源项目都应该考虑它。

MPL 2.0 保留了其前身的主要特性，但使用了更清晰和简洁的语言。它仍然是一个“基于文件”的 copyleft 许可证。虽然将弱 copyleft 范围与源文件边界关联起来一直受到偶尔和合理的批评，但它具有很大的确定性优势。（我通常认为其他类型的弱 copyleft 许可证在许多情况下，如果不是大多数情况下，都会简化为基于文件的 copyleft。）与其他流行的当代开源许可证（GPLv3 系列除外）相比，MPL 在专利许可和专利终止方面仍然具有稍微更强大的方法。像其他弱 copyleft 许可证一样，MPL 2.0 继续允许在更严格的条款下许可可执行版本。另一方面，新许可证现在明确声明 MPL 适合用作从 MPL 许可的源代码构建的二进制文件的子许可证，这将是任何主流 Linux 发行版所采用的方法。

毫无疑问（至少对于我们这些自由许可证爱好者来说），MPL 2.0 最有趣的特性是其实现与 GNU 许可证系列兼容的新机制。（这也是 MPL 2.0 的一个特性，我觉得通过与 Mozilla、FSF 和软件自由法律中心的代表进行讨论，我可能对此做出了微小的贡献。）详细讨论许可证兼容性超出了本文的范围。只需知道 MPL 和 GPL 在历史上一直被认为具有冲突的许可证要求，这阻止了被许可人部分地从 MPL 代码中形成可分发的 GPL 许可作品。Mozilla 最终通过在 MPL、GPLv2 或更高版本以及 LGPLv2.1 或更高版本下以“三许可”的方式对它们进行非此即彼的许可，从而解决了其大多数项目的这个问题。当然，这并没有解决仅以 MPL 许可的代码的兼容性问题。

MPL 2.0 提供了一个更优雅的内部解决方案，可用于新的 MPL 项目（以及升级后的 MPL 1.1 代码，这些代码也根据 GNU 许可证许可），尽管 MPL 许可方可以选择退出兼容性方案。本质上，MPL 被许可人分发通过与 GNU 许可代码组合而成的“更大作品”时，被允许额外地在 GNU 许可证下分发作品中受 MPL 保护的部分，这随后为下游接收者提供了上游 MPL 部分的非此即彼的 MPL/GNU 许可证。有关此兼容性机制的良好解释，请参阅 FSF 关于 MPL 2.0 的评论 和 Mozilla 自己关于此主题的 FAQ。

虽然这远非显而易见，但 MPL 1.1 对 GPLv3 的起草产生了一些影响，我曾在 以前的生活 中参与了 GPLv3 的起草。“GPLv3 的律师腔”，诚然，这已成为一些批评的主题，其总体风格受到 MPL 1.1 风格的启发。GPLv3 还借鉴了 MPL 中“贡献者版本”的巧妙概念，同样将其用于其专利许可授予条款中。因此，我很高兴看到 GPLv3 对 MPL 2.0 的直接影响体现在两个条款中：两部分的补救机会和明确保证下游升级到更高版本的许可证不会给上游许可方增加新的义务。

尽管 MPL 2.0 具有优点，但我预计 MPL 2.0 不会在 Mozilla 项目领域之外被广泛采用为开源许可证（这不是 Mozilla 对 MPL 2.0 的目标，就像广泛采用不是 FSF 对 GPLv3 的目标一样）。我对这个预测有三个理由；当然，如果我被证明是错的，我会很高兴。

首先，MPL 1.1 从未在 Mozilla 社区之外的开发者中获得足够的普及，以将 MPL 确立为一个流行的许可证“品牌”（因为缺乏更好的术语）。（相比之下，GPLv3 在年轻项目中的流行似乎主要是 GPL 品牌在 GPLv3 之前的实力的结果。）正如我在 2010 年关于 MPL 修订启动的 文章 中指出的那样，MPL 1.1 确实享有更可疑的流行形式，这不太可能再次发生。在开源泡沫的奇怪时代，MPL 1.1 成为了许多考虑不周的衍生品的基础，这些衍生品充其量是企业“虚荣许可证”，最坏的情况是不配“开源”标签。这些 MPL 衍生品总共覆盖的软件非常少，其中大部分现在已经过时。这些概括的一个重要例外是 Sun Microsystems 的 CDDL，它是对 MPL 1.1 的真正改进，并且继续覆盖大量的重要的开源软件。我鼓励当前的 CDDL 管理者 Oracle 考虑根据 MPL 2.0 重新许可其 CDDL 代码，MPL 2.0 与 CDDL 1.0 一样值得成为 MPL 1.1 的继任者。

其次，在某种意义上是前一点的必然结果，MPL 与 Mozilla 品牌的巨大成功紧密相连。这种强大的品牌关联可能会限制 MPL 2.0 在 Mozilla 之外的普及，这有点自相矛盾。另一个有价值的弱 copyleft 许可证，Eclipse 公共许可证，也遇到了类似的问题。可以肯定的是，具有此类品牌关联的自由软件许可证有时确实会克服这些关联，并继续在起源项目社区之外享有非凡的普及性。当然，这种情况在 1990 年代的 GPL 和 LGPL 中发生过，并且最近在 Apache 许可证 2.0 中也发生过。

最后一个原因是 Apache 许可证的崛起所暗示的。虽然这只是基于我个人印象的猜测，但我认为弱 copyleft 的概念已经逐渐失去相关性，社区项目越来越多地在强 copyleft 或标准非 copyleft 许可证之间做出选择。支持 copyleft 的开发者倾向于支持强 copyleft，而那些优先考虑技术采用而不是公共领域保护的人自然会倾向于宽松许可证。MPL 基于文件的 copyleft 的清晰性说明了为什么会这样。Copyleft 倡导者可能会认为这种 copyleft 的弱点在于易于规避，正如 Richard Stallman 本人在 1998 年对 MPL 的祖先 Netscape 公共许可证的 评论 中所做的那样（请参阅标题为“不是 copyleft”的部分）。那些寻求尽可能广泛地重用其软件的人可能会发现 MPL 相对最小的 copyleft 要求并不比 GPL、AGPL 和 LGPL 的要求更能阻碍该目标。