新闻

许可协议变更澄清

关于最近对 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] 告诉我们这种方法是否适用于您的用例。