每个人都同意澳大利亚的海岸线比古巴的海岸线长。同样，日本的海岸线比澳大利亚的海岸线长。等等……什么？CIA 这么说，所以一定是正确的。此外，事实证明海岸线的长度取决于你如何测量它。
这与许可证有什么关系？大多数第三方许可证问题都采用以下形式：
ASF 项目“A”能否对许可证为“D”的“C”进行“B”操作？
答案是，简单的规则和粗略的近似值通常都能在两种情况下给出正确的答案。例如，比较古巴和澳大利亚。然而，在某些情况下，此类规则和近似值会给出错误的答案。在极少数情况下，答案本身取决于问题的提出方式。
这旨在以轻松愉快，有时是旁敲侧击的方式介绍一个复杂且经常有争议的主题。
第三方许可证策略的第一个近似值是，ASF 必须能够仅根据Apache 许可证 2.0 版分发在 Apache 项目中创建的作品。此外，此类作品可能具有的任何依赖项都必须在类似的条款下获得许可。这是一个既非常理想又无法始终如一地实现的理想——至少在全面考虑递归依赖项时是这样。
对于此近似值，唯一决定因素是上述语句中的许可证（“D”），并且问题出现了：什么是“类似”条款？
我这样看待它：Apache 类型的许可证是通用供体。此类代码可以提供给任何人。GPL 类型的许可证更接近通用接受者，至少在开源领域是这样。此类代码可以与各种开源代码结合使用。
FSF 为我们提供了良好的视觉辅助工具。请注意所有箭头都是单向的。
为了保持通用供体，我们的产品必须保持无抗原。这自然会导致类别 A：授权许可证的定义。
第一个近似值给出了很多好的答案，但也有一些错误的答案。首先，抗原并非一无是处。Apache 许可证 2.0 版包含一项专利终止条款。该条款与贡献者许可协议相结合，是更大策略的一部分，该策略可以保护血液供应免受其他危害。
这意味着，虽然类别 A 许可证在小剂量下完全可以接受，但对根据此类许可证提供的作品的严重依赖会稀释 ASF 在其许可证策略中精心设计的专利责任限制。
反过来也是如此。根据使用方式，非类别 A 许可证也可能完全可以接受。如果您没有注意到，这就是上述语句中的“B”。为了实现难以提取的核心功能而合并作品，与使用允许与其他产品集成的可选插件是截然不同的。即使该产品是在排除许可证下提供的，甚至是在专有非开源许可证下提供的，情况仍然如此。
一个具体的例子是Jakarta NT 服务。JBOSS 部署程序是另一个例子。借用法律的另一个方面的词语，只要存在实质性的非侵权使用而无需这些插件，那么这些用途不仅可以，而且与成为通用供体的目标完全一致。当然，必须谨慎记录如何做到这一点。
因此，第二个近似值是一个矩阵。行是许可证。列是用途。最初，矩阵是稀疏的，但随着时间的推移，它可以用“始终可以”和“绝不可以”填充。其中一些答案旁边会有一个星号。以这种方式组织时，您可以开始看到一些许可证是惰性气体，而另一些则具有放射性，并且类别会随之出现。
就在您认为自己可以掌握这一点时，人们发明了新的许可证、新的条款和新的排除项。以及新的用途。
上面提到了星号。在一些许可证和用途上，星号似乎像蒲公英一样成倍增加。例如：处理对免费分发给广泛用途的专有产品的硬依赖项的列；以及处理具有类路径或用作库例外情况的基于 GPL 的许可证的行。
Java 和 C# 就是主要例子。
起初，人们倾向于试图根据使用类型来定义这一点。但您会越来越发现，以这种方式难以区分可接受的使用和不可接受的使用。最终，事实证明，简单地枚举可接受的产品更为简单。这就是上面描述中的“C”。
区分特征往往是许可证之外且我们无法控制的某些东西。处理诸如普遍性和标准之类的属性的特征。该产品是否普遍到可以假定它已安装在目标环境中？ASF 代码是否使用专门设计用于启用 ASF 产品尝试执行的操作的“标准”接口与该产品交互？注意：我把“标准”放在引号中，因为需要在没有试图弄清楚 ASF 是否认可任何特定标准机构的负担的情况下探讨这个问题。出于这些目的，任何架构接口都可以。更简单地说：我们是否按照预期的方式使用或扩展产品？
因此，log4j 依赖于 Java 显然是可以的。它甚至明确标记为这样。
在面对 Hibernate 是否可以被视为系统依赖项的问题时，孵化器只是简单地说明 Roller 无法捆绑和分发 Hibernate。这导致了此问题，该问题基于观察到 Roller 的许多目标受众尚未安装 Hibernate，并且只是有兴趣安装它以支持 Roller。
不用说，对于所有相关人员来说，此类讨论和决定都很困难。并且仅应根据 PMC 的具体请求重新开启。
如果您看到了模式，则只剩下一个字母。“A”。鉴于我们都是 ASF 项目，不可能出现两个 ASF 产品想要以相同方式使用相同的产品（显然具有相同的许可证）最终导致一个可以另一个不可以的情况，对吧？实际上，这种情况很少见，但有可能。
Lucene.Net 对Microsoft.NET Framework具有硬依赖项。如上所述，这完全可以。同样，依赖项已明确标记，因此那些对这个子项目不感兴趣的人将不会参与。
另一方面，对 httpd 进行更改以利用类似的依赖项可能会导致分支。有一段时间，Open Office 面临类似的争议，这导致邮件合并组件用 Python 重写，并最终可能在一定程度上促成了OpenJDK的形成。
并且，显然，Tomcat正是这样的一个“分支”。一个发展得非常好的分支。这里的重点是，有时保护不使用第三方库的选项与保护使用第三方库的选项一样重要。
好的，我用完了字母。但仍然不是所有内容都完全适合。Santuario 必须处理与版权、专利甚至许可证无关的法规。HTTPD 通过提供单独的下载处理了类似的情况。
本文档顶部的标题致敬了促使牛顿力学被广义相对论取代的观测现象。也可以说是一个丑陋的事实。需要注意的是，牛顿力学至今仍在教授，因为它在很大范围的应用中仍然能产生非常有用的答案，但是当广义相对论提供的答案与牛顿力学提供的答案不同时，前者往往更准确。
我并不妄自菲薄地认为这个想法能与广义相对论的意义相提并论。坦白地说，我只是用科学的比喻来为一个原本枯燥的主题增添趣味，并为以下观点提供可信度：有些事情从一个角度来看似乎违反常识，但从完全不同的角度来看实际上可能是唯一合理的立场。
说到这个话题，虽然牛顿万有引力是牛顿力学的“垮台”，但量子力学很可能会彻底改变相对论。在量子力学中，观察者的作用常常会影响被观察对象的属性。ASF 决定采用 Java 和 XML 对这两个主题都产生了深远的影响。（也许不像我们希望的那样，但仍然是实质性的）。这意味着我们应该偶尔允许自己去追求一些精心挑选的、违反上述所有标准的举措。
即使有了上述免责声明，这段冗长的论述对我来说仍然过于自命不凡。我真正想做的是快速解决此列表中的问题。我相信，为了做到这一点，我们需要具备灵活度，能够简单地说“欢迎使用基于 Java 的项目”，或者“用 Ruby 编写并在 Ruby 许可证下发布的任何内容都可以作为用 Ruby 编写的项目的依赖项”。
我想要这样做的原因很简单：什么是 Ruby 运行时的一部分，什么不是，其界限模糊；任何此类 Gem 作者的意图都很明确；坦率地说，这样的声明非常符合 Ruby 代码许可证持有人的预期。这样的声明还可以避免耗费任何精力试图将 Java 或 Ruby 许可证纳入现有的类别之一（或者，不寒而栗地修改一个或多个类别的定义以适应 Ruby），这无异于试图决定我们应该如何处理在 Ruby 许可证下许可的 TCL 代码。
在高度近似的程度上，此页面描述的方法与第三方许可政策草案相匹配。关键差异
此页面完全缺乏诸如“必须在一年或两个主要版本中的较早时间之前移除”之类的短语。如果某个现有项目在很长一段时间内一直在发布版本，并且没有受到贡献者或许可证持有者的重大异议，我认为没有理由干预。
此页面缺乏关于类别 B 或如何处理第三方脚本的任何具体信息。我还没有准备好宣布对这些问题的共识，并且处理这些情况的适当方法很可能取决于具体情况。
此页面明确承认，决策可能并非在所有项目和所有时间都保持一致，同时试图最大程度地减少和限制这种情况发生的次数。
首要目标是保持普遍捐赠者地位。虽然 PMC 将需要平衡开发人员和许可证持有人的需求，但在与第三方许可相关的问题上，法律事务委员会将主要关注确保满足许可证持有人的所有需求，从最规避风险的公司到自由软件运动中最积极的成员。
ASF 完全依靠志愿贡献，并打算在重新分发其作品时遵守版权持有者表达的限制。
所有决策都将公开做出和发布。
在人力可能的情况下，所有事情都将通过法律事务委员会的共识来决定，但可能通过惰性共识。如果出现无法达成共识的情况，决策将由主席做出，主席将随时向董事会通报此类问题。
将鼓励 PMC 提供具体问题。上面列出的形式的问题将优先于“这里有一个问题，帮我解决它”类型的开放式问题。
第三方许可政策的一个关键部分将是建立和执行针对 NOTICE、LICENSE 和 README 文件的具体政策。
