主流开源许可证全景：从 MIT 到 AGPL，工程师该怎么选

July 14, 2026 架构设计开源许可证, License, 合规, 选型开源与工程决策系列 5949 字 12 分钟阅读

🔊

2017 年 9 月，React 一夜之间从 BSD+Patents 改成了 MIT。原因是 Apache 软件基金会把 React 的许可证列入「禁止依赖」清单，WordPress 母公司 Automattic 当场宣布放弃基于 React 重写界面——Facebook 顶不住整个生态施压，妥协了。七年后的 2024 年 3 月，Redis 把核心从 BSD 3-Clause 改成 RSALv2+SSPL 双协议，AWS、Google、Oracle 一周内联合 fork 出 Valkey 把它替代了。

两件事隔了七年，背后是同一个问题：开源不等于免费随便用。每条开源许可证都是一份合同，规定了你能做什么、必须做什么、什么时候你的授权会被收回。挑错许可证，轻则被迫开源整个产品，重则吃版权侵权诉讼。中美法院都已经判定过开源许可证具有法律可执行性——这事后面会讲。

这篇先把 14 种主流 OSI 开源许可证讲清楚：它们各自的传染边界在哪、专利条款怎么写、适合什么场景。下一篇再讲 Source Available（源码可见但非开源）和 AI 时代的许可证攻防。

copyleft 强度光谱：先建立一张地图

把所有开源许可证排成一条光谱，传染性从左到右递增：

mermaid
flowchart TD
    A["CC0 / Unlicense<br/>公共领域"] --> B["MIT / BSD / ISC<br/>宽松型"]
    B --> C["Apache 2.0<br/>宽松+专利"]
    C --> D["MPL / EPL / CDDL<br/>文件级弱 copyleft"]
    D --> E["LGPL v3<br/>库级弱 copyleft"]
    E --> F["GPL v2 / v3<br/>整体强 copyleft"]
    F --> G["AGPL v3<br/>网络触发开源"]

    classDef free fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    classDef perm fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef weak fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef strong fill:#ffcdd2,stroke:#f44336,color:#B71C1C
    class A free
    class B,C perm
    class D,E weak
    class F,G strong

光谱的左端是「随便用，别找我」的 CC0/Unlicense；右端是 AGPL v3——你哪怕只是把修改版部署成云端 SaaS，用户通过网络访问一下，你就得把修改版源码交出来。中间的弱 copyleft 区是最容易被工程师误读的：MPL 卡在「文件级」，LGPL 卡在「库级」，听起来差不多，传染边界却完全不同。

理解了这张图，下面四组许可证的具体规则就只是细节。

公共领域：CC0 与 Unlicense

把代码彻底奉献出去，不保留任何权利。

The Unlicense（SPDX: Unlicense） —— OSI 已批准。明确放弃所有版权利益，任何目的（含商业）都能复制、修改、销售，无任何条件。典型项目：kakoune、react-use。它的短板是不提供专利授权，也不像 CC0 那样有「弃权无效就回退成公共许可」的法律兜底。

CC0 1.0 Universal（SPDX: CC0-1.0） —— FSF 认可是自由许可证，但 OSI 没批准。由 Creative Commons 维护，原本面向数据和内容，软件也能用。最大的特点是用「弃权 + 公共许可兜底」的双层结构：如果你的司法辖区不承认版权弃权，它就自动回退成一份免版税的公共许可，效果上等价于公共领域。但它明确排除专利授权——对涉及专利的软件项目，不如 Apache 2.0 安全。

实际选型里这两个用得不多，多数人会直接选 MIT。

宽松型：MIT、BSD、ISC、Apache 2.0

MIT / BSD 2-Clause / ISC：三兄弟几乎等价

MIT License（MIT）：约 170 字，世界上最流行的宽松许可证。React、jQuery、Rails、.NET Core 都用它。
BSD 2-Clause（BSD-2-Clause）：Homebrew、go-redis 在用。早期 BSD 有个「广告条款」要求所有衍生品宣传里都得提原作者，被剥离之后演化出 2-Clause 和 3-Clause 两个变体。
ISC License（ISC）：OpenBSD 系和 npm 生态大量在用（Node.js semver、Starship），措辞比 BSD/MIT 更简洁，移除了过时的法律语言。

这三份共同短板：没有专利授权条款。原作者如果手上攥着相关专利，理论上随时可以告你专利侵权。对依赖树庞大的前端库和小工具问题不大，对涉及算法专利的核心组件就要谨慎。

BSD 3-Clause：加一道防背书

在 2-Clause 基础上多一条：未经版权人事先书面同意，不得用版权人或贡献者的名字为衍生产品背书或推广。Flutter、LevelDB、Quill 用它。如果你不想自己的项目名被人拿去做营销，就选这条。

Apache 2.0：宽松型里唯一带专利保护

Apache 2.0 是企业级开源的首选。Kubernetes、Swift、PDF.js、Android 大量组件都是它。相比 MIT/BSD，它多出四样东西，可以看作「宽松型 + 四道护甲」：

mermaid
flowchart TD
    AP["Apache 2.0<br/>宽松型基线"] --> P1["专利授权<br/>永久/全球/免费"]
    AP --> P2["专利反制<br/>起诉即终止"]
    AP --> P3["NOTICE 文件<br/>归属声明"]
    AP --> P4["变更声明<br/>修改文件标注"]

    classDef base fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef prot fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class AP base
    class P1,P2,P3,P4 prot

专利授权：每位贡献者授予你「永久、全球、非独占、免费、不可撤销」的专利许可，覆盖其贡献必然侵权的权利要求。MIT/BSD 完全没有这条，所以大企业内部通常禁止直接依赖纯 MIT 的专利敏感组件，或者要求走法务评审。
专利反制：如果你针对任一实体提起专利诉讼，主张该作品构成侵权，你获得的专利授权自诉讼提起之日终止。这是对称保护——防止有人一边用着代码一边拿专利反向讹原作者。
NOTICE 文件：若原作品带 NOTICE 文件，衍生作品分发时必须把里面的归属声明也带上。这点最容易踩坑，很多人 copy 代码时只复制了 LICENSE 漏了 NOTICE。
变更声明：修改过的文件要带显著的「已更改」标记。

Apache 2.0 明确不授予商标权——这点和 BSD 3-Clause 的防背书条款精神类似。所以你不能拿 Kubernetes 的 Logo 去卖自己的商业发行版。

弱 copyleft：MPL、LGPL、EPL、CDDL、EUPL

弱 copyleft 的核心是「传染有边界」。修改的部分要开源，新增的部分可以闭源。但边界划在哪里，每个证不一样：

MPL 2.0（MPL-2.0）：边界划在文件。你修改了 MPL 文件，那个文件继续以 MPL 分发；你新增的文件不受影响，可以整体作为「Larger Work」闭源。Firefox、Thunderbird、HashiCorp 早期产品用它。文件级是「最容易商业化的弱 copyleft」。
LGPL v3（LGPL-3.0）：边界划在库。设计目标是让商业应用可以闭源链接 LGPL 库，但库本身的修改必须开源，还要提供「Minimal Corresponding Source」让用户能重新链接修改版库。GTK、Qt 部分组件、FFmpeg 的 LGPL 部分用它。
EPL 2.0（EPL-2.0）：Eclipse 系，传染范围以「Modified Works」定义为准，类似 MPL 的文件级。Eclipse IDE、JUnit 5、Jakarta EE 用它。EPL 2.0 关键设计是「二级许可证 = GPL v2+」，解决了历史上 EPL 与 GPL 不兼容的问题。
CDDL 1.0/1.1（CDDL-1.0）：Oracle 主导，由 MPL 1.1 演化而来，文件级。OpenSolaris 派生物、GlassFish 用它。
EUPL 1.2（EUPL-1.2）：欧盟的官方许可证，有 23 种欧盟官方语言版本，每种都具同等法律效力。最大特色是显式列出兼容许可证清单（GPL、AGPL、LGPL、MPL、EPL 等），派生作品可以转成清单里的任意一个。

为什么文件级这么重要？因为它划出了可商业化的边界。你把一个 MPL 库塞进闭源商业产品里，只要不动它的源码文件，整个产品可以闭源发布；换成 GPL，整个产品都得开源。这就是 HashiCorp 当年从 MPL 转 BSL 之前能拿 VC 钱的逻辑——MPL 给了他们「核心开源 + 商业闭源扩展」的空间。

强 copyleft：GPL v2、GPL v3、AGPL v3

强 copyleft 没有边界折中：派生作品整体必须以同一许可证开源。这一组是商业公司最警惕的。

GPL v2 vs GPL v3：差在哪里

Linux 内核至今锁在 GPL v2（明确声明 GPL-2.0-only，不接受升级），而 Bash、GCC、Samba 用 GPL v3。两者都强 copyleft，但 v3 比 v2 多了三样东西：

显式专利授权 + 反制：v2 在序言里抱怨软件专利但没写条款，v3 明确授予专利许可，并加上「你起诉就终止」的反制。
反 Tivoization：针对消费产品，分发对象码时必须提供「Installation Information」——安装和运行修改版所需的密钥和方法，不能拿技术措施挡用户改装。Tivoization 这个词来自 TiVo 机顶盒——它用了 GPL 内核但用硬件签名锁死了修改版，FSF 认为这违背了 GPL 精神。
反 DRM/反规避：覆盖作品不得被视为 WIPO 版权条约意义下的「有效技术措施」，分发方放弃禁止规避技术措施的法律权利。

实务上，如果项目要跟 Linux 内核生态兼容，必须用 GPL v2（或「v2 or later」的兼容条款）；如果想堵专利漏洞、堵硬件锁定，用 GPL v3。

AGPL v3：堵住 SaaS 漏洞

AGPL v3 是 GPL v3 加上第 13 条「网络使用即分发」：

若修改版被用于通过计算机网络向用户提供交互服务，运营者必须向该服务的用户公开修改版的完整对应源码。

这条专为 SaaS 场景设计。GPL v3 第 6 条只约束「convey」（向他人传输副本），意思是只要你不分发副本，把修改版部署成云服务就不触发开源义务——这就是所谓的「ASP 漏洞」。AGPL 把漏洞堵上了：哪怕用户只是通过网络访问，你也得交源码。

Mastodon、Nextcloud、Ghostscript 用 AGPL v3。MongoDB、Elastic、Redis 当年都先后用过 AGPL，又先后觉得 AGPL 不够用——下一篇会讲它们怎么一路演化到 SSPL 再回归 AGPL。

主流许可证对比矩阵

把上面四组合到一张表里：

许可证	SPDX	类型	传染边界	专利授权	专利反制	商标	网络条款
MIT	`MIT`	宽松	无	✗	✗	✗	✗
BSD 2-Clause	`BSD-2-Clause`	宽松	无	✗	✗	✗	✗
BSD 3-Clause	`BSD-3-Clause`	宽松	无	✗	✗	✓ 防背书	✗
ISC	`ISC`	宽松	无	✗	✗	✗	✗
Apache 2.0	`Apache-2.0`	宽松	无	✓	✓	✓	✗
Unlicense	`Unlicense`	公共领域	无	✗	✗	✗ 隐含	✗
CC0 1.0	`CC0-1.0`	公共领域	无	✗ 明确排除	✗	✗ 明确排除	✗
MPL 2.0	`MPL-2.0`	弱 copyleft	文件级	✓	✓	✓	✗
LGPL v3	`LGPL-3.0`	弱 copyleft	库级	✓	✓	✗	✗
EPL 2.0	`EPL-2.0`	弱 copyleft	文件级	✓	✓	✗	✗
CDDL 1.0	`CDDL-1.0`	弱 copyleft	文件级	✓	✓	✗	✗
GPL v2	`GPL-2.0`	强 copyleft	整体	✗	✗	✗	✗
GPL v3	`GPL-3.0`	强 copyleft	整体	✓	✓	✗	✗
AGPL v3	`AGPL-3.0`	最强 copyleft	整体+网络	✓	✓	✗	✓ SaaS 触发
EUPL 1.2	`EUPL-1.2`	弱 copyleft	派生作品级	✓	✗	✓	✗

三个维度单独拎出来看更清楚：

专利授权——有显式条款的：Apache 2.0、MPL 2.0、LGPL v3、EPL 2.0、CDDL、GPL v3、AGPL v3、EUPL 1.2。没有的：MIT、BSD、ISC、Unlicense、GPL v2。明确排除的：CC0 1.0。

网络触发开源——只有 AGPL v3 一家。其他所有 OSI 开源许可证都不会因为你部署成 SaaS 而触发开源义务。

商标限制——明确不授权商标的：Apache 2.0、MPL 2.0、BSD 3-Clause、EUPL 1.2。不涉及的：MIT、BSD 2-Clause、ISC、Unlicense。

一张决策树：场景反推许可证

拿到一个新项目，怎么挑？顺着下面这张图走：

mermaid
flowchart TD
    Q1{"允许衍生品<br/>闭源吗？"} -->|"是"| Q2{"涉及专利<br/>或需要商标保护吗？"}
    Q1 -->|"否"| Q4{"会部署成<br/>网络服务吗？"}

    Q2 -->|"否"| A1["MIT / BSD / ISC"]
    Q2 -->|"是"| A2["Apache 2.0"]

    Q4 -->|"是"| A5["AGPL v3"]
    Q4 -->|"否"| Q5{"希望闭源应用<br/>能链接它吗？"}

    Q5 -->|"是"| Q6{"库 还是 文件级？"}
    Q5 -->|"否"| A4["GPL v3"]

    Q6 -->|"库"| A3["LGPL v3"]
    Q6 -->|"文件"| A6["MPL 2.0 / EPL 2.0"]

    classDef q fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef r fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class Q1,Q2,Q4,Q5,Q6 q
    class A1,A2,A3,A4,A5,A6 r

几个补充：

只是个人小工具 / Demo → MIT。简单到不用想。
公司内部框架要给业务团队用、又不想被外部白嫖 → MPL 2.0。文件级传染既能保证你对修改的控制，又不影响业务方闭源。
做基础库，希望被广泛链接 → LGPL v3。明确允许闭源应用链接。
做操作系统内核或编译器 → GPL v2（Linux 兼容）或 GPL v3。
做 SaaS 产品核心 → AGPL v3。这一条最容易被云厂商绕过——下一篇会讲 MongoDB 为什么觉得 AGPL 不够用，又怎么造出 SSPL。
欧盟政府项目 → EUPL 1.2，多语言对等和兼容性机制是硬要求。

几个常见误读

「动态链接 GPL 代码不触发 copyleft」 —— FSF 的官方立场是动态链接也构成衍生作品，整体必须 GPL。法律上「衍生作品」定义确实模糊，但把 GPL 代码动态链接进专有产品，在法律上极可能违反 GPL。想保留闭源，要么用 LGPL，要么走 IPC 通信，要么洁净室重写。

「AGPL 只要不分发就安全」 —— 错。AGPL 第 13 条专门针对「通过网络提供交互服务」触发。你只要把修改版部署成 Web 服务让用户访问，就触发开源义务。

「源码公开就算开源」 —— 错。Source Available（源码可见）不等于 Open Source。BSL、SSPL、ELv2、RSALv2、FSL 这些都不是开源许可证，OSI 没批准它们。下一篇专门讲这一组。

参考链接

SPDX License List：https://spdx.org/licenses/
OSI 已批准许可证：https://opensource.org/licenses/alphabetical
GitHub choosealicense.com：https://choosealicense.com/licenses/
Apache 2.0 全文：https://choosealicense.com/licenses/apache-2.0/
MPL 2.0 全文：https://choosealicense.com/licenses/mpl-2.0/
GPL v3 全文：https://choosealicense.com/licenses/gpl-3.0/
AGPL v3 全文：https://choosealicense.com/licenses/agpl-3.0/
LGPL v3 全文：https://choosealicense.com/licenses/lgpl-3.0/
EPL 2.0 全文：https://www.eclipse.org/legal/epl-2.0/
EUPL 1.2 全文：https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12

下一篇《从 Redis 转 BSL 到 AGPL 复兴：Source Available、AI 与许可证攻防》会接着讲：BSL/SSPL/ELv2/RSALv2/FSL 怎么把「源码可见」做成商业模式，MongoDB/Elastic/HashiCorp/Redis 四场许可证战争怎么打，AI 时代的许可证又在演化出什么新东西。

所属系列: 开源与工程决策系列

下一篇 → 从 Redis 转 BSL 到 AGPL 复兴：Source Available、AI 与许可证攻防