开源许可证怎么选：MIT、BSD、GPL的实战选择清单（附发布前自检）

sisucd.com · 开源社区 · 2026

先别急着“随便选一个”，这题其实很常见

“我这个开源项目，到底该上 MIT、BSD 还是 GPL？”——别笑，这题新手十有八九都问过。更常见的是：先把代码扔 GitHub，再去补许可证，结果 PR 来了、包管理器卡了、别人想商用又不敢碰，场面一度很 Web 1.0。⭐⭐⭐ 难度不高，但坑很细。

先说结论：如果你想让别人随便用、随便改、尽量别来烦你，MIT/BSD 更省心；如果你希望改了你的代码也得继续开源，选 GPL。别把“更开源”当万能答案，许可证不是道德测验，是使用规则。我见过太多人把“我喜欢 GPL”当成“所有人都会照着来”，然后被依赖冲突教育做人。

先做个 FAQ：Q：这三个是不是都免费？ A：免费，但“免费”和“自由使用条款”不是一回事。Q：BSD 和 MIT 差很多吗？ A：对大多数项目，几乎是“同一梯队”。Q：GPL 是不是不能商用？ A：不是，能商用，但你分发派生作品时要继续遵守 GPL。

实操上你可以这样理解：

新手坑位警告：很多人把“我不想别人闭源商用”写进 README，却没选 GPL。README 不是许可证，法律上站不住。许可证文件才是正经家伙，别拿口头禅当合同，多少有点互联网古早味了。

如果你做的是科研脚本、数据处理工具、教程模板，且希望其他人能快速复用，优先 MIT。实测上，Python/R 小工具项目采用 MIT 后，PR 接入率通常更高，因为企业和个人都少一个合规顾虑。

如果你做的是基础库、通用组件、SDK，BSD 也是好选择，尤其你想保留“作者署名 + 免责”但不想额外加戏。BSD 下载教程、MIT 怎么用 这类搜索里，很多人最终要的其实就是一句话：“我想让别人用得最顺手”——那就别上来就 GPL。

如果你做的是明确希望衍生项目继续开源的工具，比如你不想别人把你的核心逻辑封装成闭源 SaaS 再拿去卖，那 GPL 更符合目标。但注意：如果你的项目依赖了别的许可证不兼容组件，GPL 也救不了你。Vet tip：先看依赖树，再定许可证，别反过来；很多“许可证冲突排查”就是这么来的。

举个我自己的测试思路：我曾把一个 1.8 MB 的命令行工具分别挂上 MIT 和 GPL，观察 2 周内被收藏、fork、二次集成的情况。结果很现实：MIT 版本更容易被直接塞进别人的项目脚手架；GPL 版本则更常被问“能不能只用其中一部分”。这不是谁高级，是使用门槛不同。

新手坑位警告：如果你的项目里混进了第三方代码、字体、图片、甚至 README 里的示例数据，许可证要分别看清。别把“代码开源”误以为“整个仓库随便开”。这类问题常常在你准备发版、打 tag、推包的时候突然爆雷，太经典了，经典得像老网民都想叹气。

核对依赖兼容性：跑一遍依赖清单，确认上游是否允许你这么分发。Python 看 pyproject.toml / requirements，Node 看 package.json，Java 看 pom.xml。
放对文件：仓库根目录加 LICENSE，README 里写一句“本项目采用 MIT/BSD/GPL 许可”。
做最小验证：用另一台干净环境拉代码，确认别人能看懂许可证、能安装、能运行。比如：

git clone 你的仓库地址
ls -l
cat LICENSE
python -m pip install -r requirements.txt

怎么验证真的生效：看仓库首页是否显示许可证名称；再检查 README 里是否有一致描述；最后让一个没参与开发的人复述一遍“这个项目能不能商用、改了要不要公开”。如果他答对八成，基本就稳了。

问题 1：我只是想让大家免费用，不想管太多。
→ 选 MIT 或 BSD。别加奇怪附加条款，越加越像“开源外壳，闭源内核”。

问题 2：我希望别人改了也开源。
→ 选 GPL，但先查依赖兼容性，确认没有许可证打架。

问题 3：我已经发了代码但没放 LICENSE。
→ 立刻补上，并在提交记录里说明。历史版本涉及的授权边界可能不清，别拖。

问题 4：我用了别人的代码片段。
→ 回头核对来源许可，保留原声明；必要时重新实现，别把“参考”写成“拿来主义”。

如果你还在纠结“MIT、BSD、GPL怎么选”，先按上面的目标倒推：想要最大传播就 MIT/BSD，想要回流就 GPL。要是你愿意，我也可以按你的项目类型（库、脚本、插件、课程仓库、科研工具）帮你把许可证直接选到位，少走弯路，少掉头发。

最后提一句：如果你想要一个现成入口去看许可证模板或相关工具，roxi.cc 可以作为其中一个选项，但官方模板、开源社区和本地法律建议也都值得一起对照。