喜歡就關注我們吧！

近日，Elastic 公司將旗下的知名開源項目 Elasticsearch 和 Kibana 的開源許可證變更的事件持續發酵，再次把我們的目光聚焦到開源公司與云服務廠商之間的矛盾旋渦中。

事實上，Elastic 公司與云服務廠商的“積怨”由來已久。回顧這家全球知名的開源上市公司的發展史，我們可以一窺現代開源軟件公司在商業化進程中的機遇與掙扎。

成功

時間回到 2004 年，ElasticSearch 的創始人 Shay Banon 彼時還是一個失業的程序員。Shay 的妻子想要去倫敦學習當廚師，于是 Shay 跟著她來到了倫敦。在待業期間，Shay 打算幫妻子做一個食譜搜索引擎，好讓她的廚藝進步更快。?

Shay 最初使用的是開源檢索引擎 Apache Lucene 的一個早期版本，但他發現自己直接使用 Lucene 十分困難，為了方便在 Java 程序中直接添加搜索功能，Shay 為其做了一個抽象層，并集成了自己的第一個開源項目 Compass，這就是 Elasticsearch 的雛形。?

后來的工作中，Shay 需要為一個高性能、分布式環境下的內存數據網格開發分布式搜索引擎，他決定重寫 Compass，把它變為一個獨立的服務并取名為 Elasticsearch。?

Elasticsearch 的第一個公開版本于 2010 年 2 月發布，并一躍成為 Github 上最活躍的開源搜索引擎項目之一，在短時間內迅速吸納了超過 300 名 contributors 。于是在 2012 年，Shay 專門創立了 Elasticsearch 公司，開始圍繞 Elasticsearch 項目提供商業服務，并為項目的新特性開發提供資金支持。憑借將復雜的底層邏輯封裝和提供簡單易用的 API，Elasticsearch 很快風靡全球，成為很多企業搭建搜索引擎的首選開源軟件。?

Elasticsearch 早期的商業化與很多知名開源項目一樣，采用內核開源、擴展付費的模式，即項目的基本功能保持開源和免費，而對一些專為企業定制的擴展功能進行訂閱收費的模式。2014 年，成立僅 18 個月 Elasticsearch 公司就獲得了 7000 萬美元的融資，順利進入發展快車道。?

很快，Elasticsearch 公司在 Elasticsearch 的基礎上擴展出了日志解析工具 Logstash 和可視化工具 Kibana，構建了完整的 ELK 日志分析系統產品生態。隨后又開發了用于監控的 Marvel、用于安全的 Shield 等商業化插件，并圍繞搜索和分析業務陸續收購了一些創業團隊。由于公司的主要產品已經從單一的 Elasticsearch 變為完整的搜索、分析業務整合方案，Elasticsearch 公司在 2015 年正式更名為今天的 Elastic。?

憑借成功的開源商業模式，Elastic 公司于 2018 年順利 IPO，成為一家市值超過 50 億美元的上市公司。包括 Shay Banon 在內的一眾創始團隊成員也實現了財富自由。

威脅

前面說到，Elasticsearch 之所以能夠從一個單純的個人項目發展成為一家市值數十億美元的上市公司，與其成功的開源商業模式密不可分。通過內核開源，擴展付費的方式，Elastic 公司早期從企業客戶中賺取了可觀的利潤。?

然而正是在 Elastic 公司高速發展的時期，以 AWS、谷歌云、微軟 Azure 為代表的云服務廠商開始陸續推出基于開源數據庫的云服務，對包括 Elastic 公司在內的開源軟件公司的商業模式帶來了巨大的威脅。?

2015 年，AWS 推出 Amazon Elasticsearch 服務，將開源的 Elasticsearch 集成到自家的云服務中以供客戶使用。大量的企業客戶購買了這些配套的云服務，使得 Elastic 公司失去了很大一部分市場。據統計，AWS 單單 Elasticsearch 一項服務的收入就已經高于 Elastic 公司的所有收入。?

為了奪回一部分市場，Elastic 公司也嘗試將 Elasticsearch 中的一些高級功能改為商用收費模式，以限制云廠商的索取。而 AWS 這邊的應對方式則是索性自己分支了一個 Elasticsearch 版本 ，并把 Elastic 收費的模塊全部開源。?

除了 Elasticsearch 以外，這些云服務廠商早前也針對 MySQL、PostgreSQL、MongoDB、Redis 等開源數據庫項目推出對應的云存儲服務，對這些開源項目所屬商業公司的付費業務造成了直接的沖擊。

變更

正是在這樣的背景下，以 AWS 為代表的云服務廠商與一眾開源商業公司結下了梁子，迫使后者采取了一些激進的反制行動，包括變更項目原有的開源協議，甚至直接改為商業授權等：

• 看不慣云計算公司流氓行為，MongoDB 更改開源協議

• “分叉并商品化”，GitLab 和 Elastic 炮轟 AWS 的開源方法

• 不想云廠商坐收漁翁之利，Kafka 團隊修改 KSQL 開源許可

• Confluent 修改開源許可證，限制云供應商濫用

• 不想讓云提供商白白獲利，Neo4j 宣布企業版徹底閉源

• MariaDB CEO 痛斥云廠商對開源的無盡掠奪，從不回饋社區

• 開源軟件受云服務商影響，共用條款終止開源濫用現象

• CockroachDB 修改開源協議，限制商業構建 DBaaS

Elastic 采取的舉措則是刪除旗下項目 Elasticsearch 與 Kibana 項目原本的 Apache 2.0 許可證，僅保留 SSPL 許可證與 Elastic 商業許可。其中 SSPL 是由 MongoDB 于 2018 年推出的新型許可證。?

2018 年，MongoDB 牽頭發布了新的許可證 Server Side Public License，即 SSPL，用于取代原本使用的 AGPL 協議。SSPL 的精神與 AGPL 大體上類似，最大的區別就是針對云服務商提出了更嚴格的限制：“如果您將本程序或修改版的功能作為服務提供給第三方，則必須根據本許可的條款，通過網絡下載免費向所有人提供服務源代碼。”?即明確要求托管 MongoDB 實例的云計算公司要么從 MongoDB 獲取商業許可證，要么向社區開源其整個服務的代碼。?

MongoDB 首席技術官 Eliot Horowitz 表示，由于云計算的出現，開源社區應該重新考慮并更新原有的開源許可證，以“應對新環境中的新挑戰”。Horowitz 認為，經過 OSI 認證的傳統開源許可證無法限制云服務廠商利用開源項目以 SaaS 的形式來盈利，而 SSPL 就是為此而誕生。

然而，SSPL 并沒有獲得 OSI 的認可。現代開放源代碼定義的合著者、OSI 創始人之一 Bruce Perens 表示，SSPL 協議與 OSI 開放源代碼定義的第九條相違背，該定義要求“開源許可證不得限制該開源項目（包括下游分支）以外的其他軟件”。但 SSPL 要求云廠商將與 MongoDB 集成在一起的所有 SaaS 軟件開源，因此未能通過 OSI 的認證。Bruce 認為，SSPL 實際上背離了開源軟件允許人們自由使用、更改源代碼，包括從中合理獲利的基本定義。

如今 Elastic 公司也采取了與 MongoDB 相同的變更許可證舉措，在保持開源與商業化之間面臨新一輪的輿論考驗。

爭議

Elastic 等開源軟件公司將旗下開源項目許可證變更的舉動在社區中引發了巨大的爭議，輿論導向也分成了正反兩派。?

支持開源公司變更許可證的一方與這些開源軟件公司的觀點基本一致：云服務廠商長久以來對開源社區“只索取不回饋”，從開源社區的勞動成果中獲得了巨大的利益，同時對開源社區本身的利益造成了損害，確實應該對其加以限制。?

而反面的觀點似乎更加豐富。

一些受 Elasticsearch 協議變更影響的下游開源項目首當其沖。比如使用 Elasticsearch 作為存儲后端的 Apache Skywalking，其對于 Elastic 變更許可證的回應是“不能再僅使用 Elasticsearch，會考慮其他存儲方案，例如同為 Apache License 2.0 許可的 InfluxDB、TiDB 和 H2 Server”。顯然，Elastic 擅自變更許可證對于其下游的開源項目來說也算是一種“變節”。?

還有輿論認為，云服務廠商近年來也參與了開源社區的貢獻，例如 AWS 分支 Elasticsearch 后做的一系列優化也都回饋給了上游社區，對項目的發展起到了一定的積極作用。此外，以 AWS 分支并完全開源 Elasticsearch 的付費模塊這件事來說，這樣的做法實際上從項目本身的推廣以及社區用戶來說都是有益的，而唯一利益受損的似乎只有依靠 Elasticsearch 盈利的 Elastic 公司。?

知名開源產業記者 Scott Gilbertson 表示，Elastic 的做法與其他從開源轉為專有的軟件在本質上是一樣的。“開源的初衷是通過允許最大范圍的用戶使用你的軟件，建立一個最大的社區，讓更多地人關注到軟件中的錯誤，同時也讓更多的人來修復它們。在這個過程中，社區會變成軟件發展的動力。而社區規模的增長會成為市場份額，有時市場份額會變成利潤，但這些利潤不應該是開源本身追求的東西。”Scott 認為，既然利用開源收獲了龐大的社區和市場，就不應該因為外部的競爭壓力而改變開源的本質。“如果你基于開源構建了它，在它發展壯大后又將其拿走，這可能比你從未構建過它更糟糕。”?

總而言之，開源公司在法律上擁有擅自更改旗下開源項目許可證的權利，而云服務商基于開源項目提供云服務以及分支開源項目也沒有違反現有開源許可證的要求。雙方在均未違反“游戲規則”的前提下，各自的出發點都是基于自身的利益。而正是由于雙方利益的沖突，造成了一系列許可證變更的事件。

啟示

既然涉及到利益，那么事件的雙方也就不是簡單的非黑即白了。?

開源軟件公司面對來自云廠商的市場競爭壓力，采取變更開源許可證的方式來自救無可厚非，但確實也傷害了包括下游開源社區在內的開源軟件用戶；云廠商通過分支開源項目，并將優化的代碼回饋到上游社區，對社區和用戶來說是有益的，但將開源項目以 SaaS 的方式獲利也確實威脅到了原生開源公司的生存。?

以現有的案例來看，有沒有一些相對較好的解決方案能夠帶給我們一些啟示呢？?

從開源軟件公司一方來看，CockroachDB 采用的解決方式就挺有意思。CockroachDB 是開源的云原生 SQL 數據庫，為了扼制云服務廠商的索取，同時又保持項目本身的開源理念，其官方采用了一種介于閉源和開源之間的許可證 —— BSL 。BSL 是 MariaDB 公司提出的一個新型許可證，它本質上是閉源和 Open Core 開源模式的“中間模式”，但也得到了 OSI 創始人 Bruce Perens 的認可。在 BSL 之下，源碼始終是自由的，并且保證在某個時間點會變成“真的”開源（OSI 定義的開源），表現在 CockroachDB 中是版本發布三年后會自動切換為 Apache 2.0 許可證。?

在該協議之下，CockroachDB 用戶可以將 CockroachDB 擴展到任意數量的節點，可以使用 CockroachDB 或將其嵌入到他們的應用中，無論是將這些應用分發給客戶還是將其作為服務運行，甚至還可以在內部將其作為服務運行。但是唯一不能做的是在沒有取得授權的情況下以商業形式用 CockroachDB 提供數據庫即服務（DBaaS）。?

這種附帶“延時屬性”的開源許可證在阻止云廠商利用開源項目獲利的同時，也確保了下游開源項目不受影響，且項目源代碼會在一定時間后完全開源，是業內目前比較看好的一種解決方案。

當然，也有像 Red Hat 這樣已經做大做強的開源軟件公司，索性自己也推出云服務，“打不過就加入”也是一種解決方案。?

而從云廠商一方來看，為避免類似的爭端，將資源投入到更加中立的第三方開源軟件基金會是現階段的趨勢。

由專業的開源基金會管理的項目通常在開放治理方面做得更好。一方面是開源基金會由多家廠商共同參與，各方能夠在互利互惠的前提下制衡發展，實現合作共贏；另一方面，由開源基金會管理的項目在版權上也更加中立，變更許可證往往需要經過社區內部各方的嚴格評審投票通過才可進行（通常不會輕易變更許可證），這樣的開源項目在開放治理的模式下擁有更加廣闊的市場前景。?

如今主流的開源基金會如 Apache 軟件基金會、Linux 基金會、CNCF 等，旗下的很多項目都不乏來自各大云廠商的重要貢獻，正是得益于包括云廠商在內來自各方的大力支持，這些基金會的開源項目社區才能夠發展得非常好，比如 Linux Kernel、Kubernetes 等。?

開源軟件發展到今天，已經客觀形成了一個巨大的開源產業生態，參與者有云服務大廠，有基于各開源項目的創業公司，也有千千萬萬對開源充滿熱情的個人開發者和用戶，每一個參與者都是不可忽視的。云廠商有自己的盈利模式，開源軟件公司也有自己的生存法則，在不傷害個人開發者和用戶的前提下，平衡各方的利益和諧發展，是未來整個開源世界需要長期思考和探索的重要課題。

參考鏈接：

https://www.oschina.net/news/126717/es-n-kibana-licensing-change

https://arstechnica.com/information-technology/2019/10/is-the-software-world-taking-too-much-from-the-open-source-community/

http://www.ruanyifeng.com/blog/2019/06/open-database-relicensing.html

https://www.oschina.net/news/107241/cockroachdb-relicensed

https://opensource.org/docs/osd

總結

以上是生活随笔為你收集整理的开源许可证的变更带给我们什么启示？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。