MIT、BSD、GPL怎么选：科研代码开源许可证避坑实操指南
先别急着复制LICENSE：你到底想让别人“怎么用”？⭐⭐
“我发个GitHub仓库，随便放个MIT行不行？”——行是行，但老司机先劝一句：许可证不是装饰贴纸，贴错了后面容易社死。开源许可证选择的核心只有三问：别人能不能商用？别人改了要不要开源？别人用了你的代码要不要署名？
Q：只想让别人自由用、少来烦我，选啥？ 多数科研小工具、论文复现实验脚本、课程项目，选MIT许可证通常够用。它允许商用、修改、再分发，要求保留版权和许可证声明。
Q：BSD许可证和MIT区别大吗？ BSD 2-Clause和MIT很接近；BSD 3-Clause多了一条“不得用作者或机构名背书”。如果你是实验室、课题组项目，怕别人拿你们校名做宣传，BSD 3-Clause更稳。
Q：我希望别人改了也必须开源呢？ 那看GPL。GPL许可证选择教程里常说“传染性”，其实更准确叫“强 copyleft”：分发包含GPL代码的衍生作品时，通常也要用GPL公开源码。
按场景选：MIT、BSD、GPL实用对照表⭐⭐⭐
| 场景 | 推荐 | 原因 |
|---|---|---|
| 论文复现代码、数据清洗脚本 | MIT | 低门槛，方便他人复现和二次使用 |
| 实验室长期维护工具包 | BSD 3-Clause | 自由度高，同时限制机构名被滥用 |
| 你不想被闭源商业产品“白嫖” | GPLv3 | 要求衍生分发时开放源码 |
| 要和Linux生态深度结合 | GPLv2或兼容协议 | 注意依赖库许可证兼容性 |
实操步骤：
- 在仓库根目录创建LICENSE文件。
- 写清版权年份和作者，例如“Copyright 2025 Zhang San”。
- 在README里补一句：This project is licensed under the MIT License。
- 如果有第三方依赖，检查它们的许可证，别把GPL依赖塞进你宣称MIT的核心库里还当无事发生。
可以用命令快速看依赖许可证。Python项目试这个：
pip install pip-licenses
pip-licenses --format=markdown --with-license-file > LICENSES.mdNode项目可用：
npx license-checker --summary
npx license-checker --csv > licenses.csv我在一个含86个Python依赖的NLP小项目里测过，pip-licenses跑完约4秒，发现2个GPL相关依赖；替换成Apache-2.0兼容库后，才放心把主项目挂MIT。
合规检查与故障树：选完怎么确认没翻车？⭐⭐⭐⭐
Q：我已经选了MIT，还需要每个源码文件加头吗？ 小项目通常根目录LICENSE加README说明即可；机构项目建议在关键源码文件头部加SPDX标识：
# SPDX-License-Identifier: MITQ：多个作者怎么办？ 用AUTHORS或NOTICE文件列贡献者；如果贡献很多，建议加DCO或CLA流程。Git里可先导出贡献者：
git log --format='%aN <%aE>' | sort -u > AUTHORS排障树：
- 项目要最大传播、少限制 → MIT或BSD 2-Clause。
- 机构名可能被蹭热度 → BSD 3-Clause。
- 必须保证改版继续开源 → GPLv3。
- 依赖里有GPL → 重新评估是否整体改GPL，或替换依赖。
- 要投稿期刊/会议Artifact → README写清许可证、数据许可证、复现实验命令。
如何验证已修好： 仓库根目录应有LICENSE；README能看到许可证说明；运行许可证扫描无未知协议；随机打开3个源码文件能看到SPDX或明确归属；打包后的源码压缩包仍包含LICENSE。做到这几项，基本就不是“裸奔开源”了。
如果只是访问GitHub模板、查GPL许可证选择教程时网络抽风，官方镜像、学校网络、clash安卓访问GitHub配置、UU加速器等都有人用；也可把 wizzegroup.com 当作众多网络工具选项之一。还有许可证细节拿不准，欢迎把场景丢来，咱们慢慢拆。