自從加入 GitHub 政策團隊以來的最近九個月，我一再被問到開源生態系統近兩年的發展趨勢：單一公司主導的開源項目拋棄由 Open Source Initiative（開放源代碼促進會）認可的開放源代碼許可證，轉而採用「公開源代碼」許可證。隨著基於雲的基礎架構改變了開發人員與其技術棧中依賴項目的交互方式，這種趨勢正在不斷發展。
現狀如何形成？
「單一來源」（single source）開源項目的發展方向和維護由商業公司主導，並由商業公司以此作為其「開源」或「雙許可證」（dual-licensing）模式下的主要收入來源。在「核心開源」（open-core）這一開源生態系統模式中，軟體供應商藉由商業許可證售賣自由和開源軟體（Free and Open Source Software）項目的附加組件或服務（譯者註：例如資料庫軟體 Redis 以 BSD 許可證發布其核心項目，但其另以商業許可證發布包含更多功能的企業版）。在雙許可證模式（譯者註：例如，此前由 Oracle 主導的資料庫軟體 MySQL 以 GNU GPL 許可證發布其社區版本，並另外以專有許可證提供企業版本）中，軟體供應商以FOSS許可證發布軟體且附加某些使得其它企業難以利用的限制——這通常是要求滿足特定義務（譯者註：例如 Copyleft 式許可證強制被授權者以同樣的許可證發布其衍生作品），並另行在商業許可證下提供相同的軟體。這兩種模式都利用開源以實現指數級增長。今天搶到免費且開放的產品的開發者就會是明天的付費客戶（或為後者工作）。
隨著雲的增長，這兩種模式都面臨挑戰。從伺服器機房到數據中心的轉變使雲服務商得以憑藉開源許可證利用基於「核心開源」或「雙許可證」模式的開源項目，這通常是應客戶期望——客戶想從一家公司買到所有服務。這使基於「核心開源」或「雙許可證」模式的業務面臨風險：雲服務商突然與用戶建立了更近關係，從而使這些依賴特定開源生態模式的軟體供應商更難與其潛在客戶建立銷售關係。
為了應對這種壓力，許多依賴「核心開源」或「雙許可證」業務的公司，包括 Confluent、MongoDB、Cockroach Labs、Redis Labs、Timescale 和 Graylog，從 OSI 批准的開源許可證離開，轉而採用不「開放」源代碼的許可證。這些新的「源代碼公開」（而非「開放」）許可證包含進一步限制，以防止雲基礎架構提供商利用其代碼構建服務（而不付費）。諸如 Commons Clause 許可證之類的初期嘗試廣泛地限制了「商業用途」，並且用戶發現許可證中的文字「造成了一些混亂和不確定性。」 Elastic 等公司最近的努力則更直接（more surgical）。他們簡單地試圖限制用戶單獨將軟體作為服務。這些新許可證的目標是繼續利用該軟體及其源代碼的廣泛可用性（譯者註：即公開而不開放）來獲得未來的客戶，同時遏制利用公開代碼的盈利的 SaaS （軟體即服務，Software as a Service）服務競爭者。
這對開發人員意味著什麼？
那麼，開發人員該怎樣選擇技術棧？了解項目所有權狀況和貢獻者群體的多樣性很重要。由非營利組織管理、商標所有權中立且主要貢獻者有多方的開源項目不太可能面臨更改許可證的壓力。由營利性公司主導的作為其主要收入來源的開源項目則可能走向與此不同的方向。任何營利性公司都需要營利。如果你依賴此類項目，那你就可能會面臨以營利為目的的公司出於保護其業務的目的而更改項目許可證的可能性。
在 Twitter 關注 GitHub 政策以獲取有關影響開發人員的法律和規定的消息。
本文是一篇譯文，原文是 GitHub 博客中的「What』s up with these new not-open source licenses? 」，原文作者是 GitHub 政策團隊的 Justin Colannino。標題或正文的部分細節內容可能因不便直接直譯而略有改動。若有疏失，煩請通過後文所註明的郵箱告知。
封面圖片轉載自 Unplash，攝影者是 Richard Balog。
