开源许可证是法律协议，规定了他人可以如何使用、修改、再分发你的代码。理解不同许可证的差异对开发者和使用者都至关重要。
核心分类
开源许可证主要分为两大阵营：
| 类型 | 特点 | 商业友好度 | 代表性许可证 |
|---|---|---|---|
| 宽松式 (Permissive) | 几乎无限制，允许闭源二次开发 | ✅ 极高 | MIT, Apache-2.0, BSD |
| 著佐权 (Copyleft) | 衍生作品必须保持开源 | ⚠️ 受限 | GPL, LGPL, AGPL |
主流许可证详解
1. MIT 许可证
极简主义的代表
- 核心条款：保留版权声明即可，允许闭源、商用、修改、再分发
- 适用场景：希望最大程度推广使用，不在意代码是否被私有化
- 知名项目：jQuery, React, Node.js, Vue.js
2. Apache License 2.0
企业级首选
- 超越 MIT：添加了专利授权条款，防止贡献者事后提起专利诉讼
- 要求：保留版权和免责条款，变更需注明
- 适用场景：企业开源项目，避免专利风险
- 知名项目：Android, Hadoop, Swift
3. BSD 许可证
"别用我名字做广告"
- BSD-2-Clause：基本与 MIT 相同
- BSD-3-Clause：额外禁止用原作者名义推广衍生产品
- 适用场景：BSD 系统生态、学术界
4. GPL (GNU General Public License) v2/v3
"传染性"最强的开源卫士
- 核心机制：如果你在本项目中使用了 GPL 代码，你的整个项目也必须以 GPL 开源
- v3 与 v2 区别：v3 禁止硬件加密锁定（Tivoization），明确专利权
- 风险：使用 GPL 库可能导致被迫开源整个商业软件（Copyleft 效应）
- 知名项目：Linux 内核 (GPL v2), Git, WordPress
5. LGPL (Lesser GPL)
库的折中方案
- 允许专有软件动态链接到 LGPL 库而不必开源
- 但如果修改了 LGPL 库本身，修改部分必须开源
- 适用场景：开源库开发者，希望被商业软件广泛使用
6. AGPL (Affero GPL)
填补 GPL 的"网络漏洞"
- GPL 要求分发软件时开源，但网络服务（SaaS）被视为使用而非分发，传统 GPL 不强制开源服务端代码
- AGPL 规定：通过网络提供服务也必须提供源代码
- 适用场景：云服务、网络应用
- 派生社区：MongoDB (曾使用 AGPL)、Nextcloud
7. MPL (Mozilla Public License) 2.0
"文件级" Copyleft
- 比 GPL 温和：仅修改过的文件必须开源，新增文件不受影响
- 与专有代码链接不触发开源义务
- 适用场景：既要保持开源，又不想吓跑商业用户的中间路线
关键决策矩阵
选择许可证时需考虑：
- 专利保护 → Apache-2.0 (提供明确的专利授权)
- 最大化用户 → MIT (最宽松，门槛最低)
- 保护开源不被私有化 → GPL/AGPL (确保衍生作品回馈社区)
- 作为库被广泛使用 → LGPL/MPL (平衡开源与商业调用)
- 代码即服务 → AGPL (防止云厂商白嫖不开源)
常见误区与风险
⚠️ 许可证冲突：GPL 代码不能与闭源代码静态链接；Apache-2.0 与 GPL v2 不兼容（与 GPL v3 兼容）
⚠️ 叠加遵守：依赖项的许可证义务也会传递。使用 npm/pip install 时，要检查依赖树的许可证
⚠️ 没有许可证 ≠ 开源：未声明许可证意味着代码受版权法保护，他人无使用权限。需明确添加 LICENSE 文件
建议实践：使用 Choose a License（GitHub 官方指南）或 tldrlegal.com 辅助决策。
不同的许可证哲学反映了开发者对"自由"的定义差异：是用户的自由（使用软件做任何事）还是代码的自由（代码本身必须保持开放）。
