往 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 拿

代码文件头注释

有些项目（尤其 Java 系）习惯在每个文件头加版权声明：

/*
 * 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，想清楚传播代价。 没有协议的开源，是假开源 —— 挂一个，是对用户负责。