AWS 開源:與社區一塊兒逐步實現真正開源的 Elasticsearch

近日,Elastic 在官網發文稱將對 Elasticsearch 和 Kibana 在許可證方面進行了重大的更改,由開源 Apache 2.0 許可證改成採用 Elastic License 和 SSPL(服務器端公共許可證)。html

對於 Elastic 的這一決策,AWS 在 AWS 開源博客官方博客發表文章《Stepping up for a truly open source Elasticsearch》 — Elastic 正在破壞開放源代碼自己的定義,而 AWS 將加緊建立和維護由開源 Elasticsearch 和 Kibana 得到 Apache 許可 2.0 版(ALv2)許可的分支。node

如下爲 AWS 開源博客發表的文章全文翻譯。git


上週,Elastic 宣佈他們將改變軟件許可策略,將再也不以 Apache License 2.0 版本(ALv2)發佈 Elasticsearch 和Kibana 的新版本。取而代之的是,新版本的軟件將在 Elastic License(限制了軟件的使用方式)或 Server Side Public License(有一些限制讓不少開源社區沒法接受)下提供。這意味着 Elasticsearch 和 Kibana 將再也不是開源軟件。爲了確保這兩個軟件包的開源版本仍然可用並獲得很好的支持,包括在咱們本身的產品中,咱們今天宣佈 AWS 將出面建立並維護一個 ALv2 受權的開源 Elasticsearch 和 Kibana 的分叉。github

這對 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"。segmentfault

選擇分叉一個項目並非一個輕率的決定,可是當一個社區的需求出現分歧時,這多是一條正確的前進道路--就像這裏的狀況同樣。開源軟件的一個重要好處是,當這樣的事情發生時,若是開發者有足夠的動力,他們已經擁有了全部須要的權利,能夠本身接手工做。這裏有不少成功的案例,好比 Grafana 就是從 Kibana 3 的分叉中產生的。服務器

當AWS決定提供一個基於開源項目的服務時,咱們確保咱們有能力並準備好在必要時本身維護它。AWS 帶來了多年與這些代碼庫合做的經驗,同時也爲 Elasticsearch 和 Apache Lucene(Elasticsearch構建的核心搜索庫)作出了上游代碼貢獻--僅 2020 年就有超過 230 個Lucene 貢獻。網絡

咱們對 Elasticsearch 和 Kibana 的分叉將基於最新的 ALv2 受權代碼庫,7.10 版本。咱們將在將來幾周內發佈新的 GitHub 倉庫。隨着時間的推移,這兩個版本將被包含在現有的 Open Distro 發行版中,取代 Elastic 提供的 ALv2 構建。咱們將長期參與其中,並將以促進健康和可持續的開源實踐的方式開展工做--包括實現與貢獻者社區共享項目治理。elasticsearch

這對亞馬遜 Elasticsearch 服務客戶意味着什麼?

您能夠放心,不管是 Elastic 的許可證變動,仍是咱們分叉的決定,都不會對您目前享受的 Amazon Elasticsearch 服務(Amazon ES)產生任何負面影響。今天,咱們在 Amazon ES 上提供了 18 個版本的Elasticsearch,這些版本都不會受到許可證變動的影響。ide

將來,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 知道他們作的事情很蹊蹺。社區已經告訴他們這一點(例如,見BrasseurQuinnDeVaultJacob)。這也是爲何他們以爲有必要寫一個額外的虛張聲勢的博客(在他們最初的許可證更改博客之上),試圖將他們的行爲解釋爲 "AWS 讓咱們這麼作"。大多數人並無被愚弄。咱們沒有讓他們作任何事情。他們認爲,限制他們的許可證將鎖定其餘人提供託管 Elasticsearch 服務,這將讓 Elastic 創建更大的業務。固然 Elastic 有權改變他們的許可證,擁有本身的決定。

同時,咱們對咱們與 Open Distro for Elasticsearch 一塊兒踏上的長期旅程感到興奮。咱們期待着爲 Elasticsearch 和 Kibana 提供一個使用 ALv2 許可證的真正的開源選擇,並與社區一塊兒建設和支持這個將來。

image.png

相關文章
相關標籤/搜索