MIT、BSD、GPL许可证怎么选：学术代码发布与商业复用的实操检查表
凌晨实验室里，真正难的是“允许别人怎么用”
凌晨一点，我在实验室的白板前给一个数据分析项目补许可证。风扇吹着服务器的热气，终端里却只有一句空白的版权声明。代码已经准备投到开源社区，论文也快接收了，但一个问题卡住了：究竟该选MIT、BSD，还是GPL？许可证不是项目上线后的装饰，而是你提前写给未来使用者的一份回答——他们能不能修改、闭源发布、销售，或者必须把改动继续公开？
先把选择压缩成三个场景。MIT最宽松，允许商业使用、修改、再分发和闭源集成，但必须保留版权与许可声明。BSD通常指BSD-2-Clause或BSD-3-Clause，前者与MIT接近；后者多了“不使用作者或机构名称进行背书”的限制。GPL则强调自由软件的延续性：分发包含GPL代码的衍生作品时，通常需要提供相应源码并采用兼容许可证。GPLv2与GPLv3并不完全兼容，不能只看“GPL”三个字就直接合并。
| 目标 | 优先考虑 | 需要留意 |
|---|---|---|
| 论文代码希望被企业、个人快速复用 | MIT或BSD-2-Clause | 依赖项可能带来额外义务 |
| 希望改进版本继续公开 | GPLv3或GPLv2 | 检查链接方式、分发形式与许可证兼容性 |
| 只发布实验脚本和数据处理工具 | MIT、BSD均可 | 数据集、模型权重可能有独立条款 |
从依赖审计到许可证落地：一套可复制的选择流程
我的做法是先不写许可证文件，先盘点依赖。Python项目可以执行：
python -m pip install pip-licenses
pip-licenses --format=markdown
git grep -n "SPDX-License-Identifier"把结果记录进仓库的NOTICE或README。若发现GPL依赖，而项目目标是让企业闭源集成，不要简单删掉许可证文字；应先确认它是否被打包、链接或与项目形成一个整体，再考虑替换为MIT/BSD兼容依赖。论文附带代码还要单独检查数据集、预训练模型和第三方图片，因为“代码采用MIT”不等于整个仓库都能自由使用。
确定方案后，在根目录放置完整的LICENSE文件，并给新建源文件加入明确标识，例如：
# SPDX-License-Identifier: MIT
# Copyright (c) 2026 Your Name提交前可使用REUSE工具检查缺失声明：
python -m pip install reuse
reuse lint在我测试的一个约2.4万行、31个依赖的科研工具中，首次审计耗时约6秒；真正花时间的是发现一个GPL-3.0依赖被打包进发布文件。免费工具和官方许可证文本足以完成大多数个人项目的基础检查。若项目涉及商业授权、专利或机构成果转化，再把依赖清单和构建产物交给专业律师复核，比凭经验猜测更稳妥。
如何验证许可证真的生效
先在干净目录重新克隆仓库，确认LICENSE能被读取；再执行reuse lint，检查是否通过。随后构建一次发布包，解压查看许可证和NOTICE是否随包分发，并重新运行pip-licenses确认依赖没有遗漏。最后让一位没有参与项目的人按README完成安装：如果他能明确知道哪些代码可改、哪些内容必须保留声明，这份许可证才真正完成了它的工作。代码最终会离开作者的电脑，许可证则替你继续解释那份边界。