開源中國專訪 TJ：開源許可證，歡迎來到雲時代

開源許可證從最早的 GPL 開始， 逐漸演進到 GPLv2 和 v3，中間還有 Apache、MPL、AGPL、LGPL 等，但是近幾年來有一批新的許可證的出現，引起了社群的一些激烈的討論。這些新的許可證包括 BSL、SSPL、Elastic 以及一個比較特殊的附加條款 Commons Clause。

社群內從爭論的角度主要分為兩大陣營：原教旨主義和實用主義。

原教旨主義的同學們認為只有遵從1998年成立的 Open Source Initiative(OSI)定義的10大原則，透過OSI 這個組織稽核認證過的(OSI-Certified)，才可以稱之為開源的許可證。

實用主義則從開源本身的目的出發，認為在原始碼開放，絕大部分的社群開發者在使用或者貢獻時不受影響的情況下，不必糾結於字面的定義如何，對社群有益即可。

按照 OSI 的開源許可證規則，目前使用 SSPL 的 MongoDB，使用 Elastic License V2 的 Elastic Search、Airbyte，使用 BSL 的 CockroachDB， 以及附加了 Common Clause 的 Redis，這些大名鼎鼎的開源軟體，都不能稱之為“開源軟體”了。

那麼問題來了?如果因為上面的原因，這些軟體不被認為是開源了，是 Proprietary 軟體了，難道我們真的叫這些我們已經一直在免費使用，並且可以持續使用很好的軟體為“閉源軟體”或者“商業軟體”?好像也不太對。“原始碼可用”，略微繞口了一點。

讓我們先從以 SSPL 為代表的新一代開源軟體廠商和 OSI 的角度分別來看一下這個問題兩個對立面的一些底層邏輯。最後我們再來分享下對於雲時代開源許可證的一些觀點。

我所知道的 SSPL

MongoDB 是一個非常受程式設計師喜歡的 NoSQL 資料庫，我是12年左右在矽谷和朋友創業的時候接觸到的。在花了一個週末改寫了幾千行 Python 程式碼，把和 MySQL 的互動改成了 MongoDB 之後，本來意圖是改善併發效能的我卻發現了一個意外的驚喜：程式碼行數縮小到了小几百行，是原來的15%——從此我就義無反顧地開始了我的 NoSQL 之路。

因為在社群比較活躍，自己也寫了一個和 MongoDB 相關的開源 NodeJS 元件，所以在13年創業專案停止後我就加入了 MongoDB。在我加入的時候，MongoDB 已經成立6年了，人員規模也有300~400人，每年支出一億美元，收入呢?當時 MongoDB 的主要營收來自於一些諮詢服務和企業版的售賣。但是諮詢服務收入實在是少得可憐，企業版也不太好賣，最大的競品是自己：開源版本。所以只能一直依靠大量風投資本不斷輸血。可是融資已經到了F輪，投資人的耐心終於告罄。在一場董事會後，當時的 CEO 和 CRO 全體撤下，換成一個久經沙場的職業經理人 Dev Ittycheria。

Dev 上馬以後立即制定了2-3年內完成上市的目標，推行了一系列新的商業化舉措，包括商業化第一優先，進軍全球，推出雲版產品等一系列措施。我就是在那個時間，從生活工作了10多年的美國回到中國，作為 MongoDB 在大中華區的第一位正式員工來幫助 MongoDB 在中國落地商業化。在我回國的14年下半年，MongoDB 雲產品 Atlas 還在研發中，MongoDB 的主要商業化手段還是企業版。

2016年的時候，MongoDB 正式釋出了 Atlas 產品，一個在公有云上的託管資料庫服務。MongoDB 企業版的客戶是可以用百或千計的，但是開源版本的開發者可能有幾十萬。這些大部分開發者不會購買企業版授權，但是無論如何他們需要使用和管理維護。這個時候 Atlas 這種雲產品形式就很快得到了這些開發者的青睞。雖然成本不是太低，但畢竟是開箱即用，省了0.5或者0.25個 DBA 的費用，所以MongoDB Atlas 上線後就呈現了比較快的增速，在2017年上市的時候，已經成為 MongoDB 的增長最快的業務了。

反觀國內，某公有云其實也在2016年，比 MongoDB 原廠更早的時間，推出了雲上的 MongoDB as a Service，還是用的 MongoDB 的基於 AGPL 的社群版。當時的中國市場，企業版的銷售其實是舉步維艱，企業版的售賣邏輯是提供了額外的價值，主要包括原廠技術支援和一套獨立的額外叢集管理工具(監控、備份等)，MongoDB 資料庫能力都是一樣的，和開源版相比。但是在軟體獲取成本上，一個是0元/年，一個是數十萬元/年。在10萬元就能請一個工程師的中國企業市場，可想而知企業的付費意願度有多高。

除了國內，俄羅斯的一些頭部雲廠商也開始在他們的雲上推出了 MongoDB as a Service，也都基於免費的 MongoDB 社群版。在此過程中，雲廠商為了能夠更好地將一個產品融入到他們統一的雲管平臺，提供一些額外的能力支撐，或者自己動手解決一些產品的 Bug 來滿足 SLA，勢必會對原始碼做許多修改。在這個時候 MongoDB 發現，某些雲廠商並沒有完全按照 AGPL 協議規範，將所有這些改動如數開源。

雲商的實際做法往往是如此，首先公開 Fork 某個 MongoDB 的上游版本，然後在這個 Fork 裡面象徵性地提交一些更新，推到 GitHub。實際上大量的開發會在一個 Private fork 上進行，不會推送到公開的 Fork 上面，更別說回溯到上游了。從 MongoDB 的角度，當發現這些 AGPL 協議並沒有在這些雲廠商得到很好的合規執行的跡象的時候，就試圖從商業化上和雲商進行溝通，希望對方要麼是按照行業的規矩公佈程式碼，要麼就達成商業化合作。

經過多次協商，動用到各自的 Legal Team 以後，MongoDB 發現面臨的問題是——商業化合作，雙方期望值相差太大，一個想吃肉，一個只願意給肉湯。開源合規方面，雲商指著那個基本不怎麼更新的 Repo 說我們已經按照協議開源了。只有到訴諸公堂，才可以去內部取證。怎麼辦?類似的案子，沒有先例，再在一個完全陌生的國家去走這條路，聽上去就是非常坎坷。可是雲服務又幾乎是所有新一代開源軟體公司最主要的收入增長引擎，實在又無法聽之任之。

於是 MongoDB 選擇了釜底抽薪。改許可證。

在改協議之前，MongoDB 主要採用的是 AGPL 許可證。這是 OSI Certified 的，一致認可的標準開源許可證型別。為了應對在雲廠商這裡碰到的困難，MongoDB 在基於 AGPL 協議之上，增加了一個補充條款(解釋版，非官方文字)：

第13條：如果你用這個軟體來直接在公有云上以“xxx as a Service" 的服務方式售賣這個軟體本身，那麼你需要將所有相關的改動，包括支援這個軟體使用的後臺管理平臺軟體，都進行開源。

所以，簡單來說，SSPL 就等於 AGPL + 第13條修改。理解這條修改的初衷、意圖、影響範圍，也就理解了 SSPL 的本質。

初衷：和雲廠商在商業化利益上的博弈

目的：防止這種使用開源軟體直接獲利，但是不遵循遊戲規則的第三方

影響範圍：直接提供“開源軟體 as a Service”的公有云廠商

在 SSPL 正式釋出以後，直接效果是很明顯的：雲廠商們要麼是下線，要麼就和原廠達成商業化合作，獲取特別的授權來繼續提供 MongoDB as a Service。

當然，影響也是極其深遠的——對開源界造成了巨大的動盪。針對於使用 SSPL 以及後來的 Elastic License V2 這些新的許可證的軟體，是否可以被稱之為“開源軟體”的爭議一時間充斥了技術社交網路。不少極端的觀點認為如果接受這樣的開源方式，開源將逐漸滅亡。亦有觀點認為採用這樣的”quasi-開源“ 許可證肯定會引發社群極大反彈，要不了2-3年這些公司就會隕落(這些討論集中在2018年)。

OSI Certified

我們再來看看 OSI， 開源軟體標準的守護者。

當我們說一個軟體是否可以被稱之為“開源軟體”時，嚴謹的說法應該是這個軟體如果使用了某一個 OSI Certified 許可證，那麼可以稱之為“開源軟體”。反之如果使用的許可證不在 OSI Certified 列表裡，那麼這個軟體可能就不應該被稱之為“開源軟體”。

OSI Certified 許可證我們常見的有這些：

MIT

BSD

Apache

MPL

GPL

LGPL

AGPL

……

值得注意的是，這種定義更多是一個社群的自我約束，並不具有法律意義上的約束。按照 OSI 自己的說法，“開源”這個詞並不是個註冊商標，所以理論上誰都可以使用，你無法使用法律手段來禁止某個軟體自稱“開源軟體”，哪怕它並沒有獲得 OSI 的認可。

但是，我們都是在一個生態裡面。這個生態就是有各種成員組成。在這裡，在法律管轄範圍之外，更多的是行業的一些約定俗成和標準化組織。OSI 就是一個為鼓勵促進開源軟體的蓬勃發展而成立的組織。試想一下，如果沒有OSI 透過嚴格的流程來稽核許可證，界定軟體的安全使用範圍，提供權威的解釋，那麼市場上的許可證可能會是形形色色，五花八門。對於開源社群絕大多數的成員，開源軟體的使用者，來說，這將是個巨大的認知和風險成本。如果你用了一個不知名的許可證，也沒有請律師仔細稽核，只是因為程式碼可以用就整合到你的產品裡來，等你小有成功的那一天，沒準就是你收到對方律師信的一天。

不說其他，就從這一點上看，我們需要 OSI 這樣的組織，以及 OSI Certified 許可證機制。這不是限制，目的是幫助社群使用者移除隱性的開源軟體使用風險，為了保護開源社群更好的發展。

這也是為什麼 MongoDB 在宣佈了 SSPL 以後，MongoDB 的 CTO Elliot 向 OSI 提交了 SSPL 認證申請，希望 OSI 稽核透過，將 SSPL 列為 Certified 許可證。(但是後來 MongoDB 很快就收回了申請，原因是 OSI 在開始正式稽核流程之前，已經在社交媒體上預判了 SSPL的死刑， MongoDB 認為在這樣的情況下是無法保證一個比較公平的稽核過程。)

我們來看下 OSI 對現行開源許可證的認定原則。OSI 認為，一個許可證是不是開源的屬性，要看它是否符合(Open Source Definition，OSD)的10條要求：

1. Free Redistribution-分發自由

2. Source Code- 可以獲得原始碼

3. Derived Works- 允許衍生作品(以類似的許可證)

4. Integrity of The Author's Source Code - 原作者原始碼的完整性

5. No Discrimination Against Persons or Groups - 不歧視個人或團體

6. No Discrimination Against Fields of Endeavor - 不歧視任何領域

7. Distribution of License - 許可的分發

8. License Must Not Be Specific to a Product - 許可不能針對特定產品

9. License Must Not Restrict Other Software - 許可證不能限制其他軟體

10. License Must Be Technology-Neutral - 不能以專門的技術或介面完成授權

針對 SSPL 的批評，集中在第9條規則：許可證不能約束其他軟體。而 SSPL 的條款，正是在開發者(公有云廠商)試圖直接銷售 MongoDB as a Service(注意是銷售資料庫服務本身，而不是衍生服務)的時候會觸發對開發者的其他軟體(雲管理平臺軟體)的限制。

所以如果按照現有的約定俗成，SSPL/Elastic 這樣的許可證，確實是不滿足 OSI 的開源標準。所有 MongoDB 、 Elastic 等確實在尊重這個社群共識，不直接稱呼自己為開源，而是“原始碼可用”。

作為一個非盈利的 MongoDB 中文社群運營方，我們最近做了一個小調查，來看看作為社群的主要成員——開發者和使用者們是怎麼看待這些問題的。

MongoDB 中文社群許可證問卷調查結果

我們的問卷在半天的時間，收集了99份有效答卷，以下是部分調研結果：

關注 Tapdata 公眾號，後臺回覆【許可證問卷】即可獲取完整問卷

這裡是一些摘要的資料，可以提供一些躍然紙上的觀察：

91%的使用者支援開源軟體做商業化，7%不支援，2%其他

開源軟體的程式碼貢獻者僅佔8%，其餘的可以理解為使用者。也就是說，開源社群絕大多數是開源軟體的使用者

關於選擇開源軟體，只有6%的使用者表示軟體的許可證模式是一個比較重要的考量

多達73%的使用者表示 SSPL/Elastic 針對雲廠商的修改是合理並支援的，10%表示無所謂，17%反對

對於開源軟體使用者，89% 的使用者表示許可證的改變對他們繼續使用軟體沒有影響

對於開源軟體的貢獻者，7%的使用者因為許可證改變而停止了貢獻。

我們該如理性看待雲時代開源許可證

在經過對 SSPL 和 OSI Certified 的一些討論以及一些對社群的調查之後，回到我們的核心問題：

在雲時代，我們該如何看待這些新的開源許可證?

考慮到 MongoDB、Elastic 以及 Redis 這些軟體廠商修改許可證的初衷，他們其實都是在尋找一種對抗公有云廠商不公平競爭的一種解決方案。所以我們說，這個問題是一個雲時代才出現的問題。

我先羅列一些不具太多爭議性的事實和觀點：

MongoDB / Elastic / Redis 都是獲得了巨大成功，非常主流的開源軟體廠商

這些軟體的持續健康發展，無論OSI 持什麼態度，依然可以服務絕大部分的開源社群使用者(89%)

這些廠商的開源許可證的修改都是在面臨雲廠商的碾壓式商業競爭情況下采取的應對措施

開源社群需要具有包容性，就如既定的規則裡就有不歧視任何個人和團體一樣

OSI 的開源10大規則建立於20多年前，在公有云這個跨時代形態出現之前

OSI 的最大的意義之一是制定標準，幫助社群使用者界定不同開源許可證的邊界範圍

追求商業化的開源軟體，依然是開源社群合理的一部分

社群的使用者是支援開源軟體商業化的(91%)

我們不喜歡壟斷、獨斷、一家獨大，我們喜歡生態百花齊放，鼓勵創新

在上面的這些基礎觀點之下，我分享一些我的看法：

① MongoDB / Elastic / Redis 代表的是開源技術廠商，他們的特點是以一家技術創新型公司的形式，將程式碼開放出來，透過開源社群進行產品的傳播，在為社群提供可免費獲得的非常優秀的軟體的同時，吸收社群的貢獻和反饋，並服務於自己的商業化訴求。相比於沒有商業化公司支撐的開源軟體，這種 For-profit 的開源有它自己獨特的優勢：產品路線明確(開發者可以放心規劃)，技術迭代快速(有足夠多非常優秀的工程師全職研發)，安全問題或者重大 bug 有保障得到解決。

② 20多年前 OSI 誕生的時代，開源社群大多是以個體貢獻者為主流的 Hobbist。而現在絕大部分的開源社群數量上是由開發者(使用者)而非貢獻者組成。開發者對於一個名詞的科學定義的感知度是相對較低的(6%的開發者關注許可證的內容)，反過來優秀的效能、功能及成熟度是社群使用者之首要關注點。

③ 作為一個面向社群的組織，OSI 需要以發展的視角來看待新生事物。如果真心是為社群使用者著想，可以做一些基於社群投票的機制，來吸納社群的反饋，共同修訂已經20多歲的規定，容納一些有商業化考量的許可證到開源這個大家庭裡。比如說，可以對開源軟體從不同的維度進行分類，對有商業化訴求的許可證單獨放到一個類別下，並對一些常見的合規條款進行明確的闡述和稽核，幫助大家正確採用合適的開源軟體。甚至可以考慮，只要軟體程式碼開源並且可以免費獲得，剩下的一些限制性條款，可以從Most Permissive 到 Most Restrictive 這樣一個開放程度，分成 Level 1，2，3 這樣。大家可以各自按需採用相應level的開源軟體。這樣才是一個真正為社群服務，而非一個“靠機構贊助運營，受非常有意見性的一些少數派影響的”的標準組織。

④ 對於絕大多數使用者，以及貢獻者，這些雲時代新的許可證的出現，你需要理解背後的初衷和意圖。就像我們對技術進行科學選型的時候，我們都知道不能只聽市場上的聲音，最終要看是否適合自己的業務場景。如果這些許可證的改變對你的場景沒有影響(一個簡單的判斷：你是否為公有云廠商，如果不是，大機率這些對你來說是沒有變化的)，你完全可以坦然接受這些新的“原始碼可用”許可證。

我們在 Tapdata 的實踐

在離開 MongoDB 之後，我創立了 Tapdata.inc，並對我們公司報以很大的期望，希望我們成為一家極具使命感的公司——讓企業能夠更加簡單、低成本使用實時的資料，來發揮更大的業務價值，Make Data on Tap。

歷經3年打磨，數十家客戶的線上驗證，Tapdata 儼然成為了一個以全鏈路實時為核心技術能力棧的實時資料平臺，同時也是首個支援50多個資料來源的實時異構資料整合平臺。

為了達成使命，我們發現降低獲取 Tapdata 的成本和鼓勵社群傳播是這個時代最有效的一個手段。所以我們於近期正式在 Github 上開放了原始碼，成立了 Tapdata 開源專案()。

Tapdata 開源專案採用的是一個混合許可證模式。我們的策略是針對社群貢獻者利用我們 Plugin Development Kit 來開發各種資料來源和資料計算外掛程式碼，採用 Apache V2 的許可證，而 Tapdata 開源團隊研發的核心引擎框架，包括資料型別標準化、流計算引擎、自研的運算元以及 UDF 能力等會採用 SSPL 許可證模式。

我們希望依託於 Tapdata 開源專案在實時資料領域的先發和領先優勢、強大的產品能力，以及有效的商業化手段，為社群開發者和我們的客戶持續不斷地提供一個最優秀的資料產品。

最後我引用 Thomas Kurian, Google Cloud CEO 對開源軟體的態度，來佐證在雲時代，我們需要的是一個共同發展的生態，而不是因為雲廠商的非對稱競爭優勢導致那些 For-profit 開源軟體無法生存的結局。