我是一名風險投資者，在13年中先后投資了許多開源項目背后的公司：
Spring
Mule
Ruby Rails
Groovy
Grails
Maven
Gradle
Redis
SysDig
Hazelcast
Akka
Scala
Cassandra
Spinnaker
以及其他公司
開源已經在為社會服務，開源商業模式已經大獲成功、有利可圖。
亞馬遜的行為
我很欽佩亞馬遜的執行力。在風險投資行業，我們習慣于大型軟件公司(比如IBM、Oracle、惠普、Compuware、冠群、EMC、VMware和思杰等)主要成為龐大的銷售和分銷渠道，這需要獲得創新(即收購初創公司)為渠道提供活力。亞馬遜則不然。2015年7月，《華爾街日報》引述我的話說：“亞馬遜的執行力太強了，幾乎就像一家初創公司。這對于生態系統的每個人來說都很可怕。”那個月，我在投資者網站Seeking Alpha上撰寫了《提防亞馬遜巨無霸》(https://seekingalpha.com/article/3333195-fear-the-amazon-juggernaut)。自我撰寫那篇文章以來，亞馬遜的股價已上漲了400%。(我間接持有亞馬遜的股份。)
但對于其客戶之外的任何人來說，亞馬遜可不是一家溫情脈脈的公司。好多文章詳述了其殘酷無情的企業文化。為什么它對開源的使用會有何不同?
進入到AWS，將鼠標懸停在頂部的“產品”菜單上，你會看到亞馬遜并不創建，但是作為服務來運行的無數開源項目。這些項目每年為亞馬遜帶來了數十億美元的收入。
比如說，亞馬遜享用Redis(StackOverflow的開發者調查中最受歡迎的數據庫)，幾乎沒有回饋，將其作為服務來運行，改頭換面后取名為AWS Elasticache。其他許多流行的開源項目同樣被拿來后作為AWS產品來提供，包括Elasticsearch、Kafka、Postgres、MySQL、Docker、Hadoop和Spark等。
要說明的一點是，這并不違法。但我們認為這是錯誤的，不利于可持續發展的開源社區。
共用條款(Commons Clause)
2018年初，我召集了20多家大型開源公司(其中一些已上市)的創始人、首席執行官或首席顧問，暢談該如何是好。3月份，我向GeekWire介紹了這項工作。大家在經過一番建設性的深入討論后一致認定，我們應制定一種禁止這種行為的簡單條款，而不是拐彎抹角，混合搭配多種開源許可證以阻止這種行為。我們邀請備受尊敬的開源律師希瑟•米克(Heather Meeker)起草該條款。
2018年8月，Redis Labs宣布決定將這個名為共用條款(Commons Clause)的附加條款(即另增一段條文)添加到其針對某些附加模塊的自由開源許可證。Redis仍然采用寬松的BSD許可證，Redis本身卻沒有任何變化!但是Redis Labs附加模塊將包括共用條款這個附加條款(它使源代碼具有可用性)，但無法“出售”模塊，其中“出售”包括將它們作為商業服務來提供。目的是明確防止云基礎設施提供商的不良行為。
包括通用汽車(GM)或通用電氣(GE)在內的其他所有公司仍可以對軟件做它們之前所做的一切，即使添加了共用條款。它們可以查看和修改源代碼，提交合并請求，以便將經過修改的內容添加到產品中。它們甚至可以在內部將軟件作為服務提供給員工。共用條款阻止商業服務與別人的開源軟件一起運行，就像云基礎設施提供商所做的那樣。
不出所料，這則宣布在開源社區引發了熱烈的反響，有點贊，也有炮轟。說到過于簡化的風險：那些點贊的人認為這是開源許可道路上合理而積極的演變，讓開源公司得以在投入于開源項目的同時成功運營業務。Ansible的開發者邁克爾•德哈恩(Michael DeHaan)在《為什么開源需要新的許可證?》中特別清楚地闡述了一個方面：
我們看到運營開源“基金會”和網站的一些人簡直就是電視評論員，就“開放源代碼促進會”之類的組織所描述的“開源”的定義發表政治論調，該組織旗下的許多項目擁有一定的人氣或擁躉。他們試圖聲明源代碼免費可用但使用場景有限的這種許可證“不是開源”。遺憾的是，這艘船已啟航了。
那些持中立或反對態度的人指出，共用條款使得軟件不是開源軟件，這很準確;使代碼庫的一部分成為專有代碼違反開源精神;Redis Labs準是走到了絕路，很難賺錢。
首先，別為Redis Labs而操心。這家公司做得非常好。Redis比以往任何時候更強大、更受寵、更恪守BSD。
更重要的是，我們認為現在是時候在當今的環境下重新審視開源的精神了。開源變得流行時，它旨在供從業人員拿來實驗和改進，同時回饋開源社區。當時沒有一家公司將基礎設施作為服務來提供，也沒有一家公司拿來開源項目后改頭換面另取名稱，將其作為服務來運營，攫取利潤，但回饋甚少。
我們認為，開源軟件從來就沒有打算讓云基礎設施公司拿去后售賣。這不是最初的開源精神。共用條款在重扛最初的開源精神這面大旗。希望使用流行的開源項目用于其應用程序的組件的學者、業余愛好者或開發人員仍可以這么做。但是如果你想拿來實際上別人開發的同一軟件，將其作為服務來提供以牟取私利，那就不符合開源社區的精神。
事實證明，以共用條款為例，這會使源代碼嚴格上來說不是開源的。但是為了捍衛最初的開源精神，這是我們必須忍受的。
Apache +共用條款
Redis Labs發布的某些附加模塊采用Apache +共用條款。Redis Labs明確表示，運用共用條款讓這些模塊不是開源產品，Redis本身仍然開源和采用BSD許可證。
一些偏激的開源人士指責Redis Labs試圖誘騙開源社區認為模塊是開源的，因為它們使用了“Apache”這個字眼。
沒有什么花招。共用條款是附加到任何寬松的開源許可證的補充條款。由于各種開源項目使用各種開源許可證，因此使用共用條款發布軟件時，必須指定共用條款附加到哪種寬松的底層開源許可證。
為什么不用AGPL?
這種場景下不使用AGPL有兩大原因。AGPL是一種開源許可證，表明你將采用AGPL許可證的代碼作為服務來運行時，必須向公眾發布所做的任何修改。
首先，AGPL只是讓云基礎設施提供商有上述的濫用行為很不方便，但阻止不子。它只是表明它們有這類行為時必須發布所做的任何修改。其次，AGPL含有的軟件專利方面的條文毫無必要，許多企業不喜歡。
我們投資的許多擁有AGPL項目的公司已接到了大企業的要求，要求轉而采用更寬松的許可證，因為使用AGPL違反了它們公司的政策。
平衡之道
云基礎設施提供商不是什么壞人，也不是惡意行事。開源始終是一種平衡之道。我們許多人信任客戶和同行查看我們的源代碼，進行改進和回饋。別人免費分發其工作產品，并相信你能夠有所回饋始終是一種信任的飛躍。有時候對于一些項目而言，無需太刻意的努力，就會自然平衡。但在其他時候，自然平衡并不出現：我們從基礎設施開源身上越來越多地看到這一幕，尤其是云基礎設施提供商試圖通過走向堆棧的上游：從大眾化計算和存儲走向更高級的基礎設施服務，以此實現差異化。
修訂
截至本文發稿時的共用條款版本是1.0。將來會進行修訂和調整，確保共用條款實現目標。我們想聽聽你們的意見。
我們看到的迄今為止就共用條款所表達的不同觀念實際上是理念上的差異。許多批評來自并不屬于用軟件來賺錢這個行當的開源人士。他們有不同的理念，但這不足為奇，因為他們的工作是成為政治活動家，而不是為公司打造價值。
一些人誤以為共用條款阻止人們提供維護、支持或專業服務。這是一種對該條款的誤讀。一些人聲稱，共用條款與AGPL有沖突。共用條款旨在與比AGPL更寬松的開源許可證一起使用，因此不必使用AGPL!不過，即便使用AGPL，也很少有使用作者開發的軟件產品的人會認為完全無視作者運用共用條款的意向聲明是明智的。
保護開源
一些開源利益相關者感到困惑。他們應該站在哪一邊?共用條款是新的，我們認為有爭論實屬正常。支持這個倡議的人是鐵桿的開源倡導者，我們的目的就是保護開源、遠離事關生存的威脅。我們希望其他人能團結起來、支持共用條款，那樣開源公司能賺錢，開源能存活下來，開源開發者能為他們的貢獻得到報酬。
京公網安備 11010502049343號