AI前線導讀：

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

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

更多干貨內容請關注微信公眾號“AI前線”（ID：ai-front）

這不是第一例知名開源軟件變更開源許可的事件。就在上個月，我們剛報道過知名圖數據庫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\u0026amp;isappinstalled=0

總結

以上是生活随笔為你收集整理的Kafka团队修改KSQL开源许可，怒怼云厂商的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。