這不是第一例知名開源軟件變更開源許可的事件。就在上個月，我們剛報道過 知名圖數據庫 Neo4j 企業版徹底閉源) 的消息，而在更早之前，包括 MongoDB、Redis 在內的企業都陸續變更了一些開源項目的許可協議。

正如我們在之前的報道 《開源危機：雲計算廠商成爲開源吸血鬼？》（https://www.infoq.cn/article/OE1EVpAi_LYzapRP4oYk) 中所說：

處於巔峯的開源軟件現在正面臨着潛在的危機。

毫無疑問，開源軟件的概念已經徹底改變了軟件世界。在軟件世界接受這種新的格局之前，它們花了數十億美元與這個想法鬥爭了好多年。但是，現在有不少人開始懷疑開源軟件的本質——幾乎所有人都可以使用開源軟件，並將它們用於任何目的——這種想法導致開源軟件開發者在分佈式雲計算服務時代出了大問題。

在一些開源軟件開發者眼中，這個大問題就是，雲計算提供商從開源開發者的工作中受益，尤其是那些頗爲成功的開源軟件，但他們卻沒有爲這些工作支付一分錢。Redis Labs 首席執行官 Ofer Bengal 更是直言不諱：“我想直率地說：多年來，我們就像個傻子一樣，他們拿着我們開發的東西大賺了一筆”。

開源社區和雲計算提供商的矛盾有愈演愈烈的趨勢。Kafka 無疑是目前全球最受歡迎、應用最廣泛的消息系統，而現在，爲 Kafka 提供商業化服務的 Confluent 也站出來表明了自己的態度。

AI 前線將 Jay Kreps 發表的博文翻譯整理如下：

我們正在將 Confluent 平臺的一些組件的許可從 Apache 2.0 改爲 Confluent 社區許可。這個新的許可允許你免費下載、修改和重新發行代碼（類似於 Apache 2.0），但不允許你將這些軟件作爲 SaaS 產品提供給用戶。

例如，你可以將 KSQL 作爲產品或服務的一部分，無論這些產品是作爲軟件發行還是作爲 SaaS 服務提供給用戶，但你不能用它創建類似“KSQL 即服務”這樣的東西。我們的開發仍然是開放的，並繼續接受拉取請求和功能建議。對於那些非商業雲提供商用戶，即我們的 99.9999％用戶，新許可對他們來說並沒有實質上的限制，同時我們會繼續在開發上大量投入。

但新許可並沒有針對 Kafka，Kafka 是 Apache 軟件基金會的一部分，繼續使用 Apache 2.0 許可。新許可只會影響到由 Confluent 維護的開源組件。

爲什麼要修改許可？

我們認爲這是很有必要邁出的一步。一方面，我們需要大量投入才能開發出這些免費發行的代碼，另一方面，我們需要保持業務的健康才能爲這項開發提供足夠的投入資金。接下來我會解釋爲什麼這兩件事都很重要。

首先，這種投資是否有必要？對於很多簡單的開源項目來說，我認爲不是必需的。GitHub 上有成千上萬的庫不需要太多投資，它們只需要一些志願者貢獻者就可以了。但分佈式數據系統不一樣，構建一個成功的分佈式數據平臺是非常困難的。

你不一定要相信我說的話，但事實勝於雄辯。2009——2010 年間出現了數十個 NoSQL 數據庫。有些是作爲附帶項目創建的，有些來自大型網絡公司的內部基礎設施，有些是作爲商業產品創建的。而我認爲最明顯的是，迄今爲止能夠繼續保持競爭力的系統是那些能夠建立穩定的商業實體來維持其開發的系統。那些做到這一點項目（MongoDB、ElasticSearch、Cassandra、Hadoop）都繼續蓬勃發展，併成爲現代技術棧的一部分。那些做不到的項目（Voldemort、Dynomite、CouchDB，等等）儘管早期也很受歡迎，但大都被淘汰了。它們可能仍然存在，但很可能你從未聽說過它們。

造成這種差異的原因似乎很明顯，我曾經在 LinkedIn 等公司、作爲志願者以及作爲 Confluent 的一部分參與開源工作。我們最初在 LinkedIn 開發 Kafka 時，在很長一段時間內開發團隊總共只有幾個人。我利用聖誕假期寫了原始代碼庫，因爲公司沒有爲這個項目提供資源。這個小型的 Kafka 開發團隊開發代碼、運行服務，並最終說服了 LinkedIn 將項目轉移到了 Apache 基金會。他們白天寫編碼，處理來自社區的問題和錯誤，晚上開會，並在深夜醒來處理偶爾會出現的運維問題。但隨着社區的發展，新需求也隨之增長：外部補丁的代碼評審經常延遲，除 Java 以外的客戶端庫通常無法正常運行。

後來成立了 Confluent，我們在開發上的投入遠遠超過了 LinkedIn。很多純粹出於熱情在深夜工作的人現在可以得到報酬，並轉成全職工作。Confluent 不僅可以爲開發提供資金，還可以進行相當大規模的分佈式測試，這些測試不僅可以保持代碼庫的穩定，同時擴展了來自不斷增長的社區的貢獻。雖然代碼仍然不完美，但它的改進速度要快得多。

換句話說，我認爲企業可以爲開源項目的良性循環帶來資金上的支持。

在一個數據系統被作爲內部部署軟件交付的世界中，我們已經知道如何建立可以推動這種良性循環的可持續發展公司。但這並不容易，而創辦一家公司更不容易。我們發現，Apache 2.0 等開源許可可以成爲維持健康業務的軟件產品的主要組成部分。然而，隨着雲產品的興起，它們將這些產品作爲軟件即服務提供給用戶，讓這個世界發生了巨大的變化。在這個新世界中，雲提供商具有顯著的優勢：他們可以控制資源的定價，並且可以在他們的所有產品中集成自己的服務。

主要的雲提供商（亞馬遜、微軟、阿里巴巴和谷歌）使用開源項目的方式都有所不同。其中一些公司與開源公司合作，這些公司提供系統的託管版本，並作爲服務提供給用戶。其他的公司則直接將開源代碼放到他們的雲產品中，並投入資金開發差異化的專有產品。我們不一定要從道德的角度來評判這種行爲，他們也只是爲了追求商業利益，並在軟件許可允許的範圍內行事。

作爲一家公司，我們可以考慮構建更多的專有軟件，並減少開源方面的投入。但我們認爲，構建基礎設施層的正確方法是使用開放代碼。隨着工作負載遷移到雲端，我們需要一種機制來保持自由，同時也要實現投資週期，這就是我們改變許可的動因。

我們認爲這是一個積極的變化，這樣可以確保小型的開源社區不會成爲科技巨頭的免費開發資源，他們只會將資源投入到他們自己的差異化專有產品中。

這意味着什麼？

我認爲新的許可很簡單，即使是沒有法律知識的人也能讀懂。在新許可中，我們試圖儘可能地預先告知我們可以允許那些行爲，不允許哪些行爲，以及爲什麼。

不過，我擔心會出現兩種誤讀。首先，有人可能會認爲 Confluent 陷入困境，所以需要這樣做來賺錢。但事實並非如此，Confluent 的表現其實非常出色，我們認爲這對我們的客戶以及我們投資社區和開源的能力來說都是一件很棒的事情。我們改變許可的目的是確保我們能夠保持這種增長，並繼續在開放和免費產品上投入。

第二種誤讀：這是貪婪策略的一部分，一家貪婪的公司想借此賺到更多的錢。對於這個誤讀，我只能這麼說：Confluent 並非僅僅是爲了賺錢而創立的。我們對以事件流爲中心的現代數據驅動型公司的架構有着遠大的願景，我們希望能夠實現這一目標。Confluent 是由一羣相信這個想法能夠成爲現實的人組成的，對於我們當中的很多人來說，我們在這個項目上的貢獻都早於 Confluent 本身。我們認爲，基於事件流進行重新架構是一個大膽的計劃，還需要做很多工作。這一次修改許可讓我們能夠在未來幾十年繼續開展這項工作，併爲實現這一目標的軟件、社區和實踐做出貢獻。

當然，這些並不意味着我們不是商業實體，或者不會專注於我們正在建立的業務。如果我們能夠成功，流式平臺將成爲公司架構的核心，與關係數據庫一樣，我們將成爲重要的、有價值的和具有戰略性的數據平臺。我們認爲這代表了一種巨大的範式轉變，並將成爲偉大的業務的基礎。

一些重要的問答

• 這對 Apache Kafka 有何影響？

沒有影響。Kafka 繼續使用 Apache 2.0 許可。

• 我可以下載、修改或重新發行代碼嗎？

可以。代碼仍然在 GitHub 上。

• 我可以將代碼嵌入到我的軟件中嗎？

可以。

• 我可以使用代碼構建 SaaS 產品嗎？

可以，大部分情況下是可以的。如果你正在構建 SaaS 產品，可以使用 Confluent 社區軟件。唯一的限制是不能將它們作爲與我們的託管產品相競爭的託管服務。例如，你不能將 KSQL 本身作爲 SaaS 產品提供給用戶。

i4CN（工業4.0中國-簡稱），是中國最系統化、最全面的工業4.0、工業互聯網、智能製造、無人工廠領域的第三方諮詢公司。公司整合華爲、博世、騰訊、美的等專家，首家提供工業4.0整合方案，包括i4技術項目、i4四大管理體系、十大思想變革的三層金字塔式諮詢架構；能夠指導企業實施專業化的工業4.0變革和無人工廠規劃建設與運營管理。助力國家實現中國製造2025的宏偉藍圖。

樑卓業 i4CN首席諮詢顧問中國工業4.0、智能製造、無人工廠、工業互聯網專家，華爲ISC、IPD體系專家華爲ISC+項目組成員，智能製造標杆車間項目經理工業4.0十大思想變革、無人工廠建設體系首創人中山大學麻省理工學院雙MBA，廣東工業大學機電學院本科歡迎需要導入華爲ISC、IPD體系，實施工業4.0無人工廠的企業與i4CN合作。

（請搜索i4CN樑卓業老師相關課程視頻並進一步瞭解）