引入開源庫時，授權協議決定了能否商業使用、是否必須開源衍生作品、專利授予範圍、商標使用限制等法律風險。選型錯誤可能導致專案被迫開源、面臨訴訟或無法交付。本文整理六大主流協議核心條款對照。
| 協議 | 商業使用 | 修改再發布 | 衍生作品授權要求 | 專利條款 | 典型適用場景 |
|---|---|---|---|---|---|
| MPL 2.0 | ✅ | ✅ | 檔案級Copyleft：修改檔案須同授權，但可與專有碼連結 | 明確專利授予 | Mozilla專案、需平衡開源與商業模組的庫 |
| BSD 3-Clause | ✅ | ✅ | 許可性：無Copyleft，保留版權聲明即可閉源商用 | 無明確專利條款 | 企業偏好、需最大自由度的庫/工具 |
| Apache 2.0 | ✅ | ✅ | 許可性：含專利授予、貢獻者授權協議(CLA)機制 | 強專利授予與訴訟終止條款 | 企業級專案、需專利保護的開源生態 |
| GPL v3 | ✅ | ✅ | 強Copyleft：傳染性，衍生作品必須同授權開源 | 專利授予+反TiVoization條款 | Linux核心、堅持自由軟體理念的專案 |
| LGPL v3 | ✅ | ✅ | 弱Copyleft：動態連結庫可閉源，靜態連結或修改庫碼須開源 | 專利授予 | glibc、需允許商業軟體動態連結的庫 |
| Public Domain / CC0 | ✅ | ✅ | 無限制：完全放棄版權，零條件使用 | 無 | 極小工具類、測試資料、無法律顧慮場景 |
NOTICE檔（Apache專案常見），發布時必須保留參考權威來源：OSI授權清單、GitHub Choose a License。
