Java 開發者必懂的 7 大開源授權條款：BSD、Apache、GPL、LGPL、MPL、Public Domain、Artistic

前言：授權合規是工程師的基本功

引入第三方庫時，若不理解授權條款，可能面臨法律風險 (侵權訴訟)、強制開源專有代碼、無法商業化分發等後果。本文梳理 7 大主流開源授權核心權利/義務/限制，並給出選型決策建議。

授權條款對比總覽

核心概念解析

1. Copyleft (傳染性/互惠性)

• 強：GPL/AGPL — 任何**衍生作品** (鏈接、繼承、修改、包含) 必須以相同授權開源。**商業閉源專案嚴禁直接依賴**。
• 弱 (檔案級)：MPL — 僅修改的**原始檔案**需開源，新檔案、鏈接的主程式可保持專有。
• 弱 (庫級)：LGPL — **動態鏈接**不傳染主程式授權；**靜態鏈接/修改庫代碼**則觸發。需提供重新鏈接機制 (物件檔/共享庫)。

2. 專利授予

Apache 2.0、MPL 2.0、GPLv3、LGPLv3 明確包含**專利授予條款**：貢獻者授予使用者永久、免費、不可撤銷的專利許可。若使用者對軟體提起專利訴訟，授權自動終止。BSD/MIT 僅隱含專利許可，法律效力較弱。

3. 網路服務漏洞 (AGPL 修補)

GPLv2/3 僅在「分發」 (傳輸副本) 時觸發開源義務。**SaaS/雲服務**僅透過網路互動，不構成分發，可合法使用 GPL 代碼而不開源。AGPL 3.0 明確規定：透過網路提供服務互動視為分發，**強制開源服務端代碼**。

企業級選型決策樹

1. 產品為專有商業軟體 (閉源)：
   • 優先選 **Apache 2.0 / MIT / BSD** 依賴。
   • **LGPL** 僅限**動態鏈接**，且需提供替換機制 (如 Docker 映像可替換 .so)。
   • **MPL** 可用，但修改原庫檔案需開源該檔案。
   • **嚴禁** 直接依賴 **GPL/AGPL** 庫 (除非隔離為獨立進程透過 IPC/HTTP 通訊，法律灰色地帶，需法務審核)。
2. 產品為開源專案：
   • 若希望社群貢獻回流 → 選 **GPLv3 / AGPLv3** (強保護)。
   • 若希望最大化採用 (含商業嵌入) → 選 **Apache 2.0 / MIT / BSD** (寬鬆)。
   • 庫/框架類 → **MPL 2.0** 或 **LGPLv3** 平衡保護與採用。
3. 引入依賴前必做：
   • 掃描依賴樹授權 (工具：license-maven-plugin, FOSSA, Snyk, ClearlyDefined)。
   • 建立授權白名單/黑名單策略，CI 門禁攔截違規依賴。
   • 保留 NOTICE、LICENSE 檔案隨產品分發 (Apache 2.0 強制)。

常見誤區澄清

實用工具鏈

• Maven：license-maven-plugin (檢查/生成報表/下載授權文本)、dependency-license-report。
• Gradle：license-gradle-plugin, oss-licenses。
• SBOM 生成：CycloneDX (Maven/Gradle/GitHub Action)、Syft (容器映像掃描)。
• 政策引擎：OPA/Gatekeeper + Rego 規則 在 CI/CD 強制授權合規。

總結

開源授權不是法律文本飾品，而是**代碼流通的契約**。工程師具備基本授權識別力，配合自動化掃描工具鏈、法務協作流程，才能在開源海洋中安心航行、合規交付。