喜歡就關(guān)注我們吧！

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

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

成功

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

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

后來的工作中，Shay 需要為一個高性能、分布式環(huán)境下的內(nèi)存數(shù)據(jù)網(wǎng)格開發(fā)分布式搜索引擎，他決定重寫 Compass，把它變?yōu)橐粋€獨立的服務(wù)并取名為 Elasticsearch。?

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

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

很快，Elasticsearch 公司在 Elasticsearch 的基礎(chǔ)上擴展出了日志解析工具 Logstash 和可視化工具 Kibana，構(gòu)建了完整的 ELK 日志分析系統(tǒng)產(chǎn)品生態(tài)。隨后又開發(fā)了用于監(jiān)控的 Marvel、用于安全的 Shield 等商業(yè)化插件，并圍繞搜索和分析業(yè)務(wù)陸續(xù)收購了一些創(chuàng)業(yè)團隊。由于公司的主要產(chǎn)品已經(jīng)從單一的 Elasticsearch 變?yōu)橥暾乃阉鳌⒎治鰳I(yè)務(wù)整合方案，Elasticsearch 公司在 2015 年正式更名為今天的 Elastic。?

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

威脅

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

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

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

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

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

變更

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

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

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

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

• Confluent 修改開源許可證，限制云供應(yīng)商濫用

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

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

• 開源軟件受云服務(wù)商影響，共用條款終止開源濫用現(xiàn)象

• CockroachDB 修改開源協(xié)議，限制商業(yè)構(gòu)建 DBaaS

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

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

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

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

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

爭議

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

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

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

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

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

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

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

啟示

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

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

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

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

在該協(xié)議之下，CockroachDB 用戶可以將 CockroachDB 擴展到任意數(shù)量的節(jié)點，可以使用 CockroachDB 或?qū)⑵淝度氲剿麄兊膽?yīng)用中，無論是將這些應(yīng)用分發(fā)給客戶還是將其作為服務(wù)運行，甚至還可以在內(nèi)部將其作為服務(wù)運行。但是唯一不能做的是在沒有取得授權(quán)的情況下以商業(yè)形式用 CockroachDB 提供數(shù)據(jù)庫即服務(wù)（DBaaS）。?

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

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

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

由專業(yè)的開源基金會管理的項目通常在開放治理方面做得更好。一方面是開源基金會由多家廠商共同參與，各方能夠在互利互惠的前提下制衡發(fā)展，實現(xiàn)合作共贏；另一方面，由開源基金會管理的項目在版權(quán)上也更加中立，變更許可證往往需要經(jīng)過社區(qū)內(nèi)部各方的嚴(yán)格評審?fù)镀蓖ㄟ^才可進行（通常不會輕易變更許可證），這樣的開源項目在開放治理的模式下?lián)碛懈訌V闊的市場前景。?

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

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

參考鏈接：

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。