重磅訊息：Kafka 團隊修改 KSQL 開源許可證，禁止其作為 SaaS 產品來提供
在今年的十月份，MongoDB 宣佈其開源許可證從 GNU AGPLv3 切換到 Server Side Public License (SSPL)，十一月份，圖資料庫 Neo4j 也宣佈企業版徹底閉源。就在昨天，Confluent 公司的聯合創始人兼 CEO Jay Kreps 在 Confluent 官方部落格宣佈 Confluent 平臺部分開源元件從 Apache 2.0 切換到 Confluent Community License，參見這裡，下面是這篇文章的全部翻譯，原文參見https://www.confluent.io/blog/license-changes-confluent-platform。
我們正在將 Confluent 平臺的某些元件的許可證從 Apache 2.0 更改為 Confluent社群許可證（Confluent Community License）。 這個新許可證允許您免費下載，修改和重新分發程式碼（非常類似於 Apache 2.0），但它不允許您將軟體作為 SaaS 產品提供給其他使用者。
這些措施意味著什麼呢？比如，你可以使用 KSQL，並覺得這個非常適合作為你自己的產品或服務的一部分，無論這些產品是以軟體形式還是作為 SaaS 提供；但你無法建立 KSQL 即服務（KSQL-as-a-service）的產品。 我們接下來的開發仍然是開放的，同時也接受拉取請求（pull requests）和功能建議（feature suggestions）。 對於那些不是商業雲提供商的使用者，即這些專案的 99.9999％ 的使用者，這對他們來說沒有任何有意義的限制，同時允許我們繼續大力投入於研發。
這個措施對 Apache Kafka 沒有任何影響，Apache Kafka 是作為 Apache Software Foundation 的一部分進行開發的，其仍然是使用 Apache 2.0 許可，並且我們將繼續積極地為此做出貢獻，這次協議的修改只會影響 Confluent 維護的開源元件。
為什麼要這麼做
我們認為這是很必要的一步。這使我們可以繼續大量投資我們免費分發的程式碼，同時保持業務的健康發展，為這種投入提供資金。我會解釋為什麼這兩件事都很重要。今年年初我花了一個月整理了一份最適合2018年學習的大資料學習乾貨，從最基礎的大資料叢集搭建，大資料元件和專案實戰，加群834325294 註明簡書既可免費獲得。
首先，這種投資是否必要？ 對於許多簡單的開源專案，我認為沒有必要。 有成千上萬的庫在 GitHub/">GitHub 上蓬勃發展，除了一些志願者貢獻之外，不需要太多的投資。 分散式資料系統是不同的，構建一個成功的新分散式資料平臺是非常困難的。
你不需要接受我說的話，但事實證明就是如此。2009 - 2010 年期間出現了數十個 NoSQL 資料庫。有些是作為業餘專案建立的，有些來自大型網路公司的內部基礎設施，有些是作為商業專案建立的。我認為最明顯的是，迄今為止能夠繼續保持競爭力的是那些有穩定商業實體來維持其開發的系統。 做到這一點的系統（MongoDB，ElasticSearch，Cassandra，Hadoop）都繼續蓬勃地發展併成為現代堆疊的一部分。那些沒有相關商業公司的支援的系統（Voldemort，Dynomite，CouchDB等），儘管早期受歡迎，但都已經被淘汰了。 它們可能仍然存在，但你很可能從未聽說過它們。
這種差異的原因在我看來似乎很明顯，我曾經參與了開源專案的開發，包括在 LinkedIn 公司作為志願者參與，或者是作為 Confluent 的一部分。當我們最初在 LinkedIn 開發 Kafka 時，我所在的團隊在大部分時間總共就幾人。我利用聖誕節假期編寫了原始程式碼庫，因為該專案沒有官方資源。那個小型的 Kafka 團隊編寫了程式碼，執行服務，傾向於開源社群，並最終說服 LinkedIn 將專案轉移到 Apache。 這意味著在白天編寫程式碼，然後處理向社群報告的 issues 和 bugs；晚上召開一些會議，並在深夜醒來處理一些偶爾會出現的操作問題。但隨著社群的發展，需求增長得更快：外部補丁的程式碼審查常常滯後，而 Java 之外的客戶端基本上執行不了。
Confluent 的建立使我們的投資遠遠超過 LinkedIn。很多純粹是在激情基礎上深夜做出貢獻的人現在可以得到報酬，並全職參與工作。 Confluent 不僅可以為程式碼貢獻提供資金，還可以為執行大規模分散式壓力測試所需的大筆雲費用支付費用，以確保程式碼庫穩定，同時擴充套件來自不斷增長社群的貢獻，雖然程式碼依然不完美，但改進的速度卻大大加快了。
換句話說，我相信企業可以幫助開源貢獻的良性迴圈。
在資料系統作為內部部署軟體交付的世界中，我們已經找到了如何建立可推動這種良性迴圈的可持續發展公司。這並不容易，但創辦公司向來不容易。在這個模型中，我們發現 Apache 2.0 等許可的開源許可是維持軟體產品健康蓬勃發展的主要組成部分。然而隨著雲行業的興起，世界已經發生了巨大的變化，這雲服務提供了軟體即服務的產品。在這個新世界中，雲提供商具有明顯優勢：他們控制所有服務提供商使用資源的定價，並且可以在他們的所有產品中整合自己的服務。
主要的雲提供商（亞馬遜，微軟，阿里巴巴和谷歌）在開源的態度都有所不同。其中一些公司與開源公司合作，這些公司提供其系統的託管版本作為服務。其他人採用開原始碼，將其引入到雲產品中，並將自己的所有投資都投入到差異化的專有產品中。我並不想從道德上來評價這種行為，這些公司只是遵循其商業利益並在軟體許可允許的範圍內行事。
作為一家公司，我們可以追求的一個解決方案是為我們構建更多專有軟體，並在開源方面減少投資。 但我們認為構建基礎架構層的正確方法是使用開原始碼。隨著工作負載遷移到雲端，我們需要一種機制來保持自由，同時實現投資週期，這是我們轉變許可的動力。
我們認為這是積極的變化，可以幫助確保小型開源社群沒有充當科技巨頭免費的、不可持續發展的研發工具，科技巨頭們將持續性資源只投入到它們自己的差異化專有產品中。
這麼做意味著什麼
我認為新的許可證很簡單，即使對於非律師也能理解；在許可證和本公告中，我們都試圖儘可能地預先考慮我們想要允許的做法，我們想要阻止的做法，以及為什麼。
這個公告讓我擔心有兩種憤世嫉俗的解釋。首先，這表明 Confluent 正處於困境，需要這樣做才能賺錢。事實並非如此，Confluent 的表現非常出色，我們認為這對我們的客戶以及我們投資社群和開源的能力來說都是一件很棒的事情。我們之所以這麼做的目標是確保我們能夠保持這種增長，並繼續投資開源免費的產品。
具有諷刺意味的是，第二種玩世不恭的解釋恰恰相反：這是一種貪婪策略的一部分，以便通過一個貪婪的公司提取更多的錢。與此相反，我只能這樣說：Confluent 並非是為了賺錢而建立的。我們對現代資料驅動型公司並以事件流為中心的架構有一個願景，我們希望在世界上實現這一目標。 Confluent 是一群相信這個想法的人，對於我們中的許多人來說，我們在這個專案上的工作早於 Confluent 本身。 構建程式碼和社群方面的早期工作並不是將其實現商業化的長達十年的計劃的一部分。相反，我們認為圍繞事件流重新設計世界上所有公司的計劃是一個大膽的計劃，需要做大量的工作。這一變化使我們能夠在未來幾十年繼續開展這項工作，為軟體、社群和實踐做貢獻，從而實現這一目標。
當然，這些並不意味著我們不是商業實體，或者不會專注於我們正在建立的業務。如果我們取得成功，流媒體平臺將成為公司架構的核心，與關係資料庫一樣，將成為重要，有價值和戰略性的資料平臺。 我們認為這代表了一個巨大的正規化轉變，並將成為一個夢幻般的業務的基礎。我們認為，這代表一次巨大的正規化轉變，並且將是偉大商業的基礎。
幾個典型的問答
這個改變對 Apache Kafka 有什麼影響
並沒有影響。我們繼續在 Apache 2.0 許可下通過 ASF 為 Apache Kafka 做出貢獻。