按约束强度分类：宽松型（Permissive）→ 弱著佐权（Weak Copyleft）→ 强著佐权（Strong Copyleft）。约束越强，衍生作品被要求开源的范围越大。
分类总览
| 分类 | 代表许可证 | 核心约束 | 可闭源分发 |
|---|---|---|---|
| 宽松型 Permissive | MIT、BSD、Apache 2.0 | 仅需保留版权声明 | ✅ |
| 弱著佐权 Weak Copyleft | LGPL、MPL 2.0、EPL | 修改「库/文件本身」需开源，调用方可闭源 | ⚠️ 部分可 |
| 强著佐权 Strong Copyleft | GPL v2/v3 | 分发 GPL 及其衍生组合时必须提供对应源码并遵守 GPL 条款 | ❌ |
GPL 并不禁止商业使用或收费分发（收费卖 GPL 软件的拷贝是允许的），限制点在”分发时必须提供源码、衍生作品必须同样以 GPL 授权”。实际工程中”是否构成衍生作品”还需区分动态链接、进程间通信/RPC、插件接口、mere aggregation（仅打包在一起但不构成衍生）等边界情形，边界判定比表格里的一句话结论复杂，具体场景建议查阅 GNU Selling Free Software 及 FSF 的 GPL FAQ。
宽松型（Permissive）
MIT
被授权人可自由使用、复制、修改、合并、出版、散布、再授权及贩售软件及副本，唯一义务是在软件及所有副本中保留版权声明和许可声明。
- 与 GPL 兼容，也是自由软件基金会（FSF）认可的自由软件许可证
- 相比 BSD 三条款版本，条件更少、限制更宽
- 代表项目：PuTTY、X11、Expat、Ruby on Rails、Lua 5.0+
举例：React、Vue.js、jQuery、Node.js 均使用 MIT，是目前 GitHub 上使用最广泛的许可证之一，原因是限制最少、法务审核成本最低。
BSD
原始 BSD（4-clause）要求在文档中列出贡献者鸣谢；现代变体已简化：
- 2-clause BSD：仅保留版权声明和免责声明，去掉了鸣谢条款和”不得用组织名称做推广”条款，功能上等价于 MIT。NetBSD 自 2008-06-20 起采用此版本
- 3-clause BSD：在 2-clause 基础上增加”不得使用版权方名称做推广”条款，FreeBSD 使用的即为此类变体
- BSD 不允许受让方将许可证本身删除或替换为其他许可证
举例：FreeBSD、OpenBSD 内核本身，Go 语言标准库（BSD-3-Clause）。与 MIT 相比，BSD 三条款版本多一句”不得用组织名称做推广”，实际使用体验和 MIT 几乎一致。
Apache License 2.0
- 允许派生作品使用不同许可证发布（不强制”传染”），但要求：
- 保留原始版权、专利、商标、归属声明
- 修改过的文件需注明”已变更”
- 显式专利授权条款：贡献者对其贡献自动授予专利许可，这是与 MIT/BSD 最大的实质区别，也是企业更偏好 Apache 2.0 的主因
- 与 GPLv2 不兼容（专利条款冲突），与 GPLv3 兼容
举例：Kubernetes、TensorFlow、Android（AOSP 大部分组件）、Apache 系全家桶。企业对外开源自研项目时的默认首选，专利条款能降低被专利诉讼反噬的风险。
MIT/BSD vs Apache 2.0 关键差异：MIT/BSD 更短更简单，但完全没提专利；Apache 2.0 条款更长，换来了明确的专利授权与专利报复条款（贡献者若对使用者发起专利诉讼，会丧失其被授予的专利许可）。
弱著佐权（Weak Copyleft）
LGPL（GNU Lesser General Public License）
- 允许企业/开发者将 LGPL 库集成进私有软件而不必开源整体
- Copyleft 限制不会”感染”仅链接到该库的程序，但对库本身的修改仍需开源
- 前身为 GNU Library General Public License；主要版本 LGPLv2、LGPLv2.1、LGPLv3
- 典型用途：软件库（如 FFmpeg、Qt、OpenOffice.org 曾用此协议）
常见行为对照表
以某 LGPL 开源项目为例，梳理常见操作是否允许：
| 行为 | 可以吗 | 需要注意什么 |
|---|---|---|
| 下载源码自己用 | ✅ 可以 | 没有问题 |
| 自己部署运行 | ✅ 可以 | 不需要开源自己的业务代码 |
| 修改源码自己内部使用 | ✅ 可以 | 不发布出去就没有额外义务 |
| 商业使用（收费提供服务） | ✅ 可以 | LGPL 不禁止商业使用 |
| Fork 后继续开发 | ✅ 可以 | 保留原 License |
| 修改后发布给别人 | ✅ 可以 | 修改部分必须继续以 LGPL 开源 |
| 引用其中少量代码到自己项目 | ⚠️ 可以，但有条件 | 可能受 LGPL 影响，需保留版权声明等 |
| 把整个项目改成闭源出售 | ❌ 不行 | 不能去掉 LGPL，也不能阻止别人获得源码 |
允许商业使用，例如：收费提供 API、收会员费、收部署服务费、收运维费。
允许修改源码，例如：增加新的 Provider、修改 UI、改调度算法、增加自己的接口。
什么不能做：
- ❌ 去掉 License
- ❌ 改成自己的 License
- ❌ 不提供修改后的源码
动态链接是 LGPL 的关键设计
LGPL 之所以能”链接不感染”，前提通常是动态链接（dynamic linking）而非静态链接进最终二进制：
- FFmpeg：默认构建（不启用
--enable-gpl）是 LGPL 2.1+，允许闭源商业项目动态链接使用；一旦启用 x264/x265 等 GPL 编码器，整个构建就变成 GPL，不再是”可选”而是”污染” - Qt：采用 LGPL + 商业双授权模式——用 LGPL 版本需动态链接、允许用户替换 Qt 库、公开使用的 Qt 版本；商业授权通常更适合闭源/静态链接场景，具体条款以商购协议为准
MPL 2.0（Mozilla Public License）
- 文件级（File-level）copyleft：只有你修改过的、原本以 MPL 授权的文件需要继续以 MPL 开源；你新增的文件可完全闭源或用其他协议
- 融合了 BSD 与 GPL 的特性，试图在专有软件与开源社区诉求之间取得平衡
- 专利授权：MPL 2.0 正文 2.1(b) 条款包含贡献者对其贡献的专利授权，并配有相应的专利终止条件（若发起专利诉讼可终止该授权），并非”不涉及专利限制”；但不授予开发者商标使用权
- 若与 GPL/LGPL/AGPL 授权代码结合，可选择改用这三种更严格协议之一发布
举例：Firefox、Thunderbird（Mozilla 自家项目）。相比 LGPL 以”库/程序”为边界，MPL 以”文件”为边界，粒度更细，适合大型单体代码库里只想开源部分模块的场景。
EPL（Eclipse Public License）
- Eclipse 基金会用于 Eclipse IDE 生态的许可证，替代早期的 CPL（删除了专利诉讼相关限制）
- 弱互惠（weak reciprocal）：修改 EPL 授权代码本身需开源，但与之组合（如链接）的其他代码可用不同许可证
- EPL 2.0（2017）相对 1.0 的关键变化：引入 Secondary License 机制，允许项目可选附加一个兼容 GPL 家族的许可证，解决了 EPL 1.0 与 GPL 生态割裂的问题；同时弱化了对纽约州法律管辖的地域绑定
- 已被 OSI 认可，同时被 FSF 列入自由软件许可证名单
举例：Eclipse IDE 本体、Jakarta EE（原 Java EE）大部分组件。在企业 Java 生态里比 GPL 更常见，因为允许闭源模块与之组合使用。
强著佐权（Strong Copyleft）
GPL（GNU General Public License）
任何基于 GPL 代码的衍生作品，包括链接进去的程序，必须整体以 GPL 开源。
| 维度 | GPLv2 | GPLv3 |
|---|---|---|
| 专利条款 | 无明确条款 | 新增专利授权条款，防止贡献者事后用专利反诉用户 |
| Tivoization（硬件锁定） | 未限制 | 要求嵌入消费级硬件时必须提供用户可替换/修改软件的手段 |
| 与 Apache 2.0 兼容性 | 不兼容 | 兼容 |
| DRM | 无相关条款 | 加入反 DRM 条款，用户有权移除限制 |
| 违约后果 | 立即永久终止授权 | 60 天内纠正可恢复授权 |
| 法律语言 | 偏美国法律术语 | 弱化地域依赖，更适应国际场景 |
Linux 内核坚持 GPLv2 而不迁移到 GPLv3，主要因维护者认为 GPLv3 的反 Tivoization 条款过严，不适合广泛嵌入硬件设备的内核项目。
举例：Linux 内核（GPLv2）、Git（GPLv2）、WordPress（GPLv2 or later）、GIMP（GPLv3）、MySQL 社区版（GPLv2，同时提供商业双授权）。
AGPL（Affero GPL，扩展提示）
在 GPL 的基础上额外要求：即使只是通过网络提供服务（SaaS）而未分发二进制/源码，也必须公开修改后的源码。兼容性最差，很多公司的许可证白名单里明确排除 AGPL 依赖，需法务审核。
举例：MongoDB 早期采用 AGPLv3，正是为了防止云厂商托管 MongoDB 服务而不回馈代码；但因 AGPL”通过网络提供服务算不算分发”存在法律灰色地带，MongoDB 于 2018-10 转而自创 SSPL（Server Side Public License）——要求 SaaS 化时连管理工具、备份系统等整套服务栈都要开源。SSPL 未获 OSI 认证为开源许可证，改用 SSPL 后 MongoDB 被部分主流发行版/仓库停止收录或不再更新（如 Fedora、Debian），是”许可证武器化”防御云厂商套壳的典型案例。
中国本土许可证：木兰系列
- 木兰宽松许可证 Mulan PSL v2（2020 年通过 OSI 认证）：首个我国主导的中英双语开源许可证，最大限度鼓励专利和版权开放，功能定位接近 Apache 2.0（宽松型 + 专利授权）
- 木兰公共许可证 Mulan PubL v2：在 PSL v2 基础上增加许可证的传染性（copyleft），并对 SaaS 等新兴技术场景增加分发条件限制，功能定位接近 MPL/GPL 之间
- 木兰白玉兰开放数据许可证 MBODL：面向人工智能训练数据集拟定，要求满足基本的公开发布、免费发布前提
- 木兰开放作品许可证 Mulan OWL：面向非软件类开放作品
举例：openEuler（华为主导的开源 Linux 发行版）、MindSpore（华为 AI 框架）均采用 Mulan PSL v2；openHarmony 相关组件也大量使用木兰系列，是国内厂商主导开源项目时的常见默认选择。
选择指南
- 想让别人自由使用甚至商用你的代码 → MIT 或 Apache 2.0（后者多一层专利保护，企业更放心）
- 想开源但防止别人直接闭源套壳你的核心库 → LGPL 或 MPL 2.0
- 想确保所有衍生作品都保持开源 → GPL
- 项目以 SaaS/网络服务形式提供，想堵住”魔改后不公开”的漏洞 → AGPL
- 面向国内生态、需要中英双语法律文本 → 木兰系列
兼容性要点
- 宽松型许可证之间基本互相兼容（MIT ↔ BSD ↔ Apache 2.0）
- 宽松型代码可并入 GPL 项目，反之不行（GPL 代码不能并入宽松型项目再分发）
- GPLv2 与 GPLv3 因专利条款、反规避条款不同存在兼容问题，很多项目用”GPLv2 or later”规避
- Apache 2.0 与 GPLv2 不兼容，与 GPLv3 兼容
相关
- data-and-content-licenses — 开放数据许可证（ODC 系列）与 Creative Commons 许可证