LLVM 重新授权更新及求助

在这篇博文中，我想总结一下我在 2021 年 LLVM 开发者大会上关于重新授权更新的演讲中提到的主要要点。

简而言之，我们目前正在收集过去贡献者的重新授权协议的“长尾”阶段。截至目前，我们已经重新授权了超过 94% 的旧代码。我们希望通过众包来完成这个“长尾”阶段，争取尽可能接近 100% 的目标。

求助

您可以通过查看我们还需要获得协议的个人和公司列表，联系他们，或发送邮件至 license-questions@llvm.org 告知我们如何联系他们来提供帮助。此外，如果您有其他认为对我们有帮助的信息，请发送邮件至 license-questions@llvm.org 告知我们。

有关如何提供帮助的更多详细信息，请访问 https://foundation.llvm.org/docs/relicensing_long_tail。

在本博文的剩余部分，我将提供更多历史背景并详细说明当前状态。

重新授权工作始于很久以前。让我先简要介绍一下各个阶段，然后再进行更详细的说明。在 2015 年之前，LLVM 当时采用的许可证存在一些问题。

不同的许可证是解决这些问题的答案。大约从 2015 年到 2017 年，重点是确定哪种不同的许可证最适合。

确定了新许可证后，我们开始着手让所有代码都受新许可证的约束。这包括获得所有现有代码的版权持有者同意，以在新许可证下共享他们过去的贡献。从时间轴上可以看出，获得这些同意是目前重新授权工作的重点。

我们可能无法获得每一个过去贡献的同意。在这种情况下，我们有许多选择，可以让我们宣称 LLVM 项目中的所有代码都受新的 LLVM 许可证的约束。我们称重新授权的这个阶段为“最终阶段”。

timeline

旧许可证由三个部分组成：涵盖所有代码的 UIUC 许可证、额外涵盖运行时库代码的 MIT 许可证以及开发者政策中关于授予专利权的几句话。

开发者政策中专利部分的文字阻止了一些人进行贡献。该文字可以被解释为要求在为 LLVM 贡献代码时授予不必要的广泛专利权访问权限。这使得一些公司无法进行贡献。
运行时库在 UIUC 和 MIT 许可证下双重授权；其余代码仅在 UIUC 许可证下授权。因此，我们无法轻易将代码从其他部分移动到运行时库。运行时库被双重授权的原因是为了能够链接到运行时库二进制文件，而无需对 LLVM 进行归属。
开发者政策中关于专利权的文字含糊不清，导致人们不确定它是否提供了预期的保护。

在探索了一系列选项后，我们决定解决这些问题的最佳方案是让所有代码都在 Apache-2.0 with LLVM exception 许可证下授权。

Apache-2.0 包含易于理解的专利授权，它解决了第一个和第三个问题。
LLVM exception 的存在有两个原因：
- 它消除了将 LLVM 代码与 GPLv2 代码结合使用时可能产生的不兼容性。
- 它消除了使用 LLVM 工具的开发者告知其生产的二进制文件的用户这些二进制文件可能包含来自 LLVM 的部分代码的要求。当 LLVM 运行时库的部分内容作为正常编译过程的一部分链接进来时，这种情况很容易发生。
  
  LLVM exception 使运行时库能够像代码库的其余部分一样，受同一单一许可证的约束。

在决定了新许可证后，我们开始着手让所有代码都受其约束。

作为第一步，我们确保所有新的贡献都受新许可证的约束。这是在创建 8.0 版本分支之后发生的。自那以后的 100,000 次提交都受新许可证的约束。

剩下的任务是让之前的贡献也受新许可证的约束。这包括大约 300,000 次提交，总计约 3200 万行贡献代码。

Getting all code covered

让这些之前的贡献受新许可证约束需要做些什么？

我们之所以需要许可证，是因为版权。大多数代码贡献受版权保护。这意味着拥有版权的个人或公司对该代码可以合法地做什么拥有很大的决定权。通过在代码上附加许可证，它变得明确其他人被允许对该代码做什么。如果没有与受版权保护的代码相关的许可证，其他人对代码能做的就不多了。

基本上，为了让现有代码受新许可证的约束，我们需要找到谁拥有该代码的版权，并要求他们同意在新许可证下提供其受版权保护的作品。

我们开始征求他们的同意。通过检查我们需要获得协议的 300,000 次提交的版本控制日志，我们发现大约 2800 个不同的人或电子邮件地址进行了贡献。

我们联系了他们所有人，向他们询问了两个问题。首先，任何公司是否可能拥有他们任何贡献的版权。其次，他们是否同意重新授权他们个人拥有的版权的贡献。

到目前为止，我们已经了解到大约 220 家独特的公司可能拥有过去的一些贡献的版权。我们也开始联系他们，但还没有联系过每一家。

那么，在我们开始征求同意后的两年半时间里，我们取得了哪些进展？

下面的图表总结了当前状态。它显示了一个树形图，每个矩形代表一个人的贡献。每个矩形的尺寸代表该人贡献的代码行数。

Treemap showing LLVM relicensing status

当矩形为绿色时，意味着该人的所有贡献都完全受重新授权协议的约束。

当矩形为橙色时，意味着我们尚未收到此类协议。当矩形为带有绿色星星的橙色时，意味着该人的部分贡献受协议约束，而其他部分不受约束。例如，当一个人在不同公司工作过一段时间，而只有其中一些公司同意重新授权时，就会出现这种情况。

我们已经获得了 2001 年至 2019 年间所有贡献代码行中超过 94% 的许可协议覆盖。我们还有大约 5% 的代码行需要完成。

正如您所看到的，大多数缺失的协议来自“长尾”贡献者。“长尾”贡献者指的是那些贡献了相对较少代码行的许多贡献者。我们首先专注于联系主要的贡献者。为了更好地联系“长尾”贡献者，我们希望得到更广泛的 LLVM 社区的帮助。

请考虑帮助我们联系“长尾”中的任何个人或公司。请查看我们需要帮助联系的个人和公司的最新列表。

您可以在 LLVM 基金会网站的重新授权长尾页面上找到有关如何提供帮助的更详细指南。

如果您认为可以帮助我们联系列表中的某个人，或者您可能有一些其他信息可以帮助我们，请发送邮件至 license-questions@llvm.org 告知我们。

我们目前正处于获得尽可能多的重新授权协议的阶段。我们预计我们可能无法获得所有过去贡献的 100% 协议覆盖。我们该怎么做才能让当前的顶层主线代码完全受新许可证的约束？

我们需要逐个贡献地确定可用的选项，以实现这一目标。我们至少有以下选项。