開源權力斗爭：云廠商利用項目盈利引爭議，小型公司被迫 relicense。Fork 機制成關鍵，AGPL V3 許可證被重新采用。關注 CLA、中立基金會和項目治理，保障貢獻者權益和項目可持續性，共建云原生生態。

譯自：Clouds, Code, and Control: The New Open Source Power Struggle[1]

作者：Dawn Foster

自古以來，當權者常常利用他們的權力來剝削或支配那些影響力較小的人。這種動態不僅限于歷史例子；在現代背景下，例如技術和軟件開發，尤其是在開源項目中，也可以清楚地看到。

封建主義就是一個典型的例子，強大的統治階級控制著土地，導致對辛勤耕作和保護土地的人民的壓迫和剝削。在封建主義制度下，權力主要集中在少數人手中，國王和教會擁有最大的權力。大部分權力被委托給貴族和領主，他們管理土地，并通過軍事服務提供保護。但他們仍然在國王的統治下，國王可以剝奪他們的權力。這些領主和貴族然后控制著耕種土地的農民，他們幾乎沒有權力或自主權，盡管他們做了大部分實際工作。因此，大部分權力掌握在國王和教會手中，貴族和領主擁有一些權力，而農民和農奴在做大部分工作的同時，幾乎沒有權力。

大型云提供商掌握著最大的權力，小型公司掌握著一些權力，而個人貢獻者和用戶掌握的權力很小。界限比較模糊，后果也不那么極端，但隨著大型云提供商的日益普及，開源的權力動態可能感覺類似。在開源的情況下，我們有辦法扭轉這些權力動態。

隨著我們的許多應用程序遷移到云端，使用這些云提供商提供的許多服務變得很容易。他們可以為開源項目提供這些服務，無論他們是否回饋這些項目。當他們對這些開源項目的貢獻不足時，就會與一些小型公司產生摩擦，而這些小型公司通常是開源項目的驅動力。在某些情況下（但不是全部），這些小型公司可能有權重新許可開源項目，這可以扭轉小型公司和云提供商之間的權力平衡。然而，小型公司的這種權力游戲使維護者、貢獻者和用戶處于更弱勢的地位。它會在剛剛重新許可的項目周圍產生摩擦。在開源項目中，那些權力最小的人可以fork the project[2]再次翻轉權力動態，但這需要大量的工作，并且可能成功也可能不成功。

云提供商與開源權力之戰

這些權力動態并不像我說的那么簡單。這些公司中的許多都屬于多個類別。例如，云提供商也是各種開源軟件項目的用戶、貢獻者和維護者。公司還需要對風險投資公司、董事會以及對公司擁有權力的其他利益相關者負責，無論是一家小公司還是一個非常大的云提供商。

最近，一些公司在風險投資公司、股東或其他投資者的壓力下，relicense their open source projects to generate more license revenue[3]，主要是當供應商的收入來源完全或主要依賴于開源項目時。如果其他公司（通常是大型云提供商）競爭相同的客戶并從供應商投入大量資源開發的開源項目中獲利，這種情況可能會更加復雜。對盈利能力的這些擔憂導致投資者施加壓力，要求將開源項目置于新的許可之下，該許可的限制比開源許可下的限制更多。這些限制通常使云提供商或其他公司更難以從新獲得許可的開源項目中獲利。

這顛覆了力量的動態，增加了與較小公司相關的力量，同時降低了云提供商的力量。然而，這并不是力量動態翻轉的結束。這就是 fork 發揮作用的地方，它是一種集體行動的形式，再次翻轉了力量動態，并允許那些權力較小的人掌控我們的命運，就像一個 fork，我們控制著這個新成立項目的治理。然而，事情并沒有那么簡單。Fork 是一項艱苦的工作，所以雖然你經常聽到人們說任何人都可以 fork 一個項目[4]并運行它，但這需要大量的人員和資源才能成功。我提到過，一家較小的公司可以重新許可一個開源項目，以翻轉力量動態，并從云提供商那里重新獲得權力。但是，這些云提供商可以通過 fork 一個項目并從這些較小的公司那里重新獲得權力來再次翻轉力量動態，而且這種方法效果很好，因為這些大型云提供商通常可以投入大量的人員和其他資源來使 fork 成功。

在之前的TNS 博客文章[5]中，我分享了關于三個項目案例研究的數據，在這些項目中，重新許可導致了 fork（Elasticsearch / OpenSearch、Terraform / OpenTofu 和 Redis/Valkey）。值得注意的是，在這三個案例中，由這些重新許可事件產生的 fork 往往比原始項目具有更多的組織差異，特別是當 fork 是在像 Linux 基金會這樣的中立基金會下創建的，而不是由單個公司 fork 的時候。由于這些 fork，Redis 和 Elasticsearch 已經添加了 AGPL V3 許可證[6]，再次成為開源項目，但鑒于這些 fork 獲得的關注，可能為時已晚，無法產生太大的影響。

保護貢獻者并維持項目可持續性

這些力量動態的轉變可能會為那些使用和貢獻這些項目的人帶來重大問題。作為開源的維護者、貢獻者，甚至用戶，我們將我們最寶貴的資源投入到這些項目中：時間。我們需要我們花費時間的項目能夠長期保持可持續性，以避免浪費這種寶貴的資源。沒有辦法預測哪些項目會隨著時間的推移而保持可持續性，哪些項目可能會經歷重新許可或其他 rug pull，但有一些警告信號，以及在決定在一個特定項目上花費太多時間之前我們可以考慮的事情。

? 貢獻者許可協議 (CLA)：這些協議在開源社區中造成了力量失衡。權力傾向于擁有項目并控制 CLA 的公司，這使得公司比其他貢獻者擁有更多的權力。它可能允許公司重新許可一個項目。

? 中立基金會：如果項目是在中立、良好運行的基金會（而不是單個公司）下進行的，則不太可能發生 rug pull，因為這些基金會鼓勵治理結構，從而創建一個公平的競爭環境，來自不同公司的人可以像平等的伙伴一樣一起工作，創造出對每個人都有利的東西。

? 治理：Rug pull 可能會并且確實仍然會發生在基金會項目中，通常是當所有或大部分開發都來自單個公司的員工時。具有中立治理的項目，其中領導職位和維護者來自不同的組織，并且具有公平和透明的流程來選擇這些領導者，則不太可能經歷這些類型的中斷。

? 貢獻者可持續性：項目是否有足夠的貢獻者來長期維持它[7]，并在現有維護者轉移到其他項目時替換他們？對于我們依賴的開源項目，是否有足夠的貢獻者，如果其中一位明天在海灘上退休，沒有發出任何通知，項目是否可以繼續進行，并且中斷程度最小？

這直接關系到公司如何幫助對他們重要的開源項目。我已經談了很多關于權力動態的問題。盡管如此，公司也有能力和資源做出真正的改進，并且公司的參與可以積極地影響我們開源項目的可持續性，包括分支（forks）。公司可以分配員工時間來為項目做貢獻，或提供資金和其他資源來幫助維持開源項目。讓你的員工在一個項目中工作[8]，也能讓你了解可能存在的權力動態，更好地了解該項目的優勢和劣勢，同時也能從內部影響該項目。

隨著大型云提供商的日益普及，開源權力動態看起來有點類似于我在本博文開頭談到的封建主義例子，但在開源案例中，不同之處在于我們有辦法轉變或顛覆權力動態。一家較小的公司決定將一個項目從開源許可證中移除，可以顛覆權力動態，并從那些大型云提供商那里奪回權力。但是，當他們決定重新許可該項目時，他們也同時將權力平衡進一步從貢獻者和用戶手中轉移開。這鼓勵那些權力較小的人采取集體行動來派生（fork）一個項目，從而使權力動態向貢獻者和用戶傾斜，通常包括云提供商作為用戶。在開源世界中，我們比農民和農奴要好，因為我們擁有某些自由，允許我們采取集體行動，通過派生項目來重新獲得權力，以對抗其他人濫用權力。

引用鏈接

[1] Clouds, Code, and Control: The New Open Source Power Struggle:https://thenewstack.io/clouds-code-and-control-the-new-open-source-power-struggle/

[2]fork the project:https://thenewstack.io/why-open-source-forking-is-a-hot-button-issue/

[3]relicense their open source projects to generate more license revenue:https://redmonk.com/rstephens/2024/08/26/software-licensing-changes-and-their-%20impact-on-financial-outcomes/

[4]經常聽到人們說任何人都可以 fork 一個項目:https://thenewstack.io/from-poc-to-production-why-genai-projects-often-stall/

[5]TNS 博客文章:https://thenewstack.io/what-happens-to-relicensed-open-source-projects-and-their-forks/

[6]Redis 和 Elasticsearch 已經添加了 AGPL V3 許可證:https://thenewstack.io/redis-is-open-source-again/

[7]貢獻者來長期維持它:https://thenewstack.io/its-time-to-start-preparing-apis-for-the-ai-agent-era/

[8]在一個項目中工作:https://thenewstack.io/internal-projects-working-inside-the-panopticon/