OSI 批准 58 種開源協議，主流項目集中於 5 大核心協議。選型錯誤可能導致法律風險或商業模式受阻，決策前必須理解核心差異。
協議光譜：從寬鬆到嚴格
寬鬆 (商業友好) ──────────────────► 嚴格 (傳染性強)
MIT ≈ BSD ≈ Apache 2.0 LGPL GPL
逐項深度解析
1. MIT 協議 —— 極致寬鬆
- 僅保留版權聲明與許可證副本
- 允許任意使用、修改、分發、商業化、閉源
- 無專利條款、無貢獻回饋要求
- 代表項目：jQuery, Node.js, React
2. BSD 協議 (2-Clause/3-Clause) —— 商業友好標桿
- 保留協議文本、版權聲明、不得用作者名背書
- 允許閉源商業化、修改後不開源
- 3-Clause 禁止用作者名推廣衍生產品
- 企業首選：可完全控制第三方代碼
3. Apache License 2.0 —— 專利保護增強版 BSD
- 核心同 BSD，新增專利授權條款：貢獻者授予專利權，被授權者訴訟專利則終止授權
- 修改文件需說明變更，NOTICE 文件需保留
- 商業友好，防專利流氓
- 代表項目：Kafka, Hadoop, Spring Framework
4. GPL (v2/v3) —— 強傳染性自由軟件協議
- 核心規則：使用 GPL 代碼（含動態鏈接）的軟件必須開源並採用 GPL
- 禁止閉源商業化分發
- v3 新增：反 Tivoization（禁止硬件鎖死）、專利報復條款
- Linux 內核採用 GPLv2
- 商業軟件/保密項目嚴禁集成 GPL 庫
5. LGPL (v2.1/v3) —— 庫專用弱傳染協議
- 允許商業軟件動態鏈接 LGPL 庫而不開源主程序
- 但修改庫代碼或靜態鏈接則觸發傳染，必須開源相關部分
- 適合：第三方庫引用；不適合：基於庫代碼二次開發
選型決策樹
- 希望最大化採用率、無任何負擔 → MIT
- 商業產品需引用、不想開源主代碼 → Apache 2.0 / BSD / LGPL(動態鏈接)
- 構建開源生態、要求衍生品開源 → GPL
- 提供基礎庫、平衡開源與商用 → LGPL
企業合規紅線
- 生產環境禁止未審計引入 GPL 依賴
- 分發產品時必須包含協議文本（所有協議通用）
- 修改 Apache/LGPL 代碼需保留變更說明
