譯序
我在此前的多篇文章中討論了商業開源的話題：
《企業開源的軟件協議模型實踐》
《企業實踐開源的動機》
《商業源碼協議為何得到 HashiCorp 等企業的垂青？》
《企業如何實踐開源協同》
《中國不缺好的開源開發者》“商業探索與可持續”一節
《開源不是商業模式》
《誘導轉向的偽開源戰略》
《免費增值的商業模式》
這些討論當中觀點的源頭，除了我在商業開源公司的工作經歷以外，也有對國外企業主和律師的內容的理解。其中，撰寫了《Open Source for Business》[1]（中文版為開放原子開源基金會律師劉偉翻譯的《商業開源》）的大律師 Heather Meeker 的觀點尤為重要。早在夜天之書 #6 一文里，我就引用過 Heather Meeker 的觀點。
今年五月份前后，我讀到了 Elastic License 2.0 and the Evolution of Open Source Licensing[2] 一文。它是 Heather Meeker 律師帶頭撰寫 Elastic License 2.0 協議背后的故事和自述。我深感它對于近五年商業開源軟件形勢發展的影響，于是向 Heather Meeker 申請了翻譯本文的授權。今天終于有時間完成翻譯，希望能幫助國內關注商業開源的企業家、開發者以及律師，了解發生在北美軟件行業的一系列變化。
以下原文翻譯。
2021 年 2 月，Elastic 發布了其軟件產品的新協議，即 Elastic License 2.0[3] 協議。通過這一舉措，包括 ElasticSearch 和 Kibana 在內的一系列重要軟件采用了一種新的、公開的以及簡化的協議模型。這一變化是如何發生的？其背后的原因是什么？這些變化又意味著什么呢？
Elastic 的新協議是針對采用開放發展模式的公司在軟件協議最佳實踐方面的一個重要趨勢的結晶。它并不是一個開源協議，但它旨在設定最低限度的限制，以在自由使用、共享和修改軟件之間取得平衡，并防止對社群造成損害的行為的發生。
UNIX / Linux / 自由軟件 / 開源
要想理解 Elastic License 2.0 所代表的新協議趨勢，知道它是如何從開源協議運動中發展而來的至關重要。
開源運動或自由軟件運動，源于開發者對軟件私有化和軟件開發分叉的擔憂。UNIX 的一系列操作是這些擔憂的來源。
UNIX 是當時最流行的操作系統。多年來，UNIX 的許可條件非常慷慨，因為它的開發者 AT&T 貝爾實驗室受制于 1956 年的同意法令，不能從其研究項目中獲利，其中包括 UNIX 和 C 語言。學者、研究人員和開發者開始分享他們的改動和改進，因此 UNIX 很快成為操作系統的領導者。
原注 "Modification of Final Judgment," August 24, 1982, filed in case 82-0192, United States of America v. Western Electric Company, Incorporated, and American Telephone and Telegraph Company, U.S. District Court for the District of Columbia web.archive.org/web/20060827191354/members.cox.
然而，上述同意法令在 1983 年一經解除，AT&T 就立刻根據傳統的商業條款設計不允許分享更改的軟件協議。此后，UNIX 分裂成許多不兼容的版本，并且其專有軟件協議禁止用戶像以前那樣通過分享改動進行合作。
自由軟件運動以及隨后的開源運動是對 UNIX 私有化的回應。它們試圖防止基礎設施軟件再次走向封閉。這個運動以 UNIX 的自由軟件替代品 Linux 為中心，并很快發展成一個認為“所有軟件生而自由”的具有巨大影響力的運動。這個運動的核心理念包括用戶有權訪問源代碼、改進軟件和分享軟件的改進版本。這些原則體現在 GNU 通用公共協議[4]（GPL）中，該協議要求二進制文件的分發者必須向接受者免費提供相應的源代碼。
隨著時間的推移，尤其是 2000 年初互聯網的興起，開源協議變得越來越受歡迎。盡管部分開源協議（例如 GPL 協議）新穎且復雜，引發了一些法律上的擔憂，但它們為企業間的合作鋪平了道路。很快，開源以及它所促進的合作被整個技術行業全心接受。如今，開源是電子商務的支柱，企業經常合作開發基礎軟件。
云的興起和 AGPL 協議
GPL 協議要求分享修改后的源代碼，但是這個要求只在二進制分發時生效，即取得二進制的人有權索要源代碼。但是，這意味著 GPL 允許制作和使用“私有版本”：如果不對外分發二進制，也就無需分享更改。在大多數軟件仍然依靠本地分發的年代，這種方式有效地促使了分享。從 2000 年開始，軟件交付開始向公共云遷移，軟件服務提供商不再需要直接向客戶分發任何二進制文件。相反，客戶可以在不獲取本地副本的情況下使用軟件。
隨著云服務的業務規模增長，這種范式轉變激化了部分開源社群和 AWS 等企業之間的緊張關系。云廠商沒有任何法律義務分享他們的改進。有點諷刺的是，這種情況有時被稱為“Google 漏洞”。“Google 漏洞”這一稱謂之所以說諷刺，是因為盡管谷歌依賴 Linux 來支持其搜索服務，但是谷歌和許多其他頂級云廠商（如 IBM 等）為包括 Linux 在內的開源社群做出過重大貢獻。
自由軟件社群對此的回應，是創造了一種名為 Affero GPL (AGPL) 的 GPL 替代形式。AGPL 3.0 與 GPL 3.0 幾乎完全相同，但增加了一個遠程網絡交互條款，該條款規定：“如果你修改了程序，你的修改版本必須明顯地向通過計算機網絡與之遠程交互的所有用戶，提供通過某種標準或習慣的軟件復制方式，無償地從網絡服務器獲得您版本的相應源代碼的支持。”這個新的協議旨在強制云廠商分享它們的源代碼改進，從而再現 GPL 約束 Linux 發行版開放其源代碼的成功。
If you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software….
AGPL 和雙重許可
AGPL 自首次發布以來就備受爭議。
在 GPL 3.0 起草并最終于 2007 年發布的過程中，有一派人想將 GPL 改為與如今的 AGPL 一樣的網絡共享模型。然而，自由軟件社群最終決定保留 GPL 3.0 中的“漏洞”。
幾個月后，自由軟件基金會發布了 AGPL 作為解決該漏洞的替代方案。但是 AGPL 并沒有得到廣泛采用。不過，就像 GPL 有 Linux 這一殺手級應用，AGPL 也有自己的殺手級應用，這就是 MongoDB[5] 數據庫。
MongoDB 是一款非常受歡迎的分布式數據庫產品。雖然一開始，很多企業難以理解和接受 AGPL 協議，但是大多數用戶從未更改過軟件，也沒有將其作為服務提供，因此他們能夠理性地決定在 AGPL 下使用該軟件。
MongoDB 基于 AGPL 協議設計了它的雙重許可[6]商業模型，即軟件可以根據被許可人選擇的兩種協議之一提供：（1）AGPL 協議（2）經過協商取得的商業軟件協議。那些不希望遵守 AGPL 要求，或不愿進行法律分析以確定是否能夠遵守的人，選擇購買商業軟件協議。
這種商業模型最初由 MySQL 開創，MySQL 當時使用了 GPL 的一個變種。隨著時間的推移，AGPL 成為雙重許可模式的首選軟件協議。MongoDB 在這種協議模型下取得了相當的成功。AGPL 是常用軟件協議里最強的強制共享（Copyleft）軟件協議，因此在推動商業談判方面最有用，也就被用在雙重許可模型上。但是，AGPL 的起草者批評了這種使用 AGPL 的方式，稱該商業模型是一種有害的勒索行為[7]。盡管如此，APL 的源碼分享條件并不足以阻止企業在不給開發者或用戶社群帶來任何回報的前提下大規模商用。
Strip-mining
譯注：國外開源語境下的 strip-mining 含義和國內所謂的“白嫖開源”意義類似。
就像云計算的發展打破了基于 GPL 的雙重許可模型一樣，2010 年代云計算的進步，云交付模式開始對基于 AGPL 的雙重許可模型施加壓力。
這次問題有所不同，“漏洞”出現在 GPL 或 AGPL 的范圍僅限于一個單獨的程序可執行文件。這個“漏洞”是有意設計到 GPL 中的，理論上，版權協議只能為一個可受版權保護的作品規定條款。因此，GPL 對衍生作品（derivative works）有源代碼共享的要求，但對集體作品（collective works）沒有。在法律上，這兩者之間的界線非常模糊，完全取決于觀察者的主觀看法。但在過去，隨著 GPL 的普及，強大的行業實踐已經形成：一個程序被定義為一個可執行進程。自由軟件基金會在其 GPL FAQ[8] 中長期闡述了這些原則。
然而，隨著云服務的發展，發生了兩件事：
軟件工程越來越專注于云部署。云廠商曾經需要修改開源軟件以使其能在云環境中正確運行，但軟件工程的進步使現有的開源軟件更加適應云廠商的“即插即用”需求。也就是說，不用修改一行代碼，開源軟件也可以與云基礎設施良好的集成。
云廠商開始在核心開源軟件之外進行創新。他們開發了額外的軟件來管理、監控和部署軟件。這些創新推動了云服務的業務增長。同時，它們是跟核心開源軟件獨立的軟件，即使核心軟件以 AGPL 發布，也無法強制云廠商分享這些輔助軟件的源代碼。
這兩者相結合形成了這樣一種形勢：商業開源公司實際上成為大型云廠商“資產負債表以外的研發機構”。這個問題在開源的平臺軟件或中間件方面尤為突出，因為這些軟件位于頂層應用程序和操作系統之間，在應用程序棧中起著重要作用，且對于云部署非常有用。
這種變化在商業界引起了對云廠商使用開源軟件的強烈抗議。在 2018 年的一份具有里程碑意義的宣言[9]中，貝恩資本的 Salil Deshpande 寫道：“明確地說，這并不違法。但我們認為這是錯誤的，不利于開源社群的可持續發展。”另一位評論家寫道[10]：“AWS 正在攻擊開源的阿喀琉斯之踵：竊取他人的工作，并銷售租賃這些工作成果的服務。”問題在于，所有主要的開源協議都允許以這種方式使用軟件。
商業開源公司及其投資者對開源模型的局限感到不滿，他們手頭沒有任何軟件協議可以利用版權法強制云廠商進行共享。即使是 GPL 和 AGPL 也對此無能為力。
同時，擁有龐大客戶群的云廠商可以為開源軟件提供更好的云平臺集成。在 AWS、Azure 或 Google Cloud 平臺上，客戶可以輕松地一鍵添加軟件。一些開源軟件的開發者提供了自己的云服務，但是發現與免費使用他們開發的開源軟件的大型云廠商競爭太困難了。即使開發者的服務更好，與云廠商建立合作關系也存在交易成本，而不僅僅是云廠商原生集成服務的一鍵集成體驗。
SSPL 和源碼可得協議
在 2018 年，整個行業的發展來到了一個臨界點：隨著 AWS 等云廠商持續不斷地通過托管開源軟件掙錢，開發者們開始采取應對措施，首先就是一系列快速的軟件協議變更。
商業開源公司對 strip-mining 問題[11]做出了兩種不同的反應：一種是超強網絡共享軟件協議，另一種是帶有限制條件的源碼可得協議。在此之前，還沒有人對這兩類協議進行明確定義。這兩類協議都旨在支持雙重許可模型，即引導潛在客戶經過協商購買商業軟件協議，就像幫助構建 MySQL 和 MongoDB 的模式一樣。
超強網絡共享軟件協議的方法由 MongoDB 推進發展，他們在 2018 年發布了 Server Side Public License (SSPL)[12] 協議。SSPL 與 AGPL 幾乎完全相同，但擴展了 AGPL 的遠程網絡條款，如下所述：
Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available. [emphasis added].
譯注：法律文本翻譯極其拗口，這里放原文。主要 SSPL 跟 AGPL 的區別就在于 AGPL 僅對衍生作品提出分享源碼的要求，即前文所述的運行在同一進程的代碼，而 SSPL 定義了 Service Source Code 的概念，即要求整個服務棧相關的代碼都需要以 SSPL 的條款提供。
SSPL 的編寫旨在為 strip-mining 問題提供一個開源解決方案。它的源碼共享要求比 AGPL 更廣泛。這種更廣泛的源碼共享描述被有意設計成類似于 GPL 對分發軟件的要求的形式。MongoDB 繼續采用雙重許可模型，其軟件可根據 SSPL 協議或經過協商的商業軟件協議[13]提供。
MongoDB 將 SSPL 提交給開源促進會[14]（OSI）審議。經過數月的激烈爭議后，SSPL 的 OSI 認證申請被駁回，但 MongoDB 繼續在其雙重許可模型的“開源”選項中使用 SSPL 協議。關于為什么 SSPL 符合或不符合開源定義[15]，討論很復雜。不過，符合開源定義并不是唯一的爭論點，總體而言，這個要求共享范圍如此廣泛的軟件協議是否能夠“保證軟件自由[16]”，尚且沒有一個明確的結論。
其他人選擇了不同的道路。一些公司采用了由 Salil Deshpande 主持編寫的 Commons Clause[17] 條款，而其他公司則自行制定了軟件協議，例如 Redis[18]、Confluent[19] 和 CockroachDB[20] 等，以及 Elastic 公司的 Elastic License 1.0[21] 協議。不同于 SSPL 協議，這些軟件協議從未期望符合開源定義。相反，它們具有專門針對 strip-mining 的限制條款。
為什么選擇了這些不同的道路？這與一個被稱為 Freedom 0[22] 的概念有關。Freedom 0 的內容是：用戶按照自己的意愿運行程序，用于任何目的的自由。
原注：自由軟件定義和開源定義類似，但是更加簡短和清晰。
開源或自由軟件協議的主要特點之一，就是它不包含任何許可限制或限制條件。
原注：開源協議可以包含條件，例如發布時包含 NOTICE 文件或要求共享源代碼，但是這些并不是限制用戶使用軟件的規定。它們只要求如果用戶選擇執行某些操作，那么用戶也必須執行其他操作。（譯注：例如，GPL 允許用戶自由使用，但是如果一個人要分發修改版本的二進制，那么分發者需要保證接收者能夠以和 GPL 相同的條款使用修改版本，其中包括取得修改版本的源代碼。）
相比于典型的商業軟件協議，終端用戶協議只允許用戶使用軟件，但不允許分發或修改；企業軟件協議通常限制軟件使用的用戶數、服務器數或物理位置，并要求公司對其使用進行審計。但是，開源協議不包含任何此類限制。因此，可能有些反直覺，雖然開源軟件源代碼總是免費提供，但是如果一個自稱開源協議限制軟件的非商業使用，那么它也違反了開源定義。
這意味著任何許可限制都使軟件協議不再屬于開源協議。
在 2018 年及以后的重新許可浪潮中發布的所有協議都具有大致相似的限制。雖然每個協議都有自己的條款，但它們都側重于允許用戶免費使用軟件，同時禁止使用軟件提供競爭性的托管服務。
Elastic License 2.0
在2021年初，Elastic 開辟了新的道路，同時選擇了上述兩種路徑。它使用 SSPL 和 Elastic License 2.0[23] (ELv2) 對 ElasticSearch 進行雙重許可。
ELv2 非常簡短。它用通俗的語言編寫，內容總共只有一頁多。ELv2 授予用戶一個典型開源協議授予的幾乎所有自由。軟件的接收者可以自由使用、更改和重新分發軟件。即使您以前從未閱讀過軟件協議，也值得一讀。
ELv2 在上述自由之外有兩個關鍵限制：
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.
第一條限制是為了解決 strip-mining 問題。通過這條限制，ELv2 不授權接受者基于該軟件提供托管服務。
第二條限制禁止破解軟件許可密鑰。這樣的限制在軟件許可中長期存在，但在源碼可得協議中的使用剛剛開始。這些條款允許開發人員運行與軟件交互的付費服務，或者保留一些軟件組件用于付費功能。
ELv2 的其他條款非常直接，對于任何閱讀過開源協議的人來說應該是熟悉的。
為什么選擇雙重許可？
在提供 SSPL 和 ELv2 兩種選擇給用戶時，Elastic 選擇了一條不尋常的道路。如今，許多公司采用“開放核心”模型，事實上，Elastic 之前也使用過這種模型。兩者之間的區別可能很微妙。開放核心模型在開源協議下提供核心軟件：通常使用 Apache License 2.0 這樣的寬松開源協議。然后，這些公司開發額外的適用于大規模企業部署的功能，并只在限制型協議下提供，或者僅作為商業服務提供。但是，通過新的軟件協議，Elastic 堅持采用雙重許可模型，即相同的軟件可在兩種不同的軟件協議下使用。這種模型由 MySQL 首創，通常使用類似 GPL、AGPL 或 SSPL 的強制共享協議作為免費軟件協議選擇。由于開源協議和云服務之間的緊張關系，這種模型在最近幾年變得不太流行。
Elastic 的選擇更加不尋常，因為它提供了兩種免費的軟件協議選擇，SSPL 和 ELv2 都有免費使用的條款，而雙重許可通常只提供一種免費選項。通過做出這個獨特的選擇，Elastic 強調了其靈活性，可以免費向幾乎所有用戶提供軟件。
Elastic License 2.0 和軟件協議的最新發展
Elastic 采用了新的軟件協議模型，以盡可能保持開放性，同時保持對用戶和開發人員公平可持續的商業模式。在這樣做的過程中，它呼應了源代碼可用運動中其他參與者的目標，并在創建軟件協議時尋求同行的意見。
正如 ELv2 FAQ[24] 提到的，Elastic 的軟件協議變更預計不會對其客戶群體產生影響，對社群用戶的影響也很小。因為大多數用戶在 Elastic 的軟件上構建應用程序，并不從事“將軟件作為托管或管理服務提供給第三方”的業務。
設計一個更好的軟件協議
此外，通過投入資源起草 ELv2 協議，Elastic 努力推動軟件協議起草的技術水平。從某種意義上說，源碼可得協議的存在時間與軟件一樣長。事實上，僅二進制的軟件協議是上世紀 80 年代 PC 平臺標準化的產物；在那之前，幾乎所有的軟件都以源代碼格式進行許可。但是隨著時間的推移，軟件協議的形式和部署方式發生了很大變化。
ELv2 是這一趨勢的最終體現。在形式上，它采用了一些最受歡迎的開源協議特性：簡單直觀的起草和模板協議。它的密鑰保留條款使得供應商發布同時包含免費功能和付費功能的軟件事也能輕松地使用 ELv2 協議。
與幾十年前專有 UNIX 的不兼容版本一樣，專有軟件協議是一個由自定義條款和條件組成的混亂合成體。即使是普通消費者軟件產品的簡單終端用戶協議通常也很長，晦澀難懂，大多數用戶無法理解。關于沒人閱讀用戶協議的笑話[25]屢見不鮮。但是，大部分復雜性是不必要的。這是開源協議的一個教訓，特別是寬松開源協議：一套簡單的規則就足夠了，而且規則越易理解，用戶越有可能遵守。
ELv2 不僅簡短、簡單和易理解，而且其他人也可以將其用作模板[26]。自反對 strip-mining 的辯論開始以來，用戶愈發希望出現一個能夠支持流暢部署軟件、可以具有合理限制，但是必須簡單易懂的軟件協議。但是，大多數小型軟件公司沒有資源來起草自己的協議。因此，毫不奇怪，許多軟件初創公司都希望采用 ELv2 或 Confluent Community License 等現成軟件協議來構成其軟件協議模型。
這個趨勢愈演愈烈，最終形成了一個名為 Fair Code[27] 的倡議和標準，其中寫到：
Fair-code is not a software license. It describes a software model where software:
is generally free to use and can be distributed by anybody
has its source code openly available
can be extended by anybody in public and private communities
is commercially restricted by its authors
雖然這項倡議還處于非常早期階段，但顯然行業開始意識到需要一個公平對待用戶和開發者的范式。同時，這一范式還應當允許商業開發者，以一種比如今的開源協議更加靈活的方式，在兩者之間取得平衡。一位評論員甚至將最近的軟件協議發展稱為后開源時代[28]。不過事實上，在商業和軟件協議模型不斷發展的過程中，源碼可得協議與開源協議通常是并行發展的。因此，這兩種模型互補，而不是互為替代品。
同一時間，其他標準化的軟件協議工作也在進行。2020 年，一群律師發起了 PolyForm[29] 項目，起草了一系列源碼可得協議模板。這些軟件協議由在開源和專有協議方面經驗豐富的律師進行同行評審。就像 Creative Commons[30] 用于開放內容協議一樣，它提供了一系列選項，如非商業、僅用于評估和反競爭協議。所有這些軟件協議，就像 ELv2 一樣，都允許免費使用、提供源代碼，并授予必要的專利許可。PolyForm Perimeter 和 PolyForm Shield 與其前身 Confluent Community License 類似，而 ELv2 也遵循了這一趨勢，推進了軟件協議可選項的發展。
如果您有疑問或想要信息，這里有一些資源：
The rise of open source IPOs[31] 這篇文章追蹤了一些商業開源公司的成功案例。
The After Open Source Era Has Started[32] 這篇文章討論了公司轉向源碼可得協議所代表的重大變革。
美國眾議院司法委員會關于數字市場競爭調查的報告[33]（由反壟斷、商業和行政法小組牽頭）請注意第 326 頁提到了 Elastic 的例子。
注：本文的起草代表了我（Heather Meeker）的個人觀點。然而，我想指出，撰寫這篇白皮書的工作部分受到了 Elastic 的資助。
參考資料
[1]
《Open Source for Business》: https://book.douban.com/subject/35309516/
[2]Elastic License 2.0 and the Evolution of Open Source Licensing: https://www.coss.community/cossc/elastic-license-2-0-and-the-evolution-of-open-source-licensing-3jb3
[3]Elastic License 2.0: https://www.elastic.co/licensing/elastic-license
[4]GNU 通用公共協議: https://en.wikipedia.org/wiki/GNU_General_Public_License
[5]MongoDB: https://en.wikipedia.org/wiki/MongoDB
[6]雙重許可: https://monty-says.blogspot.com/2009/08/thoughts-about-dual-licensing-open.html
[7]勒索行為: https://ebb.org/bkuhn/blog/2020/01/06/copyleft-equality.html
[8]GPL FAQ: https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
[9]宣言: https://techcrunch.com/2018/09/07/commons-clause-stops-open-source-abuse/
[10]寫道: https://onezero.medium.com/open-source-betrayed-industry-leaders-accuse-amazon-of-playing-a-rigged-game-with-aws-67177bc748b7
[11]strip-mining 問題: https://techcrunch.com/2018/11/29/the-crusade-against-open-source-abuse/
[12]Server Side Public License (SSPL): https://www.mongodb.com/licensing/server-side-public-license
[13]經過協商的商業軟件協議: https://www.mongodb.com/community/licensing
[14]開源促進會: https://opensource.org/approval
[15]開源定義: https://opensource.org/osd/
[16]保證軟件自由: https://opensource.org/licenses/review-process/
[17]Commons Clause: https://commonsclause.com/
[18]Redis: https://redis.com/legal/licenses/
[19]Confluent: https://www.confluent.io/confluent-community-license/
[20]CockroachDB: https://www.cockroachlabs.com/cockroachdb-community-license/
[21]Elastic License 1.0: https://github.com/elastic/elasticsearch/blob/7.10/licenses/ELASTIC-LICENSE.txt
[22]Freedom 0: https://www.gnu.org/philosophy/free-sw.en.html
[23]Elastic License 2.0: https://www.elastic.co/licensing/elastic-license
[24]ELv2 FAQ: https://www.elastic.co/licensing/elastic-license/faq
[25]沒人閱讀用戶協議的笑話: https://en.wikipedia.org/wiki/HumancentiPad
[26]用作模板: https://www.elastic.co/blog/elastic-license-v2
[27]Fair Code: https://faircode.io/
[28]后開源時代: https://monetize.substack.com/p/open-source-eras
[29]PolyForm: http://www.polyformproject.org/
[30]Creative Commons: https://creativecommons.org/
[31]The rise of open source IPOs: https://coss.media/rise-of-the-open-source-ipo/
[32]The After Open Source Era Has Started: https://monetize.substack.com/p/open-source-eras
[33]美國眾議院司法委員會關于數字市場競爭調查的報告: https://www.documentcloud.org/documents/7222836-Investigation-of-Competition-in-Digital-Markets.html
