開源授權不只是法律文字，更是技術選型與商業策略的關鍵依據
專案引入第三方庫時，授權條款決定了你能否修改、能否閉源商用、是否需開源衍生代碼。以下系統整理 Java 生態最常見的七大授權核心規則與商業影響。
1. Mozilla Public License (MPL)
- 允許免費使用、修改、重發布。
- 修改代碼版權歸原發起者（需無償貢獻版權）。
- 不限制連結方式，適合庫與應用分離架構。
- 商業友好：核心代碼版權集中，便於雙授權商業模式。
2. BSD 開源協議（極度寬鬆）
- 自由使用、修改、閉源商用、再授權。
- 三大義務：保留原授權文本（原始碼/二進制文檔）、不得用原作者名稱行銷。
- 企業首選：完全掌控第三方代碼，可隨時修改/二次開發無法律顧慮。
3. Apache License 2.0（企業級標準）
- 類 BSD，鼓勵共享、尊重版權、允許修改閉源商用。
- 關鍵條款：附帶授權副本、修改文件說明、保留原專利/商標/授權聲明、Notice 文件處理規範。
- 專利授權條款明確，降低專利訴訟風險，大型企業廣泛採用。
4. GPL (General Public License)（強制傳染性）
- 核心原則：使用 GPL 代碼 → 整個專案必須採用 GPL（開源免費）。
- 修改檔案需標註修改日期，發布含衍生代碼的作品需同樣授權，不得收費。
- Linux 核心採用 GPLv2，造就自由軟體生態。
- 商業禁忌：專有軟體、保密代碼庫嚴禁引入 GPL 庫（除非雙授權）。
5. LGPL (Lesser GPL)（庫級妥協）
- 允許專有軟體動態連結 LGPL 庫而不被傳染。
- 修改庫本身代碼仍需開源，但應用代碼可閉源。
- 適合函式庫、元件級開源專案。
6. Public Domain（公共領域）
- 無授權限制，任何人可任意使用、修改、商用、再授權。
- 作者放棄所有權利（含版權），極少見於成熟專案。
7. Artistic License（作者控制權）
- 保留作者對後續開發的控制權，Perl 早期版本採用。
- 現代專案多改用 Artistic 2.0（相容 GPL）。
選型決策表
| 授權 | 商業閉源 | 專利保護 | 傳染性 | 典型案例 |
|---|
| MPL | 是 | 弱 | 檔案級 | Firefox 早期 |
| BSD | 是 | 無 | 無 | Nginx, Redis |
| Apache 2.0 | 是 | 強 | 無 | Hadoop, Kafka, Spring |
| GPL | 否 | GPLv3 有 | 專案級 | Linux Kernel |
| LGPL | 是(動態連結) | 弱 | 庫級 | glibc, Hibernate 早期 |
技術選型時，務必由法務與架構師共同評估授權相容性，避免上線後面臨強制開源或侵權風險。
