为什么制定新的开源软件许可证？MPL 2.0（第 3 部分）

在我之前的文章中，我讨论了 MPL 的新功能 以及 MPL 与其他许可证之间新的 兼容性。在这最后一篇文章中，我将总结关于新 MPL 的其他一些可能让 opensource.com 读者感兴趣的小细节。

为什么 MPL 很重要？

每当您考虑编写新的许可证时，都会出现一个显而易见的问题：为什么？ 纯粹从 MPL 的角度来看，这个问题非常简单：在过去的十年中，开源软件的开发方式、版权许可证的解释和执行方式以及自由软件许可的总体技术水平都发生了变化。 鉴于这些类型的变化，定期重新评估许可证并确保我们仍在提供我们能提供的最佳许可证是有意义的。 当然，您可能会做得过火 - 没有人希望定期培训律师和开发人员使用新的许可证。 我们等待的十年似乎对我们来说是一个相当好的时间段，我们希望（除非法律发生重大变化）这个许可证能够再持续十年或二十年。

更广泛地说，可以问“我们为什么需要温和的著作权保留许可证？ Apache 或 LGPL 还不够好吗？” MPL 的温和著作权保留在 Mozilla 身上取得了良好的平衡，因此 Mozilla 希望继续使用它。 这就是启动该项目的一个充分理由。 在项目进行过程中，我也 лично 意识到，在自由软件许可证的范围内，存在一个重要的位置，即需要一定程度的共享，但要使共享简单、清晰且没有任何附加条件的许可证。 这是一个普遍的愿望，但人们并不总是能够清楚地表达出来，因此他们有时会选择不能很好地满足其需求的许可证。 MPL 过去一直是许多非 Mozilla 项目的许可证，我希望，随着新版本的发布，它将获得更广泛的接受。

为什么花了这么长时间？

另一个常见的问题是“为什么花了这么长时间？” 如果您像 Mitchell 一样才华横溢，您可以在几周的才华横溢中写出一个，但对于我们其他人来说，需要时间才能做好。 Twitter 的 Andrew Macgillivray 在 讨论合同写作时解释了问题的许多方面

[我]将合同想象成一个计算机程序。 在每种情况下，目标都是能够解释文字并使该解释驱动结果。 现在想象一下，您的程序没有编译器，并且您无法运行任何测试。 所有调试都必须仅在理论上和在您的脑海中完成。 ...您和另一位 [程序员] 轮流编辑代码，但没有通用的编码环境或标准工具来弄清楚对方（或您）是否搞砸了。 然后想象一下，您正在编写的代码很可能只会通过两个不同的解释器“运行”，这两个解释器对期望的结果有明显的冲突观点，并且您很可能看不到任何这些“运行”的结果。

Andrew 只是在描述两方之间协商的合同！ 在我们的案例中，他描述的所有因素都发挥了作用，并且必须咨询许多不同的选区。 必须仔细权衡他们输入的每一部分 - 既要考虑法律影响，又要理解建议背后的可能动机。 所有这一切都没有相当于测试驱动的开发。

当然，参与其中的许多人的时间限制也发挥了作用，但是 我的新老板 在我加入 Greenberg Traurig 之前和之后都慷慨解囊，以一种超出大多数年轻律师有权期望的方式处理了这个问题。

开源工具

三种开源工具在我们的过程中非常有用，我想在此公开感谢它们的作者

• pandoc：主文档一直以 markdown 格式 保存，pandoc 已被用于生成您可以在 mpl.mozilla.org 上看到的所有版本的文档（尽管有些版本已经以各种方式进行了后处理）。 对我偶尔在邮件列表中发布的奇怪帖子的回复总是得到有益的处理。

• dwdiff：律师能够看到版本之间的差异非常重要，但普通的 diff 无法满足要求，因为如果您更改一个单词，整个段落都会显示为已更改。 解决方案是 dwdiff。 该工具不仅为我们填补了一个重要的空白，而且作者还非常友善地对代码进行了一些修复，使我更容易使用。

• co-ment：除了传统的反馈工具（如邮件列表和（喘息）电话）之外，我们还一直在使用 co-ment 来收集整个过程中的评论和更改。 这非常有价值，并且在那里收集的评论直接导致了 MPL 在流程的每个阶段（甚至从 RC 1 到 RC 2）都发生了更改。

谁提供了帮助？

帮助新 MPL 的人员名单非常长，因此我将避免逐个姓名进行审查，这不可避免地会遗漏人员。 也就是说，有几类人提供了帮助。 通常的开源许可嫌疑人都到场了：FSF、OSI 贡献者以及来自主要开源参与者（如 Red Hat 和 Novell）的律师都阅读、审查并提出了实质性意见。 开源的主要用户（有些您听说过，如 Intel 和 HP，有些您没有听说过）也给出了详细而周到的分析，尤其是在流程的早期阶段。 几位独立律师（最著名的是自由任务组列表的成员）给出了很好的反馈，尤其是在欧洲问题上。 许多 Mozilla 社区成员提出了周到的反馈，尤其是在解释 MPL 1.1 的粗糙之处需要识别和修剪的原因和方式方面。

最后，我要特别感谢大量的非 Mozilla、非律师人士花时间仔细阅读草案并通过 co-ment 或其他渠道向我们提供反馈。 这可能不好玩； 虽然 MPL 1.1 比大多数法律文件要好，而 MPL 2（我们希望）甚至更好，但这仍然是非律师志愿者努力阅读法律文件。 这是一项重大的承诺，但许多人还是这样做了。 同样重要的是，他们的许多建议都结出了硕果，既让我们了解了许可证在现实世界中的使用方式，又经常通过捕捉措辞或不清楚且可以改进的语言（例如 that vs. which）。 结果，最终产品变得更好 - 这要归功于那些可能真的有更多有趣事情要做的人。

下一步是什么？

我们希望在不久的将来最终确定许可证，并随之获得 OSI 和 FSF 的批准。 同时，Mozilla（经过一些讨论后）将对其 Mozilla 产品采用该许可证。 之后呢？ 好吧，我希望能够为编写 MPL 3.0 的人提供很大的帮助，并且我希望这个过程发生在 2030 年左右 ;) 到时见！