檢查授權影響和評級

  • 9 分鐘

了解授權條款只是第一步——組織必須評估授權如何影響其特定的商業模式、開發實踐和產品分銷策略。 授權影響決定了開放原始碼元件是否適合特定使用案例，以及組織必須履行哪些義務。

商業軟體的授權影響

不同的授權類型對商業軟體開發的影響截然不同：

寬鬆授權的影響結果

使用寬鬆授權元件的軟體（MIT、Apache 2.0、BSD）：

最小限制：

  • 專有發行： 可以將組件合併到專有軟件中，而無需開源您的代碼。
  • 商業產品： 可以構建和銷售包含許可組件的商業產品。
  • 封閉式分發： 無需向客戶提供源代碼。
  • 再授權： 通常可以根據您自己的授權條款進行分發。

主要義務：

  • 歸屬： 必須保留版權聲明和授權文字，通常透過在文件、關於對話框或授權彙總檔案中包含通知來滿足。

專利考慮因素：

  • 麻省理工學院和 BSD： 不要包括明確的專利授權，從而對專利權造成潛在的模糊性。
  • 阿帕奇2.0： 包括明確的專利授權，為專利訴訟提供更明確的保護和防禦性終止。

業務影響：

  • 安全的選擇： 寬鬆授權對商業產品的風險最小。
  • 簡單的合規性： 歸因要求很容易滿足。
  • 最大的靈活性： 啟用任何商業模式，包括專有軟體銷售。

弱式 Copyleft 授權影響

使用弱 Copyleft 元件 (LGPL, MPL) 的軟體：

允許使用圖書館：

  • 專有應用： 可以在專有應用程式中使用弱版權函式庫。
  • 允許連結： 可以將專屬程式碼與弱版權函式庫連結（尤其是透過動態連結）。
  • 沒有完整的自由版權： 使用程式庫不會引發要求將整個應用程式開放原始碼。

修改要求：

  • 程式庫修改必須共用： 如果您修改了弱版權組件本身，則這些修改必須開放源碼。
  • 檔案層級追蹤 （MPL）： 對於 MPL，要求適用於文件級別，使邊界更加清晰。
  • 衍生作品： 創建庫的衍生作品會觸發開源需求。

合規性考慮：

  • 原始碼提供： 必須提供弱開放版權庫的原始碼（包括任何修改）。
  • 許可證保存： 必須維護程式庫的授權條款。
  • 明確分離： 保持庫代碼和專有代碼之間的明確界限。

業務影響：

  • 一般可接受：大多數企業可以在專屬產品中使用弱 Copyleft 庫。
  • 修改負擔： 修改程式庫會產生持續的合規義務。
  • 靜態連結問題： 靜態連結可能會產生更嚴格的要求;偏好動態連結。

強式 Copyleft 授權影響

使用強式 Copyleft 元件 (GPL、AGPL) 的軟體：

Copyleft 傳播：

  • 衍生作品： 創建衍生作品或將代碼與 GPL 軟件結合會觸發 Copyleft 要求。
  • 整個應用： GPL 通常適用於整個應用程序，而不僅僅是 GPL 的組件。
  • 原始碼要求： 分發二進位檔時必須提供完整的原始碼。
  • 相同的許可證： 衍生作品必須根據 GPL 分發。

分發觸發器：

  • 二進位分佈： 分發可執行二進位文件需要提供原始程式碼。
  • 網路使用（AGPL）： 對於 AGPL 來說，僅僅通過網絡提供軟件就會觸發要求。
  • 內部使用： 在內部使用 GPL 軟體而不分發不會觸發要求。

連結問題：

  • 靜態連結： 明確創建需要 GPL 合規性的衍生作品。
  • 動態連結： 法律解釋各不相同——有些人認為它是安全的，有些人則認為它會產生衍生作品。
  • 工藝分離： 將 GPL 軟件作為單獨的進程（微服務）運行可能會避免衍生工作狀態。

業務影響：

  • 與專有軟體不相容： 無法將 GPL 元件合併到您分發的專有軟體中。
  • 開源產品： 可以將 GPL 用於您願意開源的產品。
  • SaaS 例外狀況： GPL v2 和 v3 不需要 SaaS 產品的來源揭露 （AGPL 需要）。
  • 高風險： GPL 對商業專有軟體構成了重大風險。

授權風險評等

組織通常根據授權對商業軟體開發構成的風險來評估授權：

風險評級框架

低風險（綠色）：

  • 授權： MIT、BSD、Apache 2.0、ISC、其他寬鬆授權。
  • 特徵： 最小限制，主要是歸屬要求。
  • 應用案例： 可安全用於任何商業用途，包括專有軟體。
  • 合規負擔： 低—主要維護署名通知。

中等風險（黃色）：

  • 授權： LGPL、MPL、EPL、其他弱份轉授權許可證。
  • 特徵： 允許在專有軟體中使用，但對修改有限制。
  • 應用案例： 可以使用未修改的函式庫;修改時需要小心。
  • 合規負擔： 中等 — 必須追蹤資料庫來源並根據要求提供。

高風險（紅色）：

  • 授權： GPL v2、GPL v3、AGPL 等強 Copyleft 授權。
  • 特徵： 需要開源衍生作品和組合應用程式。
  • 應用案例： 與專有軟件分發不兼容;對於開源專案來說是可以接受的。
  • 合規負擔： 高 - 必須為整個應用程式提供完整的原始程式碼。

未知風險（橙色）：

  • 授權： 自訂授權、授權不明確、授權資訊遺失、授權過時。
  • 特徵： 條款不明確，相容性不確定，需要法律審查。
  • 應用案例： 避免使用，直到法律審查程序澄清相關條款和影響。
  • 合規負擔： 在澄清授權條款之前未知。

影響風險評估的因素

商業模式：

  • 開源產品： GPL 是可接受的風險。
  • 專有軟體： GPL 是不可接受的風險。
  • SaaS 產品： GPL v2/v3 可接受，AGPL 不可接受。
  • 內部工具： 所有許可證通常都是可以接受的，因為沒有分發。

分發方式：

  • 二進位分佈： 觸發 GPL 要求。
  • SaaS部署： 觸發 AGPL 需求。
  • 僅限內部使用： 不會觸發大多數需求。
  • 圖書館提供： 觸發 LGPL/MPL 要求。

修改範圍：

  • 未修改的組件： 降低合規負擔。
  • 修改組件：會增加義務，特別是與 Copyleft 相關。
  • 深度整合： 使合規性更加複雜。

法律環境：

  • 管轄區差異： 授權解譯會因國家/地區而異。
  • 執行歷史： 有些許可證具有更強的執行先例。
  • 專利考慮因素： 專利條款與組織專利策略相互作用。

智慧財產權考量

授權選擇會影響組織智慧財產權：

專有知識產權保護

寬鬆授權：

  • IP 保留： 您的專有程式碼仍然是專有的。
  • 受保護的商業秘密： 無需披露實施細節。
  • 保持競爭優勢： 不必與競爭對手分享創新。

強式 Copyleft 授權：

  • 需要披露知識產權 ：GPL 需要開源衍生作品，可能會暴露專有演算法、業務邏輯和創新。
  • 商業機密遺失： 原始碼揭露消除了商業秘密保護。
  • 競爭優勢降低： 競爭對手可以使用您的創新。

專利考慮因素

專利授權：

  • 阿帕奇2.0： 包括明確的專利授予，提供明確的權利和防禦性終止。
  • GPL v3： 包括專利授權和反Tivo化條款。
  • 麻省理工學院/BSD： 沒有明確的專利條款，造成潛在的歧義。

專利防禦終止：

  • Apache 2.0 和 GPL v3： 如果被許可人起訴貢獻者侵犯專利，則專利授權終止。
  • 戰略意義： 具有激進專利策略的組織可能會面臨複雜情況。

專利池：

  • 某些許可證與專利池集成： 授權可能會與產業專利合約互動。

合規實施

成功實施開源軟體需要系統的合規流程：

依賴關係盤點

全面追蹤：

  • 物料清單： 維護所有開源元件的完整庫存。
  • 可傳遞相依性： 不僅追蹤直接相依性，還追蹤相依性之間的相依性。
  • 版本追蹤： 記錄特定版本，因為授權有時會在版本之間變更。
  • 更新監控： 持續監控相依性及其授權的更新。

自動化工具：

  • 套件管理器： npm、pip、Maven 自動追蹤直接依賴關係。
  • SBOM 工具： 軟體物料清單工具會產生全面的相依性清單。
  • 許可證掃描儀： FOSSA、WhiteSource、Black Duck 等工具可識別跨相依性樹的授權。

授權相容性驗證

相容性檢查：

  • 自動掃描： 工具會自動識別授權不相容。
  • 法律審查： 複雜的案件需要法律專業知識來評估相容性。
  • 審批工作流程： 建立在使用前檢閱新相依性的程式。

常見的不相容：

  • GPL + Apache 2.0 （GPL v2）： 不相容——無法組合。
  • GPL + 專有： 與分散式軟體不相容。
  • 多個 Copyleft 許可證： 一般互不相容。

歸因合規性

滿足歸因要求：

  • 授權彙總： 將所有許可證文本收集在單個文件中（通常是 LICENSES.txt 或THIRD_PARTY_NOTICES）。
  • 關於對話方塊： 在應用程式的「關於對話方塊」或「設定」中包含歸因。
  • 文檔： 在產品文件中包含授權資訊。
  • 自動生成： 使用工具從相依性資料自動產生歸因檔案。

原始碼提供

Copyleft 授權：

  • 來源存取： 為 GPL 的元件和衍生作品提供完整的原始程式碼。
  • 相同介質： 歷史上要求在與二進位文件相同的介質上提供源代碼;現在可以接受互聯網下載。
  • 書面供應項目：可以提供原始程式碼，而不是將其捆綁。
  • 編譯說明： 包含建置指示，讓使用者可以從原始碼重建。

軟體供應鏈安全

授權合規性和安全性是相互關聯的問題：

弱點管理

安全性等於最弱的元件：

  • 鏈依賴性： 應用程式安全性取決於相依性樹狀結構中的每個元件。
  • 漏洞傳播： 任何相依性中的弱點都會影響使用它的所有應用程式。
  • 更新緊急性： 安全漏洞需要對所有受影響的應用程式進行快速更新。

漏洞掃描：

  • 自動偵測： Snyk、Dependabot、WhiteSource 等工具會掃描相依性以尋找已知弱點。
  • CVE監控： 追蹤相依性的常見弱點和暴露識別碼。
  • CVSS 評分： 使用通用漏洞評分系統來確定補救的優先順序。
  • 快速反應： 建立流程，以便在揭露嚴重漏洞時快速更新相依性。

供應鏈攻擊

風險緩解：

  • 套件驗證： 驗證套件簽章和檢查碼。
  • 來源口碑： 更喜歡具有主動維護、龐大用戶群和信譽良好的維護者的軟體包。
  • 私人註冊機構：鏡像私人登錄中的公用套件，以控制開發人員使用的內容。
  • 相依性釘選：鎖定特定版本以防止自動更新至遭入侵的版本。

組件質量評估

質量指標：

  • 主動維護： 定期更新表示維護項目。
  • 社區規模： 大型社區提供更好的可持續性。
  • 文件品質： 良好的文件建議專業維護。
  • 測試覆蓋率： 自動化測試表明注重質量。
  • 安全實踐： 負責任的揭露流程和安全建議展示了安全承諾。

組織政策

有效的開源管理需要明確的組織策略：

核准工作流程

使用前評估：

  • 安全審查： 在核准之前掃描已知漏洞。
  • 授權審查： 驗證授權與預期用途的相容性。
  • 品質評估： 評估程式碼品質、維護狀態和社群健康。
  • 替代分析： 考慮是否存在經批准的替代方案。

批准的包裹清單：

  • 預先審查的組件： 維護已核准的套件清單，以滿足常見需求。
  • 更快的採用： 開發人員可以立即使用已核准的套件。
  • 定期重新評估： 定期審查已核准的套件的安全性和維護狀態。

開發人員教育

培訓計劃：

  • 授權意識： 教育開發人員有關許可證類型和影響。
  • 安全實踐： 評估元件安全性的訓練。
  • 合規流程： 說明如何要求核准新相依性。
  • 風險意識： 協助開發人員瞭解組織問題。

持續監控

持續遵循標準：

  • 相依性更新： 監控新版本和安全補丁。
  • 授權變更： 追蹤專案何時變更授權。
  • 漏洞揭露： 訂閱相依組件的安全公告。
  • 合規審計： 定期審核應用程式的授權合規性。

了解許可證影響並實施系統合規流程使組織能夠利用開源優勢，同時有效管理風險。 下一個單元提供本單元所涵蓋的關鍵概念摘要。