Open Source 的商業模式？Elasticsearch 是不是要開始收費了？從 Elastic 與 Amazon 對 Elasticsearch 的開源授權爭議談起

近日 Elastic 與 Amazon 在 Elasticsearch 及 Kibana 的軟體授權協議上，進行了幾次隔空交火。

對於使用者而言，比較關心的是『當 Elastic 的 Elasticsearch 及 Kibana 的軟體授權協議更改後，對我有什麼影響？未來是不是要付費了？』；
對於創業或行銷領域的人，比較關心的是『自由開放源碼真的能賺錢嗎？怎麼樣的商業模式 (或稱為營利模式) 才是對的？』；
對於自由開放源碼授權領域的人，我們討論更本質的問題，『自由開放源碼有沒有商業模式？』。

讓我們先從此次事件談起。

Elastic CEO 表達對 Amazon 的不滿

2021 年 1 月 15 日，Elastic 創始人 Shay Banon 在公司官網宣佈, 從 Elastic 7.11 版本之後，Elasticsearch 與 Kibana 的自由開放源碼授權，將從原本的 Apache 2.0 變更為 SSPL (Server Side Public License) 與 Elastic License (商業付費授權) 的雙重授權模式。

Shay 同時表示, 這麼做的原因是希望公司與開發社群維持良好「公開」互動的初衷，不要像一些雲端服務公司 (文章特別指名 Amazon) 拿取 Elasticsearch 與 Kibana 的付出心血與貢獻來營利，卻沒有回饋。

同年 1 月 20 日，Shay 在公司官網再度表示，變更授權是因為長期受到 Amazon / AWS 打壓所進行的反抗。

文中亦表達出更強烈的用詞：

Amazon 於 2015 年基於 Elasticsearch 推出自己的服務，還將其稱為 Amazon Elasticsearch Service，這是很明顯的商標侵權行為。NOT OK。
想像一下當 Amazon 於 2015 年基於 Elasticsearch 推出其新服務 Amazon Elasticsearch Service 時，我們對此感到多麼驚訝。我們認為這是很明顯的商標侵權行為。NOT OK。
我在 2011 年用個人貸款註冊 Elasticsearch 商標，因為相信這是開源生態系統中規範。但看到商標如此公開地被濫用，令我特別痛苦。我們嘗試與 Amazon 溝通但失敗了，這迫使我們提起訴訟。NOT OK。
我們已經看到，這個商標問題使用戶感到困擾，他們認為 Amazon Elasticsearch Service 實際上是與 Elastic 共同合作提供的一項服務。這不是真的。NOT OK。
Amazon 還針對 Elasticsearch 另創了 Open Distro 分支，進一步分裂了我們的社群，引發了相當大的混亂。NOT OK。
最近，我們發現了更多挑戰道德底線的例子。我們已經在專有功能上與眾不同，但這些設計卻被認為是來自 Amazon 的 “靈感”。NOT OK。

Amazon 的回應

2021 年 1 月 21 日，Amazon 在公司官網回應表示，

我們在 2019 年推出了相容於 Elasticsearch 的 Open Distro，授權同樣採用 Apache 2.0 授權，是 100% 的自由開放源碼專案。雖然創立了分支，但對 Elasticsearch 所有的修改，都有回饋給 Elasticsearch。
Elastic 聲稱 SSPL 是 “自由和開放” 的說法具有誤導性和錯誤性。SSPL 是一種非自由開放的源碼授權，正如 Fedora 社群指出的那樣。
2018 年 4 月，當 Elastic 將專有功能 (非自由開放源碼授權的功能，如 X-Pack) 與開源的 Apache 2.0 程式碼混在一起時，為了避免 Elasticsearch 進一步私有化，我們才與其他公司創建了 Elasticsearch 分支。

Elastic 這麼做是有前跡可尋的

MongoDB 從 2018-2019 年時，也是把自家資料庫產品的授權，從 AGPL 3.0 轉變為 SSPL。至今，股價表現得不錯。同為其後上市的 Elastic，不管對內部或外部都很難不走同一條路，除非提出更有『利』的策略。

雖然走這招很明顯就是會損失開源/免費客戶量，但若有計算過轉換率，只要有信心留住一定比例，反而會更賺。至於要怎麼提高開源 / 免費客戶轉換，簡單地就是把砲口一致對外針對雲端大廠，是他們逼我們這麼做的，請支持並與我們一起走下去。

但用戶也不是笨蛋，大多都知道只是打著道德的虛招，可是對於已經儲存這麼多資料量的客戶，面對的不是開源 (FUD)，就是要付一筆資料遷移費用 (夠格的人力及時間成本)。相信 Elastic 也有分析過客戶群，就像 MongoDB 的財報，大多數營收都來自中小企業，剛好這些企業對開源 FUD，也沒能力或擔心遷移成敗，所以乾脆付錢消災了事比較快。

所以，若不是 MongoDB 與 Elasticsearch 都是『資料/儲存』型的開源軟體，否則很難玩這一招，而看著前人 MongoDB 的成功，Elastic 選擇同路策略也是可以理解的。

Elasticsearch 及 Kibana 是不是要開始付費了？SSPL 又是什麼？

是，也不是。

之前有提過 Elastic 7.11 版本之後，Elasticsearch 與 Kibana 的自由開放源碼授權將變更為 SSPL (Server Side Public License) 與 Elastic License (商業付費授權) 的雙重授權模式。

若是選擇 SSPL 是不是就不用付費了？而這授權條款又是什麼？

簡言之，只要使用 Elasticsearch 或 Kibana 時，連帶將其相關服務的程式 (不管這些程式屬於你的，或是任何第三方)，經實體或網路提供服務者，都需要依 SSPL 授權開放原始碼並提供任何人免費使用，否則就只能改採用商業付費授權的 Elastic License。

這些基於 Elasticsearch 或 Kibana 的「相關服務的程式」，根據 SSPL 第 13 條所示，包括但不限於，

management software
user interfaces
application program interfaces
automation software
monitoring software
backup software
storage software
hosting software
…

若你原本排斥 GPL、AGPL，那麼你會更不會喜歡 SSPL。

Open Source 自由開放源碼到底有沒有商業模式？

MongoDB 與 Elasitc 的模式，若對應到幾類常見的自由開放源碼商業模式，通常會是 Open Core，與 Red Hat 的 Open Source 不同。這種商業模式，在各種雲端服務興起的時代，面臨了不小的挑戰。

然後開始又有不少人討論『Open Source 有哪幾種商業模式？哪種商業模式最適合我？』。

其實不管 Open Source 現行有哪些公司成功，我們先回到源頭探討『Open Source 自由開放源碼到底有沒有商業模式？』

這個在國外討論好多年了。我比較同意一些人的觀點，” Open Source is a go-to-market strategy，not is a business model. “，『自由開放源碼是開拓市場的策略，而不是商業模式』。

商業模式應該要能夠提供商業運行的全局觀，包括誰是你的客戶、如何接觸他們、他們為何買單、做什麼不做什麼，以及成本與利潤的結構等；而開拓市場的策略，僅是專注於如何將你的服務或產品發布到顧客身上。

現在大多數公司的做法剛好相反。他們首先決定使用哪個自由開放源碼授權，然後嘗試基於此設計商業，原因是 Open Source 提供了很多的優勢及成功案例。而這種本末倒置導致的失敗，也難怪那麼多人會開始質疑 Open Source 到底對或不對了。

Credit

圖片來源 (image from) : https://unsplash.com/photos/ZYBl6VnUd_0