先确定目标
选择许可证不是偏好问题，而是你想要什么的问题。大多数情况都处于以下两个目标之间。
- 希望被尽可能多地使用 — 如果希望毫无负担地进入企业产品、其他开源项目和闭源应用，宽松型更有利。
- 希望改进能以公开形式回馈 — 如果希望有人修改并分发你的代码时，这些修改也会公开，著佐权更合适。
宽松型：广泛采用，摩擦少
MIT、BSD、ISC、Apache-2.0 大致只要求保留声明。大多数企业法务团队都会把它们列入预先批准名单，因此引入很快。但反过来，有人修改代码后放进闭源产品也无法阻止。
在宽松型内部，选择主要取决于两点。
- 专利：需要明确的专利许可和专利报复条款就选 Apache-2.0，否则选 MIT。
- 与 GPL-2.0 的兼容：FSF 的立场是 Apache-2.0 不能放进 GPL-2.0-only 项目，因此在 Linux 内核周边生态中，MIT、BSD 更方便。
著佐权：公开的连锁
GPL 以结合后的整个程序为单位、LGPL 以库为单位、MPL 以文件为单位规定公开义务。对于在服务器上运行的软件，AGPL 填补了 GPL 的空白。采用著佐权后，部分企业可能不愿使用或贡献。尤其是 AGPL，许多公司通过内部政策限制使用。这既可能是有意达到的效果，也可能是不希望出现的副作用。
生态惯例也不容忽视
许可证与社区惯例一致时，摩擦更少。
| 生态 | 常见许可证 | 备注 |
|---|---|---|
| JavaScript（npm） | MIT, ISC | 小型包多，偏好简短的宽松型 |
| Rust（crates.io） | MIT OR Apache-2.0 | Rust 本身就采用这种双重方式 |
| Python（PyPI） | MIT, BSD-3-Clause, Apache-2.0 | 科学计算领域多用 BSD-3 |
| Go | BSD-3-Clause, MIT, Apache-2.0 | Go 标准库为 BSD-3 |
| Linux 内核模块 | GPL-2.0-only | 要与内核结合实际上是必需的 |
| 桌面 GNU 工具 | GPL-3.0-or-later | GNU 项目的默认选择 |
| C/C++ 库 | LGPL, MIT, BSL-1.0 | 链接方式会影响选择 |
决策检查清单
- 确认依赖项：看看已在使用的库的许可证是否限制了你的选择。如果要分发与 GPL 库结合的程序，选择范围就缩小到与 GPL 兼容的许可证。
- 确认归属：职务上编写的代码通常以公司为版权所有者。确认公司的开源政策是否规定了许可证。
- 使用形态：是安装型、库还是服务，著佐权的效果各不相同。
- 贡献方式：如果计划接受外部贡献，要记住以后很难更换许可证，因为多人的版权会混在一起。
- 盈利模式：如果计划另外销售商业许可证，请一并考虑著佐权 + 商业双重许可以及贡献者许可协议（CLA）。
一句话总结
- 被广泛使用最优先 → MIT（担心专利就选 Apache-2.0）
- 希望收回库的改进，但让使用方保持自由 → MPL-2.0 或 LGPL-3.0
- 希望所有衍生程序都公开 → GPL-3.0
- 希望连服务器软件的修改版也公开 → AGPL-3.0
- 不想设置任何条件 → 0BSD、Unlicense、CC0
在选择向导中以问题形式回答这些标准，即可看到候选及理由。
本文为一般信息，不构成法律意见。重要决定请咨询专业人士。
参考来源
- choosealicense.com — https://choosealicense.com/
- FSF, Various Licenses and Comments about Them — https://www.gnu.org/licenses/license-list.html
- Rust 许可证（MIT OR Apache-2.0）— https://github.com/rust-lang/rust