开源许可证怎么选：给项目加 LICENSE 的实用指南

很多人把开源理解成「公开放上 GitHub 就行」，其实差得远。一个没有 LICENSE 文件的仓库，在法律上适用的是默认版权法，意思是除了作者本人，任何人都不能合法复制、修改或分发这份代码，哪怕它就明晃晃挂在公开仓库里。换句话说，不加许可证不等于慷慨，反而等于把所有人挡在门外。

这篇文章把常见的几种开源许可证讲清楚，再说怎么给项目加上正确的 LICENSE，以及商用时要留意的几条。

宽松型和 Copyleft，先分清这两派

所有主流开源许可证，本质上分成两大阵营，搞懂这条分界线，剩下的选择就不难了。

宽松型许可证，代表是 MIT、Apache-2.0、BSD、ISC。它们的态度很简单：你可以用、可以改、可以拿去卖、可以闭源，只要保留原来的版权声明就行。别人把你的代码塞进一个收费的商业软件里，也完全合规。

Copyleft 许可证，代表是 GPL-3.0 和 MPL-2.0。它的核心是「自由要往下传」：谁分发了你的代码或它的衍生作品，谁就得继续以相同条款开源。GPL-3.0 是强 Copyleft，整个程序都得保持 GPL；MPL-2.0 弱一些，以文件为单位，只有你改动过的文件需要开源。这就是为什么有人把 GPL 形容成「有传染性」，引一段 GPL 代码进来，整个项目可能被迫一起开源。

MIT 和 Apache 2.0 差在哪

这两个都是宽松型，放在一起最容易混。我自己给小工具选许可证时，几乎条件反射地写 MIT，因为它真的就三小段，读一遍不超过一分钟。

来看 MIT 许可证的关键条款长什么样：

Copyright (c) 2026 张三

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software ... to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software ...
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND ...

核心就两件事：保留这段版权声明，以及作者不担保。给你授权几乎所有事，自己不背锅。

Apache-2.0 在这之上多了两样东西：一是明确的专利授权，贡献者不能事后拿自己贡献过的代码里的专利反过来告用户；二是 NOTICE 要求。所以判断标准很清晰：纯个人小库，MIT 更省事；只要涉及公司、或者专利可能成为隐患，选 Apache-2.0 更稳。

怎么给项目加 LICENSE

加许可证的动作本身很轻，难的是选对，以及放对位置。

第一步，用 开源许可证生成器 选一种许可证，填上版权年份和持有人姓名（或公司名），它会实时把占位符替换好，给你一份可直接保存的文本。第二步，把它存成名为 LICENSE 的文件，没有扩展名，放在仓库根目录、和 README 并排。GitHub、GitLab 和 npm 都会自动识别这个文件名，在项目页显示出对应的许可证标记。

很多人栽在文件名上：放在 docs 目录里叫 license.txt 的文件，既不会显示标记，也不会被工具识别。如果还想让包元数据也识别，记得把 SPDX 编号（如 MIT 或 Apache-2.0）填进 package.json、Cargo.toml 这类清单的 license 字段。新建仓库时顺手再配个 .gitignore 文件，把构建产物和密钥挡在版本库外，一并把仓库的基础卫生做好。

商用前必须确认的几条

如果你的代码要进商业产品，或者你在引用别人的开源库，下面几点务必先看。

一是依赖的传染性。把一段 GPL 代码引进一个本来打算闭源的项目，你的项目可能被迫整体变成 GPL，发布前一定要核对每个依赖的许可证是否兼容，别等产品上线才发现。二是专利风险。涉及公司的项目，Apache-2.0 的专利条款是实实在在的保护，别图省事用 MIT。三是别留空白：没有 LICENSE 的仓库默认全保留权利，在邀请贡献者或开放使用之前，先生成一份并提交。

一句话选型

想被最大范围采用、不附条件，选 MIT 或 ISC；在意专利、要进公司内部，选 Apache-2.0；希望每个 fork 都继续开源，选 GPL-3.0；想彻底把代码送出去、不留任何权利，选 Unlicense。先想清楚你希望别人能拿你的代码做什么，再回头看许可证，答案往往就出来了。

---

Made by Toolora · Updated 2026-06-13