开源许可证怎么选

约 1160 字大约 4 分钟

2026-10-21

资源

往 GitHub 上传项目，仓库右侧那个 License 空着，总感觉差点什么。但真点下去，几十种许可证列出来， MIT、Apache、GPL、BSD、MPL……每个都认识，连起来就不知道选啥。

这篇用最少的话讲清楚区别，再给选择建议。

声明：我不是律师，以下是程序员视角的实用总结。真遇到商业纠纷，请找专业法务。

一、没有许可证 = 默认「保留所有权利」

先泼冷水：GitHub 上没写许可证的开源项目，法律上不等于开源。别人理论上不能随便用、改、分发 —— 虽然现实中大家都在用，但这就是颗定时炸弹。选个许可证挂上，既是保护用户，也是保护自己。

二、最常见的三种，一张表看懂

	MIT	Apache 2.0	GPL 3.0
他人使用	随便用	随便用	随便用
他人修改后闭源	可以	可以	不行
商用	可以	可以	可以
必须保留版权声明	是	是	是
专利授权	没明确说	明确授予	明确授予
修改后是否必须开源	不要求	不要求	必须同样协议开源
严格程度	最松	中等	最严

一句话版：

MIT：你用你随便，署个名就行，改出花也不管；
Apache 2.0：MIT 的宽松 + 明确管了专利的事；
GPL：用我的可以，但你改出来的东西也得开源，而且协议得一样（传染性，所以叫「病毒式协议」）。

图：按「你想要什么」走，三步选到答案

三、其他几种，简单认识

BSD：和 MIT 差不多，多个变体要求保留广告出处，现在基本被 MIT 平替；
MPL 2.0（Mozilla）：文件级 Copyleft，改这个文件才开源这个文件，比 GPL 温和。Firefox 用它；
AGPL：GPL 的加强版，连「通过网络提供服务」都算分发，SaaS 用了也得开源。数据库圈爱用它防云厂商白嫖；
Unlicense / CC0：直接放弃版权，公共领域，最彻底。

四、怎么选：看你的目的

想让最多人用（工具库、脚手架、组件）

选 MIT。最宽松，争议最少，npm 生态的绝对主流。用户不用看协议就能用，传播阻力最小。

担心专利问题（公司项目、可能涉及硬件的）

选 Apache 2.0。它明确给了专利授权，还处理了「专利诉讼导致授权失效」的条款。大公司出的项目（Kubernetes、TensorFlow）基本都用它。

坚持「改了必须回馈社区」（理想主义）

选 GPL 3.0。适合你真的想让改进流回社区的场景。代价：很多商业公司看到 GPL 会绕道，传播会受影响。

不想被云厂商白嫖（开源数据库、中间件）

选 AGPL。堵住「改改当 SaaS 卖但不回馈」的路。但小项目用这个，商业用户会被吓跑，慎选。

完全不在乎，就想放出来

选 Unlicense 或者 MIT。Unlicense 更洒脱， MIT 更主流（大家熟悉，工具链支持好）。

五、实操：给项目加许可证

GitHub 网页操作

仓库首页 → Add file → Create new file → 文件名输入 LICENSE（或 LICENSE.md）→ 右侧会弹出 Choose a license template 按钮 → 选一个 → 自动生成标准文本 → Commit。

命令行操作

# 有 gh CLI 的话
gh repo edit --add-topic opensource

# 或者手动：把选好的协议文本写进 LICENSE 文件
curl -sSL https://spdx.org/licenses/MIT.txt -o /dev/null  # 协议全文可从 SPDX 拿

代码文件头注释

/*
 * Copyright 2026 精华社
 * SPDX-License-Identifier: Apache-2.0
 */

SPDX-License-Identifier 是机器可读的标准写法， CI 里能自动检查，大项目推荐。

六、给项目选依赖时反过来看

选自己的协议是一回事，选别人的依赖是另一回事：

闭源商业项目里，别直接 GPL 依赖（传染性会要求你开源，这是法务红线）；
MIT/Apache/BSD 依赖随便用，保留声明即可；
分不清的，问一句 npm ls + 看每个包的 LICENSE 文件，或者用 license-checker 一键列出所有依赖的协议：

npx license-checker --summary

小结

个人玩具项目：MIT，无脑选，不出错。公司项目：Apache 2.0，专利条款说得清。理想主义社区：GPL，想清楚传播代价。没有协议的开源，是假开源 —— 挂一个，是对用户负责。

开源许可证怎么选

公告