2021 年许可证变更常见问题解答

我们将 Elasticsearch 和 Kibana 的 Apache 2.0 许可的源代码更改为 Elastic 许可证和 SSPL 1.0 的双重许可，让用户可以选择应用哪个许可证。我们还简化了 Elastic 许可证（Elastic 许可证 v2 或 ELv2），并使其更加宽松。我们的默认分发将继续采用 Elastic 许可证，就像过去三年来一样，我们将不再提供 Apache 2.0 分发。

此更改确保我们的社区和客户可以自由、公开地使用、修改、重新分发和协作 Elasticsearch 和 Kibana 源代码。它还通过限制云服务提供商在不共享其修改和服务管理层的源代码的情况下将我们的产品作为服务提供，来保护我们对开发免费和公开发布的产品的持续投资。

Elastic 许可证 2.0 适用于我们的分发以及 Elasticsearch 和 Kibana 的所有免费和付费功能的源代码。我们对 ELv2 的目标是尽可能宽松，同时防止滥用。该许可证允许免费使用、修改、创建衍生作品和重新分发的权利，但有三个简单的限制

• 您不得将产品作为托管服务提供给他人
• 您不得规避许可证密钥功能或删除/隐藏受许可证密钥保护的功能
• 您不得删除或隐藏任何许可、版权或其他声明

这些条款的目的是保护我们的产品和品牌免遭滥用，同时使分发和修改尽可能简单。有关 ELv2 的更多详细信息，请参阅此专用常见问题解答。

如果您下载并使用我们的 Elasticsearch 和 Kibana 默认分发，则对您没有任何影响。我们的默认分发继续在 Elastic 许可证下免费和公开，就像过去三年来一样。在 Elastic 许可证 2.0 中，我们简化了许可条款，并使其更加宽松。如果您在 Elasticsearch 之上构建应用程序，则对您没有任何影响。我们的客户端库继续在 Apache 2.0 下获得许可。如果您在 Elasticsearch 或 Kibana 之上使用插件，则对您没有任何影响。

首先，非常感谢您！您可以像往常一样继续为 Elasticsearch 和 Kibana 做出贡献，无论代码是在 Elastic 许可证还是 SSPL 下。要详细了解如何做出贡献，请参阅我们的贡献者指南。

在 Elastic Cloud 中或根据自管订阅使用我们产品的客户和合作伙伴不受此更改的影响。

如果您已经是客户或已达成协议重新分发我们的默认发行版，则没有任何变化。我们的默认发行版已在 Elastic 许可证下发布近 3 年，需要与 Elastic 直接达成协议才能重新分发。

对于开源项目，我们很乐意为您的项目提供支持并免费提供重新分发权。请通过[email protected]与我们联系，我们将提供许可附录，授予您重新分发的权利。

对于商业应用程序，您有几种选择。要在 Elastic 许可证下重新分发我们的默认发行版，请联系我们的团队进行讨论。您也可以考虑从源代码构建 Elasticsearch 和 Kibana，在这种情况下，您需要评估 Elastic 许可证或 SSPL 的条款在未来是否适用于您的用例。如果您有任何疑问，我们很乐意为您提供帮助：请通过[email protected]与我们联系，讨论您的具体情况。

Elasticsearch 和 Kibana 的 Apache 2.0 许可源代码将更改为在 Elastic 许可证和 SSPL 下获得双重许可。这意味着在使用源代码时，您可以选择最符合您需求的条款和条件集。我们的默认发行版将继续像过去近三年一样在 Elastic 许可证下发布，因此，如果您没有直接使用源代码，则这对您没有影响。我们还简化了 Elastic 许可证，使其尽可能宽松。

我们的大多数用户和客户已经在使用 Elastic 作为默认发行版的一部分，该发行版遵循 Elastic 许可证已有近三年时间。但是，我们希望尽一切努力尽可能保持开放和宽松，同时防止公共云提供商在不回馈社区的情况下提供托管服务。对于已经在使用 Elastic 许可证的用户，如果您愿意，请继续使用！这对您没有影响。事实上，我们通过 Elastic 许可证 2.0 更新使 Elastic 许可证更加宽松。我们选择同时提供 SSPL 选项，因为我们知道它为数百万用户和公司所熟悉，这要归功于其创建者 MongoDB 对其的使用，并且它提供了我们非常重视的那种自由。

我们在 Elastic 许可证和 SSPL 下对 Elasticsearch 和 Kibana 进行了双重许可，以便为用户提供选择。SSPL是一种源代码可用的许可证，最初由 MongoDB 创建，他们着手制定了一种体现开源理念的许可证，允许自由和不受限制地使用、修改和重新分发，并提出了一个简单的要求，即如果您将该产品作为服务提供给他人，您还必须公开发布任何修改以及您的管理层的源代码（根据 SSPL）。

SSPL 基于 GPLv3，被认为是一种“限制性”许可证。这意味着，如果您使用源代码并创建衍生作品，则这些衍生作品也必须在 SSPL 下获得许可并公开发布。有关更多信息，MongoDB 提供了很好的常见问题解答。

请注意，SSPL 尚未获得 OSI 的批准，因此为了避免混淆，我们不会将其称为开源许可证。

SSPL 为数百万 MongoDB 用户所熟悉，我们提供此选项是为了让这些用户不必查看新的许可证。有关更多信息，MongoDB 提供了很好的常见问题解答。此外，我们还看到了很多关于 SSPL 的错误信息。我们发现并认为分享以下由律师撰写的博客文章会有所帮助
https://www.coss.community/coss/sspl-re-takes-the-stage-in-2021-2koa
https://writing.kemitchell.com/2021/01/20/Righteous-Expedient-Wrong.html

需要明确的是，我们从 7.11 开始的发行版将仅在 Elastic 许可证 2.0 下提供，该许可证没有任何“限制性”方面，允许自由使用、修改和重新分发，只有 3 个简单的限制来保护我们的产品和品牌，如上所述。

如果您要从源代码构建 Elasticsearch 和/或 Kibana，则可以选择 SSPL 或 Elastic 许可证来管理您对源代码的使用。所讨论的条款仅适用于您从源代码构建、选择 SSPL 作为您的管理许可证，并且您正在将 Elasticsearch 和 Kibana 作为付费服务提供给他人的情况。在这种情况下，它仅适用于您将“提供 Elasticsearch 和 Kibana 作为托管服务”作为主要产品或其主要部分的情况。

此源代码许可证更改不应影响您 - 您可以根据 Elastic 许可证免费使用我们的默认发行版或在其之上开发应用程序。此源代码可用的许可证不包含任何“限制性”条款，并且默认功能是免费的。有关具体示例，您可以查看我们对 Magento 项目中有关此问题的回复。

此更改仅影响源代码 - 我们的版本将继续在 Elastic 许可证下免费开源。此更改将应用于我们软件的所有维护分支 - 6.8、7.x 和 master/8.0，并将在 7.11 版本正式发布之前进行。

不会，我们只对 Elasticsearch 和 Kibana 进行此许可更改 - 其他产品不会受到影响。我们一直希望使我们的数据收集和传送组件尽可能免费且易于访问。通过保护我们对 Elasticsearch 和 Kibana 的投资，此更改使我们能够使其他产品更加开放。我们将考虑将 Beats、Elastic Agent 和 Logstash 的更多功能迁移到 Apache 2.0 许可证下。如果我们决定进行任何其他更改，我们将单独传达。

是的。Elastic 许可证和 SSPL 都未经 OSI 批准，因此为避免混淆，我们不再将 Elasticsearch 或 Kibana 称为开源。我们更新了我们的网站和消息传递，将这些产品称为“免费和开放”，并且在直接谈论许可证时，我们将它们描述为“源代码可用”。如果您发现我们遗漏的地方，请告诉我们，以便我们进行更正。

虽然我们选择通过不使用术语“开源”来指代这些产品来避免混淆，但我们将继续使用“开放”和“免费和开放”。这些是描述产品可免费使用、源代码可用以及适用于我们在 GitHub 中的开放和协作参与模式的简单方式。我们仍然致力于开源的原则 - 透明、协作和社区。

在过去十年中，我们对开源原则的承诺丝毫没有改变 - 我们一直并将永远重视透明、协作和社区。我们的许多产品和项目继续采用 Apache 2.0 许可证，包括我们的客户端库、Beats、Logstash 以及 Elastic Common Schema 等标准。我们还将继续为 Apache Lucene 和其他开源项目做出贡献，就像我们一直做的那样。

如果公共云提供商希望提供从 7.11 开始发布的 Elasticsearch 和 Kibana 版本，则需要遵守 Elastic 许可证或 SSPL。

此更改不会影响您使用客户端库访问 Elasticsearch 的方式。我们的客户端库仍然在 Apache 2.0 下获得许可，但我们的 Java 高级 REST 客户端 (Java HLRC) 除外。

Java HLRC 依赖于 Elasticsearch 的核心，因此，此客户端库将在 Elastic 许可证下获得许可。随着时间的推移，我们将消除这种依赖关系，并将 Java HLRC 移至 Apache 2.0 许可证下。在此之前，为避免疑义，我们不认为在开发用于访问 Elasticsearch 的应用程序或库中使用 Java HLRC 作为客户端库构成 Elastic 许可证下的衍生作品，并且这不会对您如何许可使用此客户端库的应用程序的源代码或如何分发它产生任何影响。

更新：Java HLRC 已在 7.15.0 中弃用，取而代之的是Java API 客户端。Java API 客户端在 Apache 2.0 下获得许可。

如果您有任何疑问，请通过[email protected]与我们联系

此更改不会影响您构建或许可 Elasticsearch 或 Kibana 插件的方式。为避免疑义，构建要在 Elasticsearch 或 Kibana 中使用的插件不构成衍生作品，并且不会对您许可插件源代码的方式产生任何影响。

如果您有任何疑问，请通过[email protected]与我们联系

没有影响。我们与这些公共云提供商建立了牢固的商业关系，并将继续与他们合作。Elastic Cloud 可在微软、谷歌和 AWS 上使用，在这三种情况下，我们都是其市场生态系统的一部分。我们与阿里巴巴和腾讯建立了合作伙伴关系，允许他们将 Elasticsearch 作为服务提供。这些关系不受许可证变更公告的影响。

如上所述，我们广泛的目标是与采用我们产品并将其作为服务提供的公共云提供商合作。我们与 Google Cloud、Microsoft Azure、阿里巴巴云和腾讯云建立了牢固的关系。我们还与 AWS 合作，在 AWS Marketplace 中列出了 Elastic Cloud，并继续投资于这种关系，使 Elastic Cloud 成为 AWS 上最好的托管 Elasticsearch 和 Kibana 体验。但是，我们与 AWS 在 Amazon Elasticsearch Service 上没有商业关系。我们不积极支持该服务，并且不再希望我们对软件的投资直接使该服务受益。为了透明起见，我们还与 AWS 进行着持续的诉讼，此处和此处对此进行了讨论。

我们博客文章标题的目的是延续三年前开始的转变，当时我们首次宣布使用 Elastic 许可证开放 X-pack。我们非常有意地在信息传递中专注于“开放”，而不是“开源”。对于由此可能造成的任何混淆或歧义，我们深表歉意。博客的第一句话确实非常清楚地说明了这一变化。
这种变化的主要原因是通过不允许云提供商在未与我们和我们的社区合作的情况下直接将我们的产品作为服务提供来保护我们的投资。在这样做的同时，我们正在努力保持尽可能的自由和开放。

如果您的应用程序不是托管或托管服务，则您可能根本不会受到影响。如果您想获得澄清或有其他问题，请通过 [email protected] 与我们联系。

我们鼓励大家为 Kibana 制作插件。您可以继续构建使用 EUI 或 Elastic Charts 的 Kibana 插件。如果您还有其他问题，请通过 [email protected] 与我们联系。

• 2021 年 12 月 21 日：更新了有关新 Java API 客户端的详细信息
• 2021 年 6 月 7 日：添加了关于 EUI 和 Elastic Charts 许可的两个问题
• 2021 年 2 月 2 日：全文进行了多处更改，以反映对 Elastic 许可证 v2 (ELv2) 的更新。
• 2021 年 1 月 26 日：扩展对“什么是 SSPL 以及它是如何工作的？”的回答，以获得更多清晰度。
• 2021 年 1 月 18 日：合并“我嵌入了 Elasticsearch 和/或 Kibana 的修改版本……”和“我构建了一个嵌入和重新分发 Elasticsearch 的应用程序……”问题，以澄清和推动一致性。
• 2021 年 1 月 17 日：发布“我构建了一个嵌入和重新分发 Elasticsearch 的应用程序……”问题以获取更多上下文。发布“根据 SSPL，什么样的使用构成‘将产品作为服务提供’？”问题和答复。
• 2021 年 1 月 15 日：发布“为什么要提供双重许可策略？”、“我使用 Elasticsearch 作为后端构建了一个 SaaS 应用程序……”以及“这种变化如何影响您与 AWS 的关系？”问题和答复。