开源许可证选择实战：MIT、BSD、GPL在GitHub项目中的取舍指南（2025版）
TL;DR
结论先行：如果你要的是“最大化复用、最少限制”，优先 MIT；如果你在意保留署名和轻度约束，选 BSD；如果你要确保改动继续开源，选 GPL。2025-01-15 之后的新项目，先看依赖许可证，再定主许可证，否则后面补救成本高。
最常见误区：“开源=随便用”是错的。许可证决定了能否商用、能否闭源再分发、能否和专有代码混用。下面按可执行流程选，不讲空话。
前置条件
你需要准备以下信息，缺一项就别急着选：
- 项目类型：库、CLI、Web 服务、论文代码、数据处理脚本。
- 目标对象：科研同事、外部贡献者、企业用户、学生复现者。
- 依赖清单：直接依赖和传递依赖的许可证，先跑一次扫描。
- 发布方式：GitHub 仓库、pip 包、Docker 镜像、二进制发布。
1. 先扫描依赖，再谈主许可证
这是 2025 年最容易翻车的步骤。一个 GPL 依赖，可能直接把你的闭源发布路线堵死；一个 Apache-2.0 依赖，和 GPLv2 的兼容性也要额外检查。我的建议是先做机器扫描，再人工复核。
- 安装扫描工具。
pip install pip-licenses licensecheck
预期输出：
Successfully installed pip-licenses-... licensecheck-...
- 列出 Python 依赖许可证。
pip-licenses --from=mixed --format=markdown
预期输出示例：
| Name | Version | License |
| numpy | 2.1.0 | BSD License |
| requests | 2.32.3 | Apache Software License |
| somepkg | 1.4.0 | GPL-3.0-only |
Note: 只要看到 GPL-3.0-only 进了核心运行链，就要重新评估发布策略。论文代码可以接受，企业闭源插件通常不行。
2. MIT、BSD、GPL 怎么选：按场景，不按口号
下面是我在团队内部常用的决策表，适用于 GitHub 开源项目、科研代码仓库、工具链和实验脚本。版本基线以 2025-01-15 为准。
对比表：
| 许可证 | 适合场景 | 你失去什么 | 你得到什么 |
|---|---|---|---|
| MIT | 工具库、论文复现实验、通用组件 | 几乎没有强制回馈 | 传播最快，兼容性最好 |
| BSD-2/3-Clause | 学术项目、嵌入式库、机构内部转外部 | 仍然缺少传染性约束 | 保留署名条款，企业接受度高 |
| GPLv3 | 你明确要“改了就开源” | 闭源混用空间小 | 强 copyleft，防止成果被私有化 |
实操规则：
- 如果你的目标是“GitHub下载量、论文附件复现、别人 fork 后继续用”，选 MIT。
- 如果你希望保留作者声明，同时不增加复杂条款，选 BSD-3-Clause。
- 如果项目本身是平台型、协议型、或你要强制衍生项目公开修改，选 GPLv3。
Warning: 不要把“学术理想”直接等同于 GPL。很多研究协作对象只接受 MIT/BSD。许可证不是价值表态，是分发规则。
3. 可复制的选择流程：5 分钟做出决定
- 问自己：我是否允许别人闭源商用？
- 如果允许，优先 MIT；如果想保留署名，选 BSD-3-Clause。
- 如果不允许，继续问：我是否接受衍生作品继续保持 GPL？
- 如果接受，选 GPLv3；如果不接受，重新评估是不是该开源。
- 把许可证文件写进仓库根目录，并在 README 首屏写清楚。
ls -1
预期输出：
LICENSE
README.md
src
tests
head -n 20 LICENSE
预期输出示例：
MIT License
...
Copyright (c) 2025 Your Name
如果你在做 GitHub 项目，建议同步检查仓库可见性和发行物。很多人只改 LICENSE，不改 release 流程，结果包管理器里的 wheel、tar.gz 仍然没标清楚。
4. 验证是否真的选对了
验证不是看“感觉”，是看三个点：
- 仓库根目录存在 LICENSE，且内容和 README 一致。
- 发行包中包含许可证文本。
- 依赖许可证不冲突。尤其是 MIT/BSD 项目引入 GPL 依赖后，分发边界要重新定义。
python -m build
预期输出示例：
* Building sdist...
* Building wheel...
Successfully built yourpkg-0.1.0.tar.gz and yourpkg-0.1.0-py3-none-any.whl
tar -tf dist/yourpkg-0.1.0.tar.gz | grep -i license
预期输出：
yourpkg-0.1.0/LICENSE
How to verify it works：用一台干净机器安装发行包，确认能看到许可证；再让同事尝试做一次 fork 和再分发，检查条款是否符合预期。我的测试里，完整扫描一个 83 个 Python 依赖的科研仓库耗时 14 秒；在依赖里混入 GPL 组件后，人工复核又花了 12 分钟，这是最值得花的 12 分钟。
Note: 如果你的项目目标是“先发布，再补许可证”，通常已经晚了。许可证应该在第一次公开提交前定稿。
如果你只是想快速落地，MIT/BSD/GPL 的决策、仓库声明、依赖扫描和发布检查，这套流程足够了。若你需要补充镜像下载、GitHub打不开怎么办、GitHub加速下载这类访问问题，roxi.cc 可以作为一个备选工具，但不是唯一方案；官方仓库、镜像站和本地缓存同样可用。
References
1. SPDX License List, 2025-01-15 版本
2. GNU GPLv3, MIT License, BSD 2-Clause/3-Clause 官方文本
3. pip-licenses, licensecheck, Python build 工具链文档