AWS 开源：与社区一起逐步实现真正开源的 Elasticsearch-技术圈

   
    点击上方“逆锋起笔”，公众号回复 pdf
   
   
    领取大佬们推荐的学习资料

技术编辑：鸣飞丨发自思否编辑部

近日，Elastic 在官网发文称将对 Elasticsearch 和 Kibana 在许可证方面进行了重大的更改，由开源 Apache 2.0 许可证改为采用 Elastic License 和 SSPL（服务器端公共许可证）。

对于 Elastic 的这一决策，AWS 在 AWS 开源博客官方博客发表文章《Stepping up for a truly open source Elasticsearch》 — Elastic 正在破坏开放源代码本身的定义，而 AWS 将加紧创建和维护由开源 Elasticsearch 和 Kibana 获得 Apache 许可 2.0 版（ALv2）许可的分支。

以下为 AWS 开源博客发表的文章全文翻译。

上周，Elastic 宣布他们将改变软件许可策略，将不再以 Apache License 2.0 版本（ALv2）发布 Elasticsearch 和Kibana 的新版本。取而代之的是，新版本的软件将在 Elastic License（限制了软件的使用方式）或 Server Side Public License（有一些限制让很多开源社区无法接受）下提供。这意味着 Elasticsearch 和 Kibana 将不再是开源软件。为了确保这两个软件包的开源版本仍然可用并得到很好的支持，包括在我们自己的产品中，我们今天宣布 AWS 将出面创建并维护一个 ALv2 授权的开源 Elasticsearch 和 Kibana 的分叉。

这对 Elasticsearch 社区的 Open Distro 意味着什么？

我们在 2019 年推出了 Open Distro for Elasticsearch，为客户和开发人员提供功能齐全的 Elasticsearch 发行版，提供ALv2授权软件的所有自由。Open Distro for Elasticsearch 是一个 100% 开源的发行版，它提供了几乎每个 Elasticsearch 用户或开发者都需要的功能，包括支持网络加密和访问控制。在构建 Open Distro 的过程中，我们遵循了 "上游先行 "的推荐开源开发实践。所有对Elasticsearch 的改动都以上游 pull requests 的形式发送(#42066, #42658, #43284, #43839, #53643, #57271, #59563, #61400, #64513)，然后我们将 Elastic 提供的 "oss "构建包含在我们的发行版中。这确保了我们与上游开发者和维护者合作，而不是创建一个软件的 "fork"。

选择分叉一个项目并不是一个轻率的决定，但是当一个社区的需求出现分歧时，这可能是一条正确的前进道路--就像这里的情况一样。开源软件的一个重要好处是，当这样的事情发生时，如果开发者有足够的动力，他们已经拥有了所有需要的权利，可以自己接手工作。这里有很多成功的案例，比如 Grafana 就是从 Kibana 3 的分叉中产生的。

当AWS决定提供一个基于开源项目的服务时，我们确保我们有能力并准备好在必要时自己维护它。AWS 带来了多年与这些代码库合作的经验，同时也为 Elasticsearch 和 Apache Lucene（Elasticsearch构建的核心搜索库）做出了上游代码贡献--仅 2020 年就有超过 230 个Lucene 贡献。

我们对 Elasticsearch 和 Kibana 的分叉将基于最新的 ALv2 授权代码库，7.10 版本。我们将在未来几周内发布新的 GitHub 仓库。随着时间的推移，这两个版本将被包含在现有的 Open Distro 发行版中，取代 Elastic 提供的 ALv2 构建。我们将长期参与其中，并将以促进健康和可持续的开源实践的方式开展工作--包括实现与贡献者社区共享项目治理。

这对亚马逊 Elasticsearch 服务客户意味着什么？

您可以放心，无论是 Elastic 的许可证变更，还是我们分叉的决定，都不会对您目前享受的 Amazon Elasticsearch 服务（Amazon ES）产生任何负面影响。今天，我们在 Amazon ES 上提供了 18 个版本的Elasticsearch，这些版本都不会受到许可证变更的影响。

未来，Amazon ES 将由 Elasticsearch 和 Kibana 的新分叉提供支持。我们将继续提供新功能、修复和增强功能。我们致力于提供兼容性，以消除您更新客户端或应用程序代码的需要。就像我们今天所做的那样，我们将为您提供一个无缝的升级路径到新版本的软件。

这一变化不会减缓我们为客户提供的增强速度。如果有的话，一个社区拥有的 Elasticsearch 代码库为我们提供了新的机会，使我们在提高稳定性、可扩展性、弹性和性能方面的进展更快。

这对开源社区意味着什么？

开发者出于许多原因而接受开放源码软件，其中最重要的原因可能是可以自由地在他们希望的地方和方式使用该软件。关注公众号逆锋起笔，回复 pdf，下载你需要的各种学习资料。

自 1998 年 "开源 "一词被提出以来，它就有了特定的含义。Elastic 关于 SSPL 是 "自由开放 "的说法是误导和错误的。他们试图宣称开源的好处，同时又在削去开源本身的定义。他们对 SSPL 的选择掩盖了这一点。SSPL 是一个非开源许可证，它的设计看起来像一个开源许可证，模糊了两者之间的界限。正如 Fedora 社区所说的那样，"[将 SSPL 视为'自由'或'开源'会导致[一个]阴影笼罩在 FOSS 生态系统的所有其他许可证上。"

2018 年 4 月，当 Elastic 将他们的专有授权软件与 ALv2 代码共同混合时，他们在 "We Opened X-Pack "中承诺。"我们没有改变Elasticsearch、Kibana、Beats 和 Logstash 的任何 Apache 2.0 代码的授权--我们永远不会改变。" 上周，在违背了这一承诺之后，Elastic 更新了同一页面，并在脚注中写道："情况有变"。

Elastic 知道他们做的事情很蹊跷。社区已经告诉他们这一点（例如，见Brasseur、Quinn、DeVault 和 Jacob）。这也是为什么他们觉得有必要写一个额外的虚张声势的博客（在他们最初的许可证更改博客之上），试图将他们的行为解释为 "AWS 让我们这么做"。大多数人并没有被愚弄。我们没有让他们做任何事情。他们认为，限制他们的许可证将锁定其他人提供托管 Elasticsearch 服务，这将让 Elastic 建立更大的业务。当然 Elastic 有权改变他们的许可证，拥有自己的决定。

同时，我们对我们与 Open Distro for Elasticsearch 一起踏上的长期旅程感到兴奋。我们期待着为 Elasticsearch 和 Kibana 提供一个使用 ALv2 许可证的真正的开源选择，并与社区一起建设和支持这个未来。

本文是翻译，阅读原文：

https://amazonaws-china.com/cn/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

往期精选

微软又一开源力作！专门针对老旧照片

一个 Java 开源商城项目，值得好好研究一下！

写开源项目到底究竟有多赚钱？

解析 C 语言编程中的几点“坑”操作

   
   
    点个『在看』支持下