一文读懂开源协议：MIT、GPL-3.0、Apache 2.0 到底怎么选？
别再复制粘贴“随便选一个”了，搞错协议可能让你惹上版权麻烦
如果你写过代码、做过开源小项目，甚至只是在 GitHub 上 fork 过仓库，大概率见过这些标签：MIT、GPL-3.0、Apache 2.0、BSD……
但是它们到底是什么意思？我能用别人的代码吗？我自己的代码应该选哪个协议？
别担心，这篇博客会用最直白的方式，帮你彻底搞清楚开源协议这件事。最后还会给出选择协议的核心建议，让你不再迷茫。
一、什么是开源协议？为什么需要它？
简单说，开源协议 = 一份法律许可。它告诉别人：你可以怎么用我的代码，你要遵守什么条件，哪些事绝对不能做。
没有协议的项目，默认就是“保留所有权利”——别人只能看，不能复制、修改、再发布（即使放在 GitHub 上公开也一样）。而开源协议就是主动把这些权利授予出去。
选择协议的核心矛盾在于：你希望别人用你的代码时付出什么？
- 什么都不要求 → 别人随便用，闭源商用都行（最宽松）
- 要求署名 → 必须保留你的版权声明
- 要求“传染” → 衍生作品也必须开源（强保护）
二、常见开源协议速览
1. MIT 协议 —— “几乎无限制”
一句话：你爱咋用咋用，只要保留我的版权声明。
- 允许：任意修改、闭源、商用、再发布
- 条件：必须包含原作者的版权声明和许可声明
- 传染性：无
- 适用场景：库、工具、教学代码，希望被广泛使用（尤其商用项目）
示例：React、Node.js、jQuery 都使用 MIT。
2. Apache 2.0 —— MIT + 专利保护
一句话：比 MIT 多了明确的专利授权和免责条款。
- 允许：同 MIT，同时授予专利使用权
- 条件：必须保留版权声明和 Apache 声明；修改过的文件要标注变更
- 额外亮点：禁止用原作者名字做商业推广；提供专利报复条款（你用专利告我，你的授权就失效）
- 传染性：无（但最好保留修改记录）
适用：重视专利风险的大公司项目，如 Android、Kubernetes。
3. BSD 协议 —— 类似 MIT，分为 2-clause、3-clause、4-clause
最常遇见的BSD 3-Clause：
- 和 MIT 基本一样，多一条“不得用原作者名义推广”
- 2‑Clause 删掉这一条，几乎等同 MIT
- 4‑Clause 多了一个“广告限制”，已很少用
简单记：遇到 BSD 无脑当作 MIT + 署名即可，除非明确说是 2‑Clause。
4. GPL-3.0 —— “强传染”自由战士
一句话：你用了我的代码，你的代码也必须开源（并且用 GPL 协议）。
- 强制要求：
- 任何分发（包括只提供二进制）必须同时提供完整源代码
- 衍生作品也必须是 GPL 协议
- 不能添加额外限制（比如禁止商用也不行）
- AGPL（网络服务版）：通过 Web 调用也算“分发”，防止云服务商滥用
- 传染性：强 —— 即使你只引用了一个函数，整个项目都得 GPL
适用：希望所有衍生作品都回馈开源社区，阻止闭源商用。例如 Linux 内核、Git、WordPress。
5. LGPL —— GPL 的“弱传染”版本
主要针对库：你可以动态链接一个 LGPL 库，你的主程序可以闭源商用；但如果你修改了库本身，修改的部分必须开源。
适用：希望库能被商业软件使用，但库本身要保持自由。例如 GLib、FFmpeg（部分组件）。
6. Mozilla Public License (MPL 2.0)
介于 MIT 和 GPL 之间：修改过的文件必须开源，但你可以把新文件和它组合成一个更大的闭源项目。
三、一张表看懂核心区别
| 协议 | 商用 | 闭源分发 | 必须署名 | 必须公开源码 | 传染到整个项目 |
|---|---|---|---|---|---|
| MIT / BSD | ✅ | ✅ | ✅ | ❌ | ❌ |
| Apache 2.0 | ✅ | ✅ | ✅ | ❌ | ❌ |
| LGPL | ✅ | ✅ | ✅ | ⚠️ (仅库本身) | ❌ (动态链接时可闭源) |
| GPL-3.0 | ✅ | ❌ | ✅ | ✅ | ✅ |
| AGPL-3.0 | ✅ | ❌ | ✅ | ✅ (含网络分发) | ✅ |
✅ 允许 / 要求 ❌ 禁止 / 不要求 ⚠️ 特殊
四、如何为自己的项目选择开源协议？
不要盲目跟风，先问自己三个问题：
Q1：你希望别人能直接用你的代码做闭源商业软件吗？
- 是→ 选 MIT / Apache 2.0 / BSD
- 否，我希望所有衍生品都要回馈开源社区 → 选 GPL-3.0 或 AGPL（如果是服务端应用）
Q2：你的项目是一个库（会被别人引用），还是一个完整应用？
- 库：用 MIT / Apache 2.0 最受欢迎（商业公司敢用）。如果你希望库本身永远自由但允许商业项目调用 → 用 LGPL。
- 应用：用 GPL 可以防止别人拿你的应用改一改就闭源卖掉。
Q3：你的项目涉及专利技术吗？你担心有人拿你的代码去申请专利反过来告你吗？
- 担心→ 一定要用 Apache 2.0（它明确授予专利许可，且有报复条款）
- 不担心→ MIT 足够用。
五、最后给你的实操建议
| 你的情况 | 推荐协议 |
|---|---|
| 新手第一次开源，希望被更多人使用，不关心商用 | MIT |
| 你做的是公司内部基础库，只希望保留版权 | MIT |
| 你或你公司有专利，希望明确授权，避免专利诉讼 | Apache 2.0 |
| 你理念坚定：“用了我的代码就必须开源整个项目” | GPL-3.0 |
| 你做后端 API / SaaS，不想被云厂商白嫖 | AGPL-3.0 |
| 你写的是函数库，希望商业项目也能用，但库本身开源 | LGPL |
两个常见误区：
❌ “我的项目放 GitHub 上没有协议，别人就可以随便用” → 不对，没协议默认禁止一切。
❌ “GPL 代码别人不能用” → 当然能用，只是你用了之后你的代码也得 GPL。
写在最后
开源协议不是束缚，而是沟通你对代码的“期望”。选择协议就像给你的项目贴一个标签，告诉未来所有人：
- MIT：“尽管拿去用，记得谢谢我”
- GPL：“请把你的改进也分享给世界”
- Apache：“放心用，专利问题我帮你兜底”
如果你实在不知道怎么选 —— 用MIT。这是最安全、最受欢迎、最不容易踩坑的协议。等到你真正理解了项目的价值主张，再换也不迟（注意：协议变更通常只能兼容更宽松的，不能反向收紧）。
希望这篇能帮你走出开源协议的第一步。如果有疑问，欢迎留言讨论！