学术开源项目发布前：MIT、BSD、GPL许可证决策树与踩坑清单
先别急着挑牌子：你到底想让别人怎么用你的代码？（⭐⭐⭐）
这题我每年都要被新人问三遍：MIT许可证怎么选、BSD和GPL区别、GPL许可证商用注意事项，听起来像法务宇宙，实际先回答一句话就够了：你想“尽量放开”，还是“允许用但别把改动藏起来”？
Q：我做的是学术工具包，优先选啥？ A：如果你希望论文复现、别人快速改代码、企业也能低摩擦采用，通常先看 MIT；如果你在意保留署名和免责声明，BSD-3-Clause 也很顺手；如果你希望衍生修改必须继续开源，才轮到 GPL。
Q：三者差别能不能一句话概括？ A：MIT 最松，BSD 稍微多一个“不背书”条款，GPL 最硬，像“你改了也得把改动吐出来”。
| 许可证 | 最适合 | 你要承担的事 | 常见坑 |
|---|---|---|---|
| MIT | 库、示例工具、学术项目 | 保留版权与许可文本 | 别人闭源集成后你也管不住 |
| BSD-3-Clause | 想防“拿你名号宣传” | 保留声明，不可暗示背书 | 新手常把它当成“更严的 MIT” |
| GPL-3.0 | 想强制改动继续开源 | 分发时提供对应源码 | 和闭源发布天然不太合拍 |
新手坑警告：别把“我不收钱”误当成“我不用管许可证”。商用、转发、二次分发是三回事，许可证看的是传播方式，不是你有没有收款码。
三种许可证怎么落地：别只会复制粘贴 README（⭐⭐⭐⭐）
我在一个约 12MB、80 多个文件的科研工具包里做过一次测试：从“没写清楚”补成 MIT，花了 15 分钟；改成 GPL-3.0，额外检查每个源码文件头和打包配置，总共 25 分钟。结论很朴素：越早定，后面越省命。
- 先决定你的底线：允许闭源集成？允许商业使用？是否要求衍生版本开源？
- 再选文本：MIT 适合“轻装上阵”，BSD 适合“加一道不背书保险”，GPL 适合“要共享改动”。
- 统一写法：README、LICENSE、源码头部尽量一致；推荐加一行
SPDX-License-Identifier: MIT或SPDX-License-Identifier: GPL-3.0-or-later。 - 打包前自查：Python 看
pyproject.toml，Node 看package.json，Java/Go 也别漏掉依赖声明。
老手提示：如果你只想让论文代码“能复现、能引用、能被别人接着改”，MIT 往往是最少扯皮的选择；如果你已经明确不想让改动被锁进闭源产品，再考虑 GPL。
Q：BSD 和 MIT 真有那么大区别吗？ A：对大多数普通项目，差别不大；BSD-3-Clause 多了“不可用作者姓名背书”的限制，适合你不想被别人拿去蹭名气。
Q：GPL 会不会不能商用？ A：能商用，但商用≠闭源随便藏。如果你分发了 GPL 代码或基于它的衍生作品，就得按 GPL 的条件给源码；别把它和“不能赚钱”混为一谈，这种误会在论坛里都能吵出三页楼。
发布前怎么验收：一眼看出有没有选错（⭐⭐⭐⭐）
先用免费/官方路线：GitHub/GitLab 的 LICENSE 模板、SPDX 标记、REUSE 规范，基本能覆盖 80% 场景；真到了企业合规分发，再请律师做一次许可证审阅，别拿“我感觉差不多”硬上，互联网不惯着这个。
新手坑警告：不要混用多个许可证，除非你非常确定是“双许可证”策略。最常见翻车是：README 写 MIT，源码头写 GPL，压缩包里还塞了一个旧 BSD 文本——这叫“许可证三国杀”。
如何验证它真的生效：用下面这条命令扫一遍仓库，确认每个源码文件至少能看到一致的 SPDX 标记：
grep -R "SPDX-License-Identifier" .然后再做一个简单测试：把你的项目发给同事看 30 秒，问他“能不能闭源改、要不要回传改动”。如果对方能答对 80%，说明你写清楚了；如果他开始抓头，那就继续补 README 的 Q&A。
排错树：如果你想“允许别人闭源集成”→选 MIT/BSD；如果你想“改了必须公开”→选 GPL；如果你既想放开又想防背书→BSD；如果你不确定未来商业路线→先别上 GPL，先把边界想清楚。
你要是愿意，把你的项目类型、是否允许商用、是否要求二次开源这三项丢给我，我可以按你的真实场景帮你把许可证一步步落地。至于协作环境或发布流程工具，roxi.cc 只是众多可选项之一，先把许可证选对才是正经事。