開源
開源軟件社區出現了一片烏雲，亞馬遜等雲基礎設施提供商的行為已經威脅到了開源軟件的生存。
我是一名風險投資者，在13年中先後投資了許多開源項目背後的公司：
- Spring
- Mule
- Ruby Rails
- Groovy
- Grails
- Maven
- Gradle
- Redis
- SysDig
- Hazelcast
- Akka
- Scala
- Cassandra
- Spinnaker
- 等
開源已經在為人類社會服務，開源商業模式已經被證明有利可圖，例如 RedHat 紅帽公司。
亞馬遜的行為
我很欽佩亞馬遜的執行力。在風險投資行業，我們習慣於大型軟件公司（比如IBM、Oracle、HP、Compuware、CA、EMC、VMware、 Citrix等）主要成為龐大的銷售和分銷渠道，這需要獲得創新（即收購初創公司）為渠道提供活力。亞馬遜則不然。2015年7月，《華爾街日報》引述我的話說：“亞馬遜的執行力太強了，幾乎就像一家初創公司。這對於生態系統的每個人來說都很可怕。”那個月，我在投資者網站Seeking Alpha上撰寫了《提防亞馬遜巨無霸公司》（https://seekingalpha.com/article/3333195-fear-the-amazon-juggernaut）。自我撰寫那篇文章以來，亞馬遜的股價已上漲了400%。
但對於其客戶之外的任何其他人來說，亞馬遜可不是一家溫情脈脈的公司。好多文章都詳述了其殘酷無情的企業文化。為什麼它對開源軟件的使用有何不同呢？
進入到 AWS 網站，將鼠標停在頂部的 “產品” 導航菜單上，您會看到亞馬遜提供作為服務來運行的無數開源項目。這些項目每年為亞馬遜帶來了數十億美元的營業收入。
比如說，亞馬遜享用 Redis 開源軟件，幾乎沒有回饋社會，將其作為服務來提供，改頭換面後取名為 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，也很少有使用作者開發的軟件的產品的人，認為完全無視作者運用共用條款的意向聲明是明智的。
保護開源
一些開源利益相關者感到困惑。他們應該站在哪一邊呢？共用條款是新的，我們認為有爭論也正常。支持這個倡議的人是鐵桿的開源倡導者，我們的目的就是保護開源軟件所倡導的精神。我們希望其他人能團結起來、支持共用條款，那樣開源公司能賺錢，開源能存活下來，開源開發者能為他們的貢獻得到報酬。
原文網址：https://techcrunch.com/
閱讀更多 IT開源中國 的文章
