主流开源协议说明

一、开源协议核心分类

宽松型许可（Permissive Licenses）
- 核心特征：允许闭源使用和商业集成，仅要求保留版权声明。
- 代表协议：
  - MIT License
    - 核心条款：允许任意使用（商业/闭源/修改），仅需保留版权声明和许可文本。
    - 适用场景：个人项目、工具库（如jQuery、Rails）。
  - Apache 2.0
    - 核心条款：允许闭源，但需标注修改文件并提供专利授权（使用者可免费使用代码中的专利）。
    - 适用场景：企业级项目（如Kubernetes、Hadoop），需规避专利风险。
  - BSD License
    - 变种区别：
      - BSD-2-Clause：仅需保留版权声明。
      - BSD-3-Clause：额外禁止使用作者名义推广衍生品。
    - 适用场景：学术研究、操作系统（如FreeBSD）。
Copyleft许可（传染性协议）
- 核心特征：衍生作品必须开源并采用相同协议。
- 代表协议：
  - GPL（GNU通用公共许可证）
    - 强传染性：任何衍生作品（含动态链接）必须开源并采用GPL。
    - 适用场景：强调开源共享（如Linux内核）。
  - LGPL（较宽松公共许可证）
    - 弱传染性：允许闭源软件动态链接该库，但直接修改库代码需开源。
    - 适用场景：开源库被商业软件引用（如FFmpeg）。
  - AGPL（Affero通用公共许可证）
    - 网络传染性：SaaS服务需公开修改后的源代码。
    - 适用场景：云服务项目（如Mastodon），防止厂商“白嫖”代码。
折中型许可
- MPL 2.0（Mozilla公共许可证）
  - 文件级Copyleft：仅要求修改后的文件开源，允许混合闭源代码。
  - 适用场景：需部分闭源的项目（如Firefox浏览器）。

二、协议对比速查表

协议	允许商用	允许闭源	传染性	专利条款	特殊要求
`MIT`	✅	✅	❌	❌	保留版权声明
`Apache 2.0`	✅	✅	❌	✅	标注修改文件
`BSD-3-Clause`	✅	✅	❌	❌	禁止用作者名义推广
`GPL v3`	✅	❌	强传染（衍生作品需开源）	✅	动态链接软件也需开源
`LGPL v3`	✅	✅（动态链接）	弱传染（仅修改部分开源）	✅	静态链接时需开源
`AGPL v3`	✅	❌	网络传染（SaaS需开源）	✅	网络服务提供源码
`MPL 2.0`	✅	✅（部分）	文件级传染	✅	修改文件需开源

注：传染性强度排序：宽松型（MIT/BSD/Apache）< 折中型（MPL/LGPL）< 强Copyleft（GPL/AGPL）。

三、协议选择指南

关键问题决策树：
- 是否允许闭源？
  - ✅ → 选择MIT/Apache/BSD。
  - ❌ → 选择GPL/AGPL。
- 是否要求衍生作品开源？
  - ✅ → 选择GPL/AGPL（强传染性）。
  - ❌ → 选择宽松型协议。
- 是否需要专利保护？
  - ✅ → 优先Apache 2.0/GPL v3。
  - ❌ → MIT/BSD更简洁。
典型场景推荐：
- 个人/社区项目：MIT（最大化传播）。
- 企业开源项目：Apache 2.0（专利保护+商业友好）。
- 核心代码防私有化：GPL（确保开源延续）。
- SaaS服务：AGPL（防止云服务商闭源获利）。
- 混合开发库：LGPL/MPL（平衡开源与专有需求）。

四、法律风险规避

常见误区澄清：
- 误区1：使用MIT代码可不署名 → 必须保留版权声明。
- 误区2：动态链接GPL库无需开源 → GPL要求衍生作品整体开源。
- 误区3：公司内部使用GPL代码需开源 → 仅分发时触发。
合规实践：
- 添加LICENSE文件：项目根目录放置协议文本。
- 标注版权信息：每个源文件头部声明（如Copyright (c) 2025 [作者]）。
- 检查依赖协议兼容性：
  - GPL项目不可集成MIT代码（因GPL要求相同协议，而MIT允许闭源）。
  - 使用工具（如FOSSA、ScanCode）扫描依赖树冲突。

五、总结

协议类型	核心优势	理想场景
宽松型（`MIT/BSD`）	商业友好、限制最少	工具库、快速传播项目
`Apache 2.0`	专利保护+商业兼容	企业开源、专利敏感型技术
`GPL/AGPL`	防止代码私有化	生态共建项目、开源核心基础设施
`MPL/LGPL`	文件级/库级传染	混合开发框架、商业软件集成库