換協議、改代碼，Elastic要逼開發者二選一？

沒有企業希望他們從自己創造的產品中獲得的收益比依賴該產品的其他企業要少幾個數量級。 

為應對云服務提供商，Elastic 近日對其 Elasticsearch 數據庫的官方 Python 客戶端（Elasticsearch-py）做出了修改，使其無法與各分叉版本相兼容，之后又粗暴地關閉了 GitHub 上的話題評論。這一行為引起了廣大開發者激烈討論。

Elasticsearch 是一款數據庫管理器與分析引擎，在行業內被廣泛使用。官方客戶端在 Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby 和許多其他語言中都是可用的。根據 DB-Engines 的排名顯示，Elasticsearch 是最受歡迎的企業搜索引擎，其次是 Apache Solr。

Elasticsearch-py 旨在為 Python 中一切與 Elasticsearch 相關的代碼提供共識，目前客戶端的下載量已經超過 20.2 萬次。Elasticsearch-py 一直堅持以中立性與高可擴展性作為基本定位，而負責運行 Elasticsearch 查詢的高級庫 Elasticsearch DSL，也將 Elasticsearch-py 以庫的形式來使用。

這次代碼修改也是 Elastic 與 AWS 矛盾激化的體現。

作為一款開源產品，Elasticsearch 在今年 1 月份調整了其開源許可證，將之前的 Apache 2.0 許可授權改為雙重許可模式（即 SSPL 1.0 和 Elastic 許可），用戶可以選擇適合自己的許可方式。促使 Elastic 做出該決定的最大原因便是，以此應對公有云平臺（特別是 AWS）上發生的不公平使用情況。

“隨著很多公司不斷向 SaaS 轉型，有些云服務提供商使用了開源產品，并在不向社區提供任何回饋的情況下，將其作為一項對外提供的服務。這種做法轉移了本可以再投資到產品上的資金，損害了用戶和社區的利益。”Elastic 在 聲明 中寫道，“社區逐漸認識到，開源公司只有更好地保護自己的軟件，才能保持高水平的投資和創新。”

為了應對這一變化，AWS 搶在許可證變更之前對 Elasticsearch 進行了分叉，構建起 Open Distro for Elasticsearch，之后逐漸演變為 OpenSearch，并在上個月發布了 1.0 版本。

根據 AWS 介紹，OpenSearch 是一個社區驅動的開源搜索和分析套件，源自 Apache 2.0 許可的 Elasticsearch 7.10.2 和 Kibana 7.10.2。它包括一個搜索引擎守護進程 (OpenSearch)、一個可視化和用戶界面 (OpenSearch Dashboards)，以及用于彈性搜索的 Open Distro，包括安全、警報、異常檢測等功能。

根據亞馬遜網絡服務副總裁 Adrian Cockcroft 的說法，發行說明和文檔未能闡明什么是開源的、什么不是，這讓企業開發人員面臨這樣的情況：他們會在無意中使用到可能會在未來造成財務或法律問題的代碼。AWS 的介入可以確保其客戶可以繼續運行 Elasticsearch，而不必擔心他們的計費周期可能會中斷。不過有開發者表示，OpenSearch 社區活躍度還有待提高。

如今，開發者們注意到，Elasticsearch-py 的源代碼已經被悄悄更改，其會單獨檢查數據庫屬于 Elastic 還是分叉產物。更新說明中提到，“如果響應當中沒有 X-Elastic-Product HTTP 標頭，或者 X-Elastic-Product HTTP 標頭的值不是 Elasticsearch，就會引發錯誤。”

“神仙打架、凡人遭殃”。這場企業間的對抗深深傷害了曾為 Elasticsearch 做出貢獻的開源開發者們。在數據搜索管理開源項目 Invenio 產品經理 Lars Holm Nielsen 看來，Elastic 是在逼迫普通開發者站隊。

“我們開發了一款開源產品，能夠輕松與 Elasticsearch 或者 OpenSearch 配合使用，而用戶再根據自己的需求選擇到底使用 Elasticsearch 還是 OpenSearch……Elastic 的種種行為確實沉重打擊了我們對該公司及其旗下產品的信心。別把鍋都甩給 Amazon，Elastic 之前已經修改過服務器許可證了，根本沒必要再把其他分叉版本拒之門外。”Nielsen 表示。

Elastic 公司高級工程技術經理 Philip Krauss 則回應稱，“Amazon OpenSearch 是另外一款不同的產品。雖然與 Elasticsearch 有些淵源，但二者之間的諸多差異必然導致大量問題甚至混亂。”

目前該話題在 GitHub 上的評論功能已被關閉，后續留言也被刪除。

做出修改的不止是其官方 Python 客戶端，Elasticsearch 的.NET Connector 也沒能幸免，同時開始出現諸如“客戶端發現服務器不是受支持的 Elasticsearch 發行版”等錯誤提示。

面對用戶的抱怨，Elastic 高級軟件工程師 Steve Gordon 回應稱：“建議大家升級到 Elasticsearch 的最新默認發行版，此版本可以在 Elastic License v2 下免費使用……我們將此次修改視為增強功能，因為它只會影響到不受支持的客戶端與服務器組合。在受支持的配置中，變更不會給業務造成任何影響。這次調整的目的是通過快速失敗的方式聲明不兼容性，避免消費者錯誤地認為可以在未經測試、且可能無法達成預期效果的配置下長期運行負載。”

此外，還有一個變化：Elasticsearch 的 Java 客戶端也已切換為 Elastic License。這個問題已經在 OpenSearch 社區中引發用戶們的焦慮。

“OpenSearch 要怎么處理當前可用的各種編程語言所對應的多種 connector 和 binding？根據報道，其中很多已經集成了反競爭機制。”有開發者提出疑問。

許可約束跟產品檢查還不是一回事。Elastic 公司表示，“我們的客戶端庫仍然遵循 Apache 2.0 許可證，但其中不包括 Java 高級 Rest 客戶端（Java HLRC）。Java HLRC 依賴于 Elasticsearch 核心，因此該客戶端庫將采用 Elastic License。隨著時間推移，我們會逐步消除這種依賴性，并將 Java HLRC 轉移至 Apache 2.0 許可。”

如果在代碼層面阻止連接，那么遵循 Apache 2.0 許可證的這些客戶端（包括 Python 與.NET 客戶端）將無法與 OpenSearch 協同使用。當然，各客戶端的分叉與修改難度并不高，應該還是會有解決辦法。

云的興起給基礎軟件公司和開源公司提供了很好的分發渠道，能夠更好地構建競爭壁壘，還可以迅速將開源用戶發展到云上來。在云上統一部署，省去了企業要給每一個用戶安裝、部署甚至定制化的高成本。但這對傳統的開源軟件企業的商業模式形成了沖擊。

近年來，云廠商與開源廠商之間的矛盾日益顯著。早在 18 年底，圖數據庫 Neo4j 便宣布，從 Neo4j 3.5 版本開始，企業版僅在商業許可下提供，不再提供源代碼。近幾年，Confluent、MongoDB、Kafka、Redis 等也紛紛修改開源協議，限制云廠商從中牟利卻不做貢獻的行為。

針對兩個陣營之間的紛爭，開發者們的觀點也不相同。

“我個人也受不了 Elastic，因為他們收取企業級的支持費用，然后提供開源級別的支持。你在遇到一個問題時，得到的回應通常是‘為什么要嘗試這樣做?’，或者‘請參考這個自 2016 年以來就不新鮮的問題’。”有代碼貢獻者分享了自己使用 Elastic 的感受。

隨著競爭的加劇，開源軟件背后的商業公司可能不得不考慮如何進化自己的服務和商業模式。

不過，Open UK 首席執行官兼首席政策官 Amanda Brock 認為，開源是多種多樣的，但它不是一種商業模式。像 Elastic 這樣對云提供商使用其代碼方式感到不滿的公司并沒有完全理解開源許可證的含義。“根據我的經驗，云提供廠商正在以開源許可范圍內可接受的方式使用它。”

當然，也有開發者表示理解 Elastic 開源廠商的做法：

如果 Elastic 在 ElasticSearch 上取得成功，那么完全可以預想到，其他公司也會加入這一風口，并嘗試從中獲利。作為創造產品的公司，可能并不是能從中獲利最多的公司，企業應該計劃獲得足夠的利潤。但事情變得復雜的地方在于，沒有企業希望他們從自己創造的產品中獲得的收益比依賴該產品的其他企業要少幾個數量級。 

開源軟件企業們沒有預見到，云服務提供廠商的出現，最大限度地降低了他們的價值主張。亞馬遜可以投入大量資源，甚至可能比 Elastic 本身還要多。有人可能會爭辯說，亞馬遜濫用了他們在云服務領域的壟斷地位，提供了 Elastic 永遠無法與之競爭的捆綁式 ElasticSearch 體驗。 

即使他們開發了替代的內部產品，它看起來也與當年 Microsoft 將 Internet Explorer 與 Windows 捆綁在一起的情況完全相同。即使在今天，如果企業愿意開發一個開源或免費的軟件產品，一旦足夠成功，便很可能會成為大型企業的利用目標。公司始終可以選擇重新許可內部編寫的代碼，以及由適當的貢獻者許可協議 (CLA) 的簽署人提交的任何代碼。 

利益分配問題確實是開源廠商和云廠商之間最大的爭論點，這個問題或許還是要從商業角度解決，看誰能在兩者之間的博弈中占據上風。

參考鏈接：

https://www.theregister.com/2021/08/09/elasticsearch_python_client_change/

本文來自微信公眾號 “InfoQ”（ID：infoqchina），作者：褚杏娟、核子可樂，36氪經授權發布。