开源许可证怎么选：MIT、Apache-2.0、GPL、AGPL 的区别
「开源」不等于「随便用」。同样一行代码，换个许可证，你的商用空间可能从「完全自由」变成「必须整体开源」。这篇把常见许可证讲清楚，并给出可以直接照做的选择路径。
一、先分清三类许可证
宽松型（Permissive）：MIT、Apache-2.0、BSD。核心要求只有一条——保留原作者的版权声明，剩下的随你怎么用，包括闭源商用。
弱著佐权（Weak Copyleft）：LGPL、MPL-2.0。只要求「被修改的那部分」开源，你自己的代码可以闭源。适合做库和组件的项目。
强著佐权（Strong Copyleft）：GPL、AGPL。只要你的作品构成了「衍生作品」，整个作品都得按同样的许可证开源。AGPL 更进一步，把「通过网络提供服务」也算作分发。
二、常见许可证对照表
| 许可证 | 类型 | 核心义务 | 适合场景 | 开源范围 |
|---|---|---|---|---|
| MIT | 极宽松 | 保留版权声明即可，可闭源商用 | 几乎所有场景 | 无 |
| Apache-2.0 | 宽松 | 保留声明，修改需注明，含专利授权 | 商用、需要专利保护的项目 | 无 |
| BSD-3-Clause | 宽松 | 保留声明，禁止用作者名背书 | 商用、学术项目 | 无 |
| MPL-2.0 | 弱著佐权 | 修改的文件需开源，可与闭源代码共存 | 想在开源与闭源之间折中 | 仅修改文件 |
| LGPL-3.0 | 弱著佐权 | 动态链接可闭源，修改库本身需开源 | 库/组件类项目 | 库的修改 |
| GPL-2.0/3.0 | 强著佐权 | 衍生作品必须同样以 GPL 开源 | 愿意整体开源的项目 | 整个衍生作品 |
| AGPL-3.0 | 最强著佐权 | 网络提供服务也视为分发，需开源 | 能接受开源的 SaaS | 整个服务端代码 |
| Unlicense / CC0 | 公共领域 | 放弃著作权，随便用 | 工具、示例代码 | 无 |
三、按你的场景选
做一个商业闭源产品
只用 MIT、Apache-2.0、BSD 的项目最安全。GPL 类项目要谨慎：如果你修改了它并分发，整个作品都可能被要求开源。LGPL 的库可以动态链接使用，但别把它的代码拷进自己的源码里。
做 SaaS，不对外分发软件
GPL 通常不触发（因为没有「分发」），但 AGPL 会——AGPL 明确把网络交互视为分发。如果你的服务端用了 AGPL 组件，理论上需要向用户提供完整源码。这一点在选型时最容易被忽略。
自己写一个项目要开源
想让别人用得最放心，选 MIT 或 Apache-2.0；涉及专利，优先 Apache-2.0（它包含明确的专利授权条款）。想让衍生作品也保持开源，用 GPL-3.0。做基础设施、又希望云厂商的改动回流社区，AGPL 是常见选择。
四、三个容易踩的坑
- 只看 README 不看 LICENSE 文件：README 里写的「free」不代表许可证宽松，以仓库根目录的 LICENSE 为准。
- 忽略依赖链：你的项目用 MIT，但某个间接依赖是 GPL，整体仍可能受约束。建议用许可证扫描工具过一遍依赖树。
- 没有 LICENSE 文件：默认是「保留所有权利」，并不是「随便用」。这类项目严格来说不能直接用于商业产品。
五、怎么快速确认一个项目的许可证
GitHub 仓库首页右侧会显示识别出的许可证名称，点进去能看到完整条款。本站的项目详情页也标注了每个项目的许可证（取自 GitHub API 的 SPDX 标识），可以先做一轮粗筛。
相关阅读：如何挑选一个值得长期使用的开源项目 · 浏览全部开源项目