AWS 發文！直指 Elastic 正在破壞開放源代碼自己的定義

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）許可的分支。

1、Elastic 爲何要修改開源協議？

計算機技術進入雲時代後，與雲平臺的爭端成爲了開源軟件業務沒法逃避的一個難題。

這背後的緣由，是雲廠商經過打包這些產品進行基於雲的 SaaS 服務，對這些公司造成了直接的競爭，「挪用」了原本能夠從新投入到產品中的資金，損害了用戶和社區的利益。相似於 MongoDB 、 Redis Labs 和 Confluent 等公司爲了防止競爭不得不選擇更改了軟件許可證，從原來的開源許可證轉向更嚴格的條款，限制了軟件的功能。

雖然每家開源公司都採起了不一樣的方法來解決這個問題，但他們通常都修改了開源許可證，以保護他們在自由軟件上的投資，同時努力維護開放、透明和協做的原則。一樣，Elastic 也是對他們的源代碼以受權的方式進行鍼對性的修改。

2、來自雲廠商的質疑

雖然 Elastic 表示這一改變不會影響絕大多數用戶，但這種作法在某種層面上「背離了開源之路」。

AWS 於今天發佈的公開信中表示，「Elastic 認爲 SSPL 是‘自由開放’的說法具備誤導性和錯誤性。他們試圖宣稱開放源代碼的好處，同時破壞開放源代碼自己的定義。」

SSPL 是一種非開放源代碼許可證，但其的一些設定卻讓它看起來更像一種開放源代碼許可證，這模糊了二者之間的界限。

而 AWS 之因此提出自身的質疑，還有一個很重要的緣由是「2018 年 4 月當 Elastic 將其專有許可軟件與 ALv2 代碼混合在一塊兒時，給出了開源的承諾，但如今‘狀況已經改變’。」

同時 AWS 也指出，Elastic 試圖經過限制許可將使其餘人沒法提供託管的 Elasticsearch 服務，從而創建更大的業務。雖然 Elastic 有權更改其許可證，但他們也不該推翻此前的承諾。

3、Elastic 用戶，走向何方？

AWS 對 Elastic 的質疑，能夠追溯到 2019 年 3 月份。當時 AWS 就宣佈了 Elasticsearch 公開發行版。然而，該版本並無獲得全部社區成員的支持。雖然 AWS 表示，他們發佈公開發行版是爲了確保 Elasticsearch 保持徹底開源，但技術社區的其餘成員對此大部分持保留意見。

AppsFlyer 開發人員關係負責人 Sharone Zitzman 在當時對 AWS 宣示決定的方式提出了批評。她表示：

向一家充滿活力並深深紮根於 OSS 價值觀之中的開源公司鼓吹開源 —— 該公司對其盈利和維護一流產品的需求是徹底透明的，而對其可靠性提出可疑的斷言是很是虛僞的。這是亞馬遜看到別人閃亮的玩具，想要獲得它。這就是分叉。

Chef 的首席技術官 Adam Jacob 則認爲 AWS 的這一舉措整體上是對開源軟件的積極舉措。他解釋說，主要贏家是自由軟件的價值觀：

我百分之百肯定：這不是開源的失敗。這是關於開源和自由軟件的最深入、最基本的事實。你，做爲一個用戶，有權利。這些權利延伸到全部人，包括 AWS —— 要不，它們就根本不會存在。

而此次 Elastic 作出這一決定後，不知道社區成員以及開源社區用戶，將持何種觀點、作出何種選擇。