共计 2676 个字符，预计需要花费 7 分钟才能阅读完成。
近日，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 代码库为咱们提供了新的机会，使咱们在进步稳定性、可扩展性、弹性和性能方面的停顿更快。
这对开源社区意味着什么？
开发者出于许多起因而承受开放源码软件，其中最重要的起因可能是能够自在地在他们心愿的中央和形式应用该软件。
自 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 许可证的真正的开源抉择，并与社区一起建设和反对这个将来。
