1. 引言
当你在 GitHub 上创建开源项目时，选择合适的开源协议（License）是至关重要的一步。它不仅定义了他人如何使用你的代码，也保护了你作为作者的权益。本文将详细介绍常见的开源协议及其使用场景，帮助你做出明智的选择。
2. 为什么需要开源协议？
没有协议的代码在法律上属于"保留所有权利"，这意味着：
- ❌ 他人不能合法使用、修改或分发你的代码
- ❌ 即使代码公开在 GitHub 上，也不代表可以随意使用
- ✅ 添加协议后，明确了使用权限，让你的项目真正"开源"
3. 常见开源协议详解
3.1. MIT License（最宽松、最流行）
特点：
- ✅ 极其简单宽松
- ✅ 允许商业使用
- ✅ 可以修改、分发、私有使用
- ✅ 只需保留版权声明和许可声明
限制：
- 无担保声明（使用风险自负）
- 不提供专利授权
适合场景：
- 个人项目想要最大化传播
- 希望被广泛采用，包括商业项目
- 不想有太多法律限制
知名项目： jQuery, Node.js, React
3.2. Apache License 2.0（企业友好）
特点：
- ✅ 允许商业使用
- ✅ 明确的专利授权
- ✅ 可以修改、分发
- ✅ 必须声明修改内容
限制：
- 必须包含 NOTICE 文件
- 不能使用项目商标
适合场景：
- 涉及专利的项目
- 希望企业采用的项目
- 需要明确贡献者专利权的场景
知名项目： Android, Apache 系列软件, Kubernetes
3.3. GNU GPL v3.0（强传染性）
特点：
- ✅ 允许商业使用
- ✅ 必须开源修改后的代码（Copyleft）
- ✅ 强制衍生作品使用相同协议
- ✅ 明确的专利授权
限制：
- ⚠️ 衍生作品必须开源
- ⚠️ 不能用于闭源商业软件
适合场景：
- 希望代码永远开源
- 防止被商业公司闭源使用
- 推广自由软件理念
知名项目： Linux, Git, WordPress
3.4. GNU GPL v2.0
与 v3.0 类似，但不包含某些新增条款：
- 没有专利条款
- 与某些协议兼容性不同
- 一些老项目仍在使用
3.5. BSD 2-Clause & BSD 3-Clause（简洁宽松）
BSD 2-Clause（简化版）：
- 与 MIT 类似，但措辞更简洁
- 只需保留版权和免责声明
BSD 3-Clause（修订版）：
- 增加了一条：不能用作者名字背书
适合场景：
- 学术项目
- 希望简单明了的协议
- 类似 MIT 的使用场景
知名项目： BSD 操作系统, NumPy, Flask
3.6. GNU AGPL v3.0（网络服务专用）
特点：
- 基于 GPL v3
- ⚠️ 即使通过网络提供服务也必须开源
- 最严格的 Copyleft 协议
适合场景：
- 网络服务/SaaS 项目
- 防止云服务商闭源使用
知名项目： Nextcloud, Mastodon
3.7. LGPL v2.1（库的折中方案）
特点：
- 允许闭源软件链接使用
- 库本身修改必须开源
- 使用库的软件可以闭源
适合场景：
- 开发库/框架
- 希望被商业软件使用，但库本身保持开源
3.8. Mozilla Public License 2.0
特点：
- 文件级 Copyleft（修改的文件必须开源）
- 可以与其他协议的代码混合
- 介于 MIT 和 GPL 之间
适合场景：
- 希望核心代码保持开源
- 允许与专有代码集成
知名项目： Firefox, Thunderbird
3.9. Boost Software License 1.0
特点：
- 非常宽松
- 不需要在二进制分发时包含协议
- 适合库的开发
适合场景：
- C++ 库（Boost 社区标准）
- 嵌入式系统
3.10. Eclipse Public License 2.0
特点：
- 类似 MPL
- 商业友好
- 弱 Copyleft
适合场景：
- Eclipse 生态项目
- 企业开源项目
3.11. Creative Commons Zero v1.0（公共领域）
特点：
- 放弃所有权利
- 完全的公共领域
- 无需署名
适合场景：
- 数据集
- 配置文件
- 放弃所有版权
3.12. The Unlicense（公共领域）
特点：
- 类似 CC0
- 完全放弃版权
- 最自由的"协议"
适合场景：
- 小工具、示例代码
- 完全不在乎版权
4. 个人项目如何选择？
4.1. 决策树
开始
│
├─ 想要代码被广泛使用？
│ ├─ 是 → 不在乎商业闭源使用？
│ │ ├─ 是 → MIT / BSD / Apache 2.0
│ │ └─ 否 → GPL v3.0 / AGPL v3.0
│ │
│ └─ 否 → 放弃所有权利？
│ ├─ 是 → Unlicense / CC0
│ └─ 否 → 保留所有权利（不添加协议）
│
├─ 是网络服务/SaaS？
│ └─ 想防止云服务商闭源？
│ └─ 是 → AGPL v3.0
│
├─ 是库/框架？
│ ├─ 允许商业闭源使用？
│ │ ├─ 是 → MIT / Apache 2.0
│ │ └─ 否 → LGPL / MPL 2.0
│
└─ 涉及专利？
└─ Apache 2.0 / GPL v3.0
4.2. 具体建议
1. 个人小项目、工具、Demo
- 推荐：MIT License
- 理由：简单、流行、没有负担
2. 希望防止被商业闭源使用
- 推荐：GPL v3.0
- 理由：强制开源衍生作品
3. 网络服务/API 项目
- 推荐：AGPL v3.0
- 理由：防止云服务商闭源使用
4. 库/框架项目
- 推荐：Apache 2.0 或 MIT
- 理由：企业友好，容易被采用
5. 涉及专利的项目
- 推荐：Apache 2.0
- 理由：明确的专利授权
6. 完全开放的数据/配置
- 推荐：CC0 或 Unlicense
- 理由：放弃所有权利
5. 如何在 GitHub 添加协议
5.1. 方法一：创建仓库时选择
- 创建新仓库
- 在"Add a license"下拉菜单选择
- GitHub 会自动添加 LICENSE 文件
5.2. 方法二：已有仓库添加
- 进入仓库主页
- 点击"Add file" → “Create new file”
- 文件名输入
LICENSE或LICENSE.md - 点击右侧"Choose a license template"
- 选择协议，GitHub 会自动填充内容
- 修改年份和作者信息
- 提交文件
5.3. 方法三：手动添加
- 访问 choosealicense.com
- 选择协议并复制全文
- 在项目根目录创建
LICENSE文件 - 粘贴内容并修改年份/作者
- 提交到仓库
6. 协议对比表
| 协议 | 商业使用 | 修改 | 分发 | 私有使用 | 责任 | 专利授权 | 衍生作品开源 |
|---|---|---|---|---|---|---|---|
| MIT | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Apache 2.0 | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ |
| GPL v3.0 | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ 必须 |
| AGPL v3.0 | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ 必须（含网络） |
| BSD 3-Clause | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| LGPL v2.1 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | 部分 |
| MPL 2.0 | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | 文件级 |
| Unlicense | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
7. 常见问题
7.1. Q1: 可以更改协议吗？
可以，但：
- 只能对未来版本更改
- 已发布的版本仍遵循旧协议
- 可能影响现有用户
7.2. Q2: 可以使用多个协议吗？
可以（双协议或多协议），例如：
- MIT + Apache 2.0
- GPL + 商业协议（双授权）
7.3. Q3: 不添加协议会怎样？
- 代码受版权保护
- 他人不能合法使用
- 可能限制项目传播
7.4. Q4: 协议可以自己修改吗？
不建议，因为：
- 失去标准协议的法律保障
- 增加理解成本
- 可能存在法律漏洞
8. 总结
8.1. 快速选择指南
- 大多数个人项目 → MIT License
- 希望永久开源 → GPL v3.0
- 网络服务 → AGPL v3.0
- 企业友好库 → Apache 2.0
- 完全开放 → Unlicense
选择开源协议是一个权衡的过程：
- 宽松协议 = 更广泛传播 + 可能被闭源使用
- 严格协议 = 保持开源 + 可能限制采用
对于大多数个人项目，MIT License 是最佳选择，它简单、流行、没有负担，能让你的代码被最大化利用。
9. 参考资源
- Choose a License - GitHub 官方协议选择指南
- Open Source Initiative - OSI 认证的开源协议列表
- TLDRLegal - 用通俗语言解释各种协议