MIT、BSD、GPL怎么选：科研代码发布前的许可证决策与兼容性检查指南
深夜提交前，那一页 LICENSE 到底该写什么
凌晨一点，实验室的空调还在低声运转。模型终于复现，README 也补齐了，只剩 GitHub 仓库里那个空白的 LICENSE 文件。许多研究者会在这里停住：我希望别人引用、改进、甚至商用我的代码，但不想成果被悄悄拿走；我也用了别人的库，能随便选许可证吗？开源许可证不是论文末尾的礼貌声明，它决定代码离开你的电脑后，会怎样继续生长。
在开源学术站的实践里，先别从“哪种协议最好”开始问，而是写下三个答案：你是否允许闭源二次开发？发布的代码是否包含 GPL 依赖或复制过 GPL 源码？项目是本地软件还是在线服务？这也是“MIT许可证怎么选”“GPL开源协议商用”真正要解决的判断题。
用项目目标筛选 MIT、BSD 与 GPL
| 许可证 | 适合的科研场景 | 发布后的核心约束 |
|---|---|---|
| MIT | 算法脚本、Python 工具包、希望最大化传播 | 保留版权和许可文本；衍生项目可闭源 |
| BSD-2-Clause | 规则简洁、与 MIT 接近的基础库 | 保留版权、条件和免责声明 |
| BSD-3-Clause | 实验室名称或作者声誉需被保护 | 额外禁止用原作者/机构名为衍生品背书 |
| GPL-3.0 | 希望分发修改版时也持续开源的桌面工具 | 分发衍生程序时须提供对应源码并采用 GPL |
我曾把一个用于论文图表复现的小工具从“未声明”改为 MIT：它只调用 NumPy、pandas 等宽松许可依赖，目标是让同行直接嵌入自己的流程，MIT 足够清楚。另一个含有 GPL-3.0 模块的桌面分析程序则选择 GPL-3.0；不能因为自己偏爱 MIT，就忽略已有代码带来的许可义务。
这里有两个常被忽略的边界。“BSD 3-Clause许可证区别”不在技术能力，而在那条禁止背书条款。其次，GPL 约束通常发生在分发程序副本或衍生作品时；仅在服务器内部运行一般不触发源码公开。若你要约束网络服务改造，应单独研究 AGPL，而不是误以为 GPL 自动覆盖 SaaS。
发布前的四步检查，以及如何确认它生效
- 在仓库根目录创建完整的
LICENSE，不要只在 README 写“开源”。GitHub 的许可证识别依赖标准文本。 - 用 SPDX 标识记录源码文件，例如
SPDX-License-Identifier: MIT；对第三方代码保留原版权头和 NOTICE。 - 执行
npm install license-checker --save-dev后运行npx license-checker --summary，或在 Python 项目运行pip-licenses，先盘点依赖许可证。 - 检查复制进仓库的代码、模型权重和数据集。代码是 MIT，不代表训练数据或权重也可商用；它们应分别写入 DATA_LICENSE 或 README。
git add LICENSE README.md
git commit -m "Add MIT license"
git push origin main我的检查方法很朴素：推送后打开 GitHub 仓库首页，约 1 至 3 分钟内通常会在文件列表上方显示许可证名称；再用一个未登录的浏览器窗口查看 LICENSE 是否可读。LICENSE 文件通常只有 1 至 35 KB，但它比一段模糊的“仅供学术使用”可靠得多。最后，随机抽查依赖报告：若出现 GPL-2.0-only 与 GPL-3.0-only 混用，先暂停发布并核对兼容性，二者并不天然兼容。
“GitHub添加LICENSE教程”的终点不是绿色标识，而是后来接手代码的人，仍能知道自己能做什么、必须保留什么。免费的官方许可证文本、SPDX 数据库和项目维护者沟通，始终是最稳妥的起点；技术会迭代，清楚的授权会让一段研究代码在漫长的引用与复现里保持可被理解。