新闻

许可协议变更澄清

作者
Shay Banon

关于最近对 Elasticsearch 和 Kibana 的许可变更，我们有几个问题需要澄清，虽然我们一直在更新常见问答，但我们还是想说明一下哪些用户会受到本次变更的影响：

  • 我们的本地部署客户或 Elastic Cloud 客户不会受到影响。
  • 我们绝大多数的用户不会受到影响。
  • 那些采用我们的产品并直接将产品作为一项服务（如 Amazon Elasticsearch Service）对外出售的用户将会受到影响。

如果您正在使用这些产品或在 Elasticsearch 和 Kibana 之上构建应用程序，我们的主旨是不让您受到影响。我们一直在根据收到的问题不断更新我们的常见问答，但如果您还有其他需要解答的问题，请通过 [email protected] 与我们联系。

此外，我们还希望解释一下双重授权许可模式的运行机制。我们把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 源代码变更为采用 SSPL + Elastic 许可的双重授权许可模式后，会有以下两种许可模式供您选择：

  • 我们熟知的 SSPL — 当今有数百万人在基于这个许可使用 MongoDB。我们选择这个许可作为许可模式之一，是为了让数百万使用 MongoDB 的开发人员更易于作出选择。SSPL 是一种基于 GPL 的 Copyleft 许可，旨在让用户在多个方面获得开源许可提供的自由使用权，尽管它不是 OSI 批准的许可，也不被认为是开源许可。
  • Elastic 许可也广为人知 — 如果您使用的是我们的默认分发版，就像过去 3 年里数百万用户和超过 90% 的下载用户一样，您已经在使用它了，那么您不会受到任何影响。根据这个许可，可获得源代码，允许免费使用，而且没有 SSPL 的 Copyleft 限制。Elastic 许可禁止下列操作：将我们的产品直接作为一项服务对外出售（如 Amazon Elasticsearch Service）；重新分发产品；篡改源代码以达到自己在不订阅的情况下使用我们付费功能的目的，或者将修改后的版本投入生产之用。

Elastic 许可的未来

如我们的常见问答中所述，根据截止目前收到的反馈，我们将考虑如何进一步简化 Elastic 许可。我们的目标与 BSL 的精神高度一致。BSL 由 MariaDB 创建并由 CockroachDB 采用，他们在自己优秀的博客中谈到了为何决定采用这种方法：“……认为这是平衡商业需求和我们对开源承诺的最佳方式”。

得到 OSI 创始人 Bruce Perens 认可的 BSL 是一个简单的参数化许可，每个公司都可以根据自身需求进行定制。只要满足“附加权利”的各项参数，根据这个许可就能够获得复制、修改、创建衍生作品、重新分发的权利。我们正在评估允许用于生产的附加权利授予，只有 3 个基本限制条件：

  • 您不得使用授权作品来将“Elasticsearch/Kibana 作为一项服务”对外提供。
  • 您不得在不订阅的情况下破解软件来启用我们的付费功能。
  • 您不得移除、替换或隐藏产品的 Elastic 品牌和商标（例如，不得更换徽标等）。

然后经过一段时间（通常为 3-4 年，但不超过 5 年），这些限制会失效，源代码将自动转换为采用开源许可（对我们来说，就是 Apache 2.0）。

需要明确的是，BSL 不是 OSI 批准的许可。

我们正在花时间来解决这个问题 — 理想的情况是提供一个单一许可，既能涵盖我们的免费和付费功能，同时又能最大程度地保持开放，这种平衡很微妙。尤其是如果这意味着代码在 3-4 年后就变成开源代码的话，更需要认真对待。如果我们能够安全地实现这一步，便可为我们的商业功能提供更多的自由，并为我们的分发版提供一个简单、单一的许可。这是一项值得为之努力的挑战。我们担心我们的产品遭到滥用，想必您也知道都有谁 :)，所以请耐心等待。

如果我们最终认为这不是正确的方法，我们会考虑将许可拆分为基于 BSL 的 Elastic 社区许可和简化的 Elastic 许可，分别用于提供免费功能和付费功能。

正如我们在博文中提到的，我们的目的是在下一个版本 7.11 发布之前完成这个变更，所以我们非常希望得到您的反馈！请通过 [email protected] 告诉我们这种方法是否适用于您的用例。