为什么需要开源许可证
把代码发布到 GitHub，并不意味着其他人就自动获得了自由使用、修改和分发代码的权利。
开源许可证的作用，就是明确告诉其他人：这个项目可以怎么使用、能不能修改、能不能商业使用、修改后是否需要公开源码，以及分发时需要保留哪些声明。
Choose a License 将开源许可证按照限制程度进行了整理，从 GNU AGPLv3、GNU GPLv3、GNU LGPLv3，到 MPL 2.0、Apache License 2.0、MIT License，再到基本没有额外条件的许可证，形成了一个从强 Copyleft 到宽松许可的连续范围。
因此，选择许可证真正需要考虑的不是「哪个许可证最好」，而是：
你希望别人如何使用你的代码？
如果希望别人可以自由使用，包括商业项目和闭源项目，通常应该选择宽松许可证；如果希望衍生作品继续保持开源，则应该考虑 Copyleft 许可证。
开源许可证主要解决什么问题
选择许可证之前，需要先理解几个核心问题。
商业使用
商业使用是很多开发者首先关注的问题。
主流开源许可证通常允许商业使用，包括 MIT、Apache License 2.0、GPL、LGPL、MPL 和 AGPL。区别并不在于「能不能赚钱」，而在于商业使用过程中需要履行什么义务。
例如：
MIT：可以用于商业软件，也可以制作闭源商业软件。
Apache 2.0：可以用于商业软件，并提供明确的专利授权。
GPL：可以用于商业软件，但分发衍生作品时需要遵守 GPL 的开源要求。
AGPL：可以用于商业软件，同时对网络服务场景增加了更强的源码公开要求。
因此，「允许商业使用」并不等于「可以随便闭源」。
修改和再分发
大多数主流许可证都允许修改代码，但对修改后的代码如何发布存在明显区别。
宽松许可证通常允许：
开源项目
↓
修改
↓
加入商业项目
↓
发布闭源版本
而 Copyleft 许可证则通常要求符合条件的衍生作品继续采用相同或兼容的许可证，并提供对应源码。
是否必须公开源码
这是选择许可证时最重要的区别之一。
可以简单理解为：
MIT / Apache 2.0
↓
允许闭源
↓
商业软件可以不公开源码
GPL
↓
Copyleft
↓
符合条件的衍生作品需要开放源码
LGPL / MPL
↓
弱 Copyleft
↓
只对特定范围的修改要求开放
AGPL
↓
强 Copyleft
↓
进一步覆盖网络服务场景
需要注意的是，具体的源码公开义务取决于许可证定义的触发条件，不能简单理解成「用了 GPL 就必须把整个公司所有代码开源」。
先理解两类许可证
实际开发中，可以先把许可证分成两大类。
宽松许可证
典型代表：
MIT
Apache License 2.0
BSD
ISC
它们的共同特点是限制较少。
通常允许：
商业使用
私人使用
修改
分发
创建闭源衍生作品
代价是需要履行较少的许可义务，例如保留版权和许可证声明。
MIT 就是典型代表。Choose a License 对 MIT 的描述非常直接：它允许商业使用、分发、修改和私人使用，主要条件是保留版权和许可证声明。
Copyleft 许可证
典型代表：
GPL
LGPL
AGPL
MPL
Copyleft 的核心思想是：
允许你使用和修改，但希望你在满足特定条件后继续开放修改成果。
不同许可证的「开放范围」不同。
因此 Copyleft 并不是一个许可证，而是一类许可证设计思想。
MIT：最简单的选择
如果你只是希望：
「我的代码开源，大家可以自由使用，商业项目也可以直接使用，不希望增加太多限制。」
那么 MIT 通常是最简单的选择。
MIT 允许：
商业使用
私人使用
修改
分发
再许可
销售
同时主要要求保留版权和许可证声明。
例如一个 PHP 开源组件：
OpenSource PHP Library
↓
MIT
↓
个人项目 ✓
商业项目 ✓
修改代码 ✓
二次分发 ✓
闭源商业软件 ✓
MIT 最大的优势就是简单。
如果你维护的是：
PHP 库
JavaScript 工具
Vue 组件
CLI 工具
开发者工具
小型框架
示例项目
学习项目
并且没有特别强的「必须保持开源」诉求，MIT 往往是非常合适的默认选择。
Apache License 2.0：需要关注专利时的选择
Apache License 2.0 同样属于宽松许可证，但相比 MIT，它对专利问题提供了更加明确的处理机制。
Apache 2.0 允许：
商业使用
修改
分发
私人使用
创建闭源衍生作品
同时要求保留版权和许可证声明，并包含修改声明等条件。更重要的是，贡献者明确授予专利权。
因此可以简单理解：
MIT
↓
简单、短小、限制少
Apache 2.0
↓
同样宽松
+
更明确的专利授权机制
如果你的项目涉及：
大型企业
基础设施
云计算
数据库
网络协议
分布式系统
大型商业组织参与贡献
Apache 2.0 往往比 MIT 更值得认真考虑。
例如 Kubernetes、很多云原生基础设施项目都会采用 Apache 2.0 或相关许可证体系。
GPL：希望衍生作品继续开源
GPL 的核心目标与 MIT、Apache 2.0 不同。
MIT 和 Apache 2.0 更强调：
「尽可能自由地使用。」
GPL 更强调：
「你可以自由使用，但符合条件的衍生作品也应该继续保持开放。」
Choose a License 将 GPLv3 定义为强 Copyleft 许可证。它允许商业使用、分发、修改和私人使用，但要求符合条件的衍生作品公开源码并采用相同许可证，同时保留版权和许可证声明。
因此：
GPL 项目
↓
修改
↓
形成符合 GPL 条件的衍生作品
↓
继续 GPL
↓
提供对应源码
这使 GPL 非常适合希望保护开源生态的项目。
如果你的目标是：
「任何人都可以使用我的代码，但不能拿走以后闭源，同时希望改进成果继续回到开源社区。」
那么 GPL 是一个值得考虑的选择。
LGPL：适合希望被其他软件使用的库
LGPL 可以理解为一种「更温和的 Copyleft」。
它仍然要求 LGPL 覆盖的库及其修改遵守相应的开源要求，但允许更大的作品通过库提供的接口使用该库，并以不同许可证发布更大的作品。
可以简单理解：
LGPL Library
↓
商业软件
↓
调用 Library
↓
商业软件本身
可以保持其他许可证
因此 LGPL 经常适用于：
通用库
SDK
系统组件
底层软件
希望被大量商业软件集成的组件
它试图在「保护库本身的开源性」和「方便商业软件使用」之间取得平衡。
MPL 2.0：按文件进行 Copyleft
Mozilla Public License 2.0 是一种弱 Copyleft 许可证。
它的一个重要特点是：
Copyleft 主要作用于被许可证覆盖的文件。
MPL 2.0 要求被许可文件及其修改版本提供源码，但使用这些文件构建的更大作品可以采用其他许可证，并且新增文件不必自动采用 MPL。
例如：
项目
├── core.js → MPL
├── utils.js → MPL
├── application.js → 其他许可证
└── business.js → 其他许可证
这与 GPL 的整体 Copyleft 思路存在明显区别。
因此，如果你希望：
「我修改的核心文件继续开源，但允许其他代码与它组合形成闭源软件。」
MPL 2.0 是值得考虑的方案。
AGPL：特别关注网络服务场景
AGPL 可以理解为 GPL 的更强版本。
它除了包含 GPL 的 Copyleft 思路之外，还特别针对网络服务场景增加了源码提供要求。
例如：
用户
↓
Web API
↓
AGPL 软件
↓
服务器运行
如果你修改 AGPL 软件，并通过网络向用户提供服务，在满足许可证规定的条件时，需要向用户提供对应修改版本的完整源码。
这也是 AGPL 与 GPL 最值得关注的区别之一。
如果你的目标是：
「我不希望别人拿我的开源项目修改一下，然后放到服务器上提供 SaaS 服务，却完全不把修改成果开放出来。」
那么 AGPL 值得考虑。
但 AGPL 对商业公司和 SaaS 产品的约束也更强，因此不应该仅仅因为「开源」两个字就直接选择 AGPL。
常见许可证对比
把常见许可证放在一起，可以更直观地理解：
| 许可证 | 商业使用 | 允许闭源 | Copyleft | 专利授权 | 网络服务源码要求 |
|---|---|---|---|---|---|
| MIT | ✓ | ✓ | 无 | 无明确专利授权条款 | 无 |
| Apache 2.0 | ✓ | ✓ | 无 | ✓ | 无 |
| BSD | ✓ | ✓ | 无 | 视具体许可证 | 无 |
| MPL 2.0 | ✓ | ✓ | 文件级 | ✓ | 无 |
| LGPL 3.0 | ✓ | 有条件 | 弱 | ✓ | 无 |
| GPL 3.0 | ✓ | 有条件 | 强 | ✓ | 一般无 AGPL 式网络触发 |
| AGPL 3.0 | ✓ | 有条件 | 更强 | ✓ | ✓ |
这张表适合快速判断，但不能替代具体许可证文本。尤其是 GPL、LGPL、MPL 和 AGPL，实际项目中的「衍生作品」「组合」「分发」「网络服务」等概念需要结合许可证原文判断。
如何选择许可证
实际项目不需要从几十种许可证开始研究。
可以先回答几个问题。
我允许别人做闭源商业软件吗
如果答案是「是」：
MIT
Apache 2.0
BSD
MPL
LGPL
都可以进入候选范围。
如果答案是「否」，应该优先考虑：
GPL
AGPL
我是否特别关注专利
如果项目涉及专利风险或者企业级基础设施，Apache 2.0、GPLv3、LGPLv3、MPL 2.0、AGPLv3 等包含明确专利授权机制的许可证值得重点考虑。
如果项目非常简单，并且你更关注许可证的简洁程度，MIT 通常更加直接。
我是否希望 SaaS 服务也开放修改
如果答案是「是」，AGPL 应该进入重点考虑范围。
如果只是希望：
「发布软件时，修改后的软件继续开源。」
GPL 通常已经能够满足这种诉求。
我维护的是一个库还是一个完整应用
这是一个非常实用的判断维度。
对于：
Library / SDK / Framework
通常更关注「别人能否方便集成」。
因此：
MIT
Apache 2.0
LGPL
MPL
比较常见。
对于：
完整应用 / 服务端软件
如果希望修改成果继续开源：
GPL
AGPL
通常更值得考虑。
一个实用的选择决策树
如果不想研究复杂的许可证条款，可以先按照下面的流程判断：
开源项目
│
▼
是否允许闭源商业使用？
│ │
是 否
│ │
▼ ▼
是否关注专利？ GPL / AGPL
│ │
是 否
│ │
▼ ▼
Apache 2.0 MIT
如果允许闭源，但又希望对自己的核心文件保持 Copyleft：
允许闭源
│
├── 希望文件级开源 → MPL 2.0
│
└── 希望库保持开源 → LGPL
如果是 SaaS 场景，并且希望网络服务也受到源码开放要求约束：
SaaS / Web Service
│
▼
AGPL
这套决策方式并不是法律上的许可证判定，只适合作为工程选型的第一步。
开源项目最常见的选择
对于个人开发者和普通开源项目，可以把选择进一步简化。
个人项目
如果只是希望：
「代码开源，别人随便使用。」
优先考虑：
MIT
企业基础设施
如果项目涉及企业、云计算、基础设施或者专利问题：
Apache 2.0
通常是值得优先考虑的方案。
希望衍生项目继续开源
选择：
GPLv3
开源库，但允许商业软件自由集成
可以考虑：
LGPLv3
希望核心文件保持开源，但允许组合成闭源产品
可以考虑：
MPL 2.0
开源 SaaS / 服务端项目
如果希望修改版本即使通过网络提供服务，也需要履行源码开放义务：
AGPLv3
不选择许可证会发生什么
这是很多 GitHub 项目容易忽略的问题。
如果一个项目没有明确声明许可证，不能简单理解为：
「GitHub 上公开了，所以大家可以随便用。」
「公开可见」和「授予开源许可」是两个不同概念。
因此，如果希望其他开发者明确知道项目可以如何使用，应该在项目根目录增加：
LICENSE
或者：
LICENSE.txt
并放入完整的许可证文本。
以 MIT 为例，Choose a License 建议在源代码根目录创建 LICENSE 或 LICENSE.txt，然后将许可证文本复制进去，并填写年份和版权持有者信息。
例如：
LICENSE
README.md
composer.json
src/
tests/
同时可以在 README 中明确说明：
## License
This project is licensed under the MIT License.
如果使用 Apache 2.0、GPL、LGPL、MPL 或 AGPL，也应该使用对应许可证的完整官方文本，而不是自己重新编写一份「简化版」。
开源许可证与依赖许可证
还有一个非常重要的问题：
你的项目许可证不能脱离依赖许可证单独考虑。
例如一个 PHP 项目：
你的项目
├── package A
├── package B
├── package C
└── package D
这些依赖可能分别采用：
MIT
Apache 2.0
BSD
LGPL
GPL
因此，在确定项目许可证之前，应该检查项目依赖。
尤其需要关注：
GPL
AGPL
LGPL
等具有 Copyleft 特征的许可证。
对于 PHP 项目，可以检查：
composer licenses
也可以结合 Composer 依赖管理工具和 CI 流程，对第三方依赖的许可证进行持续检查。
不要出现：
项目使用 MIT
↓
直接引入 GPL 组件
↓
没有检查许可证兼容性
↓
最终才发现许可证存在冲突
许可证兼容性属于工程发布流程的一部分，而不是项目上线前才临时处理的问题。
如何给 GitHub 项目添加许可证
最简单的方式是在项目根目录添加：
LICENSE
例如使用 MIT：
LICENSE
README.md
composer.json
src/
tests/
LICENSE 文件内容使用完整的 MIT License：
MIT License
Copyright (c) [year] [auth]
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction...
实际项目中不要手动修改许可证正文，只需要按照许可证要求填写版权信息即可。
GitHub 也可以在创建仓库时直接选择许可证，或者后续添加 LICENSE 文件。
如果使用 GitHub 的许可证识别功能，项目根目录中的标准许可证文件也更容易被平台和其他开发者识别。
不要自己设计开源许可证
如果只是个人项目或者普通企业开源项目，没有必要自己设计一个：
Leanku Open Source License
然后规定：
允许个人使用
禁止商业使用
允许修改
禁止 SaaS
必须保留作者头像
……
这种许可证虽然可以表达自己的意图，但很容易产生兼容性、法律解释和社区接受度问题。
更合理的方式是：
明确项目目标
↓
选择成熟许可证
↓
使用官方许可证文本
↓
检查第三方依赖
↓
在 README 中说明
对于绝大多数项目，MIT、Apache 2.0、MPL 2.0、LGPL、GPL、AGPL 等成熟许可证已经覆盖了绝大多数常见需求。Choose a License 也明确指出，这些许可证覆盖了从高度保护性到宽松许可的主要范围，其中一种通常可以适用于新的开源项目。
最终应该怎么选
如果不考虑特殊法律或商业约束，可以记住下面这张表：
| 你的目标 | 推荐考虑 |
|---|---|
| 最简单，允许别人随便使用 | MIT |
| 宽松许可，同时重视专利授权 | Apache 2.0 |
| 希望衍生软件继续开源 | GPLv3 |
| 开源库，希望商业软件方便使用 | LGPLv3 |
| 希望修改过的文件继续开源 | MPL 2.0 |
| 希望 SaaS 修改版本也需要开放 | AGPLv3 |
最常见的两个选择其实非常明确：
不知道选什么
↓
MIT
希望更完整地处理专利问题
↓
Apache 2.0
希望保护开源成果
↓
GPL
希望限制 SaaS 闭源使用
↓
AGPL
因此，对于大多数个人开发者维护的 GitHub 项目，我通常建议先从 MIT 和 Apache 2.0 中选择；如果项目本身明确要求衍生作品继续开源，再考虑 GPL、LGPL、MPL 或 AGPL。
最后需要强调的是，许可证选择涉及法律权利和义务。本文适合作为工程选型参考，不构成法律意见；对于商业产品、闭源产品集成、复杂依赖关系或企业级开源项目，应结合具体许可证原文和专业法律意见进行判断。