共计 1641 个字符，预计需要花费 5 分钟才能阅读完成。
Elastic 和 AWS 就开源协定的争议，再次降级了。
早在 1 月 15 日，Elastic 在官网发文称将对 Elasticsearch 和 Kibana 在许可证方面进行了重大的更改，由开源 Apache 2.0 许可证改为采纳 SSPL（服务器端公共许可证）。
对此，Elastic 公司 CEO Shay Banon 给出的理由是：“之所以做出这一决定，次要起因是为了阻止云厂商的「白嫖」。”
Elastic 在官网申明中示意，变更确保了他们的社区和客户能够自在凋谢地应用、批改、从新公布和合作代码。它还通过限度云服务提供商在没有回馈的状况下将 Elasticsearch 和 Kibana 作为一项服务提供给用户，来爱护他们在开发收费和凋谢的产品方面的继续投资。
对于 Elastic 的这一决策，AWS 作为云厂商的代表率先给出了本身的态度 —— Elastic 正在毁坏凋谢源代码自身的定义，而 AWS 将加紧创立和保护由开源 Elasticsearch 和 Kibana 取得 Apache 许可 2.0 版（ALv2）许可的分支。
一、Elastic 为什么要批改开源协定？
计算机技术进入云时代后，与云平台的争端成为了开源软件业务无奈回避的一个难题。
这背地的起因，是云厂商通过打包这些产品进行基于云的 SaaS 服务，对这些公司造成了间接的竞争，「挪用」了原本能够从新投入到产品中的资金，侵害了用户和社区的利益。相似于 MongoDB、Redis Labs 和 Confluent 等公司为了避免竞争不得不抉择更改了软件许可证，从原来的开源许可证转向更严格的条款，限度了软件的性能。
尽管每家开源公司都采取了不同的办法来解决这个问题，但他们个别都批改了开源许可证，以爱护他们在自由软件上的投资，同时致力保护凋谢、通明和合作的准则。同样，Elastic 也是对他们的源代码以受权的形式进行针对性的批改。
二、来自云厂商的质疑
尽管 Elastic 示意这一扭转不会影响绝大多数用户，但这种做法在某种层面上「背离了开源之路」。
AWS 于明天公布的公开信中示意，“Elastic 认为 SSPL 是‘自在凋谢’的说法具备误导性和谬误性。他们试图声称凋谢源代码的益处，同时毁坏凋谢源代码自身的定义。”
SSPL 是一种非凋谢源代码许可证，但其的一些设定却让它看起来更像一种凋谢源代码许可证，这含糊了两者之间的界线。
而 AWS 之所以提出本身的质疑，还有一个很重要的起因是“2018 年 4 月当 Elastic 将其专有许可软件与 ALv2 代码混合在一起时，给出了开源的承诺，但当初‘状况曾经扭转’。”
同时 AWS 也指出，Elastic 试图通过限度许可将使其他人无奈提供托管的 Elasticsearch 服务，从而建设更大的业务。尽管 Elastic 有权更改其许可证，但他们也不应颠覆此前的承诺。
三、Elastic 用户，走向何方？
AWS 对 Elastic 的质疑，能够追溯到 2019 年 3 月份。过后 AWS 就发表了 Elasticsearch 公开发行版。然而，该版本并没有失去所有社区成员的反对。尽管 AWS 示意，他们公布公开发行版是为了确保 Elasticsearch 放弃齐全开源，但技术社区的其余成员对此大部分持保留意见。
AppsFlyer 开发人员关系负责人 Sharone Zitzman 在过后对 AWS 宣示决定的形式提出了批评。她示意：
向一家充满活力并深深扎根于 OSS 价值观之中的开源公司宣扬开源 —— 该公司对其盈利和保护一流产品的需要是齐全通明的，而对其可靠性提出可疑的断言是十分虚假的。这是亚马逊看到他人闪亮的玩具，想要失去它。这就是分叉。
Chef 的首席技术官 Adam Jacob 则认为 AWS 的这一动作总体上是对开源软件的踊跃动作。他解释说，次要赢家是自由软件的价值观：
我百分之百确定：这不是开源的失败。这是对于开源和自由软件的最粗浅、最根本的事实。你，作为一个用户，有权力。这些权力延长到所有人，包含 AWS —— 要不，它们就基本不会存在。
而这次 Elastic 做出这一决定后，不晓得社区成员以及开源社区用户，将持何种观点、做出何种抉择。