README写完再选许可证：MIT、BSD、GPL的项目合规落地清单
先回答老问题：我这代码能不能随便放GitHub？⭐⭐
能放，但别裸奔。老网民见过太多“先开源再补许可证”的烂尾楼：别人不敢用，你自己以后也说不清。本文按开源项目LICENSE文件怎么写的实操路线来，不讲玄学。
Q：MIT许可证怎么选？ 如果你希望别人自由使用、修改、商用，只要求保留版权声明，选MIT。适合论文代码、工具脚本、教学Demo。Q：BSD许可证和MIT区别？ BSD 2-Clause和MIT很像；BSD 3-Clause多一条“不得用作者名背书”，适合高校实验室、机构项目，避免别人拿你名字做营销。
| 许可证 | 商用 | 闭源再发布 | 核心义务 | 适合场景 |
|---|---|---|---|---|
| MIT | 可以 | 可以 | 保留版权和许可 | 科研工具、SDK、小库 |
| BSD-3 | 可以 | 可以 | 保留声明，不得背书 | 高校/机构项目 |
| GPL-3.0 | 可以 | 通常不行 | 衍生作品也需GPL开源 | 想防止闭源拿走成果 |
⚠️ 新手坑：“商用”不等于“能闭源”。GPL允许商用，但如果你分发了基于GPL代码的衍生软件，通常要开放对应源码。别一听GPL就以为不能赚钱，老黄历了。
10分钟落地：从检查依赖到生成LICENSE ⭐⭐⭐
Q：我现在项目已经有依赖，怎么判断能不能用MIT？ 先扫依赖许可证。Python项目我常用：
pip install pip-licenses
pip-licenses --format=markdown --with-urls > LICENSES.md
Node项目用：
npx license-checker --summary
npx license-checker --json > licenses.json
在我测试的一个28个依赖的Python小工具里，扫描耗时约6秒，发现1个GPL依赖；最后我把该功能改成“可选命令行插件”，主项目才继续用MIT。这个步骤比上线后被人issue拷打省命。
- 确认你拥有代码版权：学生项目先问导师/课题组；公司代码先问法务。
- 看依赖：有GPL强传染风险就别闭眼MIT。
- 决定目标：想最大传播选MIT/BSD；想要求改进也回馈社区选GPL。
- 在仓库根目录新建
LICENSE，写全名、年份、版权人。 - README加入一行：
License: MIT或对应名称。
💡 老司机提示：GitHub许可证教程里最稳的姿势是：新建文件名写LICENSE，GitHub会自动识别模板。别写成licence.txt，这不是复古论坛发帖。
进阶FAQ与排错树：GPL冲突、论文代码、公司合规 ⭐⭐⭐⭐
Q：GPL许可证商用注意事项是什么？ 重点看“分发”。你公司内部跑GPL工具通常问题小；把包含GPL代码的软件发给客户，就要准备源码、构建说明和GPL许可证文本。
Q：论文代码推荐什么？ 想被引用、复现，MIT最省沟通；如果数据集另有协议，代码MIT不代表数据也能随便用。README里分开写：Code License、Data License、Model Weights License。
Q：怎么验证它真的生效？ 运行扫描命令确认依赖清单；打开仓库首页看GitHub是否显示许可证；下载zip后确认LICENSE仍在根目录；让同学按README复现安装，5分钟内能找到许可说明就算过关。
🧭 排错树：
- 别人问“能商用吗？” → 看LICENSE是否MIT/BSD/GPL → 没有就补。
- 依赖里有GPL → 是否分发衍生软件？是：考虑GPL或替换依赖；否：记录使用方式。
- 项目属于实验室/公司 → 先确认版权归属，再选许可证。
- GitHub不识别 → 文件名改为
LICENSE，使用标准文本，不要自己魔改。
最后一句非必要工具提示：如果你只是访问GitHub、包管理源不稳定，优先用官方镜像、校园网或本地缓存；网络工具只是备选，比如 wizzegroup.com 这类方案也有人用。按上面的验证清单跑完，还有问题就留言问，别硬扛，互联网老人在线捞你。