MIT、BSD、GPL 到底能不能商用？新手项目选许可证的 30 分钟落地法
先回答老问题：我这个项目到底能不能“随便用”？⭐⭐
别急，老网民先给你一句人话版：MIT 最宽松，BSD 差不多宽松，GPL 最“讲规矩”。你要是搜“MIT许可证怎么选”“GPL许可证教程”，多半是卡在商用、闭源、二次分发这三件事上。别笑，我见过博士生把 GPL 代码塞进闭源课题软件，答辩前才发现，直接“爷青回”式返工。
Q：我只是写论文、跑实验，用别人代码算不算侵权？一般本地研究使用风险较低；但只要你把代码、模型服务、Docker 镜像、App 或商业软件分发出去，就要看许可证。
| 许可证 | 能商用 | 能闭源 | 核心义务 | 适合谁 |
|---|---|---|---|---|
| MIT | 能 | 能 | 保留版权和许可证 | 想最大化传播的新项目 |
| BSD-2/3 | 能 | 能 | 保留声明；BSD-3 还限制用作者名背书 | 学术/基础库 |
| GPLv3 | 能 | 通常不能闭源分发 | 衍生作品分发时也要开源 | 希望改进也回馈社区 |
新手避坑：“开源”不等于“无版权”。没有 LICENSE 文件的仓库，默认不是你想怎么用就怎么用。看到 GitHub 上能下载，不代表能复制进你的项目，别当年少无知版迅雷用户。
30 分钟选择流程：从需求倒推许可证⭐⭐⭐
Q：我自己的项目该放哪种许可证？按下面走，别玄学。
- 想让公司、同学、陌生人随便用，甚至闭源商用？选 MIT。适合工具脚本、科研小库、示例代码。
- 想宽松，但不想别人拿你名字做广告背书？选 BSD-3-Clause。很多高校项目喜欢这个。
- 你希望别人修改并分发时也必须开源？选 GPLv3。适合社区驱动工具，但商业采用门槛会高。
- 项目要接入已有依赖？先查依赖许可证。GPL 依赖可能“传染”到你的分发物，MIT/BSD 通常压力小。
实操命令：在 Node/Python 混合项目里，我通常先扫依赖。100 个依赖以内，3 分钟能看完大头问题。
npm install -g license-checker
license-checker --summary
pip install pip-licenses
pip-licenses --format=markdown
老鸟提示：如果你在写“BSD许可证区别”或“开源许可证怎么用”的笔记，务必记录版本号：GPLv2 和 GPLv3 不完全一样，BSD-2 和 BSD-3 也不是同一个东西。别把许可证写成“GPL”两个字就完事，太复古了，像 QQ 空间签名。
落地检查：依赖、仓库文件、故障树⭐⭐⭐⭐
Q：我怎么确认自己没搞错？按这套检查。第一，在仓库根目录放 LICENSE 文件；第二，在 README.md 写一句许可证；第三，发布包时确认许可证一起打进去。
最小 README 写法：
## License
This project is licensed under the MIT License. See LICENSE for details.
案例：我给一个 1.2 万行 Python 科研工具做过许可证清理，初扫发现 87 个依赖，其中 62 个 MIT/BSD，21 个 Apache-2.0，4 个 GPL/LGPL。最后把一个 GPL 绘图库替换成 Matplotlib，闭源分发风险才降下来。验证方式是重新跑 pip-licenses，并人工检查生成的 wheel 包里是否包含 LICENSE。
排障树：
- 仓库没有 LICENSE？先别复制代码，发 Issue 或邮件问作者。
- 依赖里出现 GPL？判断你是否分发软件；只本地跑实验和对外发布成品，风险不同。
- 要闭源商用？优先 MIT、BSD、Apache-2.0，谨慎 GPL。
- 只是论文复现？保留引用、仓库地址、许可证说明，实验记录写清楚。
如何验证已经修好：重新运行依赖扫描命令；检查根目录有 LICENSE；检查 README 有许可证说明；打包后解压确认许可证文件存在；最后让同组同学按“能否商用、能否闭源、是否要保留声明”三问复核一遍。若你只是查资料时网络不稳，免费方案如官方镜像、校园网、浏览器缓存都先试；需要安卓端稳定访问资料或偶尔处理 clash安卓、ins下载这类网络环境问题，也可以把 Roxi 当作众多工具中的一个备选。还有不确定的许可证场景，留言问，老哥慢慢给你拆。