GitHub 如何維持開源相依套件的合規性
了解開源專案辦公室（Open Source Program Office，OSPO）如何使用 GitHub 新的授權合規產品，大規模管理開源相依套件。
每天，GitHub 工程師都會把新的相依套件導入 GitHub 平台、內部應用程式與開源專案。GitHub 不只是開源的家，也是由開源驅動的！而負責任地使用開源，很重要的一部分就是尊重你所依賴專案的授權條款。
在 GitHub，我們致力於履行對開源社群以及我們所使用相依套件的義務。以下說明我們的開源專案辦公室（OSPO）如何使用新的 GitHub License Compliance（授權合規）功能，管理數以千計的相依套件。
管理開源授權合規流程
幾乎所有軟體都帶有某種授權協議。只要你遵守其中的義務，授權就會允許你使用該專案。這些義務可能簡單到只要在文件中標註原作者，也可能要求你在發布程式時一併散布所有原始碼。在某些情況下，授權也可能限制特定活動或使用類別。
你的組織很可能會依據商業模式、軟體生態系與散布策略，制定自己對可接受授權的政策。舉例來說，假設你的組織銷售的是商業、閉源的二進位應用程式，你可能會想避免引入會要求你開源專有程式碼的相依套件。
或者，你可能有一個計畫以開源套件形式發布的專案。在這種情況下，你可能會想避免納入受商業授權或不相容開源授權約束的相依套件。
如果在上述任一情境中，你都無法遵守相關義務，就應避免使用該相依套件，以防範法律或營運風險。事後移除這些授權可能需要投入工程資源。對企業軟體而言，不合規帶來的商業風險非常高，因為它可能導致代價高昂的訴訟與聲譽損害。
傳統上，授權審查多半是人工進行，或透過第三方軟體完成。但現在，GitHub 已為 GitHub Advanced Security 客戶推出授權合規功能，讓你可以直接在 pull request 上審查新的依賴項。這項審查有助於確認這些依賴項的授權是否符合你的政策，同時也保留彈性，讓你可以擴充政策，允許新的授權條款或個別專案。
兩個月前，GitHub 的 OSPO（開源計畫辦公室）從我們過去為管理合規而自行打造的內部工具，遷移到這項新功能。作為早期採用者，我們快速向開發團隊提供回饋，並協助確保這項功能能達到大型、快速運作且有複雜合規需求企業的標準。
為政策順利推行做好設定
由於 GitHub 在推出這項產品之前，就已經打造過內部授權合規工具，我們手上已有一份可接受授權條款清單，可以作為初始政策使用。你很可能會發現，許多依賴項都使用常見的寬鬆授權條款，例如 MIT、Apache 2.0 和 BSD-3-Clause，這些都很適合作為建立政策的起始清單。我們一開始是在組織層級的規則集上使用「Evaluate」模式推出這項功能；這會在 pull request 中產生註記，但不會阻擋合併，因此我們能讓開發者習慣新的工作流程，同時不影響他們的生產力。讓新舊工具並行，也讓我們能觀察兩者的行為是否有所差異。在這種模式運作約一個月後，我們逐漸進入一個狀態：警示主要集中在授權條款不常見、缺失，或明確不被允許的套件上。
GitHub 授權合規如何運作
從底層來看，授權合規檢查是透過規則集啟用的。我們透過自訂屬性指定儲存庫，並由該屬性的值決定授權檢查要以「Active」或「Evaluate」模式啟用。在被規則集涵蓋的儲存庫中，只要 pull request 修改了專案的依賴項，就會觸發掃描，查詢每個新增依賴項所使用的授權條款。如果新增依賴項的授權已被允許，或存在特定套件的例外設定，檢查就會通過。如果直接依賴或傳遞依賴中出現失敗項目，工具就會在 pull request 上留言，針對每個有問題的套件提出警示。
接著，開發者會檢視這些警示。如果他們判斷該依賴套件不可接受，可以更新自己的程式碼，或關閉 pull request 來移除它。如果他們認為該授權條款或套件應該被允許使用，可以提出例外申請；這會通知組織中的特定團隊，由該團隊決定是否以及如何修訂政策。
授權政策團隊的一天
GitHub 的授權政策團隊由 OSPO 成員，以及具備授權審查與供應鏈分析專業的工程師組成。由於我們是一家全球公司，政策審查團隊的成員分布在不同時區，能夠及時審查警示。我們正在正式制定審查授權申請的 SLA，但實務上，收到申請後通常很少超過幾個小時就能完成初步分流。
團隊成員會收到新審查申請的電子郵件通知，也可以進入儀表板查看待處理申請的清單。
核准申請時，我們有兩個決策點：第一，是要允許該授權條款，還是該套件。接著，決定要使用哪個範圍：企業層級或儲存庫層級。如果這是一個安全、只是過去未曾出現過的授權條款，我們會把它加到企業層級，因此讓 GitHub 任何地方都可以使用帶有該授權條款的依賴套件。有些套件採用商業授權，不能在所有地方都允許使用，但如果某個團隊已為該軟體付費，就應該允許在該團隊擁有的儲存庫中使用，因此這類政策修訂會加到儲存庫層級。套件例外對內部軟體很有用，因為這類軟體通常沒有相關的授權資料。很方便的是，這項工具支援套件例外的萬用字元比對。舉例來說，我們已允許 @github-ui/* React 命名空間中的所有內容，因此不需要逐一核准那些套件。
讓開發者更容易使用
為了支援這個流程，我們建立了聯繫 GitHub OSPO 的程序，以及如何使用緊急「break glass」覆寫機制。這類情況應該很少發生，但對於時間極度緊迫的 pull request 來說，明確的緊急覆寫流程非常重要。如前所述，授權政策的執行是透過 ruleset 進行，而 ruleset 的條件會依據一個自訂屬性判斷。因此，如果有某個關鍵修正被授權警示擋住，只要切換該屬性的值，就能暫時關閉執行機制。到目前為止，我們只需要使用過一次，但能有這個選項非常有幫助。
我們也提供了內部文件與訓練，協助開發者理解授權合規的重要性。說到底，協助確保合規並管理風險是每個人的責任，而我們的工作就是盡可能讓這件事變得容易。
總結
授權合規是管理軟體供應鏈的重要一環。透過協助開發者依照 GitHub 的授權政策，對依賴套件做出知情選擇，我們可以避免代價高昂的重寫，以及潛在的法律問題。過去幾個月，我們一直積極使用新的 GitHub License Compliance 功能，並提供回饋。現在它已進入公開預覽，我們很期待看到更多公司採用，也希望如果你才剛開始，我們的經驗能提供一些指引。
GitHub Enterprise Cloud 客戶可以在具備有效 GHAS Code Security 授權的儲存庫中使用 License Compliance 功能。更多資訊請見關於開源授權合規。
標籤
作者
Jeff Luszcz
Jeff 協助營運 GitHub 的開放原始碼專案辦公室（Open Source Programs Office），專注於開放原始碼授權遵循與軟體供應鏈完整性。加入 GitHub 之前，他曾任 PEAK6 開放原始碼總監，也是 Palamida 的創辦人兼技術長；Palamida 是最早期的軟體組成分析公司之一。自 2004 年以來，Jeff 已協助數百個軟體組織有效運用開放原始碼，同時履行授權義務。
Eric Sorenson
Eric 是 GitHub 的產品經理，專注於供應鏈安全。他已經投入大規模開放原始碼工作二十多年，最早是從 SRE 做起，近期則擔任 PM。如果你想來一場刺激的對話，可以問他關於軟體物料清單（Software Bill of Materials）的資料格式、SPDX 授權條款表示式，或傳遞套件相依性！在科技圈之外，Eric 會替重金屬演唱會做現場音響和燈光，也喜歡騎著礫石車去弄得滿身泥巴。
目錄
更多關於 開放原始碼 的內容
每位 GitHub 維護者本週都應啟用的 6 項安全性設定
這六項免費設定不會讓你的專案變得完全無法被駭。沒有任何設定做得到。它們能做的，是關上那些容易被利用的入口。啟用這些設定後，你的專案會比以前更難被攻擊，而且是有實質差異的那種難度提升。
GitHub 與 UNDP 合作，以開放原始碼推進迦納的發展優先事項
GitHub 與聯合國開發計畫署（UNDP）在迦納合作，探索開放原始碼治理如何支持西非最具企圖心的數位改革之一。
每位 GitHub 維護者本週都應啟用的 6 項安全性設定
這六項免費設定不會讓你的專案變得完全無法被駭。沒有任何設定做得到。它們能做的，是關上那些容易被利用的入口。啟用這些設定後，你的專案會比以前更難被攻擊，而且是有實質差異的那種難度提升。
Git 2.55 重點更新
開放原始碼 Git 專案剛發布了 Git 2.55。以下是 GitHub 整理的幾項自上次以來最有意思的新功能與變更。
GitHub 與 UNDP 合作，以開放原始碼推進迦納的發展優先事項
GitHub 與聯合國開發計畫署（UNDP）在迦納合作，探索開放原始碼治理如何支持西非最具企圖心的數位改革之一。
探索更多 GitHub 資源
文件
掌握 GitHub 所需的一切，都在這裡。
GitHub
在 GitHub 打造下一個未來，這裡讓來自任何地方的人都能建構任何事物。
客戶案例
認識使用 GitHub 建構產品的公司與工程團隊。
GitHub Universe 2026
10 月 28 至 29 日，歡迎到舊金山或線上參加 GitHub Universe，這是我們的旗艦開發者活動，串連人們、agents，以及全世界的程式碼。