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

劍指雲廠商

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) 的簽署人送出的任何代碼。

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