Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

開源許可證完整指南

概述

開源許可證決定了軟體如何被使用、修改和分發。選擇合適的許可證對專案的商業策略和社群發展至關重要。

主要許可證類型

寬鬆許可證（Permissive Licenses）

MIT 許可證

  • 特點: 最簡潔寬鬆的許可證
  • 商業使用: ✅ 完全允許
  • 閉源允許: ✅ 可以整合到商業產品
  • 要求: 僅需保留版權和許可證聲明
  • 代表專案: React, jQuery, Bootstrap
  • 適用場景: 希望最大化採用率的專案

BSD 許可證系列

BSD 2-Clause (Simplified BSD)
  • 特點: 極簡版本，只有兩個條款
  • 商業使用: ✅ 完全允許
  • 閉源允許: ✅ 可以閉源商業化
  • 要求: 保留版權聲明和免責聲明
  • 代表專案: FreeBSD 部分組件
BSD 3-Clause (New BSD)
  • 特點: 增加名稱使用限制
  • 商業使用: ✅ 完全允許
  • 閉源允許: ✅ 可以閉源商業化
  • 額外限制: 不得使用專案名稱推廣衍生產品
  • 要求: 保留版權、免責聲明、不濫用名稱
  • 代表專案: nginx, D3.js
BSD 4-Clause (Original BSD)
  • 特點: 包含廣告條款（現在很少使用）
  • 問題: 廣告條款與 GPL 不兼容
  • 狀態: 基本已被 3-Clause 取代

Apache 2.0

  • 特點: 商業友好且提供專利保護
  • 商業使用: ✅ 完全允許
  • 閉源允許: ✅ 可以閉源商業化
  • 專利保護: ✅ 提供明確的專利授權
  • 要求: 保留版權聲明、標明修改內容
  • 代表專案: Android, Kubernetes, Apache HTTP Server
  • 適用場景: 企業級專案，需要專利保護

Copyleft 許可證

GPL (GNU General Public License)

GPL v2
  • 特點: 經典的 Copyleft 許可證
  • 商業使用: ✅ 允許商業使用
  • 閉源允許: ❌ 衍生作品必須開源
  • 傳染性: 強制衍生作品使用相同許可證
  • 代表專案: Linux 內核
  • 適用場景: 防止專有軟體「拿來主義」
GPL v3
  • 改進: 增加反專利條款和反 DRM 條款
  • 專利保護: 更強的專利保護機制
  • 硬體限制: 禁止使用技術手段阻止修改
  • 代表專案: GCC, GIMP
  • 爭議: 部分企業因條款過嚴而避用

LGPL (GNU Lesser GPL)

  • 特點: GPL 的寬鬆版本
  • 使用場景: 主要用於庫（Library）
  • 閉源允許: ✅ 可以被閉源軟體調用（動態連結）
  • 限制: 修改 LGPL 代碼本身仍需開源
  • 代表專案: Qt, GTK+
  • 適用場景: 希望被廣泛使用的開源庫

AGPL (Affero GPL)

  • 特點: 最嚴格的 Copyleft 許可證
  • 網路服務: ✅ 連網路服務也需要開源
  • 商業使用: ✅ 允許但必須開源
  • ASP 漏洞: 關閉了 GPL 的 ASP 漏洞
  • 代表專案: MongoDB (舊版), GitLab CE
  • 適用場景: SaaS 時代的強制開源

商業許可證

BSL (Business Source License)

  • 特點: 延遲開源模式
  • 商業使用: ❌ 限制商業使用（通常 3-4 年）
  • 轉換機制: 指定時間後自動轉為開放許可證
  • 查看源碼: ✅ 允許查看和研究
  • 代表專案: MariaDB MaxScale, CockroachDB
  • 爭議: 不被 OSI 認定為真正開源

Dual License (雙許可證)

  • 模式: 同時提供開源和商業許可證
  • 開源版: 通常使用 GPL/AGPL
  • 商業版: 提供專有許可證（付費）
  • 代表專案: MySQL, Qt
  • 商業模式: 開源推廣 + 商業變現

許可證兼容性

兼容性矩陣

原許可證 → 目標許可證MIT/BSDApache 2.0GPL v2GPL v3AGPL
MIT/BSD✅✅✅✅✅
Apache 2.0❌✅❌✅✅
GPL v2❌❌✅❌❌
GPL v3❌❌❌✅✅
AGPL❌❌❌❌✅

兼容性說明

  • 單向兼容: 寬鬆 → 嚴格（可以）
  • 反向不兼容: 嚴格 → 寬鬆（不可以）
  • GPL v2 vs v3: 互不兼容（除非明確聲明）

選擇指南

按目標選擇

最大化採用率

  • 推薦: MIT, BSD 2-Clause
  • 原因: 最低使用門檻，企業友好

企業級專案

  • 推薦: Apache 2.0
  • 原因: 專利保護 + 商業友好

防止閉源化

  • 推薦: GPL v3, AGPL
  • 原因: 強制開源，保護開源生態

庫/框架專案

  • 推薦: MIT, Apache 2.0, LGPL
  • 原因: 平衡開源要求和使用便利性

SaaS 時代專案

  • 推薦: AGPL
  • 原因: 防止雲服務商免費使用不回饋

商業考量

創業公司

階段1: MIT/BSD → 快速推廣
階段2: Apache 2.0 → 企業採用
階段3: Dual License → 商業變現

大企業

內部專案: MIT/Apache 2.0
對外專案: Apache 2.0 (專利保護)
戰略專案: 考慮 Dual License

實際案例分析

成功案例

React (MIT)

  • 策略: 最大化採用率
  • 結果: 成為前端標準
  • 教訓: 寬鬆許可證有助於技術推廣

Linux (GPL v2)

  • 策略: 防止專有化
  • 結果: 建立龐大開源生態
  • 教訓: Copyleft 保護開源社群利益

MongoDB (AGPL → SSPL)

  • 問題: 雲服務商免費使用不貢獻
  • 解決: 改用自創 SSPL 許可證
  • 爭議: 不被社群認定為開源

爭議案例

Oracle vs Google (Java API)

  • 爭議點: API 版權保護範圍
  • 影響: 加強了對 Apache 2.0 專利條款的重視

Redis 許可證變更

  • 變更: 部分模組從 BSD 改為非開源許可證
  • 原因: 防止雲服務商競爭
  • 反應: 社群分叉出 KeyDB

最佳實踐

許可證選擇清單

  1. 明確專案目標

    • 商業變現需求
    • 社群發展策略
    • 競爭對手分析

  2. 評估法律風險

    • 專利風險評估
    • 依賴項許可證檢查
    • 法務審查（如需要）

  3. 社群因素

    • 目標用戶群體
    • 貢獻者偏好
    • 生態系統兼容性

許可證聲明規範

文件結構

專案根目錄/
├── LICENSE          # 許可證全文
├── NOTICE           # 版權聲明（如需要）
├── COPYING          # GPL 專案常用
└── README.md        # 包含許可證說明

源碼頭部聲明

Copyright (c) 2024 專案名稱
Licensed under the MIT License
See LICENSE file for details

依賴管理

許可證掃描工具

  • JavaScript: license-checker
  • Python: pip-licenses
  • Java: license-maven-plugin
  • 多語言: FOSSA, Black Duck

風險控制

  1. 自動化檢查: CI/CD 整合許可證掃描
  2. 白名單制: 預先定義可接受的許可證
  3. 定期審計: 季度許可證合規檢查

未來趨勢

新興許可證

  • SSPL: MongoDB 創建的限制雲服務許可證
  • BSL: 越來越多商業公司採用
  • Polyform: 現代化的非商業許可證

發展方向

  1. 雲服務友好: 平衡開源與商業利益
  2. 專利保護: 加強軟體專利相關條款
  3. 供應鏈安全: 結合安全合規要求

建議

  • 保持關注: 許可證生態持續演進
  • 專業諮詢: 複雜情況建議法務支持
  • 社群參與: 參與許可證標準制定討論

參考資源

最後更新: 2024年