開源許可證風險地圖：從 MIT 到 AGPL，企業該怕什麼、不該怕什麼

開源許可證有兩千多種，但企業法務和工程團隊真正需要建立直覺的，只有一張按「傳染性」分層的地圖。怕錯了對象，要麼錯殺效率（禁用一切 GPL），要麼放過風險（把 AGPL 組件塞進 SaaS）。

第一層：寬鬆型——放心用，但別忘了署名

MIT、BSD、Apache-2.0 屬於寬鬆型（Permissive）許可證，允許商用、修改、閉源分發，義務基本只有保留版權聲明與許可證文本。Apache-2.0 額外帶專利授權條款，對企業反而是保護。這一層的真實風險不是許可證本身，而是執行細節：產品裏連一份 NOTICE 文件都沒有的「零署名」交付，在客户盡調時同樣會被記為合規缺陷。我們在審計中最常見的問題，恰恰是有團隊把寬鬆型代碼的版權頭也剝掉當自研——這在片段級檢測面前無所遁形，詳見我們的 SCA 選型指南。

第二層：弱傳染——動了它才傳染你

LGPL、MPL-2.0、EPL 屬於弱 Copyleft：以「文件」或「庫」為邊界，你修改了它的文件必須開源該部分，但你自己的代碼只要保持邊界清晰就不受影響。工程上的關鍵是鏈接與隔離方式——LGPL 組件用動態鏈接通常安全，靜態鏈接則可能把整個產品拖入開源義務。嵌入式與 C/C++ 項目是重災區，因為靜態鏈接是常態。

第三層：強傳染——分發即觸發

GPL-2.0/3.0 的規則簡單而嚴厲：只要你分發了包含 GPL 代碼的軟件，整個衍生作品必須以 GPL 開源。對外交付的商業軟件、預裝設備固件、客户端程序都構成分發。但注意兩個常被誤解的邊界：一是純內部使用不構成分發，服務器上自用 GPL 軟件沒有開源義務；二是 GPL 的「衍生作品」邊界在法律上仍有灰區，獨立進程通信通常不傳染，深度鏈接則風險高。

第四層：網絡傳染與商業限制——SaaS 時代的新雷區

AGPL-3.0 把觸發條件從「分發」擴展到「網絡提供服務」——用户通過網絡使用你的 SaaS，你就要開源。這正是各大雲廠商把 AGPL 列入禁用清單的原因。更新的一批「源可用」（source-available）許可證走得更遠：SSPL（MongoDB）、BSL（HashiCorp 曾用）、Elastic License 直接限制「提供競爭性託管服務」，它們已不是 OSI 認證的開源許可證，但大量團隊仍把這些組件當普通開源引入。近年多個明星項目的許可證切換證明：許可證不是靜態屬性，版本升級可能改變一切，鎖定版本時必須同時鎖定許可證版本。

三步落地的治理方法

第一步：摸清家底。用 CleanSource SCA 對代碼庫做全量掃描，重點不是依賴清單裏聲明的，而是複製粘貼與改名引用進來的——許可證風險最高的代碼，往往正是清單上看不到的那部分。輕量起步可以用免費的 社區版。

第二步：按分發模式定策略。同一個組件，在內部工具、對外交付、SaaS 三種形態下的風險完全不同。策略應寫成矩陣（許可證類型 × 分發模式 × 允許/評審/禁止），並配置進掃描工具作為準入門禁，而不是留在法務的 Word 文檔裏。

第三步：把義務履行工程化。自動生成隨版本更新的開源聲明文件（NOTICE/attribution），把許可證信息寫進 SBOM 一併交付。客户驗收和出海認證時，這份文件的存在與否，直接決定合規檢查是十分鐘還是十天。

許可證合規的目標從來不是「消滅 GPL」，而是讓每一次引入都是知情決策。地圖畫清楚了，路怎麼走是業務的自由。