跳至主要内容
The Apache Software Foundation
Apache 20th Anniversary Logo

ASF 第三方许可证策略

目的

本策略为 Apache 软件基金会项目提供许可证指南。它确定了在 Apache 软件基金会产品中包含第三方开源组件的可接受许可证。

项目可以将许可证问题提交给法律事务委员会 JIRA 空间

许可证标准

以下标准作为本页类别指南。

  1. 许可证必须符合 开源定义a
  2. 在实践中应用的许可证不得施加超出 Apache License 2.0 施加的重大限制。

a.(已审查:2019-02-16)

高级概述

在高级别上,本策略将许可证分为三个类别。

类别 A:我们可以在 ASF 项目中包含什么?

为了包含在 Apache 软件基金会产品中,我们认为以下许可证在条款方面与 Apache License 2.0 类似

许多这些许可证都有项目需要遵守的特定归属条款,通常通过 将其添加到 NOTICE 文件 中。在包含这些作品时,请确保您正在执行此操作。

处理公共领域“许可”作品

您可以在 Apache 产品中包含公共领域的作品(或类似处理的许可证覆盖的作品)。您必须提供归属(以类似于类别 A 列表的方式)。

当以下情况之一适用时,应将作品视为属于公共领域

我们视为类似于公共领域的许可证

请注意,作品是否属于公共领域可能是一个 困难 的问题。确定作品的版权是否已过期可能并非易事,并且可能因司法管辖区而异。如果您对作品是否属于公共领域有任何疑问,请在 legal-discuss@ 或通过 JIRA 问题中提出。

类别 B:我们可能可以在 ASF 项目中包含什么?

您可以在 Apache 软件基金会产品中包含本节中描述的许可证和/或项目,如果它们满足指定的条件。

适当标记的条件

在所有类别 B 的情况下,我们的用户不应对其包含在我们的产品中感到意外。如果我们在分发版中附加一个适当且突出的标签,用户不太可能不知道与 Apache License 有显着差异的限制。适当且突出的标签是用户在了解分发版时会阅读的标签 - 例如在 README 中,它应该识别第三方产品及其许可证,并提供其主页的 URL。请同时遵守所涉具体许可证中的任何归属/声明要求。

仅二进制包含条件

任何类别 B 许可证下的作品都可以在 Apache 软件基金会便利二进制文件中以仅二进制的形式包含。请勿在源代码版本中包含类别 B 许可证下的作品。

“弱版权”许可证

本节中的每个许可证都要求一定程度的互惠性。这可能需要采取其他措施来最大程度地减少 Apache 产品的用户在不知情的情况下创建 Apache 产品的不同许可部分的派生作品的可能性。

如果您适当地标记了包含内容(请参见上文),则可以在 Apache 产品中以二进制形式包含以下许可证下的软件

通过仅包含对象/二进制形式,第三方作品的暴露面减少了,因此人们不太可能从中派生出作品。这解决了本策略的第二个指导原则。

对于 ASF 产品在运行时直接使用的少量源代码,以及该源代码未经修改且不太可能更改(例如,由于由标准指定)的源代码,您可以包含适当标记的源代码。一个例子是 web-facesconfig_1_0.dtd,其包含是 JSR 127:JavaServer Faces 规范所强制要求的。

包含 Creative Commons 署名内容

根据 Creative Commons 署名 (CC-BY) 许可证 (2.5、3.0 和 4.0) 的作品包含与“有效技术措施”相关的条款,这可能会让用户感到意外。因此,您应该适当地标记它们,并且仅以二进制形式包含它们。

在 Creative Commons 署名-相同方式共享许可证下未修改的媒体

您可以将未修改的媒体包含在 Apache 产品中,这些媒体根据知识共享署名-相同方式共享 2.5知识共享署名-相同方式共享 3.0知识共享署名-相同方式共享 4.0 许可证授权,但须遵守许可证的署名条款,这可能需要更改 LICENSE/NOTICE/README 文件。对于任何其他类型的 CC-SA 许可作品,请联系法律 PMC。

请注意,媒体是指我们文档中使用的二进制视觉/视频/音频元素。它不包括包含在我们的源代码中。

我可以从 Stack Overflow 复制代码并将其贡献给 ASF 项目吗?

不可以,除非您联系原始作者并获得他们的许可,允许在 Apache 项目中根据 Apache 许可证 2.0 使用该代码。

Doug Lea 的并发库

Doug Lea 的并发库是公共领域的,但包含一些并非公共领域的 Sun 文件。您可以像上面“弱版权”列表中的资源一样,将此库包含在 ASF 产品中。“如果包含在 Apache 产品的二进制形式中,则应进行适当的标记”。如果使用源代码,请删除 Sun 许可给 Doug 的文件,并将其视为类别 A(或从Harmony获取这些文件)。

向弱版权二进制文件添加 OSGi 元数据

您可以将 OSGi 元数据插入“类别 B”许可的 jar 文件中,前提是您在 jar 文件的突出标签中包含一条说明,表明已执行此操作。

Cobertura 报告

您可以在 ASF 发行版中包含 Cobertura 报告。

处理禁止修改的许可证

有些许可证允许广泛地重新分发未修改的副本。此类许可证并非开源许可证,但它们确实满足上述第二和第三条指导原则。

Apache 项目不得在版本控制中或发布的源代码包中包含此类许可证下的材料。但是,构建过程可以自动下载此类非软件材料(如字体和标准化数据),并将其包含在生成的二进制文件中是可以接受的。这种用法明确表明这些依赖项不是项目开源代码的一部分。

您可以使用以下许可证下的材料,如上所述

在 ASF 产品中包含构建工具

许多语言都开发了相关的工具生态系统,这些工具有助于构建用于分发的工件。虽然此类工具可能并非始终以其他兼容许可证提供,但我们已批准将特定工具包含在 Apache 发行版中,前提是它们用于此特定目的。

请注意,该工具不得影响项目的源代码许可证。我们还期望我们使用工具构建源代码是其典型用途。

迄今为止,我们已批准以下工具用于此用途

创建动态加载的 XS 模块时包含 Perl 许可的头文件

开发链接编译的 C 代码以创建动态加载的 XS 模块的 Perl 绑定需要包含根据 Perl 许可证授权的头文件(https://dev.perl5.cn/licenses/ - GPL-any/Artistic1,带例外情况)。

您可以包含这些头文件 - XSUB.h、perl.h 和 EXTERN.h(请参阅:LEGAL-79)。

包含 Doxygen 生成的配置文件

只要删除生成的注释,您就可以使用这些文件。

Apache 项目是否可以对 Ruby 许可作品有外部依赖关系?

主要且明显用 Ruby 编写的项目可以依赖于 Matz 的 Ruby 解释器 (MRI),或任何根据Ruby 许可证授权的 Gem。
当然,根据其他许可证(如 MIT)编写的 Gem 也可能没问题,具体取决于许可证。

另请注意,Ruby 许可证列在上述“类别 B”弱版权列表中,用于二进制用途(例如 JRuby)。

从 Java 9 开始,Javadoc 可以包含搜索功能,其中包括根据其他开源许可证授权的 JavaScript。Apache 项目可以包含此 javadoc 吗?

从 Java 9 开始,Javadoc 可以包含根据 MIT、MIT 或 GPL-3.0 或 GPL-2.0 附带 ClasspathException-2.0 授权的 JavaScript。Apache 二进制发行版(包括 Maven javadoc jar 文件)和 Apache 网站可以将其包含在其 javadoc 中。它不得包含在源代码发行版中。

类别 X:我们不能在 ASF 项目中包含哪些内容?

您不得在 Apache 产品中包含以下许可证

“其他问题”的详细信息

Facebook BSD+Patents 许可证
Facebook BSD+Patents 许可证包含 PATENTS 文件的规范,该文件将风险传递给我们软件的下游使用者,对许可方有利,而不是对被许可方有利,从而违反了我们 Apache 法律政策,即成为通用捐赠者。Facebook BSD+Patents 许可证的条款不是 ALv2 中条款的子集,并且不能作为 ALv2 许可。

NPL
Netscape 公共许可证是 Mozilla 的原始许可证,其中包含特定于 Netscape 的修订。这些修订允许“Netscape”(现在是 AOL 的一部分)避免所有其他被许可方必须遵守的互惠要求。这使得该许可证不符合开源定义第 5 条(“不歧视个人或团体”)。

无意义的许可证
这些许可证虽然对它们的创建者很有趣,但在法律上却存在问题。它们通常包含主观的用途范围限制,例如“不要作恶”,但没有定义该主观限制的仲裁者。在某些情况下,它们甚至可能无法授予足够的权利以符合 OSI 开源定义。由于我们不希望让我们的下游使用者感到意外,因此我们禁止使用此类许可证。

JSON 许可证
截至 2016 年 11 月 3 日,JSON 许可证已移至“类别 X”许可证列表。在此之前,允许使用JSON Java 库。请参阅 Debian 的页面,了解替代方案列表

不得分发

Apache 项目不得以源代码或二进制形式分发类别 X 许可的组件;不得在 ASF 源代码中或便捷二进制文件中分发。与之前有关平台的问题一样,如果该组件的许可条款不影响 Apache 产品的许可,则您可以依赖该组件。例如,在构建过程中使用 GPL 许可的工具是可以的,但包含 GPL 许可的源代码是不行的。

当它们支持可选功能时,您可以依赖它们

如果组件仅用于可选功能,则 Apache 项目可以依赖受禁止许可证约束的组件。在这种情况下,项目应向用户提供有关如何获取和安装未包含作品的说明。可选意味着该组件不是产品标准使用或产品达到理想质量水平所必需的。在这种情况下,您需要问自己的问题是

常见问题解答:

Apache 产品用于哪个平台是否重要?

这并不重要,除非该平台的条款会影响 Apache 产品的许可。例如,创建在 Windows 或 Java 上运行的产品、使用 Google 服务或 Yahoo 搜索等 Web 服务或作为 JBoss 或 JIRA 等产品的插件是可以的,而创建 Linux 内核模块则不行,因为 Apache 产品本身必须根据 Apache 许可证 2.0 版以外的其他许可证授权。

请注意,这并不意味着您可以重新分发平台代码本身。这当然取决于所述代码的许可。如果您对平台的许可是否会影响 Apache 代码有任何疑问,请检查 legal-discuss@ 档案以查看它是否之前出现过,如果未出现,请发送电子邮件至 legal-discuss@ 以了解情况。

库依赖项是否需要 IP 许可?

不需要。

IP 许可 用于从 Apache 外部导入代码库,以便将来在此处进行开发。

当有多种许可证可供选择时,我应该如何处理作品?

在包含该作品的许可证时,说明您正在使用哪个许可证,并且仅包含您选择的许可证。优先选择类别 A,然后是类别 B,最后是类别 X。例如,如果作品在源代码头文件中提到了各种许可证选项,则您不需要修改作品本身。

什么是必需的第三方通知?

当发布版本包含第三方作品时,涵盖这些作品的许可证可能会要求您以某些特定方式告知消费者。这些第三方声明因许可证而异。Apache 发布版本应包含每个许可证的副本,通常包含在 LICENSE 文档中。对于许多许可证,这已足够。一些许可证需要额外的声明。在许多情况下,您可以在依赖的构件中包含此声明。

必需的第三方声明是指上述情况未涵盖的任何第三方声明。

有关发布版本包含其他 Apache 产品时所需声明的说明,请参阅捆绑其他 ASF 产品