開源授權合規

本頁內容僅為一般資訊，並非法律意見。若要針對特定產品做出決策，請諮詢律師。

開源授權的類型

類型	範例	通常的要求
寬鬆型授權	MIT, BSD, Apache-2.0	保留著作權與授權聲明。Apache-2.0 另有專利條款。
弱 copyleft	LGPL, MPL-2.0	公開對該授權元件本身所做的修改
強 copyleft	GPL-2.0, GPL-3.0	與其一同散布的軟體必須以相同條款提供，並附上原始碼
網路 copyleft	AGPL-3.0	與強 copyleft 相同，且在使用者透過網路與軟體互動時同樣適用
原始碼可見型（Source-available）	BUSL, SSPL	不屬於開源：原始碼可以查看，但使用受到限制

什麼是 copyleft 授權？

Copyleft 授權允許您使用、修改及分享軟體，條件是您所散布的內容必須維持相同的授權條款。它讓開源保持開放。對商業產品而言， 風險在於：若將強 copyleft 元件連結到您的程式碼中，就可能衍生出您自己的程式碼是否也必須公開的問題。

是否適用，取決於該元件的使用方式與產品的交付方式。散布給客戶的軟體，比內部工具承受更高的風險；SaaS 產品通常可避開 GPL 的散布條款，但無法避開 AGPL 的條款。

常見的合規風險

• 遞移授權。寬鬆授權的套件可能相依於 copyleft 套件。只檢查 直接相依套件就會漏掉這種情況。
• 缺少聲明。大多數授權都要求保留出處標示，而忘記附上聲明檔案是最常見的疏失。
• 授權變更。專案可能在新版本中更換授權，因此一次升級就可能改變您須遵守的條款。
• 宣告授權與實際授權。套件的中繼資料可能有誤或不完整，而內嵌（vendored）的程式碼也可能帶有自己的授權。
• 盡職調查。收購方與大型客戶會要求提供授權清冊，而且通常期限很短。

如何維持合規

1. 制定政策。依產品類型，決定哪些授權允許使用、哪些需要審查、哪些禁止使用。
2. 建立資產清冊。SBOM 會列出每個元件及其授權，包括遞移相依套件。
3. 自動檢查。在 CI 中強制執行政策，讓新的相依套件在加入的當下就失敗，而不是等到稽核時才發現。
4. 履行義務。在授權要求時產生聲明檔案並提供原始碼。
5. 保存紀錄。為每個版本保存資產清冊，因為問題通常出在您已經出貨的版本。

授權合規軟體能做什麼

授權合規是軟體組成分析的標準環節。 這類工具會識別元件、回報其授權，並標示違反您政策的項目。它們的分析深度各有不同：

• 宣告授權：大多數工具會讀取每個套件在中繼資料中宣告的授權。這種方式速度快， 能涵蓋常見情況。
• 深度授權掃描：FOSSA 與 Black Duck 也會分析程式碼中的授權文字，並協助產出出處標示報告與進行法務審查。請參閱 CRACI vs FOSSA 與 CRACI vs Black Duck。
• 免費工具：許多 SBOM 產生工具與 SCA 掃描工具都能免費回報宣告授權。請參閱 最佳 SCA 工具。

CRACI 的定位

CRACI 在建置中處理宣告授權。作為您的 GitHub Actions 執行器，它會記錄作業拉入的每個套件， 而每個套件都帶有其宣告授權，因此 copyleft 授權能在進入產品之前就被發現。授權政策規則可依授權封鎖建置， 而 CycloneDX 與 SPDX 格式的 SBOM 匯出檔也會包含每個元件的宣告授權。CRACI 依據套件所宣告的內容運作， 因此若您需要法務審查流程或授權文字分析，請搭配專業工具一起使用。

開源授權合規：常見問題

什麼是開源授權合規？

指的是掌握您所使用的軟體適用哪些開源授權，並履行其條件，例如保留聲明或公開原始碼。

什麼是 copyleft 授權？

這種授權允許您使用及修改軟體，條件是您所散布的內容必須維持相同的條款。GPL 是最知名的例子。

商業軟體可以使用 GPL 程式碼嗎？

可以，但若您散布包含 GPL 程式碼的軟體，可能就必須以 GPL 提供該軟體的原始碼。程式碼的結合方式會影響結果，請針對您的情況尋求法律意見。

Copyleft 適用於 SaaS 嗎？

GPL 的條款一般是由散布行為觸發，而 SaaS 通常不涉及散布。AGPL 則填補了這個缺口，將條件延伸到透過網路與軟體互動的使用者。

商業使用最安全的開源授權是哪一種？

MIT、BSD 與 Apache-2.0 等寬鬆型授權的要求最少，但您仍須保留其聲明。

如何檢查相依套件的授權？

產生包含遞移相依套件與宣告授權的 SBOM，或使用 SCA 工具。並在 CI 中強制執行您的政策，讓新的違規直接導致建置失敗。