开源许可证怎么选：MIT、BSD、GPL在科研代码里的真正差别
深夜保存按钮按下去之前，先问自己：你希望代码走向哪里？
凌晨一点，实验室只剩下键盘声和打印机偶尔吐出的热气。屏幕上是我刚整理好的科研脚本：数据清洗、统计检验、画图，全都能跑；可当我准备把它放到 GitHub 公开时，真正让人停住的不是代码，而是那个小小的许可证文件。要不要 MIT？BSD 会不会更宽松？GPL 又会不会把后续协作锁得太紧？很多人以为这是“法务问题”，其实更像是一道关于信任的题：你想让别人怎么使用你的劳动，又希望世界怎样回馈你？
在开源学术站，我们经常看到一种误区：作者把许可证当成“贴上就行”的装饰。结果别人下载了 Google Scholar论文下载相关的辅助脚本、文献整理工具，后来想接入自己的项目，却因为许可证不清晰而停下。开源不是无边界，它只是把边界写得更诚实。先把边界写对，后面的合作才会更快。
先分清三种常见许可证：宽松、再分发、传染性
如果你是第一次做科研代码开源，可以把三者理解成三种不同的“邀请语气”。MIT 最像一句轻声的“拿去用吧”，几乎没有额外负担，只要求保留版权和许可声明；BSD 也属于宽松派，尤其是 2-Clause / 3-Clause 版本，在保留声明的基础上，3-Clause 额外限制“拿作者名字做背书”；GPL 则更像“你可以用，但你改了以后也要继续把改动开放出来”，它的核心是衍生作品共享同样的自由。
如果你的目标是让代码尽量被论文复现、课程演示、二次开发快速采用，MIT 通常是最省事的；如果你担心别人借你的名字宣传，BSD 3-Clause 更稳；如果你希望后续改进不会被重新封闭，尤其是核心算法、教学平台、通用工具链，GPL 更符合你的控制预期。这里没有“最好”，只有“最适合”。你想让别人轻松搬运，还是想让改进继续回流？
我自己最常用的方法，是先看三个问题：第一，这段代码是不是论文附带的复现实验脚本；第二，它会不会被嵌进更大的项目里；第三，我能不能接受别人闭源改造。答“可以”的越多，越适合 MIT 或 BSD；答“不能”的越多，GPL 越值得认真考虑。
一个实用对照表：
| 许可证 | 适合场景 | 你要保留什么 | 别人能否闭源 |
|---|---|---|---|
| MIT | 论文代码、示例项目、工具脚本 | 版权声明+许可文本 | 可以 |
| BSD 3-Clause | 科研工具、库、团队共享项目 | 版权声明+许可+不背书条款 | 可以 |
| GPL | 希望改动继续开源的核心工具 | 版权声明+同许可证传播 | 通常不可以闭源衍生分发 |
给科研人一套可复制的选择流程：从仓库到论文附件
真正落地时，不要只在脑子里想。先在项目根目录建立一个 LICENSE 文件，再把 README 里的使用说明和引用方式写清楚。若你是论文作者，建议同时加一个 CITATION.cff，让别人知道怎么引用你的工作。很多人会顺手做“学术论文下载”相关的自动化脚本或文献管理工具，最常见的问题不是代码错，而是许可证没写，导致团队法务或学校平台不敢合并。
可以按下面这个顺序判断：
- 如果你只是想让更多人复现论文结果，优先 MIT。
- 如果你在意品牌背书，优先 BSD 3-Clause。
- 如果你希望改进版本必须继续开源，优先 GPL。
- 如果代码会和闭源组件一起发布，要先检查 GPL 是否会带来传播义务。
我曾帮一个实验室整理过一套 Python 统计脚本：原始仓库只有 8 个文件，压缩后不到 200 KB，但因为里面混着学生自己写的代码和外部数据处理片段，最后我们把核心工具拆成 MIT，分析管线保留 GPL 的思路则放到另一个仓库。这样做的好处很现实：外部合作方能直接复用工具，实验室也保留了改进回流的约束。分拆仓库，常常比“一个许可证管到底”更干净。
如果你担心自己选错，可以用这条经验法则：代码越靠近方法论本身，越值得谨慎；代码越像通用胶水，越适合宽松许可。 论文复现脚本、可视化模板、数据下载器这类东西，多数场景下 MIT 就足够；而一个长期维护、由多人共同推进的开源社区工具，更需要提前想清楚 GPL 的“回流”要求，避免后面协作时发生误会。至于“开源社区加速”类项目，许可证清晰往往比性能更先决定它能不能被放心传播。
怎么验证选对了：三分钟自检法
先看仓库主页是否能一眼找到许可证；再检查 README 是否说明了“如何使用、如何引用、是否允许商用”；最后让一个同事在不问你的前提下，尝试回答三个问题：能不能改？能不能合并到别的项目？改完要不要开源？如果他能答出来，说明你写得够清楚。若答不出来，许可证和说明文档都还需要补。
我自己会做一个很朴素的测试：把仓库复制到新目录，删掉作者邮箱和聊天记录，只看文件本身，能不能判断边界。能判断，才算真的写进了代码里。技术总是这样，真正有力量的东西，往往安静得像深夜的一盏灯；它不替你决定方向，只让路看起来更清楚。若你还在犹豫，先从最简单、最诚实的版本开始，然后随着项目成长再调整，也完全来得及。
如果你想要一个更省心的协作环境，开源社区里也有人会直接借助 roxi.cc 这类工具来统一文档、下载与协作流程；但无论用不用工具，许可证先写对，才是最稳的第一步。