GPL、MIT 与 Apache 许可证有什么区别？

GPL、MIT 与 Apache：每种许可证对您的要求

GPL、MIT 和 Apache 2.0 以不同方式回答同一个问题：您分发软件时，需要对其他人承担什么义务？MIT 只要求保留版权声明，没有其他要求。Apache 2.0 除了要求保留该声明，还规定了所有接触代码的人之间的专利授权安排。GPL 则要求您以获得软件时使用的相同许可证，发布您在其基础上构建的软件的源代码。

在项目更改许可证并一分为二之前，这似乎只是律师需要处理的问题。之后，它就变成了运维问题。您需要在两个软件包仓库之间做出选择，客户端库也可能不再相互兼容。本指南介绍这些许可证及其运作机制，而不是介绍产生这些许可证的运动。因此，每个部分都会说明它对您的实际影响：您需要负责执行升级。

GPL 存在的原因：一台不允许用户自行修复的打印机

大约在 1980 年，MIT 人工智能实验室收到了一台 Xerox 9700 激光打印机。实验室曾为较早的一台打印机修改软件，使它能在打印任务卡住时通知用户。但这台新打印机没有提供源代码，而实验室索要源代码的请求因保密协议被拒绝。当时在该实验室工作的程序员 Richard Stallman 没有把这次拒绝视为偶发问题，而是将其视为普遍现象，并于 1983 年 9 月 27 日宣布启动 GNU 项目。

Copyleft 建立在版权法之上，而不是对抗版权法。默认情况下，您完全无权复制他人的代码。GPL 授予您这项权利，但附带一个条件：如果您将程序提供给他人，就必须按照相同条款向对方提供源代码，使对方能够完成实验室无法完成的事情。该条件具有法律约束力，因为如果没有许可证，您原本就没有获得许可。

Stallman 首先为 GNU Emacs 编写许可证，随后将其推广为 GPL version 1，于 1989 年 2 月 25 日发布。GPL version 2 于 1991 年 6 月发布，您运行的大多数系统软件至今仍采用该许可证。之后又推出了 Lesser GPL，适用于库。这样，采用 copyleft 的库可以被任何许可证下的程序链接，而不会使该程序也受 GPL 约束。

有一个细节决定 GPL 会如何影响自行托管的用户。义务在分发时触发，而不是在使用时触发。您可以修改 GPL 程序，将其运行在自己的服务器上，并用它向公众提供服务，而无需向任何人承担相关义务，因为您从未交付程序副本。AGPL 正是为解决这一差异而存在的。

宽松许可传统：BSD，然后是 MIT

Berkeley 采取了不同的路线。计算机系统研究组以一种许可协议发布其 Unix 工作成果，要求保留版权声明，并声明不提供任何担保。原始版本包含 4 条条款。其中第 4 条是广告条款，要求所有提及该软件功能的广告材料都必须注明 University 的贡献。这种要求无法扩展。Stallman 统计过，NetBSD 的 1997 版本需要 75 次单独的致谢。UC Berkeley 于 1999 年 7 月 22 日通过其技术许可办公室 William Hoskins 的一封信，撤销了该条款。

后来保留下来的是 3-clause BSD licence。它新增一项限制：不得使用贡献者的姓名为产品背书。2-clause 版本则连这项限制也取消了。MIT licence 文本于 1980s 年代由 MIT 发布，当时用于 X Window System。实际使用中，它与 2-clause BSD licence 起到相同作用。

双方的动机不同。一所由公共资金资助的大学希望其成果得到广泛使用，包括被公司使用。GNU project 希望建立一个无法被关闭的共享资源。两种立场都是真诚的，但两者都有失败模式。宽松许可代码可能被私有化，而原作者得不到任何回馈。Copyleft 代码则会被其律师不接受相关条件的公司拒绝。

Berkeley 还带来了第二个教训，也是本文反复回到的主题。AT&T 的 Unix System Laboratories 于 1992 年因 BSD 代码起诉 Berkeley Software Design，案件于 1994 年初达成和解。在长达 2 年的时间里，没有人能确定 BSD 是否可以安全地作为构建基础。BSD 的采用因此停滞，而 Linux 持续增长。法律上的不确定性比缺少某项功能更快地阻碍采用。

Apache 2.0 为什么新增专利授权

Apache Group 最初的许可证是 BSD 4-clause 的衍生版本，也存在相同的广告条款问题。2000 年发布的 1.1 版移除了该条款。2004 年 1 月发布的 2.0 版则是一次重写，而不是简单修补。

最重要的新增内容是专利条款。MIT 和 BSD 完全没有提及专利。贡献者可以明确授予您使用其代码的版权许可，但仍持有一项涵盖该代码功能的专利，然后起诉使用这些代码的人。Apache 2.0 填补了这一漏洞：每位贡献者都会授予涵盖其贡献内容的专利许可；如果有人以该作品侵犯其专利为由提起诉讼，其对该作品享有的专利许可也会终止。该威胁是相互的，因此实际上没有人会发起诉讼。

2.0 的其余内容属于管理性规定，这也是企业喜欢它的原因。许可证规定了 NOTICE 文件，因此归属信息集中在一个位置，而不是散落在整个代码树中。通过引用即可应用该许可证，无需将其粘贴到每个源文件中。贡献内容受明确条款覆盖。商标不在许可范围内。对 Apache 2.0 依赖项进行法律审查时，审查人员想提出的问题都已在文本中得到回答，因此审批可以成为例行流程；这基本就是“企业默认选项”的含义。

GPLv3 的变化，以及 Linux 为何仍使用 GPLv2

TiVo 发布了一款运行 Linux 的录像机，并按照 GPLv2 的要求公开了内核源代码。随后，硬件在启动时检查加密签名，拒绝运行无法识别的内核。您可以阅读源代码、修改代码并编译。您却无法在提供该内核的设备上运行修改后的版本。许可证的字面要求得到了满足，但其目的落空了。这种做法后来被称为 tivoisation。

GPL version 3 于 29 June 2007 发布，并直接回应了这一问题。当您在消费类设备中分发二进制文件时，还必须提供“Installation Information”：安装修改版本并使其运行所需的密钥或操作说明。Version 3 还新增了明确的专利授权，加入了针对 Microsoft 与 Novell 于 November 2006 签订的专利协议而制定的条款，并增加了与 Apache 2.0 的单向兼容性。

Linux 没有跟进。该内核仅采用 GPL version 2，并且没有“or any later version”这一授权条款；其 COPYING 文件也明确说明了这一点。Linus Torvalds 曾公开反对针对签名硬件的反 tivoisation 条款。实际障碍比意见分歧更大：内核拥有数千名版权持有人，因此即使所有人都同意，也没人能够收集重新授权所需的许可。这一事实本身就是项目能够拥有的最强保护之一。当您考察由单一公司控制的项目时，值得记住这一点。

另一个 2007 年的许可证与您关系更大。GNU Affero GPL version 3 于同年 November 发布，将源代码提供义务扩展到了通过网络与程序交互的用户。面向公众运行经过修改的 AGPL 服务时，您必须向这些用户提供源代码。这就是许多自托管 Web 软件采用 AGPL 的原因。Nextcloud 是其中一个例子。如果您正在比较 Nextcloud 的自托管替代方案，每个候选项目仓库中的许可证信息，比功能列表更能说明它未来五年的发展方向。

实际可以组合哪些许可证？

兼容性是单向的：可以从宽松许可证方向组合到 copyleft 许可证。

• MIT 和 BSD 代码可以加入任何项目，包括闭源产品。
• Apache 2.0 代码可以包含在 GPLv3 项目中，组合后的作品采用 GPLv3。
• Apache 2.0 代码不能包含在仅允许 GPLv2 的项目中。Apache 2.0 的专利终止和赔偿条款属于额外条件，而 GPLv2 不允许添加这些条件。FSF 和 ASF 都发布了这一结论。
• 您不能自行将 GPL 代码改为宽松许可证。只有版权所有者可以这样做，因此问题又回到了确定版权所有者是谁。

许可变更时代：SSPL、BUSL，以及它们不是什么

导火索来自商业利益。一家公司拥有某个产品的版权，云服务商以托管服务的形式大规模销售该产品，却很少回馈这家公司，于是公司修改许可证来阻止这种做法。Redis Labs 于 2018 年 8 月率先采取了广受关注的行动：在其多个模块的 Apache 2.0 许可证之上增加 Commons Clause。MongoDB 随后于 2018 年 10 月 16 日从 AGPLv3 改用 Server Side Public License。

SSPL 是对 AGPL 某一节进行重写后的版本。如果您将该程序作为服务提供给第三方，就必须公开为提供该服务而使用的所有软件的源代码，包括围绕该程序运行的管理和编排软件。这项义务的边界并不明确，法院也没有对此进行审理。OSI 从未批准该许可证，MongoDB 于 2019 年 3 月撤回了申请。Debian 早在 2018 年 12 月就表示，采用 SSPL 的软件不应进入其软件包仓库；Fedora 于 2019 年 1 月裁定该许可证不属于自由许可证。随后，Red Hat 将 MongoDB 从 Fedora 和 Red Hat Enterprise Linux 中移除。这就是许可证变更的直接结果：发行版停止打包该软件，之后您的升级只能按厂商安排，从厂商的软件仓库获取。

Business Source License 是另一种机制。它由 MariaDB 的创始人提出，1.1 版本发布于 2017 年。它不是 copyleft 许可证，也不是开源许可证。源代码公开，除厂商明确排除的用途外，其他使用均可免费进行；通常被排除的是运行竞争性的托管服务。每个版本都会在变更日期自动转换为真正的开源许可证，变更日期最迟不超过该版本发布后的四年。转换后的许可证必须与 GPLv2 兼容。HashiCorp 于 2023 年 8 月 10 日将 Terraform 及其其他产品改用 BUSL 1.1。如果您正在从自托管的 Notion 替代方案中进行选择，这一点也值得了解：您可以为自己的团队运行它，但不能基于它构建服务。

这两种许可证都没有隐瞒事实。它们都明确说明自己属于源代码可用许可证。按照 OSI 的定义，它们都不是开源许可证，而最终承担这一差异影响的是您，而不是它们原本针对的云服务商。

OpenSearch：一次许可证分叉给运营方带来的成本

Elastic 于 2021 年 1 月 14 日宣布，从 7.11 版本开始，Elasticsearch 和 Kibana 将不再使用 Apache 2.0，而改用 SSPL 或 Elastic License。7.10.2 是最后一个使用 Apache 2.0 的版本。大约一周后，AWS 表示将创建并维护二者的 Apache 2.0 分叉版本。2021 年 4 月 12 日，该分叉命名为 OpenSearch，Kibana 更名为 OpenSearch Dashboards。OpenSearch 1.0 于 2021 年 7 月 12 日正式发布，基于 Elasticsearch 7.10.2 和 Kibana 7.10.2 构建。

看看这给集群运营人员带来了什么成本。软件包名称和软件源发生了变化。运行手册中所有提到 Kibana 的地方都变成了 OpenSearch Dashboards。插件名称也发生了变化。随后，分歧扩展到了应用代码：从 Elastic 官方客户端库的 7.13 版本开始，客户端会检查连接到的产品；如果连接的不是 Elasticsearch，就会拒绝继续运行，并报告服务器是未知产品。一个与你无关的公司做出的许可证决定，最终变成了你自己应用中的一次失败调用。

之后，情况又发生了两次变化。2024 年 8 月 29 日，Elastic 增加了 AGPLv3 这一第三种许可证选项，因此当前的 Elasticsearch 再次成为 OSI 批准的开源软件。2024 年 9 月 16 日，AWS 将 OpenSearch 转交给由 Linux Foundation 托管的 OpenSearch Software Foundation，使该分叉拥有不属于单一公司的治理机构。截至 2026 年 8 月，分叉已经过去 5 年。两个项目都是开源项目，也都在持续维护；OpenSearch 已进入 3.x 系列。

结论就是这里。许可证回来了，但分叉仍然存在。一个生态系统一旦出现两套完整的组件，撤销许可证变更也不会让它们重新合并。

决定重新授权会造成多大影响的数字，是许可证公告与实际可部署的稳定分叉之间的时间差。

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

每个时间差都从供应商公开公告开始计算，到分叉首次发布稳定版本为止，使用下方列出的日期。OpenSearch 1.0 用了 179 天，因为该分叉必须重新命名和构建，之前没有可供复制的分叉版本。OpenTofu 用了 153 天。Valkey 用了 27 天，因为它从 Redis 7.2.4 分叉，并保持协议和磁盘格式不变。趋势才是重点：现在，一个可信的分叉可以在数周内推出，并且从第一天起就有基金会和付费维护者参与。

Valkey 和 OpenTofu：相同的模式，更快的迁移

2024 年 3 月 20 日，Redis Ltd 将 Redis 的许可证从三条款 BSD 许可证改为 RSALv2 或 SSPLv1 二选一。8 天后，Linux Foundation 宣布推出 Valkey。它从 Redis 7.2.4 分叉而来，并继续采用三条款 BSD 许可证。Valkey 7.2.5 于 2024 年 4 月 16 日发布，使用相同的协议和相同的数据文件。因此，对大多数运维人员来说，迁移只涉及软件包名称。随后，Redis 在 2025 年 5 月发布的 Redis 8 中加入 AGPLv3 作为第三个选项。按照 OSI 的定义，Redis 因此再次成为开源软件；而 Valkey 继续由自己的治理体系管理。其发展模式与 Elasticsearch 高度相似。

Terraform 也经历了相同的过程，只是多了一章。OpenTofu 从最后一个采用 Mozilla Public License 2.0 的版本分叉而来，于 2023 年 9 月加入 Linux Foundation，并于 2024 年 1 月 10 日发布 1.6.0。2024 年 4 月 3 日，HashiCorp 的律师向该项目发出停止侵权函，声称分叉版本复制了某个采用 BUSL 许可证的 Terraform 版本中的代码。OpenTofu 于 2024 年 4 月 11 日发布了详细回应，否认这一指控，并追溯称争议代码来自双方共有的 MPL 许可证版本历史。此后，公开渠道没有进一步进展。这一事件真正需要记住的风险是：仅一项指控就可能让项目采用冻结一个季度。这与 30 年前 Berkeley 诉讼造成的影响相同。

并非所有分叉都始于许可证问题。Forgejo 于 2022 年从 Gitea 分叉，此前 Gitea 的开发转由一家企业负责。这是治理争议，而不是许可证争议。Forgejo 在其 8 系列版本中继续采用 MIT 许可证，随后从 2024 年的 9.0 版本开始改用 GPLv3 或更高版本，以避免其代码被重新纳入商业控制的产品。如果您正在评估自托管 Git 服务器选项，这对项目是当前最清晰的实例：同一个代码库，两种理念。

采用任何项目之前要执行的测试

在首次安装之前，而不是安装之后，先回答以下4个问题。

1. 谁持有版权？重新许可需要获得每位版权所有者的许可，因此，一个拥有数百名独立贡献者且未进行权利转让的项目，实际上无法重新许可。若所有权均由一家公司持有，则可以在董事会会议上完成重新许可。
2. 是否存在 CLA？它授予了哪些权利？允许公司按任意条款重新许可您所贡献内容的贡献者许可协议，正是上述每次重新许可背后的具体机制。DCO（开发者来源证明）是 Linux 内核在 2004 年采用的签署声明，不会转让任何权利。由基金会持有的 CLA 比由公司持有的更安全，因为公司可能被出售。
3. 谁拥有商标？Elastic 保留了 Elasticsearch 这个名称，因此该分支必须更名，所有提到 Kibana 的运行手册也都必须重写。
4. 重新许可对您具体会产生哪些成本？清点数据格式、客户端库、需要重写的配置，以及是否已经存在兼容的分支。

运行以下两个命令，可以在几秒内回答其中一部分问题。

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

每个 Debian 和 Ubuntu 软件包都会在 /usr/share/doc/<package>/copyright 提供一个文件。该文件记录的是您所安装版本的许可证，而不是项目当前使用的许可证。对于 Ubuntu 24.04 中的 bash，该文件会标明 GNU General Public License version 3。在源代码检出目录中运行第二个命令，可以查看许可证文件本身的历史记录。如果该文件在过去两年内有提交记录，建议您在基于该项目构建任何内容之前阅读相关提交。如果命令没有输出，说明仓库使用了其他名称作为许可证文件名，请列出根目录并查找。

没有任何许可证能让您避免所有结果，按意识形态选择项目，最终往往会令人措手不及。优先选择版权分散在许多人手中或由基金会持有的项目，并将数据保存为可导出的格式。然后确定您会迁移到哪个分支，并在真正需要之前记下其名称。对每个候选项目执行一次检查只需不到1小时；在决定 2026 年自行托管什么 时，这正是升级与迁移的区别。

FAQ

MIT 许可证与 BSD 许可证相同吗？

实际上，MIT 许可证与 2-clause BSD 许可证一致：保留版权声明和免责声明，然后可以按自己的意愿使用，包括构建闭源产品。3-clause BSD 许可证增加了一项限制：未经许可，不得使用贡献者的姓名为产品背书。更早的 4-clause 版本还要求在广告材料中致谢。UC Berkeley 于 22 July 1999 撤销了该条款，因此目前几乎没有版本仍包含它。

可以将 Apache 2.0 代码放入 GPLv2 项目吗？

不可以。Apache 2.0 增加了 GPLv2 不允许添加的条件，主要是专利终止条款，因此合并后的作品无法同时满足这两种许可证。FSF 和 ASF 都发布过这一结论。反方向则可行：Apache 2.0 代码可以包含在 GPLv3 项目中，结果适用 GPLv3。这也是 Apache 2.0 代码不能合并到 Linux kernel 的原因，因为 Linux kernel 仅使用 GPL version 2。

SSPL 是开源许可证吗？

不是，这一结论具有实际影响。OSI 从未批准 SSPL，MongoDB 也于 March 2019 撤回了申请。Debian 于 December 2018 表示，SSPL 软件不应进入其软件仓库；Fedora 于 January 2019 裁定该许可证不是自由许可证。随后，Red Hat 将 MongoDB 从 Fedora 和 Red Hat Enterprise Linux 中移除。对您而言，这意味着发行版过去维护的软件包，现在由供应商仓库提供，并按照供应商的支持时间表更新。Business Source License 同样是源代码可用许可证，而不是开源许可证，不过每个版本都会在四年内转换为开源许可证。

许可证变更会影响我已经运行的版本吗？

不会。随某个版本授予的许可证不能从已经发布的副本中撤回，这正是可以创建分支的原因。OpenSearch 基于 Elasticsearch 7.10.2 构建，这是 Elastic 以 Apache 2.0 发布的最后一个版本。您失去的是未来，因为下一项安全修复将按照新条款发布。固定使用最后一个宽松许可版本只能争取几个月时间，不能作为长期方案。