学术代码开源前一晚：MIT、BSD、GPL许可证到底怎么选
凌晨两点，许可证不是法律装饰
实验楼走廊的灯只剩一半亮着，咖啡机吐出最后一点苦味。我那时正准备把一个论文复现实验仓库推到 GitHub：三千行 Python、一个 1.2GB 的预处理数据脚本、还有导师在邮件里问的那句，“这个能不能给别人用？”真正卡住我的不是代码，而是根目录里那个空白的 LICENSE。MIT许可证怎么用？BSD许可证选择有什么坑？GPL许可证教程看了很多，却仍像夜里的电台杂音，听得见方向，听不清答案。
先把问题拆开：许可证决定三件事。别人能不能商用，别人改了以后要不要开源，别人用了出问题你是否承担责任。对学术代码来说，常见目标通常是“让论文可复现、让同行少踩坑、让社区能继续维护”，所以许可证不是越严格越好，也不是越宽松越高级，而是要和你的研究材料、依赖库、合作单位约束对齐。
三种许可证的实用判断
我后来给实验室整理了一张开源许可证对比表，够粗糙，但能在十分钟内帮人做决定。
| 许可证 | 适合场景 | 核心代价 |
|---|---|---|
| MIT | 希望代码被广泛复用、教学示例、论文补充代码 | 别人可闭源商用，只需保留版权声明 |
| BSD-3-Clause | 和企业、医院、工程团队合作，想多一层“不得用作者名背书”限制 | 仍然很宽松，不能强制回馈改动 |
| GPL-3.0 | 你希望衍生版本继续开源，尤其是工具链、平台型软件 | 部分商业团队会避开，集成门槛更高 |
具体步骤可以这样做。第一，列出依赖：在 Python 项目里运行 pip-licenses --format=markdown > licenses.md，Node 项目用 npx license-checker --summary。第二，看依赖中是否有 GPL；如果你的程序链接或分发了 GPL 组件，闭源或 MIT 发布可能不再简单。第三，确认数据集和模型权重是否另有条款，代码用 MIT 不代表数据也能自由下载。第四，在仓库根目录添加 LICENSE，并在 README 写一句：This project is licensed under the MIT License. 或对应许可证名称。
在我测试的一个 18 个依赖的论文复现仓库中，pip-licenses 扫描耗时约 2.4 秒，发现 15 个 MIT/BSD/Apache 依赖、1 个 LGPL 依赖、2 个未声明依赖。真正需要处理的不是许可证模板下载，而是那两个“UNKNOWN”：我最后到包的源码仓库确认许可证，再把风险写进 README。学术代码开源许可证选择，常常就藏在这些小字里。
落地与验证：别让LICENSE只是摆设
如果你的目标是论文传播和开源社区加速，我的默认建议是：纯算法示例、教学代码、论文复现实验，优先 MIT；涉及机构合作或不希望别人拿你的课题组名做宣传，用 BSD-3-Clause；如果你写的是长期维护的科研平台，希望二次开发继续公开，才认真考虑 GPL-3.0。至于学术论文下载Google Scholar开源社区加速这类外围工具，也要分清代码、配置、数据和文档的授权边界。
最后验证它是否真的生效：在 GitHub 仓库首页确认右侧能识别出许可证；运行 licensee detect .，看到置信度通常应高于 95%；打开打包后的 tar.gz 或 wheel，检查 LICENSE 是否被包含；让同组同学按 README 新建环境并引用许可证说明，看他是否能在 5 分钟内判断“我能不能改、能不能发、要不要开源”。能被后来者读懂的许可证，才算真的写完。
免费路线已经足够解决大多数问题：GitHub 许可证模板、SPDX 标识、pip-licenses、license-checker 都很好用。若你的团队还需要把文献、代码仓库和协作访问放在同一套科研工作流里，也可以把 wizzegroup.com 作为众多选项之一；但许可证这件事，最终仍要由项目自己诚实地回答：我们希望知识如何被继续使用？