本文從2019年多家著名開源公司因爲雲服務對其業務的威脅而更改代碼許可的事件出發，分析了正反兩方意見和心理，再通過開源發展中的歷史教訓舉例，強調了開源的核心是慷概，並呼籲企業必須在開源和利用開源賺錢的權利之間劃一條線。
站在2019年，自由軟件和開源軟件讓我們當下所熟知的世界成爲現實。從Web服務器到互動式諮詢服務站，再到挖掘Facebook社交媒體消息的大數據算法，現在幾乎所有與我們交互的計算機系統，至少都部分地使用了自由軟件。而在更廣闊的科技行業中，自由軟件不僅催生了一大批創業公司，還促成了世界歷史上最大的軟件收購——IBM收購紅帽（Red Hat）。
自由軟件是一份讓我們當前所熟知的世界成爲可能的禮物。一開始，自由軟件的出現讓世界上的很多大企業產生抵觸心理，以至於最初讓那些不習慣這種模式的衆多企業深感不安。這些公司並不是不願意使用開源軟件，只是這個概念太激進，於是就延伸出濃重的政治化色彩。它必須重新換一個名字，於是，它被命名爲“開源”。
這一旦發生，開源軟件就如洪水猛獸般佔領了世界。
然而，最近在這些開源力量中出現了一種騷動。在過去的一年中，像Redis Labs、MongoDB和Confluent這樣的公司都更改了軟件許可證，從原來的開源許可證轉向更嚴格的條款，限制了軟件的功能，使其不再屬於開源軟件。
Redis Labs、MongoDB和其他公司對此的辯解是，這些變動的主要原因來自於一個更現代的技術趨勢——託管軟件服務。也就是衆所周知的“雲”。而在很多真實的應用場景下，這又專指亞馬遜公司的AWS。
在這種騷動下，針對Elastic（Elastic Search背後的公司）的許可變更，亞馬遜公司在今年春天發佈了自己的Elastic Search代碼版本。除了針對亞馬遜的版本命名而狀告亞馬遜註冊商標侵權以外，Elastic公司對此的迴應與MongoDB和Redis非常不同，這家公司甚至都沒有表示任何抗議。
“雲”的爆發
MongoDB公司因其“NoSQL”的數據庫產品MongoDB而創立。MongoDB的數據庫對於存儲非結構化數據（例如圖像）非常有用，它可以像處理那些傳統的數據類型一樣處理圖像。數據存儲在類似JSON格式的文檔中，而不是存儲爲關係數據庫中傳統的列和行。由於MongoDB中沒有結構化的表，就沒有所謂的“結構化查詢語言（SQL）”來處理數據，因此產生了術語“NoSQL”數據庫。
MongoDB並不是唯一的NoSQL數據庫，但它是其中使用最廣泛的數據庫之一。根據DB Engines的行業彙總報告，當前MongoDB已經是全世界第五大最受歡迎的數據庫產品，從谷歌、Code Academy到Foursquare，現在很多公司都在使用MongoDB。
而且，MongoDB還引領潮流地創建了一種新的開源許可，這家公司的CTO Eliot Horowitz認爲，隨着計算機技術進入雲的新世界，有必要採取一些措施對開源軟件業務進行保護。
Horowitz和其他人對此的解釋是，在當前的雲環境下，開源社區需要重新思考並有可能更新原來的開源許可，以“應對新環境中的新挑戰”。從本質上來說，這些挑戰來自於AWS、Google Cloud和微軟Azure這些巨頭，因爲他們都有足夠的能力將開源軟件打包成自己的服務，然後轉售出去。AWS或Azure打包MongoDB並將其作爲基於雲的SaaS服務（Software as a service）的一部分進行售賣，這樣的問題在於，這些服務直接與MongoDB自己基於雲的SaaS服務——MongoDB Atlas形成了競爭。這種情況下，受到威脅的不是MongoDB的源代碼，而是MongoDB自己的SaaS服務，而這恰恰是該公司的主要收入來源。
爲了應對這種挑戰其底線的潛在威脅，MongoDB就試圖將自己的許可證從GNU通用公共許可證（GPL）更改爲所謂的服務器端公共許可證（SSPL）。SSPL許可證中寫道，本質上，你可以用這個軟件做任何想做的事情，除了用它來構建一些與MongoDB Atlas形成商業競爭的東西。
一開始，MongoDB將該SSPL許可證提交給開放源代碼促進會（OSI）， OSI負責監督和批准新的開源許可證。但是，經過OSI來來回回的一系列郵件討論後，再加上該許可證本身的措辭問題，使得SSPL不太可能被OSI 批准，所以MongoDB今年早些時候已經取消了對SSPL許可的申請。於是，SSPL並不是開源許可，而且將來也不可能成爲正式許可。
如果要究其原因，可以首先了解一下情況，MongoDB並不是第一個遇到這種情況的開源企業。事實上，這個問題的一部分其實是，許多公司隨意使用這些開源軟件，但又對開源社區毫無回饋貢獻，而來自多方的回饋和完善原本應該是開源軟件存在的全部意義。
各類開源許可雖然各有不同，但其普遍適用的核心要旨自1998年成立OSI起便被定義如下：你可以使用這段代碼，做任意你想做的事情，但是你不能擁有這段代碼的專有所有權，如果你在另一個項目中使用了這些代碼，那麼這個項目也不能成爲專有的。這些許可使用這樣的字眼就是爲了防止有些公司把開源代碼放在自己的代碼中使用，但又不把任何工作成果共享回原始的開源項目。
但是SaaS的概念在20年前並不存在。而到了今天，Horowitz認爲，在SaaS產品中夾帶一段代碼其實就等同於在應用程序中使用它。
這是一個新穎的論點，但這其實是在爲一個非常古老的問題做出辯護，而該問題已經遠遠超出了許可證的範疇。這是一個可以追溯到很久以前還未成立OSI，在自由軟件誕生之時的問題——如果你免費提供軟件，你該如何從軟件中賺錢呢？
這個問題的一個傳統的答案是，你可以圍繞你的開源軟件進行服務銷售。但對Horowitz來說，這個答案還不夠好。他告訴Ars Technica技術新聞資訊網站：“通過服務支持性合同來爲開源軟件賺錢從來都不是一個好的商業模式。” 紅帽公司可能不會同意這點，但Horowitz堅信，更多的保護性許可將帶來更多的風險資本投資，並在MongoDB使用的開放模式的基礎上催生更多的軟件業務。“我們很獨特，” 他說，“但我希望這成爲開源軟件的風潮，讓我們變得不那麼獨特。”
他可能是對的。保護性更強的許可證可能會吸引更多的風險資本投資，因爲（當然也有待證明）這讓他們的投資有更大的回報可能性。但是，如果這些資金真的向此處投資，這已經不算是投資於開源開發了，因爲這種加在軟件上的限制已經意味着它不再符合開源軟件的定義。
反對的意見
然而，還有相當多的開源倡導者已經對MongoDB其CTO Horowitz的觀點提出了反對意見。這些人認爲，目前的這一套開源許可證的定義並沒有問題，需要改進的是商業模式。
Bruce Perens，最初開源定義（OSD）的聯合作者之一，他認爲SSPL與OSI的開源定義第九條是不兼容的，第九條說“許可證不能限制其他軟件”。由於SSPL強制地讓任何包含了該軟件的整個SaaS軟件，即使其中有些代碼並不是該軟件的衍生部分，統統都成爲開源軟件，因此和開源定義的第九條是相斥的。“當初我把第九條寫進了OSD，就是爲了禁止這種行爲，” Perens說，“我認爲OSD中該部分文本的意思清楚無誤。”
而且，MongoDB也絕對不是唯一一個抱怨雲計算正在侵蝕其利潤的公司。另一家數據存儲公司Redis Labs，是第一個針對雲提供商對自身業務的威脅發出警告的公司，而Redis Labs最終可能會比MongoDB有更好的解決方案。一開始Redis Labs改變了它的許可證，加入了一種叫做“通用條款子許可證”（Common Clause sub-license）的東西，它禁止任何人出售包含這些代碼的任何軟件。當然，不管依照何種定義而言，帶有這種通用條款許可的軟件都不能算是開源的，而Redis Labs也認同這一點。它也從未將這些更改了許可的部分描述爲開源性質的軟件。
但是到了今年春天，Redis Labs又做出了另一項許可變更，從本質上放棄了其所有關於開源軟件的僞裝，對其中部分模塊採用了自主開發的專有許可。說得更清楚一些就是，雖然大多數Redis代碼是由三句BSD許可所監管的，但有些模塊不是，具體而言即指RedisJSON、RedisSearch、RedisGraph、RedisML和RedisBloom這些模塊。
根據Redis Labs加於這些模塊的許可證，雖然用戶可以查看和修改代碼，或在其應用程序中使用這些代碼，但該許可限制了用戶可以構建的應用程序類型。有了Redis Labs的新許可證，你就不能用這些代碼自由地構建任何你想要的東西。比如，你不能構建數據庫產品、緩存引擎、處理引擎、搜索引擎、索引引擎或任何ML或AI衍生服務引擎。換句話說，你不能使用Redis Labs的代碼來與Redis Labs競爭。這樣的許可當然違背了開源許可的核心原則之一——對衍生軟件沒有限制。
遺憾的是，對於Redis Labs和MongoDB來說，不能一方面說自己是開源的，一方面又嚷嚷自己應該從開源軟件中獲利，這在道理上講不通。而在另一個商業模式中，道理上是行得通的，那就是帶專有所有權的軟件。
這也正是Elastic所選擇的一條道路，而且這條路已經開鑿有一陣時間了。雖然這裏面還有部分問題沒有形成板上釘釘的規則，但不可否認的是，一些公司已經通過他們的開源代碼和私有代碼成功地蓬勃發展起來。Elastic公司就是這樣一個例子，雖然它面臨着來自AWS的激烈競爭，但還是頑強地堅持下去。
亞馬遜公司不僅多年來一直在AWS上提供Elastic search，表面上已與Elastic自己的產品形成了競爭，最近亞馬遜還打包了自己版本的Elastic search代碼庫，並將其擴展爲免費提供的好幾項服務，而Elastic公司尚未在這些服務方向上發佈其開源服務。面對這樣的挑戰，Elastic公司我自巋然不動，其反應不過是瀟灑地聳聳肩罷了。
歷史的教訓
爲什麼MongoDB還是想要讓自己歸類於開源呢？畢竟，專有商業軟件非常成功的例子也比比皆是。爲什麼MongoDB並不願意選擇擁抱這條大道繼續前進呢？
Horowitz告訴Ars Technica，他堅信“開源會產生更好的系統軟件，尤其是在數據庫方面”，他還強調了，繼續讓代碼保持開源的性質就能擁有安全和社區兩大優勢。這兩方面的優勢他確實說得很對，只要保持開源，對該軟件更多的關注就意味着更少的bug，更好的安全性。
但是讓我們再回頭看一看最初的開源定義，很明顯，Horowitz忽略了深深地嵌入每種開源許可中的另一個關鍵要素——慷慨。
真正意義的開源永遠不會限制你對軟件的使用。絕對不會。這可能是開源這一概念能取得巨大成功的主要原因，這當然也是讓這些開源產品成爲大企業首選軟件的原因。
這種慷慨是推動軟件社區發展的方式，它是所有成功的開源項目的基石。通過允許儘可能多的用戶使用你的軟件，就可以爲之獲得儘可能大的軟件社區。這意味着會有更多的人關注bug，有更多的人修復bug。這樣的開源社區纔有蓬勃發展的勢頭。而這種發展勢頭會變成產品的市場份額。有時市場份額會轉化成爲利潤，但並不總是這樣，開源產品並不能保證你最終一定能獲取商業利潤。
正如Perens所說，“我們必須在‘開源’和利用開源賺錢的權利之間劃一條線。雖然開源定義允許你賺錢，但開源的本質並不支持你賺錢的權利。而且我們不會改變這條規則，因爲你可以通過他種方式更好地賺錢。”
值得讚揚的是，Horowitz和MongoDB公司如今似乎已經接受了這一觀點，或者至少說，在他們撤回SSPL作爲OSI許可證的申請時已經接受了這一不可避免的事實。不會僅僅因爲你創造了開源產品，產品問世了，這些產品就非得爲你帶來巨大的商業利潤。
事實上，如果你創造了一個開源產品，他們問世了並傳播了，然後此時你把它從市場上拿走了，這種狀況可能比你從來沒有創造過這款產品更糟糕。
Redis Labs從開源中收割了所有開源所能帶來的好處，其中最主要的好處有社區支持、廣泛傳播和來自廣泛來源的代碼貢獻，然後，Redis Labs選擇背棄了開源。坦率地說，Redis Labs此舉激怒了整個開源社區。
當自由軟件開發者開始抓狂時，他們就會選擇爲代碼拉出分支，而事實上，針對Redis變更許可問題，已經拉出一個名爲GoodFORM的分支。GoodFORM分支爲重新授權的Redis模塊保留了許可變更之前的版本，這個項目將爲Debian、Fedora和其他Redis不再發布專有軟件的Linux版本一直維護這些模塊。
於是Redis Labs的新許可證帶來了一個意想不到的後果，那就是任何想要使用完整的、開源的Redis代碼的人都必須使用GoodFORM分支版本，而不是Redis自己發佈的版本。
或許個體開發人員不會太在意這其中的區別，但是希望使用開源軟件的大公司就不會那麼無所謂了。對他們來說，這通常會歸結於一個選擇——要麼使用帶有OSI許可的開源軟件，要麼打電話給律師諮詢相關法律法規。沒有人願意僅僅爲了安裝一個軟件而打電話給律師。
Perens告訴Ars Technica，這正是他們寫下最初的開源定義（最初是爲Debian項目編寫的）背後的主要動機之一。“開源的定義意味着你不會僅僅爲了成爲一個軟件的用戶而需要一個律師，” Perns說。“而我們做到這一點的方法之一，就是最小化法律負擔。”
然而Redis Labs的新許可證卻將自己的公司用戶置於需要律師的位置，因此GoodFORM成爲了更合乎情理的選擇。這也暗示了爲什麼MongoDB最終仍然想要保持其開源的特性。
從歷史上看，其他從開源轉爲閉源許可證的項目進展並不算一帆風順。在20世紀90年代的大部分時間裏，Xfree86項目是運行X Windows的事實標準，這一直持續到21世紀初。從2004年起，Xfree86發佈的代碼，被自由軟件基金會認定違背了GPL許可。那些使用Xfree86的下游操作系統認爲這種狀況是不可接受的，於是一個分支X.org誕生了。到了今天，X.org完全替代了Xfree86曾經佔據的地位，而Xfree86則已經被歷史所拋棄了。
其他不難找到的類似例子還包括：從OpenOffice中分離出來的LibreOffice分支，從MySQL的許可變更中分離出來的MariaDB分支，從Ethereal中分離出來的Wireshark分支，這樣的例子簡直舉不勝舉。在所有這些情況下，需要注意的關鍵點不僅僅是誕生了分叉，隨之而生的還包括新項目帶來的開發人員、社區和長期支持開源軟件的發展動力。如果失去了來自開源社區的善意，那麼它相應的報復就可能造成滅頂之災。而報復的反撲常常也是非常高效的：Xfree86實際上在X.org啓動六個月後就迅速死亡了，而OpenOffice也同樣很快地就變得無足輕重。
因此，開源的歷史帶給我們的最重要的教訓是，一旦你成爲了開源集體中的一員，你就不太可能中途改道並依然生存下來。
開源的核心是貢獻
如果開源的歷史告訴我們，在開源這條路上沒有回頭路，那麼值得思索一下，一開始爲什麼要選擇開源。
Beanbooks是由Linux計算機製造商System76所派生出來的一個小項目，它也是Perens所認爲的，開源軟件理想場景的一個完美示例。在“新興的開源經濟範式”這篇文章中，Perens認爲公司的非差異化軟件是使用開源軟件的最佳場景。也就是說，開源軟件能提供公司業務的基礎架構，但不是核心業務部分。
換句話說，Beanbooks並不是System76的利潤中心，但它爲System76的利潤中心提供了一種支撐性技術，該公司的利潤中心仍然是構建基於linux的計算機。
然而，儘管Beanbooks是開源許可證的最佳候選項目，但事實上它卻並不是開源的。爲什麼呢？
System76的實際選擇是出售一個託管的Beanbooks版本，即一個SaaS，當時公司擔心之後會出現一個更大的公司，採用GPL許可監管的代碼，但產品內容本質上是對Beanbooks的克隆，並從System76的投資中奪走所有的利潤。所以System76的創始人Carl Richell說，他對MongoDB和Redis Labs這些公司的擔憂表示感同身受，但是他之前就做出了選擇，已經走在了“擔心有人爲了競爭而竊取你的代碼而出售閉源SaaS軟件”的非開源道路上，併爲之深感後悔。
Richell對Ars Technica說：“我們擔心有人會把這樣的軟件打包，那樣的話我們會失去所有的投資。” 他說，System76在想要用一些類似專利保護的東西來保護這些軟件幾年，但那“最終傷害了我們，傷害了平臺，我們本不應該抱有那些顧慮。”
雖然Beanbooks的SaaS版本看上去不錯，但是這些可用的代碼不會得到更新，而從自由軟件的角度來看，沒有更新的代碼其實就毫無用處。這些代碼的Github頁面就像是是一個死寂的無人鎮一樣。沒有人來推動代碼的發展，沒有交流的社區。儘管Beanbooks的服務還在繼續，但伴隨這種服務的並沒有一個社區去貢獻各種想法、代碼、以及其他活躍的開源項目所擁有的一切公共社區資源。Richell認爲，如果Beanbooks從一開始就擁有GPL或類似的開源許可證，它可能會避免自己現在的命運。
“如果有人想要使用這些軟件，單就這一點來講就已經足夠好了，” Richell這樣說。對他而言，成功的關鍵不是軟件開源本身，而是隨之而來的創新動力。“這其中的差異不是去看你今天的成就，而是你能以多快的速度進步，” 他有感而發地說。作爲軟件開發者，你有一個良好的開端，單就這一點並不夠，你還希望對自己的長遠目標有一個規劃。用Peren的術語來說，這些纔是在競爭中真正體現差異的地方。
“取得成功的唯一途徑就是始終保持領先，” Richell補充說道，“我並不認爲這和軟件許可證有任何關係。”
多種軟件自動化和部署工具的製造商Chef公司似乎對這一點深表同意。基於這一精神，又開闢了與MongoDB和Redis截然相反的一條道路。在今年春天，Chef宣佈將之軟件許可更改爲在Apache 2.0許可下的完全開源。Chef首席執行官Barry Crist寫道：“我們歡迎任何人使用我們的軟件，並根據自由軟件的四項基本自由原則對其進行擴展開發。” 雖然Crist發表的言論中並沒有提及其他任何公司，但仔細揣摩，還是能看出“四項基本自由原則”這裏的措辭正是針對Redis和MongoDB的一種迴應。
展望未來
人人都喜歡聽受壓迫的弱者奮起反抗的故事，Redis Labs和MongoDB也想要把自己粉飾成一個開源的受壓迫者，揭竿而起英勇反抗以AWS爲代表的邪惡勢力。而他們真的是受壓迫的弱者嗎？
至少目前看起來，Redis Labs和MongoDB仍然是非常健康發展的公司。今年早些時候，Redis Labs還籌到了6000萬美元的資金，而且根據提供資金的公司而言，Redis已經爲一次成功的IPO做好萬全準備。而從各方面而言，MongoDB在2017年的IPO都算得上是一個巨大的成功。該公司股票首次公開發行價格爲24美元，此後一直穩步攀升。如今，它的股價已經在每股100美元以上。在2019年早些時候，雖然MongoDB最大的用戶之一Lyft確實轉用了亞馬遜，但在股價小幅下跌之後，MongoDB的股價又回到了Lyft變節之前的水平。
由此可見，兩家公司其實都沒有受到太大影響。或者說，至少現在還沒有。他們許可證變更的影響還有待觀察，但是考慮到之前MongoDB的大部分開發貢獻本就來自於自家員工，所以無論是否開源，MongoDB很可能都能夠一直保持不錯的狀態。
其實，這兩家公司的業務都不會直接影響更大範圍的整個開源生態。開源生態環境從來就不是適合每家企業的。正如Perens在今年早些時候的一次對話中所說的那樣，“只要你不將之稱爲開源，你可以使用任何你想要的軟件許可，那是你的自由。但如果選擇開源，就得服從於某些權利，爲了保護自己的商業模式而放棄這些權利在道理上是講不通的。”
事實上，在我與開發人員和創始人的所有對話中，有一句話總是浮現在我的腦海中。System76的創始人Carl Richell說得再明確不過：“如果沒有把‘奉獻’嵌入到開源中，開源就無法工作。”
所以，在這種情況下，無論你報以什麼目的來使用開源軟件，奉獻都是使用開源軟件的基本權利。
這一直以來都是對所有新的開源許可的基本定性測試，即該許可是否限制了軟件的慷慨程度？開源之所以能發展到今天，是因爲它可以在任何地方、任何東西上使用。想要把開源軟件和專有軟件結合起來嗎？可以。想要重新編寫開源代碼庫，以便它可以與你的專有代碼進行接口嗎？也可以。想要把那個開源代碼庫拿過來，把它包裝成一種服務，然後賣掉它嗎？仍然可以。因爲最終，這就是開源的定義：通過奉獻而獲得自由。正如Perens所指出的那樣，即使這種模式對某些特定的企業不奏效，開源就是開源，本該如此。
英文原文：
In 2019, multiple open source companies changed course—is it the right move?