最近在研究开源项目，对开源协议有点陌生，所以写一篇文章加深印象。
协议选择指南（从宽松到严格）
MIT → Apache 2.0 → BSD → MPL → LGPL → GPL
最宽松 最严格常用协议对比
| 协议 | 商业使用 | 修改代码 | 需要开源修改 | 专利授权 | 特点 |
|---|---|---|---|---|---|
| MIT | ✅ | ✅ | ❌ | ❌ | 最简单、最宽松 |
| Apache 2.0 | ✅ | ✅ | ❌ | ✅ | 包含专利保护 |
| BSD (3-Clause) | ✅ | ✅ | ❌ | ❌ | 类似 MIT |
| MPL 2.0 | ✅ | ✅ | ⚠️ 部分 | ✅ | 文件级开源 |
| LGPL v3 | ✅ | ✅ | ⚠️ 库文件 | ✅ | 可闭源链接 |
| GPL v3 | ✅ | ✅ | ✅ | ✅ | 病毒式传播 |
详细说明
MIT License 🟢 最推荐
✅ 可以商用
✅ 可以修改
✅ 可以闭源
❌ 无专利保护
❌ 无任何声明责任一句话： 做什么都可以，只需保留版权声明。
适用场景：
- 希望代码被广泛使用
- 不介意别人闭源
- 想要最简单的协议
Apache License 2.0 🟢 企业友好
✅ 可以商用
✅ 可以修改
✅ 可以闭源
✅ 专利授权（重要！）
❌ 需要说明变更一句话： 类似 MIT，但多了专利保护和变更声明要求。
适用场景：
- 企业项目
- 涉及专利风险的技术
- 需要法律保护的开源项目
BSD License 🟢 简单宽松
✅ 可以商用
✅ 可以修改
✅ 可以闭源一句话： 和 MIT 类似，但表述方式不同。
3-Clause BSD 比 2-Clause 多了： 禁止用作者名义做背书
Mozilla Public License 2.0 🟡 文件级开源
✅ 可以商用
✅ 可以修改
⚠️ 修改的文件必须开源
✅ 可以闭源链接
✅ 专利授权一句话： 修改哪个文件，哪个文件就必须开源，但整体项目可以闭源。
适用场景：
- 库/框架项目
- 想让别人贡献但不强制整个项目开源
GNU Lesser GPL v3 🟡 库友好的 GPL
✅ 可以商用
✅ 可以修改
⚠️ 修改的库必须开源
✅ 可以闭源链接（动态链接）
✅ 专利授权一句话： 如果是静态链接，你的代码也要开源；动态链接可以闭源。
适用场景：
- 开源库
- 希望保护库本身，但允许商业应用使用
GNU GPL v3 🔴 最严格
✅ 可以商用
✅ 可以修改
✅ 修改必须开源
✅ 使用必须开源（病毒式）
❌ 不能闭源链接
✅ 专利授权一句话： 使用 GPL 代码，你的项目也必须 GPL。
适用场景：
- 想强制所有衍生项目也开源
- 自由软件运动
- 不希望商业公司利用
常见问题
Q: 我应该选哪个协议？
| 情况 | 推荐协议 |
|---|---|
| 不知道选什么 | MIT |
| 企业项目/担心专利 | Apache 2.0 |
| 开发库，希望别人闭源使用 | MIT / Apache 2.0 |
| 开发库，希望修改开源但整体闭源 | MPL 2.0 |
| 坚决反对闭源 | GPL v3 |
Q: 协议可以改吗？
可以！ 但有条件：
- 旧版本代码保持原协议
- 新版本可以换协议
- 如果有其他贡献者，需要获得所有贡献者的同意
Q: 什么是"病毒式"？
指 GPL 的特性：如果你使用了 GPL 代码，你的整个项目也必须以 GPL 协议开源。
Q: 闭源项目可以用开源代码吗？
| 协议 | 能否闭源使用 |
|---|---|
| MIT / Apache / BSD | ✅ 可以 |
| MPL | ✅ 可以（只开源修改部分） |
| LGPL | ✅ 可以（动态链接） |
| GPL | ❌ 不可以 |
GitHub 上如何选择
- 创建仓库时，点击 "Choose a license"
- GitHub 提供可视化选择器
- 或直接在
LICENSE文件中写入协议全文
快速命令
bash
# 创建 MIT License 文件
curl -o LICENSE https://choosealicense.com/licenses/mit/总结建议
90% 的情况选 MIT 或 Apache 2.0
MIT: 我不关心别人怎么用我的代码
Apache: 我想保护自己，也想保护使用者
GPL: 我要捍卫自由软件精神