出處丨AI前線

今天，Confluent 公司（為 Apache Kafka 開源軟件提供商業化服務支持的初創公司，由 Kafka 的幾位創立者離開 LinkedIn 後成立）聯合創始人兼 CEO Jay Kreps 在 Confluent 官方博客發文表示：Confluent 平臺部分開源組件正式變更開源許可協議，從 Apache 2.0 切換到 Confluent 社區許可。這個新的許可允許免費下載、修改和重新發行代碼（類似於 Apache 2.0），但不允許將這些軟件作為 SaaS 產品提供給用戶。去年剛推出並引發關注的流數據 SQL 引擎 KSQL將受到新許可的影響，但 Kafka 本身不受影響。

上個月，我們剛剛報道過最受歡迎圖數據庫 Neo4j 宣佈企業版徹底閉源的消息，其中一個原因就是想避免雲提供商只從開源中“薅羊毛”而不為這些項目作貢獻。這一次 Confluent 變更開源許可協議，有人認為是開源和雲對抗的升級，也有人認為這意味著開源社區的覺醒，你怎麼看？

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

正如我們在之前的報道《開源危機：雲計算廠商成為開源吸血鬼？》中所說：

在一些開源軟件開發者眼中，這個大問題就是，雲計算提供商從開源開發者的工作中受益，尤其是那些頗為成功的開源軟件，但他們卻沒有為這些工作支付一分錢。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 產品提供給用戶。

英文原文：

https://www.confluent.io/blog/license-changes-confluent-platform?from=timeline&isappinstalled=0

閱讀更多 InfoQ 的文章

關鍵字: 開源軟件 雲計算 NoSQL