2026-04-22 · architecture / opensource
【开源许可与版权工程】闭源项目如何选择开源依赖：公司内部合规实操
面向做闭源/商业产品的团队：逐一拆解 MIT、LGPL、GPL、AGPL、SSPL、BSL 在 SaaS、私有化部署、移动 App、嵌入式固件等形态下的许可边界，给出三级名单模板、CI 扫描配置、SBOM 存证方案与出海补充要求。
本文讨论的是一组”非典型”开源许可证：它们试图用条款而非技术，约束”拿开源代码做 SaaS 赚钱却不回馈”的云厂商。这组许可证自 2007 年的 AGPL 起，经 MongoDB SSPL、Elastic ELv2、HashiCorp BUSL，一路延伸到 2024 年 Redis 的 RSALv2，构成了”开源与云”十五年博弈的主脉络。
在云厂商崛起之前，开源软件（Open Source Software）的商业化路径基本围绕两种假设：
传统 Copyleft（如 GPLv2/v3）的核心触发点是”conveying”（传递）——即把程序副本交到别人手中。只要你自己用、或者把程序跑在自己服务器上给别人用，其实都不触发传染条款。
21 世纪初，软件即服务（Software as a Service，SaaS）与云计算（Cloud Computing）兴起。亚马逊网络服务（Amazon Web Services，AWS）2006 年正式推出 S3 和 EC2，微软 Azure 2010 年公测，阿里云 2009 年成立。
云厂商的商业模式与传统分发完全不同：
业内把这种现象称为”Amazon 问题”（Amazon Problem），也叫”strip-mining”——一锄头挖走表层矿，留下一地废渣。MongoDB CEO Dev Ittycheria 曾在 2018 年的公开信中直接点名：某些云厂商”从开源软件中获取了巨大的经济利益，却没有以同等比例回馈社区”。
围绕这场博弈，有几组结构性张力：
| 年份 | 事件 | 性质 |
|---|---|---|
| 2007 | GNU AGPL v3 发布 | 开源（OSI 认证） |
| 2018 | Confluent Community License；MongoDB 从 AGPL 迁移至 SSPL | 源可得 |
| 2019 | CockroachDB 从 Apache 2.0 迁移至 BSL；AWS 推出 DocumentDB | 源可得 / 兼容实现 |
| 2021 | Elastic 从 Apache 2.0 迁移至 SSPL + ELv2；AWS Fork 出 OpenSearch；Grafana 从 Apache 2.0 迁移至 AGPL | 源可得 / Copyleft |
| 2023 | HashiCorp 将 Terraform、Vault、Consul、Nomad 迁移至 BUSL 1.1；社区 Fork 出 OpenTofu | 源可得 |
| 2024 | Redis 从 BSD-3-Clause 迁移至 RSALv2 + SSPLv1；Linux 基金会主持 Fork 出 Valkey | 源可得 |
从这张表可以看出一条规律：每当一个主力开源项目实施”反云”协议变更，往往在 12 到 24 个月内出现一个由云厂商或基金会主导的开源 Fork。这不是巧合，而是云厂商之间博弈均衡的结果——当一家公司锁死源码，其他云厂商宁可共同维护一个 Apache 2.0 分支，也不愿接受商业锁定。
GNU Affero 通用公共许可证第 3 版（GNU Affero General Public License v3，简称 AGPLv3）由自由软件基金会（Free Software Foundation，简称 FSF）于 2007 年 11 月 19 日发布——与 GPLv3 同期。
“Affero”这个词来自 Affero Inc.，一家 2001 年就开始尝试把网络服务纳入 Copyleft 范畴的公司。他们当时起草的 Affero General Public License v1 是一个基于 GPLv2 的修改版，加入了”网络交互触发披露义务”的条款。FSF 后来与 Affero 合作，把这个理念正式纳入 GPLv3 体系，形成 AGPLv3。
AGPL 要解决的核心问题是：
当程序不再通过”分发”方式传播，而是通过”网络服务”方式提供时，Copyleft 如何继续生效？
换句话说，AGPL 是 FSF 对”SaaS 漏洞”（SaaS loophole）的回应。
AGPLv3 的条款与 GPLv3 几乎完全一致，关键差异只有一条：第 13 节（Section 13）。为便于理解，这里对照一下：
GPLv3 §13（原文节选）
This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
AGPLv3 §13（原文节选，重点部分）
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
拆解关键词：
这是工程师最容易搞混的一点。AGPL 并没有禁止”修改后不对外公开”。它禁止的是：
几种典型场景：
| 场景 | 是否触发 AGPL §13 |
|---|---|
| 公司内部使用 AGPL 软件（未修改） | 不触发 |
| 公司内部修改 AGPL 软件，仅供员工使用 | 一般不触发（员工是否算”用户”有争议，但主流解释认为内部不算对外提供服务） |
| 未修改 AGPL 软件作为托管服务对外提供 | 不触发 §13（但仍需保留许可证、版权声明等） |
| 修改 AGPL 软件并作为托管服务对外提供 | 触发，必须向所有远程用户披露源码 |
| AGPL 客户端程序（非服务端）本地运行 | 按普通 GPLv3 分析，不涉及 §13 |
这里的”员工是否算用户”在法律上并没有绝对判例。保守的做法是：任何”超出本法人范围”的远程访问——包括子公司、外包团队——都按”对外服务”处理。Google 在内部政策中干脆禁止任何 AGPL 软件进入生产代码库，就是这种极端保守策略的体现。
历史上和当前仍活跃的 AGPL 项目包括：
Grafana 的迁移是一个特别值得分析的案例。2021 年 4 月，Grafana Labs 宣布将 Grafana、Grafana Loki、Grafana Tempo 从 Apache 2.0 迁移至 AGPLv3。当时的公开理由是”希望生态里更多的改进能回流社区”。但更现实的解读是：作为可视化层，Grafana 被各种托管服务大量内嵌为 UI；切换到 AGPL 后，任何修改 Grafana 的托管服务都必须开源其修改，这对 Grafana Labs 自家的 Grafana Cloud 构成明显的竞争优势。
AGPL 虽然尝试填补 SaaS 漏洞，但仍有若干边界模糊：
AGPL 填补了一部分漏洞，但远远不够——它的”触发阈值”还是”修改”。只要云厂商不修改上游代码，只是包装运维和监控，AGPL 就不触发。这恰恰是 MongoDB 后来转向 SSPL 的直接原因。
2018 年 10 月 16 日，MongoDB Inc. 宣布将 MongoDB Community Server 的许可证从 AGPLv3 迁移到一份新的许可证：服务器端公共许可证（Server Side Public License，简称 SSPL）。
表面上的时间线是这样的：
而 2019 年 1 月，AWS 顺势推出 DocumentDB（with MongoDB compatibility），被广泛认为是对 MongoDB 的直接对抗——尽管 DocumentDB 并没有使用 MongoDB 的源码，只是实现了 wire protocol 的兼容层。
SSPL 的关键条款是第 13 节，和 AGPL 第 13 节完全不是同一件事：
SSPL §13（原文节选，重点部分）
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
以及它对 “Service Source Code” 的定义：
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
这段条款的影响是颠覆性的：
对于一家大型云厂商而言，遵守 SSPL §13 几乎不可能：因为”用于把它做成服务”的全部软件，通常包括大量与云平台核心深度耦合的私有代码——计费、身份识别、监控告警、运维自动化等等。这些代码往往是云厂商的核心商业秘密，不可能公开。
因此，SSPL 的设计目的其实是把云厂商从社区版的用户中排除出去，迫使他们要么签商业许可证，要么放弃使用 MongoDB。
开放源代码促进会（Open Source Initiative，简称 OSI）是事实上的开源许可证认证机构，其维护的《开源定义》（Open Source Definition，简称 OSD）共 10 条准则。
MongoDB 在 2018 年向 OSI 提交了 SSPL 认证申请。经过数月的 license-review 邮件列表讨论，MongoDB 于 2019 年 3 月主动撤回申请。OSI 并未正式”拒绝”SSPL，但社区讨论的结论高度一致：SSPL 至少违反 OSD 第 9 条：
OSD #9: The license must not restrict other software. The license must not place restrictions on other software that is distributed along with the licensed software.
SSPL §13 要求披露与程序一起用于提供服务的所有软件的源码，这等于对”其他软件”施加限制——这些其他软件自身可能是专有的、MIT 的、Apache 的，却被 SSPL 强行要求按 SSPL 条款披露。
自由软件基金会（FSF）的立场比 OSI 更明确：SSPL 不是自由软件许可证，也不被视为与 GPL 兼容。
因此，业界形成共识：SSPL 是 “Source Available”（源代码可得）许可证，不是开源许可证。在正式文档、合规流程、投资尽调中，SSPL 应被列入与 BSL、ELv2 并列的”非开源”类别。
MongoDB 的实际商业模型是”开放核心”（Open Core）+ 双许可：
客户端驱动单独使用 Apache 2.0，意味着：
这是一种经过精心设计的条款结构：保护商业护城河的同时，最大化生态里的应用开发者基数。
MongoDB 的贡献者许可协议（Contributor License Agreement，简称 CLA）也值得一提。所有向 MongoDB 主仓库贡献代码的贡献者必须签署 CLA，把他们的贡献版权的双许可授权权让渡给 MongoDB Inc.，这使得 MongoDB 能持续以 SSPL + 商业双许可模式运作——包括未来再次切换许可证的能力。
2019 年 1 月，AWS 发布 Amazon DocumentDB（with MongoDB compatibility）。关键技术事实：
MongoDB 在 2019 年提起过对 DocumentDB 的公开批评，但未提起版权诉讼——因为 AWS 没有复制代码。MongoDB 的主张更多是”商标和品牌混淆”类型的间接主张。
这个案例揭示了一个基本事实：Wire Protocol 和 API 本身并不受著作权法保护（参考美国最高法院 Oracle v. Google 案的结论），因此云厂商总能通过”从零实现兼容层”的方式绕开任何基于版权的许可证。SSPL 的威慑力有限。
2021 年 1 月 14 日，Elastic N.V. 宣布将 Elasticsearch 和 Kibana 的许可证从 Apache 2.0 迁移至双许可：SSPLv1 和 Elastic License v2（ELv2）。这是继 MongoDB 之后，又一次”明星级”Apache 项目转向源可得许可证。
Elastic CEO Shay Banon 在公开信中把这件事的起因直接指向 AWS：
Elastic 的改协议，本质是”如果不能阻止 AWS 做托管，那就让 AWS 无法继续用最新源码”。
ELv2 是一份比 SSPL 简短得多、更聚焦的源可得许可证。它的核心限制有三条：
ELv2 不要求像 SSPL 那样披露全部服务源码，它采用的是”禁止性”而非”传染性”路径。对大多数企业内部自用、SaaS 应用内嵌、客户侧部署都非常宽松；仅对”直接与 Elastic Cloud 竞争的托管服务提供商”构成限制。
从工程合规的角度看：
但 ELv2 仍然不是开源许可证。OSI 未认证，FSF 也未认证。
Elastic 宣布改协议后不到 4 个月，2021 年 4 月 12 日，AWS 宣布将 Open Distro for Elasticsearch 升级为独立 Fork，命名为 OpenSearch。关键事实：
从这次 Fork 起，搜索引擎生态被一分为二：
2024 年 8 月，Elastic 又做了一次协议调整：将 Elasticsearch 加入 AGPLv3 作为第三种许可选项，形成 ELv2 + SSPLv1 + AGPLv3 三重许可。官方解释是”回归开源”。AGPLv3 是 OSI 认证的开源许可证，这一步让 Elasticsearch 重新可以被称为”开源”项目（在三选一场景下）。
但从工程角度看：
与此同时，Grafana Labs 在 2021 年 4 月跟进，将 Grafana、Loki、Tempo 从 Apache 2.0 迁移至 AGPLv3。Grafana Enterprise 保留商业条款。这种”双层结构”——AGPL 社区版 + 商业增强版——成为许多开源公司的新范式。
业务源码许可证（Business Source License，缩写为 BSL，也写作 BUSL，最新版本 1.1）由 MariaDB 公司于 2013 年前后提出，最初用于 MariaDB MaxScale 等产品。其最独特的设计是”延迟开源”：
到了 Change Date，当前发布版本自动转换为 Change License。这是 BSL 与其他”源可得”许可证的最大区别——它有一个可预期的开源时间表。
2023 年 8 月 10 日，HashiCorp 宣布将其旗舰开源产品 Terraform、Vault、Consul、Nomad、Boundary、Waypoint、Packer 全部从 Mozilla Public License 2.0（MPLv2）迁移至 BUSL 1.1。
关键参数：
| 参数 | 值 |
|---|---|
| 基础许可证 | BUSL 1.1 |
| Change License | MPL 2.0 |
| Change Date | 各产品当前发布日期后 4 年 |
| Additional Use Grant | 允许内部使用、非商业用途、未构成与 HashiCorp 商业产品竞争的商业用途 |
HashiCorp 的 Additional Use Grant 原文（Terraform 仓库 LICENSE 文件节选）：
You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp’s products.
“与 HashiCorp 产品构成竞争的托管或嵌入式服务”——这个定义在实务上覆盖了大量场景：
HashiCorp 宣布改协议仅 5 天后，2023 年 8 月 15 日，一组 Terraform 生态公司联合发布《OpenTF Manifesto》（后更名 OpenTofu Manifesto），要求 HashiCorp 收回协议变更，否则将发起 Fork。签署方包括 env0、Spacelift、Gruntwork、Harness、Scalr 等。
一个月未果后，9 月 20 日 OpenTF 项目正式启动，随后更名 OpenTofu，并于 2023 年 12 月正式加入 Linux 基金会。
OpenTofu 的关键事实：
tofu init 替代
terraform init；对工程团队而言，BSL 的几个重要影响：
每一次 BSL 迁移，社区都会经历一次”信任重置”。即便 HashiCorp 在条款文本层面已经非常克制（明确保留了内部使用、非竞品 SaaS 嵌入等），Fork 的发生仍然几乎不可避免——因为社区方无法承担”协议条款随时可能变得更严格”的长期风险。
Redis 项目的许可证演进在社区里被反复讨论，是一段典型的”从 BSD 出发，逐步源可得化”的历史：
| 时间 | 变化 |
|---|---|
| 2009 | Redis 最初发布，BSD-3-Clause |
| 2018 | Redis Modules（RediSearch、RedisGraph、RedisBloom 等）从 AGPL 迁移至 Redis Source Available License v1（RSALv1），但 Redis 核心仍为 BSD-3-Clause |
| 2019 | RSALv1 更新，条款收紧 |
| 2024 年 3 月 | Redis Inc.（前 Redis Labs）宣布 Redis 核心 从 BSD-3-Clause 迁移至 RSALv2 + SSPLv1 双许可 |
2024 年 3 月 20 日的官方公告中，Redis Inc. 表示此举是为了”确保那些通过托管 Redis 赚取可观收入的云服务提供商为 Redis 的开发作出贡献”。点名对象明显指向 AWS ElastiCache、阿里云云数据库 Redis 版、Google MemoryStore 等托管服务。
RSALv2 与 ELv2 结构非常相似，核心限制两条：
允许的行为：
和 ELv2 类似，RSALv2 不是开源许可证——OSI、FSF 均未认证。双许可 RSALv2 + SSPLv1 的设计也与 Elastic 类似：用户可自选其一。
Redis 改协议公告发布仅 8 天后，2024 年 3 月 28 日，Linux 基金会宣布主持 Fork——Valkey。Fork 起点是 Redis 7.2.4（最后一个 BSD-3-Clause 版本）。
Valkey 的关键事实：
一个引人注意的细节：Redis 项目本身在 2024 年晚些时候重新请回了原作者 antirez（Salvatore Sanfilippo），并发布了 Redis 8.0，同时在 2025 年宣布增加 AGPLv3 作为第三种许可证选项（类似 Elasticsearch 的回归尝试）。但 Valkey 社区已经形成，两个项目长期共存的可能性很高。
阿里云 ApsaraDB for Redis 服务基于 Redis 社区版提供托管服务，是受此次协议变更影响最大的国内云厂商之一。阿里云在 2024 年 4 月公开表态支持 Valkey，并作为创始成员加入 Valkey 项目。阿里云 Tair（一个基于 Redis 协议的自研 KV 数据库）的外围工具链和兼容性工作也逐步向 Valkey 靠拢。
腾讯云的立场类似——其 Redis 托管服务同样需要在 Valkey / Redis 新版本 / 自研替代之间做选择。公开信息显示腾讯云同样支持 Valkey 生态。
华为云在此前的 Elasticsearch 事件中已经全面拥抱 OpenSearch 路径，Redis 事件上也倾向于 Valkey。
国内云厂商的这种一致性选择，本质上是一场集体均衡：一旦某家选择继续跟随 Redis Inc. 的 RSALv2 路径，就需要为此向 Redis Inc. 支付商业许可费，这会成为巨大的成本劣势。集体转向 Valkey 是成本最优的博弈结果。
Confluent 是 Apache Kafka 的主要商业支持者，由 Kafka 原作者创立。Confluent 在 2018 年 12 月为其 Confluent Platform 中的若干专有组件（KSQL、Schema Registry、部分连接器）发布了 Confluent Community License（CCL）。
CCL 的核心限制：
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
注意三点：
Cockroach Labs 于 2019 年 6 月把 CockroachDB 从 Apache 2.0 迁移至 BSL（早期版本，非 1.1），Change Date 为 3 年后，Change License 为 Apache 2.0。
关键条款：
但故事没有结束：2024 年 8 月，Cockroach Labs 进一步宣布从 BSL 迁移至完全专有的 CockroachDB Enterprise License，停止开源版本发行。这被视为”开放核心”走到尽头的又一案例。
MariaDB 作为 BSL 的发明者，自家产品 MariaDB MaxScale 长期使用 BSL。MariaDB Server 核心则仍是 GPLv2，未受影响。
2023—2024 年间出现了一批新的”源可得”变体：
阿里云作为国内最大公有云厂商，在开源许可证策略上表现得尤其谨慎。几个关键观察：
阿里云自身的开源策略值得一提：包括 Higress、Nacos、Dubbo、Seata、RocketMQ、Spring Cloud Alibaba 等项目绝大多数使用 Apache 2.0。这一选择不仅是对社区友好，也是让其他云厂商愿意采用的必要条件——避免国外客户因为许可证原因拒绝。
腾讯云的策略与阿里云类似：
华为云因自身定位（运营商/政企市场为主），对许可证合规的敏感度更高：
国内两大自研分布式数据库的许可证选择，代表了”中国开源基础软件如何避免反云博弈困境”的两种思路。
从博弈角度看：
这是一种”用宽松换生态、用生态换市场”的战略选择。与 MongoDB 所处阶段的策略差异本质上源于博弈位置不同。
工程团队在合规流程中最常纠结的两个问题：
Google 的做法是最保守的：“AGPL 软件全面禁用”。理由不是 AGPL 违法，而是：
国内头部互联网公司内部政策大多同样保守。
许多国内工程师不清楚”SSPL / ELv2 / BUSL 不是开源”意味着什么。几个实际影响点：
这是最容易被忽视的法律事实：软件的某个特定版本一旦以某个许可证发布，该许可证永久有效。
Fork 策略的关键：
git log -p path/to/LICENSE
可以看到 LICENSE 文件的历史；使用
git show <commit>:path/file
查看特定版本的文件许可证；一个具体的命令示例：
# 以 Redis 为例，找到最后一个 BSD-3-Clause 版本
git clone https://github.com/redis/redis.git
cd redis
git log --all --follow -p -- COPYING | grep -E '^commit|BSD|RSAL|SSPL' | head -40
# 列出所有 tag 的许可证信息
for tag in $(git tag -l '7.*'); do
echo "=== $tag ==="
git show $tag:COPYING 2>/dev/null | head -3
done这种考古工作在 OpenSearch、OpenTofu、Valkey 的启动阶段都做过——团队需要精确确认”哪个 commit 之前的代码是开源可 Fork 的”。
MongoDB、Redis、Elastic、MySQL 都是双许可模型的典型：社区版 + 商业版。工程使用时的常见陷阱：
BSL/BUSL 的 Change Date 承诺：
对于微服务架构的企业，建议在 CI 流水线中：
为方便工程师在代码评审、合规审批、SBOM 扫描时快速判断，下面给出一张”反云博弈”语境下常见许可证的对比表。
| 许可证 | OSI 认证 | FSF 认可自由软件 | 网络服务触发披露 | 禁止托管服务 | 代码必须披露 | 典型代表项目 |
|---|---|---|---|---|---|---|
| MIT / BSD-3-Clause | 是 | 是 | 否 | 否 | 否 | Redis 7.2.4、Rails、React |
| Apache License 2.0 | 是 | 是（宽松） | 否 | 否 | 否 | Kafka、Kubernetes、Spark |
| MPL 2.0 | 是 | 是（弱 Copyleft） | 否 | 否 | 同文件修改需披露 | Firefox、Terraform 1.5.x、OpenTofu |
| LGPLv2.1 / LGPLv3 | 是 | 是 | 否 | 否 | 仅 LGPL 部分 | glibc、Qt（LGPL 选项） |
| GPLv2 | 是 | 是（强 Copyleft） | 否（“分发”才触发） | 否 | 合并作品全体披露 | Linux 内核、MariaDB Server |
| GPLv3 | 是 | 是 | 否 | 否 | 合并作品全体披露 | GCC、GNU Bash |
| AGPLv3 | 是 | 是 | 是（修改后） | 否 | 网络用户可获取 | Nextcloud、MongoDB v4 前、Grafana |
| Elastic License v2 | 否 | 否 | - | 是 | 否 | Elasticsearch 8.x |
| SSPLv1 | 否 | 否 | 是（作为服务） | 事实上是 | 全服务栈源码 | MongoDB v4+、Elasticsearch（双许可之一） |
| BUSL 1.1 | 否 | 否 | 否 | 是（Change Date 前） | 否 | Terraform 1.6+、Vault 1.15+ |
| RSALv2 | 否 | 否 | - | 是 | 否 | Redis 7.4+ |
| Confluent Community License | 否 | 否 | - | 是 | 否 | KSQL、Confluent 专有组件 |
| FSL（Functional Source License） | 否 | 否 | 否 | 是（2 年内） | 否 | Sentry 部分组件 |
| Mulan PSL v2 | 是（2020） | 未单独评估 | 否 | 否 | 否 | openEuler、openGauss、OceanBase 旧版 |
对于中大型企业的工程与法务团队，建议把下列项固化到合规流程中：
假设你是一家 SaaS 公司的架构负责人，2024 年 3 月 20 日晨间看到 Redis Inc. 的公告：核心 Redis 从 BSD-3-Clause 改为 RSALv2+SSPLv1。你的生产系统：
第一步：评估 RSALv2 对当前场景的影响
第二步：评估合规与尽调风险
第三步：评估 Valkey 替换的工程成本
第四步：决策矩阵
| 策略 | 短期成本 | 长期风险 | 合规复杂度 |
|---|---|---|---|
| 继续 Redis 社区版升级到 7.4 | 低 | 中（下次再改协议风险） | 中（需准备法务说明） |
| 锁定 Redis 7.2.4（最后 BSD 版） | 低 | 高（不能享受上游安全补丁） | 低 |
| 迁移到 Valkey 7.2 | 中（一次性测试+切换） | 低 | 低 |
| 迁移到 KeyDB / Dragonfly | 高 | 中 | 低 |
典型务实结论：中短期锁定 Redis 7.2.x 保持稳定，并行在测试环境验证 Valkey，6—12 个月内完成生产切换。
Q1：我的公司内部 IT 用了 MongoDB 社区版 5.0，这样算不算违反 SSPL？
A：不算。SSPL §13 触发的条件是”把程序功能作为服务提供给第三方”。员工/子公司内部使用通常不算第三方。注意：如果你把 MongoDB 嵌入到你的某个 SaaS 产品里提供给客户，且你的产品”主要价值来自 MongoDB”，才可能构成触发——而 SaaS 嵌入数据库的典型场景一般不会满足”主要价值来自 MongoDB”。
Q2：我 Fork 了一个 BSL 项目的最后一个开源版本，然后加了自己的改动——改动以什么协议发布？
A：最佳实践是与原项目保持一致的开源协议（原项目的 Change License 或原上游转协议前的许可证）。例如 Fork Terraform 1.5.x（MPLv2），自己的改动也以 MPLv2 或兼容协议发布。OpenTofu 就是这么做的。
Q3：AGPL 软件能做 Docker 镜像发布吗？
A：可以。分发 Docker 镜像属于 GPLv3/AGPLv3 的”conveying”，需要遵守：镜像内附带完整对应源码（或提供获取链接）、保留许可证、NOTICE 等。如果你修改了 AGPL 软件并在容器里运行提供网络服务，还要额外履行 §13 披露义务。
Q4：SSPL 和 AGPL 哪个”更严”？
A：SSPL 更严。AGPL 只要求披露被修改的 AGPL 程序的源码；SSPL 要求披露“提供服务所需的一切软件”的源码——包括管理、UI、API、自动化、监控、备份、存储、托管软件。任何实际提供托管服务的组织都几乎不可能满足 SSPL §13。
Q5：HashiCorp BUSL 下，我还能用 Terraform 写基础设施脚本吗？
A：完全可以。BUSL 允许内部使用、非竞品的生产使用。只有当你”把 Terraform 作为托管/嵌入式服务卖给第三方，且与 HashiCorp 产品构成竞争”时才受限。绝大多数企业用 Terraform 管理自家云资源的场景都在 Additional Use Grant 范围内。
Q6：如果我想做开源项目但也想阻止 AWS 抢我生意，该用什么许可证？
A：几个真实案例的路径：
没有一个免费午餐选项。更深层的建议是：靠产品力而不是条款。真正的反云护城河，是云厂商的托管版做不到你 SaaS 版的功能，而不是禁止他们使用。
Q7：Valkey / OpenSearch / OpenTofu 会不会再被改协议？
A：一般认为不会，原因：
这恰恰是基金会模式相对”单一公司主导开源”的核心价值：治理中立性带来许可证稳定性。
值得单独说明的一个误区：很多工程师把 AGPL、SSPL、BSL 都混在一起叫”限制性许可证”，但它们的法律属性差异巨大：
在内部合规政策中，应该明确区分这四类，而不是笼统地按”限制”强度排序。
许可证变更常常在数天之内就从公告发展到 Fork。工程团队应建立监控：
spdx/license-list-data
仓库会新增标识符时通常伴随生态事件。示例：一个简单的 CI 脚本检测依赖中 SSPL/BUSL 类许可证的出现：
#!/usr/bin/env bash
# check-risky-licenses.sh
# 生成 SBOM 后扫描风险许可证
set -euo pipefail
SBOM_FILE=${1:-sbom.json}
RISKY_LICENSES=(
"SSPL-1.0"
"BUSL-1.1"
"Elastic-2.0"
"Confluent-Community-1.0"
"RSAL-2.0"
"FSL-1.1-Apache-2.0"
"FSL-1.1-MIT"
)
found=0
for license in "${RISKY_LICENSES[@]}"; do
if jq -e --arg l "$license" '.components[]?
| select(.licenses[]?.license.id == $l)' "$SBOM_FILE" > /dev/null 2>&1; then
echo "[WARN] Risky license detected: $license"
jq --arg l "$license" '.components[]
| select(.licenses[]?.license.id == $l)
| {name, version, purl}' "$SBOM_FILE"
found=1
fi
done
if [[ $found -ne 0 ]]; then
echo ""
echo "Build contains Source-Available or restrictive licenses."
echo "Please confirm with legal before proceeding."
exit 1
fi
echo "No risky licenses detected."在 GitLab CI / GitHub Actions 中接入此脚本，就能把许可证合规从”人工审查”升级为”自动门禁”。
分析 OpenSearch、OpenTofu、Valkey 三次 Fork 的共同点，可以抽取”成功 Fork”的模式：
反过来，失败或半死的 Fork 往往在上述一点或多点缺位——例如只有一家厂商推动、没有基金会背书、兼容性断裂、Registry 重建慢等。
| 产品形态 | 推荐许可证（自研时） | 应避免依赖的许可证 |
|---|---|---|
| SaaS / 云服务 | Apache 2.0 或 MIT（最大化商业灵活性） | AGPL、SSPL（可能强制披露全部源码） |
| 托管数据库 | Apache 2.0（吸引云厂商合作） | SSPL、BSL |
| 桌面应用 | GPLv3 或 MIT | - |
| 嵌入式 / IoT | Apache 2.0 或 BSD | GPLv2（内核除外） |
| 内部工具 | Apache 2.0 或 MIT | - |
| 开源基础设施库 | Apache 2.0 或 MIT | AGPL（大多下游用户不能/不愿用） |
| 要约束云厂商的项目 | AGPLv3（OSI 认证） / SSPL（非 OSI） / BUSL（延迟开源） | - |
对于国内做基础软件（数据库、中间件、编排、观测性）并希望：
必选 Apache 2.0。没有第二个选项。
这也解释了为什么 OceanBase、TiDB、OpenTelemetry 中国贡献方（如阿里、腾讯、字节）发起的开源项目几乎清一色 Apache 2.0——这是进入国际生态的入场券。
如果你希望商业化但又想开源：
许多企业从 Apache 2.0 直接跳到 SSPL / BUSL 的剧烈变更，都带来了显著的社区反弹——不仅因为条款本身变严，也因为变更过程中的沟通不透明。MongoDB、Elastic、HashiCorp、Redis 都经历过类似风波。如果你计划协议变更，建议：
为了让工程师能够把许可证文本与实际场景对应起来，下面给出 AGPLv3 §13 的逐段注解（非法律意见）。
原文段 1
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction)
注解：
Notwithstanding any other provision =
“不顾本许可证其他条款”，意味着 §13 凌驾于 AGPL
其他条款；if you modify the Program =
触发的前提是”修改”。AGPL
认为未修改的程序保持原有条款，即便作为网络服务运行也不触发额外披露义务；prominently offer =
需要”醒目地”提供，不能藏在某个隐蔽角落。常见实务：登录页页脚链接、API
响应头包含 X-Source-URL、Help 菜单中的 “Get
Source” 按钮等；all users interacting with it remotely through a computer network
=
所有通过计算机网络与之交互的用户——这个定义相当宽泛，HTTP、gRPC、数据库协议、MQTT、WebRTC
甚至 SSH 都可能包含在内。原文段 2
an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
注解：
an opportunity to receive the Corresponding Source
=
必须提供获取”对应源码”的机会，不一定要主动推送，但必须是用户可触达的；from a network server at no charge =
必须通过网络服务器免费提供，不能收费下载；through some standard or customary means =
“标准或习惯方式”，Git 仓库、tarball 下载、SCM 服务（如
GitHub/GitLab）都符合。原文段 3
This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
注解：如果你在修改版中集成了 GPLv3 代码（通过 AGPL §13 允许的向下兼容路径），那部分 GPLv3 代码的对应源码也必须纳入披露范围。
从 MongoDB、Elastic、Redis 的案例看，业界对”modification”的典型判断标准：
| 操作 | 是否构成 AGPL 意义上的”修改” |
|---|---|
| 修改源码并重新编译 | 是 |
| 应用 patch / 二次开发功能 | 是 |
| 调整默认配置文件（通过 flag/env var） | 一般否 |
| 使用 LD_PRELOAD 注入函数 | 争议，保守认为是 |
| 运行官方发布的二进制 | 否 |
| 添加外层反向代理/网关 | 一般否（独立进程） |
| 裁剪源码去掉不需要的模块 | 是 |
| 通过插件机制加载自有逻辑 | 争议，视插件是否使用了 AGPL 内部 API |
AGPL §1 定义的 “Corresponding Source” 包括：
对于微服务场景，常见混淆：
SSPL §13 由 MongoDB 起草时，以 AGPLv3 §13 为基础但显著扩展。对比两者的触发条件与披露范围，就能直观看出 SSPL 的激进程度。
| 维度 | AGPLv3 §13 | SSPLv1 §13 |
|---|---|---|
| 触发前提 | 修改程序 | 把程序功能作为服务提供给第三方（无需修改） |
| 披露对象 | 通过网络与程序交互的用户 | 所有人（via network download） |
| 披露范围 | 修改版程序的对应源码 | 服务源码（Service Source Code）：全部用于提供服务的软件 |
| 包含项 | 程序、构建脚本、接口定义 | 管理软件、UI、API、自动化、监控、备份、存储、托管软件 |
| 实务可满足性 | 一般可满足 | 商业云厂商几乎不可能满足 |
| OSI 认证 | 是 | 否 |
| FSF 自由软件 | 是 | 否 |
从这张对照表清晰可见：AGPL 在”触发”和”披露”两个维度都是”适度 + 聚焦”，而 SSPL 则是”宽触发 + 全披露”。SSPL 的设计本意不是让云厂商”服从披露”，而是让云厂商”放弃使用”。
OSD #9 原文：
The license must not restrict other software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
SSPL §13 要求披露”所有用于提供服务的其他软件”的源码。这些”其他软件”可能是：
SSPL 通过 §13 把对这些完全独立的软件的披露义务绑到了 MongoDB 上，这正是 OSD #9 想禁止的”对其他软件施加限制”。因此 OSI license-review 的结论是 SSPL 不符合开源定义。
SSPL 本身有对”internal use”的隐含豁免——从 §13 的措辞看，只有”作为服务对第三方提供”才触发。如果你用 MongoDB SSPL 为自己公司的系统提供后端服务，原则上不触发 §13。
但”第三方”与”内部”的边界仍模糊：
以下信息基于各云厂商公开的开源使用政策、开源委员会声明、开发者文档。
如果你是一家以开源项目为核心的公司，正在考虑协议变更，下面是基于过去十年案例总结的教训清单（反面教材和正面经验）。
| 术语 | 全称 | 简要说明 |
|---|---|---|
| OSS | Open Source Software | 开源软件 |
| OSI | Open Source Initiative | 开放源代码促进会，开源定义的权威机构 |
| FSF | Free Software Foundation | 自由软件基金会，自由软件定义的权威机构 |
| OSD | Open Source Definition | 开源定义（10 条准则） |
| SaaS | Software as a Service | 软件即服务 |
| DBaaS | Database as a Service | 数据库即服务 |
| Copyleft | - | 强传染式开源策略，修改必须开源 |
| Permissive | - | 宽松许可证，无强制开源要求 |
| AGPL | GNU Affero General Public License | 网络 Copyleft 许可证 |
| GPL | GNU General Public License | 传统 Copyleft 许可证 |
| LGPL | GNU Lesser General Public License | 库级 Copyleft |
| MPL | Mozilla Public License | 文件级弱 Copyleft |
| SSPL | Server Side Public License | MongoDB 发起的服务端 Copyleft，非 OSI 开源 |
| BSL/BUSL | Business Source License | 延迟开源许可证，非 OSI 开源 |
| ELv2 | Elastic License v2 | 禁止托管服务的源可得许可证 |
| RSALv2 | Redis Source Available License v2 | Redis 2024 起采用的源可得许可证 |
| CCL | Confluent Community License | Confluent 发起的源可得许可证 |
| FSL | Functional Source License | Sentry 发起的延迟开源许可证 |
| CLA | Contributor License Agreement | 贡献者许可协议 |
| DCO | Developer Certificate of Origin | 开发者证书，CLA 的轻量替代 |
| SBOM | Software Bill of Materials | 软件物料清单 |
| SPDX | Software Package Data Exchange | 软件包数据交换标准，包含许可证标识符 |
| Fork | - | 基于某版本独立分叉开发 |
| Upstream | - | 上游项目（原项目） |
| Downstream | - | 下游项目（使用或基于上游的项目） |
| OSPO | Open Source Programs Office | 开源项目办公室 |
本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。
下面将主线时间线中的事件按时间顺序、以更细粒度的信息进一步展开，便于做培训或合规宣讲的引用。
未来值得关注的几条线索：
下面用一个简化的决策树帮助工程团队快速判断：“在我的项目里，应该选择什么许可证？”
你的项目核心类别是？
|
+----------------------+----------------------+
| |
基础库/SDK 服务端软件/数据库
| |
最大化采纳优先？ 需要保护商业化？
/ \ / \
是 否 是 否
| | | |
Apache 2.0 MIT 是否希望保留 Apache 2.0
/ MIT / BSD OSI 认证身份？ （默认推荐）
/ \
是 否
| |
AGPLv3 BUSL / ELv2 / RSALv2
（放弃开源标签）
|
精确定义 AUG / 禁止条款
|
准备社区 Fork 风险并制定回应策略这个决策树的核心信息：绝大多数场景下 Apache 2.0 是最优解。只有当你明确要”约束服务化使用”，并愿意承担社区反应代价时，才考虑 AGPL 或源可得方向。
记住一条简单的直觉：名字里含”Source Available”、“Business Source”、“Community License”的，基本都不是 OSI 意义上的”开源”。遇到要当作专有许可证处理。
本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。
上一篇：GPLv2、GPLv3、LGPL：Linux 内核为什么停在 v2
下一篇：木兰许可证与国产开源许可
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / opensource
面向做闭源/商业产品的团队：逐一拆解 MIT、LGPL、GPL、AGPL、SSPL、BSL 在 SaaS、私有化部署、移动 App、嵌入式固件等形态下的许可边界，给出三级名单模板、CI 扫描配置、SBOM 存证方案与出海补充要求。
2026-04-22 · architecture / opensource
从 MIT 到 AGPL，从 SPDX 标识符到 OSI 认证：一篇讲清楚四类开源许可证的边界、兼容性矩阵、SSPL/BSL 的争议、Commons Clause 事件，以及工程里最常见的踩坑场景和选型建议。
2026-04-22 · architecture / opensource
面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。
2026-04-22 · architecture / opensource
企业开源战略的完整决策框架：何时开源与为何开源、六种商业模式对比（Open Core/双许可/托管服务/支持服务/Source Available）、中国案例（PolarDB/OceanBase/TiDB/鸿蒙/麒麟）、协议改变的教训与代价、以及完整的决策树。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。