2021 年许可变更常见问答

我们即将把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 源代码变更为采用 SSPL 1.0 + Elastic 许可的双重授权许可模式，以便用户选择适合自己的许可。我们还简化了 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 上使用插件，对您也不会有任何影响。

首先感谢您所做的贡献！无论这些代码是在 Elastic 许可还是 SSPL 下发布的，您都可以一如既往地继续为 Elasticsearch 和 Kibana 贡献内容。如需了解有关如何贡献内容的更多信息，可参阅我们的贡献者指南。

在 Elastic Cloud 中或通过自管型订阅使用我们产品的客户和合作伙伴都不受此次变更的影响。

如果您已经是我们的客户，或者同意重新分发我们的默认分发版，就不会受到任何影响。我们的默认分发版已采用 Elastic 许可近 3 年，需要与 Elastic 直接达成协议才可进行重新分发。

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

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

我们将把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 源代码变更为采用 Elastic 许可 + SSPL 双重授权许可的模式。这意味着，在您使用源代码时，可以选择最适合自身需要的一组条款和条件。近三年来，我们的默认分发版一直采用 Elastic 许可进行发布，今后我们会继续采用这一许可，如果您不直接使用源代码，对您不会有任何影响。我们还简化了 Elastic 许可，使其授权条件尽可能的宽松。

我们的大多数用户和客户已经将 Elastic 作为默认分发版的一部分使用，该分发版使用 Elastic 许可已有近三年的时间。然而，我们希望尽一切努力做到尽可能的开放和宽松，同时防止公共云服务提供商在不向社区回馈的情况下将托管服务对外提供。对于已经在使用 Elastic 许可的用户，如果您愿意，可以继续使用！这对您不会有任何影响。事实上，通过 Elastic 许可 2.0 的更新，我们已经使 Elastic 许可的授权条件变得更加宽松了。我们之所以选择将 SSPL 仍作为用户的选项，也是因为我们知道，由于它的创建者 MongoDB 对它的使用，让它成为了数百万用户和公司所熟悉的许可，并且它提供了我们非常珍视的自由。

我们对 Elasticsearch 和 Kibana 采用 Elastic 许可 + SSPL 的双重授权许可模式，以为用户提供选择。SSPL 是一个最初由 MongoDB 创建的可获得源代码的许可，MongoDB 当时设计了一个体现开源理念的许可，允许自由随意地使用、修改和重新分发产品源代码，但有一个基本要求：在 SSPL 协议下，如果您将产品作为服务对外提供，则必须同时公开发布任何修改以及您自己管理层的源代码。

SSPL 基于 GPLv3 构建而成，被认为是一种 Copyleft 许可。也就是说，如果您使用源代码并创建衍生作品，那么这些衍生作品也必须根据 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 下提供，该许可没有任何 Copyleft 限制，允许免费使用、修改和重新分发，但为了保护我们的产品和品牌，需要遵循如上所述的 3 个基本限制条件。

如果您是从源代码构建 Elasticsearch 和（或）Kibana，您可以选用 SSPL 或 Elastic 许可来管理您对源代码的使用。该条款仅适用于以下情况：您从源代码进行构建，选择 SSPL 作为管理许可，并且您将 Elasticsearch 和 Kibana 作为付费服务对外提供。也就是说，只有当您“将 Elasticsearch 和 Kibana 以托管服务的形式”作为主要产品/服务提供，或者是产品/服务的主要部分时，该条款才适用。

此次源代码许可变更不会影响您。您可以继续使用我们的默认分发版，或在 Elastic 许可下免费基于该分发版开发应用程序。这个可获得源代码的许可不包含任何 Copyleft 规定，默认功能免费提供。如需了解具体示例，您可以查看我们对 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 的方式。除了 Java 高级 REST 客户端 (Java HLRC) 之外，我们的客户端库仍然使用 Apache 2.0 许可授权。

Java HLRC 依赖于 Elasticsearch 的核心，因此这个客户端库将使用 Elastic 许可授权。我们将逐渐消除这种依赖性，并将 Java HLRC 改为 Apache 2.0 许可授权。在完全消除之前，为免存疑，我们认为在开发应用程序或用于访问 Elasticsearch 的库时使用 Java HLRC 作为客户端库，并不构成 Elastic 许可证下的衍生作品，而且这不会对您使用此客户端库授权应用程序的源代码或分发它的方式产生任何影响。

更新：在 7.15.0 版中，Java HLRC 已被弃用，取而代之的是 Java API 客户端。Java API 客户端是采用 Apache 2.0 进行许可授权的。

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

此次变更不会影响您构建或授权 Elasticsearch 或 Kibana 插件的方式。为免存疑，构建用于 Elasticsearch 或 Kibana 的插件并不构成衍生作品，也不会对插件源代码的授权方式产生任何影响。

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

没有影响。我们与这些公共云服务提供商有着良好的商业关系，并将继续与他们合作。Elastic Cloud 可在 Microsoft、Google 和 AWS 上使用，不管其中哪个平台，我们都是他们市场生态系统的一部分。我们与阿里巴巴和腾讯建立了合作关系，允许他们提供 Elasticsearch 服务。这些合作关系不受许可变更公告的影响。

如上所述，我们的总体目标是与公共云服务提供商合作，这些提供商采用我们的产品并将我们的产品作为服务对外提供。我们与 Google Cloud、Microsoft Azure、阿里云和腾讯云建立了紧密的合作关系。我们还与 AWS 合作，让 Elastic Cloud 入驻 AWS Marketplace，并继续投资于这一关系，致力于将 Elastic Cloud 打造成 AWS 上优质的 Elasticsearch 和 Kibana 托管平台。但是，我们与 AWS 在 Amazon Elasticsearch Service 上没有进行任何商业合作。我们不积极支持这项服务，也不希望我们在软件上的投资让这项服务直接受益。为了透明起见，我们还在与 AWS 进行诉讼，详见这里和这里。

我们以此用作博文标题是为了继续三年前开始的转变，当时我们首次宣布使用 Elastic 许可开放 X-Pack。在我们传递的讯息中，我们非常有意地选择关注“开放”，而不是“开源”。对于由此造成的任何混乱或歧义，我们深表歉意。博文中的第一句话将本次变更已经说得很清楚了。
此次变更的主要原因是为了保护我们的投资，不允许云服务提供商在没有与我们及社区合作的情况下直接将我们的产品作为服务对外提供。在此变更过程中，我们一直在努力保持尽可能的免费和开放。

如果您的应用程序不是托管型或托管服务，那么您可能根本不会受到影响。如果您有其他疑问或需要进一步说明，请通过 [email protected] 与我们联系。

我们希望鼓励用户为 Kibana 制作插件。您可以继续为 Kibana 构建使用 EUI 或 Elastic 图表的插件。如果您有其他疑问，请通过 [email protected] 与我们联系。

• 2021 年 12 月 21 日：更新了有关新 Java API 客户端的详细信息
• 2021 年 6 月 7 日：增加了两个关于 EUI 和 Elastic 图表许可的问题
• 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 的关系有什么影响吗？”三个问题和回答。