開源軟體的中年危機如何破解？

作者 |Paul Dix

譯者 | 彎月

責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

2018年12月，Confluent宣布他們將改變平台上一部分功能的授權，不再使用Apache2，而改用Confluent Community License；

而這之前，AWS剛剛在Re:Invent 2018上發布了AWS管理的Kafka服務；

RedisLab將其特定的插件授權改成了Commons Clause授權；

MongoDB也將其授權從AGPL改成了Server Side Public License；

之前還有CockroachDB宣布將採取CockroachDB Community License；

......

所有這些都有一個共同點：它們的目標都是利用新的授權維護這些公司的軟體在託管服務上的壟斷地位——這一切都是為了抵抗AWS、GCP、Azure等公有雲服務商給他們的商業活力造成的威脅。

在這篇文章中，我將提煉這些改變招致的各種非議和憤怒，並從多個角度闡述我的個人觀點。最後我會證明，寬容的開源授權加上封閉的商業產品，才是那些靠開源項目為生的公司最理想的開源之路。實際上，後一點正是我們在InfluxData採取的策略，因此我提出這個觀點也許並不是太突兀，但我想說的是，InfluxData也走了許多彎路，在看到它與其他開源供應商、項目和社區的交流之後，我在這個問題上有了更清晰的看法。

與往常一樣，這些觀點還在不斷變化，所以我現在寫的只是我目前的看法。將來我可能會覺得我現在的觀點很愚蠢，也可能會贊成我現在對於開源、雲和商業的看法。免責聲明說完了，現在我們來回顧下歷史……

我們啟動InfluxDB時，一切都是MIT授權，開發也完全在開放的環境下進行。這符合我當時（也是現在）對於開源的理念，即開源軟體應當可以免費使用、集成並創建派生的作品，對於任何人、任何使用條件都是如此，也無論是用於商業目的還是非商業目的。儘管我認為我們的所有軟體都應當採取MIT授權並保持免費，但在2016年早期，我們在商業化上碰壁了，所以不得不將產品中的集群和高可用性部分改成了封閉的商業授權。在我宣布這項變動的文章中，我寫出了我的顧慮：擔心雲服務商會把我們的軟體當作服務來提供。

有一段時間，我曾想過我們可以在AGPL或類似的授權下提供集群功能，以限制雲服務商，同時保護我們在OEM和受管理的服務（managed service）方面的商業機會。但在最近看到各種授權改變的行為後我意識到，AGPL、SSPL和Community Licenses只是在攪混水，他們帶來了大量大型組織無法認可的授權。一些公司禁止使用AGPL授權，比如Google。但在分析這些授權之前，我先提煉下各種爭議的焦點，大致如下：

人們認為軟體廠商聲稱開源但實際上並非開源而產生的憤怒；

以開源的名義作為誘餌獲得開源貢獻，之後再改變授權；

從開源授權改成有限制的授權的趨勢（或者用Bryan Cantril的話來說，開源軟體的中年危機）。

人們憤怒是因為他們認為所謂「開源」只不過是誘餌。開源廠商已經聲明，新的社區授權不是開源授權，只是提供源代碼而已。而人們依然拿著獵叉和火把圍聚在廠商門前，因為他們覺得一些本應開放的東西被廠商拿走了。而且他們還認識到，社區會因為廠商的社區授權中的限制而遭受到局限或傷害。我認為，開源軟體的短暫歷史表明，整個項目和生態環境的授權越寬鬆，社區就越大、越有活力（儘管只有授權並不能保證開源項目的成功）。

認為以開源作為誘餌之後再改變授權的觀點就有點誇張了。編寫開源軟體的廠商、個人甚至基金會都沒有承諾永遠以開源模式開發軟體並改進。你的貢獻是在現有軟體的基礎上作出的。社區可以分裂，項目可以分叉，用戶和貢獻者可以消失，廠商也會破產，或者被有著不同目標的公司收購。一個公司作為開源項目的主要開發者，如果它無法找到在長期內收回成本的途徑，那麼最後一條路是不可避免的。

一個項目，不論是由社區驅動，還是由一家公司驅動，如果你不喜歡它的新方向，你可以在它改變授權之前的版本上創建新的分叉（或在拒絕一些你不想要的拉取請求之後），然後在派生的項目上繼續使用、開發並培養新的社區。這就是為什麼對於社區來說，寬容的授權要比「社區授權」更好的原因，它不限制派生的作品。儘管如此，我們也應當更友善（同時也是更現實）地認為，廠商的這些決定是根據當前的環境作出的，而不是多年處心積慮誘惑開發者貢獻代碼再讓項目人間蒸發的計劃的一部分。就算真的有這種計劃，貢獻者和佈道者們的努力也沒有白費（參考上面關於分叉並創建派生作品的建議）。

最後一種觀點認為這種趨勢是開源軟體的末日。同樣，我認為這種看法也太誇張了。如果這的確是個問題，那麼早在幾年前SaaS和雲服務成為軟體發布的主流模型時就應該出現了。SaaS和雲服務都是與開源運動直接對立的，因為它們都代表了閉源軟體而不是開源軟體（儘管它們主要是在開源軟體的基礎上構建的）。如果這是趨勢，那麼早在15年前就應該出現了。拋開誇張的一面不談，我還認為，在開源和閉源中間應該還有一種混合模式。如果基礎設施供應商想要把社區認為重要的東西改成閉源，那麼其他項目和公司都會來解決同樣的問題。開源意味著選擇，只要開發者還有電腦、編輯器和網路，就會不斷有新的選擇出現。

好了，現在我們來聊聊授權。像AGPL、SSPL這種copyleft（反版權）從整體的社會益處來說，比MIT、Apache2等自由授權要弱一些。copyleft有兩種解釋，我分別稱之為「十字軍」和「資本家」。在十字軍的解釋下，開發者宣稱他們希望一切都是開放的。他們強迫世界上的一切都是自由的、分享的，想要創造一種類似於星際迷航那種不需要金錢的社會。這是個偉大的夢想，但我認為它不可能出現。人們的熱情並不僅靠目標和偉大的理想來維持，他們需要自己的人生，需要家庭和後代（也就是資本）。Copyleft完全忽略了後者，簡單地認為一切都沒問題。

而資本家解釋則是利用copyleft授權來保護商業模型。但是，資本家通常會偽裝成十字軍，因為大部分人更喜歡這種說辭，而不是說「我想用我的工作來賺錢」（儘管這種說法完全合理）。通常，授權的選擇造成了所謂的「偶然資本家」。例如，我懷疑MySQL在選擇GPL的時候考慮的就是在OEM合同中銷售軟體的商業授權，從而可以繞開GPL，這是他們（早期）的主要盈利模式。Mongo可能也是同樣的方式，但我還沒有機會直接詢問Dwight或Elliot（我也不期待他們會毫無保留地回答，畢竟他們要運營一個上市公司）。最終，資本家會將這個授權偽裝成開源，同時保留一種商業化的途徑。

如果軟體是個持續進化的過程，需要在前人的基礎上構建，那麼copyleft帶來的就是進化的死胡同，而自由授權則代表了樹上不斷生長的新枝。原因是，自由授權的軟體可以用來創建任何其他授權的軟體，可以是copyleft，也可以是商業授權軟體。而Copyleft軟體只能被用來創建其他copyleft軟體（除非一個公司擁有該copyleft授權，並將其賣給其他商業作品，這樣也能產生進化的新葉）。再加上copyleft不僅對嵌入了代碼的程序有要求（比如GPL），還對通過網路訪問代碼的程序有要求（比如AGPL或更嚴格的SSPL），這隻會加劇這個問題。不管OSI怎麼說，最終在我看來，copyleft代表的是真正的開源。Copyleft是一種限制。

社區授權也是同樣。只要你遵守它們的規則和約束，它們就是開放、免費的，可以隨意修改。而它們是否屬於開源，實際上只是語義之爭。如果你認為它們不是開源，那麼copyleft授權也不是，除非你採用十字軍的解釋。如果你非要這樣說，那我建議你還是準備迎接世界崩潰的殘酷現實吧。

社區授權還有個很嚴重的潛在問題，這個問題我沒有聽任何人說起過。如果你是開發者，決定建立一個開源項目或者分叉一個開源項目，來代替某個社區授權中的部分功能和API，那麼你可能會接到該社區授權擁有者的起訴。你可能沒有用到它們的一行代碼，但只要你讀過社區的代碼，就可能需要為此付出代價。至少在商業軟體中，廠商並不能向法庭證明你訪問並複製了他們的源代碼。當然，我不是律師，所以這也許並不是問題，但針對個人或小公司的訴訟可能是毀滅性的。所以從開源的角度來看，這些社區授權代表了軟體進化樹的死胡同。

需要明確的是，我並沒有責備RedisLabs、Elastic、Confluent、Cockroach或任何急於創建社區授權的開源軟體廠商。他們完全有權利這樣做，我甚至認為，儘管有各種限制，但這樣做甚至是件好事。這樣他們才能打造商業流程，以此為昂貴的開源開發提供資金。只是，這些社區授權不再是開源授權而已。

即使copyleft和社區授權被用於商業，它們也不是沒有任何價值和好處。它們為軟體能被自由使用和改動的規則提供了樣本。對於一些用戶來說，這完全沒有意義。他們只需要接受這個事實，即採用了這些授權的代碼代表了他們一切商用產品的基礎。社區授權的最大問題是，大量各不相同的授權在許多大企業或高風險的組織中是禁止使用的。所以這些代碼惠澤的人群範圍將大大減少。儘管有了這些限制，許多商業依然依靠copyleft軟體，所以我認為依靠社區授權軟體的商業也不會少。所以相比之下，社區授權代表了對社會的好處，只不過是沒有MIT和Apache2等開源授權那麼大而已。

在Influx我們曾經研究過AGPL授權。第一版Flux中採用該授權的是Chronograf（我們的UI項目）。但後來我們將Flux改成了MIT授權，Chronograf移動到了InfluxDB中作為UI，採用InfluxDB 2.0的MIT授權。改變的原因是，這不僅對社區有好處，而且也有益於我前面說過的軟體進化。我們希望更多的人使用這些代碼，並建立最大的社區。因此，我們甚至請我們的競爭對手來修改並使用我們的代碼。

原因是，我們早就認識到，Flux的價值在於集成了Flux和可能集成Flux的系統的數量。這條經驗來自Telegraf，這是我們的一個數據收集項目，它一直都是MIT授權，並且收到了大量社區的貢獻（它是我們最廣泛使用、收到貢獻最多的開源軟體）。在建立Telegraf的時候似乎沒有任何理由建立一個數據收集項目，但我們希望有些東西能無縫集成到InfluxDB的數據模型中。但我們需要激勵社區，讓社區願意構建一些插件，從多個地方獲取數據。因此我們決定，不應該將Telegraf限制為僅兼容InfluxDB。最的的結果是，我們接受了一些拉取請求，這些拉取請求可以將Telegraf集成到我們的競爭對手中。但是，當我們有了來自社區的幾百個插件後，我們的競爭對手也有了同樣的幾百個插件。這些插件對我們有好處，也對他們有好處。所以，開源從來不是個零和遊戲。

最後來揭示我對於創建開源業務的回答：採用自由授權的軟體（如MIT或Apache2），並給你希望商業化的軟體提供閉源商業授權。因為幾乎所有SaaS產品或雲平台都會在這種模型下為開源軟體作出貢獻，他們是否也能稱自己為開源軟體業務？我認為他們不應該。但是我認為，如果你有相當一部分開發者是全職編寫開源軟體，那你也可以聲稱自己是開源軟體。在Influx，我們超過半數的開發者一直在編寫開源代碼。我們一直就是一家開源公司。

我已經寫過很多文章討論為什麼我喜歡開放授權。我同時也喜歡商業授權，因為它在開放與封閉之間有明確的界限。其中開放就意味著任何人都可以做任何事。這給社會和社區帶來了巨大的好處。而且，如果社區決定創建開源項目與你的商業授權軟體競爭，他們也無需獲得你的許可。儘管一些商業公司不喜歡這一點，但這種授權給予了社區必要的控制和權力，使之能夠為你的項目做貢獻並推廣。如果你不喜歡這一點，那大可保持閉源，但要清楚，社區參與和保持控制力（以及商業化）兩者不可兼得。最後，即使是閉源的API，也有可能被開源項目取代（我不想說Oracle引發的訴訟的事情）。

我聽到過一些觀點認為，社區授權還是要比閉源商業授權更好，因為閉源授權代表了你無法窺探的黑盒子。如果你這樣認為，那你就不應該使用任何SaaS產品甚至雲平台，因為它們都是閉源的黑盒子。你也需要僱傭真正懂得社區授權的開發者來工作。與人們一般的認知相反，你能閱讀其代碼並不代表它不是黑盒子。對於許多開發者來說，資料庫的代碼就是黑盒子，而實際上這並不是壞事。我們直接使用建立好的抽象，不需要每個開發者都要理解一切。

所以我喜歡完全自由的開源授權和商業授權。但是我更傾向於在一切地方都使用自由授權。但比爾蓋茨也不會平白無故給我錢，所以通過開源給開發者們發工資的唯一途徑就是讓他們同時開發閉源軟體，以此建立業務。我之前說過，開源軟體永遠都需要資金支持，我們必須認清這個現實。

同時，我們需要繼續研究怎樣才能為世界提供更多開源軟體。這是我畢生的奮鬥目標。

原文：https://dzone.com/articles/copyleft-and-community-licenses-are-not-without-me

本文為 CSDN 翻譯，如需轉載，請註明來源出處。

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！