開源許可證衝突檢測實操：五種典型衝突與工程化處置

讀懂單個許可證不難，難的是組合：一個現代應用動輒數千個組件、幾十種許可證，兩兩之間的兼容關係構成一張複雜的矩陣，任何一處衝突都可能讓整個產品的分發合法性出問題。這篇講工程團隊實際會遇到的五種衝突形態，以及怎麼用工具把檢測和處置流程化——這是律所研究文章不會寫、但交付驗收時真正被檢查的部分。

五種典型衝突形態

一：強傳染許可證混入專有產品。最經典也最嚴重：GPL 代碼進入閉源交付物。入口往往不是顯式依賴，而是複製的工具函數、fork 後改名的模塊、外包團隊"借用"的實現——依賴清單乾乾淨淨，衝突藏在文件級。我們的許可證風險地圖詳細講過各層級的傳染邏輯。

二：開源許可證之間互不兼容。最著名的組合是 Apache-2.0 與 GPLv2：Apache-2.0 的專利條款與 GPLv2 的要求衝突，兩者的代碼不能合併進同一個衍生作品（GPLv3 解決了這個問題）。同理還有 CDDL 與 GPL（當年 ZFS 不能進 Linux 內核主線的原因）。單看每個許可證都"沒問題"，合在一起就是問題。

三：聲明與實際不符。組件包管理器元數據聲明 MIT，包體內卻混着 GPL 文件——上游作者自己拷了別人的代碼。清單級工具信任聲明，這類衝突只有對文件與片段實際比對才能發現。這不是罕見情形：多語言大型項目裏，聲明與實際的偏差率足以讓純清單審計的結論失去意義。

四：雙許可證組件未做選擇記錄。MySQL 客户端庫、Qt 這類雙許可證（GPL/商業）組件，用了哪個許可證分發需要明確的決策與記錄。沒有記錄，審計時默認按最嚴格的那個算——而那往往是 GPL。

五：弱傳染許可證的邊界破壞。LGPL 組件本可安全使用，但靜態鏈接、直接修改源碼後未開源、或者把它的代碼抽出來內聯進自己的模塊，都會擊穿"庫邊界"，讓弱傳染升級為實際義務。

工程化檢測：三層遞進

第一層，清單解析：讀依賴聲明，快速建立組件與聲明許可證的基線——免費的 CleanSource SCA 社區版即可完成。第二層，文件與片段級驗證：對源碼做許可證文本識別、版權頭解析與代碼指紋比對，發現"聲明之外"的真實成分，核對聲明與實際是否一致——這需要片段級檢測能力。第三層，衝突判定：基於許可證兼容矩陣與你的分發模式（對外交付/SaaS/內部使用）自動計算衝突項，按嚴重度分級輸出。

關鍵配置是把分發模式作為判定輸入。同一個 AGPL 組件，內部工具裏是低風險，SaaS 裏是高危——脱離分發模式談衝突都是誤報或漏報。

四級處置動作

檢出衝突後按成本從低到高走：替換（同功能的寬鬆許可證替代品，工具通常能直接推薦候選）；隔離（進程級分離、動態鏈接、網絡接口調用，把傳染邊界擋在產品之外——需要架構評審確認隔離有效）；履約（按許可證要求開源相應部分、附帶聲明文件——有時開源一個非核心模塊的成本遠低於替換）；商業授權（雙許可證組件購買商業許可，或與版權方協商）。

每個處置決策都應記錄進台賬：哪個組件、什麼衝突、選了哪種處置、誰批准的——這份記錄在客户盡調和出海認證時就是你的證據鏈。

最後一條經驗

許可證衝突治理最貴的時點是交付前兩週才開始。把三層檢測配置進 CI，讓衝突在引入當天就被攔截，處置成本是交付前突擊的十分之一。合規不是一場審計,而是一道常開的門禁。