【开源许可与版权工程】AGPL、SSPL、BSL：云厂商时代的"反云"许可证

本文讨论的是一组”非典型”开源许可证：它们试图用条款而非技术，约束”拿开源代码做 SaaS 赚钱却不回馈”的云厂商。这组许可证自 2007 年的 AGPL 起，经 MongoDB SSPL、Elastic ELv2、HashiCorp BUSL，一路延伸到 2024 年 Redis 的 RSALv2，构成了”开源与云”十五年博弈的主脉络。

一、问题的起源：云厂商与”搭便车”困境

1.1 开源商业模式的原始假设

在云厂商崛起之前，开源软件（Open Source Software）的商业化路径基本围绕两种假设：

1. 分发假设：软件以二进制或源码形式分发给终端用户，许可证通过”分发”这一动作触发。GNU 通用公共许可证（GNU General Public License，简称 GPL）最初的设计就基于这种假设——只要不对外分发软件，内部修改无需披露源码。
2. 支持服务假设：开源公司通过为下载软件的用户提供付费支持、咨询、培训、企业版附加功能等方式赚钱。Red Hat、MySQL AB、SUSE 都是这一路线的代表。

传统 Copyleft（如 GPLv2/v3）的核心触发点是”conveying”（传递）——即把程序副本交到别人手中。只要你自己用、或者把程序跑在自己服务器上给别人用，其实都不触发传染条款。

1.2 SaaS 改变了一切

21 世纪初，软件即服务（Software as a Service，SaaS）与云计算（Cloud Computing）兴起。亚马逊网络服务（Amazon Web Services，AWS）2006 年正式推出 S3 和 EC2，微软 Azure 2010 年公测，阿里云 2009 年成立。

云厂商的商业模式与传统分发完全不同：

• 代码不离开机房：用户不再下载软件，而是通过网络访问运行在云上的软件副本；
• 不构成”分发”：从 GPL 的法律角度看，云厂商没有把”程序副本”交给任何人，传染条款不触发；
• 零义务 + 巨额收入：一个开源数据库项目花费数十人年构建，云厂商包装几周就能作为托管服务（Managed Service）卖给企业客户，营收可能超过原作者的数倍乃至数十倍。

业内把这种现象称为”Amazon 问题”（Amazon Problem），也叫”strip-mining”——一锄头挖走表层矿，留下一地废渣。MongoDB CEO Dev Ittycheria 曾在 2018 年的公开信中直接点名：某些云厂商”从开源软件中获取了巨大的经济利益，却没有以同等比例回馈社区”。

1.3 经济与工程的双重张力

围绕这场博弈，有几组结构性张力：

1. 投入与收益的错配：开源项目的核心维护通常由一家主力公司承担——MongoDB Inc. 之于 MongoDB、Elastic N.V. 之于 Elasticsearch、HashiCorp 之于 Terraform、Redis Ltd. 之于 Redis。这些公司承担了绝大多数研发成本，但云厂商的托管版本（ElastiCache、OpenSearch Service、DocumentDB）却稀释了其商业化空间。
2. 品牌与信任的争夺：当”AWS Elasticsearch Service”出现时，用户极易把它等同于 Elastic 官方服务，导致品牌混淆。
3. 贡献回流的不均衡：云厂商并非完全不贡献。AWS 对 Linux 内核、Kubernetes、Postgres 都有大量 PR；但对于某些公司级产品（如 MongoDB、Redis 单线程架构优化），云厂商的 upstream 贡献相对稀薄。
4. 开放标准与 API 兼容性：从技术层面说，MongoDB wire protocol、Redis RESP 协议、S3 API 都是事实标准，任何人都可以实现兼容层。这让云厂商即便不使用原始代码，也能用”wire-compatible”产品抢占市场——这恰恰是 AWS DocumentDB 的路线。

1.4 时间线速览（2007—2024）

从这张表可以看出一条规律：每当一个主力开源项目实施”反云”协议变更，往往在 12 到 24 个月内出现一个由云厂商或基金会主导的开源 Fork。这不是巧合，而是云厂商之间博弈均衡的结果——当一家公司锁死源码，其他云厂商宁可共同维护一个 Apache 2.0 分支，也不愿接受商业锁定。

二、AGPL v3（2007）：网络 Copyleft

2.1 AGPL 的设计意图

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）的回应。

2.2 §13 条款解读：AGPL 与 GPLv3 的关键差异

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.

拆解关键词：

1. “if you modify the Program”：只有在你”修改”了程序之后，才会触发第 13 节的披露义务。如果你只是未加修改地部署 AGPL 软件提供服务，理论上可以不披露源码（当然仍需保留原始许可证声明）。
2. “interacting with it remotely through a computer network”：用户通过计算机网络远程与程序交互，包括 HTTP API、WebSocket、gRPC、数据库协议等。SSH 登录到跑着修改版的服务器上使用命令行工具，也在讨论范围内。
3. “prominently offer … an opportunity to receive the Corresponding Source”：必须向这些远程用户”醒目地”提供获取对应源码的机会。实务上，通常的做法是在 Web 界面上放一个”获取源码”链接，或在 API 文档中指向 Git 仓库。
4. “Corresponding Source”：这个定义沿用自 GPLv3——包括可以构建、安装、运行修改版所必需的所有源码，还包括任何接口定义文件、用于控制工作流的脚本等。但不包括系统库、通用 Linux 发行版组件等。

2.3 AGPL 的工程影响：内部使用 vs 外部服务

这是工程师最容易搞混的一点。AGPL 并没有禁止”修改后不对外公开”。它禁止的是：

• 修改了 AGPL 程序；
• 把修改版以网络服务形式提供给”用户”；
• 却不给这些用户披露源码。

几种典型场景：

这里的”员工是否算用户”在法律上并没有绝对判例。保守的做法是：任何”超出本法人范围”的远程访问——包括子公司、外包团队——都按”对外服务”处理。Google 在内部政策中干脆禁止任何 AGPL 软件进入生产代码库，就是这种极端保守策略的体现。

2.4 哪些项目使用 AGPL

历史上和当前仍活跃的 AGPL 项目包括：

• MongoDB：2009 年到 2018 年间 MongoDB Server 采用 AGPLv3，2018 年迁移至 SSPL；
• Nextcloud：私有云协作平台，AGPLv3；
• Mastodon：去中心化社交网络服务端，AGPLv3；
• Matrix Synapse：Matrix 协议参考实现，Apache 2.0（注意：Synapse 本身是 Apache 2.0，而非 AGPL；Element Matrix Services 曾讨论过转 AGPL，但主仓库保持 Apache）；
• Grafana：2021 年之前是 Apache 2.0，之后全部迁移至 AGPLv3；
• GitLab Community Edition：MIT 许可证；GitLab EE 为商业；Mattermost（GitLab 曾集成）部分模块 AGPL；
• MinIO：对象存储服务，AGPLv3。

Grafana 的迁移是一个特别值得分析的案例。2021 年 4 月，Grafana Labs 宣布将 Grafana、Grafana Loki、Grafana Tempo 从 Apache 2.0 迁移至 AGPLv3。当时的公开理由是”希望生态里更多的改进能回流社区”。但更现实的解读是：作为可视化层，Grafana 被各种托管服务大量内嵌为 UI；切换到 AGPL 后，任何修改 Grafana 的托管服务都必须开源其修改，这对 Grafana Labs 自家的 Grafana Cloud 构成明显的竞争优势。

2.5 AGPL 的局限性

AGPL 虽然尝试填补 SaaS 漏洞，但仍有若干边界模糊：

1. “网络交互”的定义不够精确：例如一个 Web Worker 里的 AGPL 程序，通过浏览器 postMessage 与同页面其他脚本交互，算不算”网络交互”？一个 CLI 工具在远程 SSH 会话里运行呢？
2. 微服务组合难以界定”modified version”：如果你有一个 AGPL 服务 A，以及一个独立部署的专有服务 B，B 调用 A 的 HTTP API，B 是否算 A 的修改版？主流解释是：独立进程、独立网络接口调用不构成”修改”，但如果你把 A 的代码剪贴到 B 里再部署，那就是修改了。
3. “用户”的范围：AGPL §13 说”所有通过网络与之交互的用户”。但这些用户是否必须是”最终人类用户”，还是可以是上游调用者？一般解释是任何网络对端，包括其他服务。
4. 企业内部政策差异：Google 在《Google Open Source Licenses》政策中明确把 AGPL 归入”Restricted”类别，默认禁止引入；这并非因为 AGPL 违法，而是合规成本高于收益。许多国内大型云厂商的内部政策也效仿此做法。

AGPL 填补了一部分漏洞，但远远不够——它的”触发阈值”还是”修改”。只要云厂商不修改上游代码，只是包装运维和监控，AGPL 就不触发。这恰恰是 MongoDB 后来转向 SSPL 的直接原因。

三、MongoDB SSPL（2018）：比 AGPL 更激进

3.1 SSPL 出现的背景

2018 年 10 月 16 日，MongoDB Inc. 宣布将 MongoDB Community Server 的许可证从 AGPLv3 迁移到一份新的许可证：服务器端公共许可证（Server Side Public License，简称 SSPL）。

表面上的时间线是这样的：

1. MongoDB 自 2009 年起以 AGPLv3 发布；
2. AWS、阿里云、腾讯云等厂商陆续推出”MongoDB 兼容”的托管数据库服务；
3. 2018 年起，MongoDB Inc. 判断 AGPL 已不足以约束这些云厂商——因为云厂商通常不修改社区版代码，而是把运维、监控、备份、自动伸缩等外围功能包装在 MongoDB 之外；
4. MongoDB 起草 SSPL，试图把传染范围扩展到”服务全栈”。

而 2019 年 1 月，AWS 顺势推出 DocumentDB（with MongoDB compatibility），被广泛认为是对 MongoDB 的直接对抗——尽管 DocumentDB 并没有使用 MongoDB 的源码，只是实现了 wire protocol 的兼容层。

3.2 SSPL §13 解读

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.

这段条款的影响是颠覆性的：

1. 触发条件放宽：不再要求”修改”。只要你把程序功能”作为服务对外提供”，就触发披露义务；
2. 披露范围扩展：不仅要披露程序本身源码，还要披露”用于把它做成服务”的所有程序——管理软件、用户界面、API、自动化、监控、备份、存储、托管软件；
3. 闭环条款：“使得用户能够用你披露的源码运行一个等价的服务实例”——实务上意味着配置、脚本、部署代码都必须披露。

对于一家大型云厂商而言，遵守 SSPL §13 几乎不可能：因为”用于把它做成服务”的全部软件，通常包括大量与云平台核心深度耦合的私有代码——计费、身份识别、监控告警、运维自动化等等。这些代码往往是云厂商的核心商业秘密，不可能公开。

因此，SSPL 的设计目的其实是把云厂商从社区版的用户中排除出去，迫使他们要么签商业许可证，要么放弃使用 MongoDB。

3.3 为什么 OSI 不认证 SSPL

开放源代码促进会（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 并列的”非开源”类别。

3.4 MongoDB 的双许可策略

MongoDB 的实际商业模型是”开放核心”（Open Core）+ 双许可：

1. 核心数据库：SSPLv1（社区版）；
2. 企业版（MongoDB Enterprise Advanced）：私有商业许可证，包含审计、Kerberos、LDAP、加密等功能；
3. Atlas（托管云服务）：私有商业；
4. 客户端驱动（Drivers）：Apache 2.0——这是关键工程细节。

客户端驱动单独使用 Apache 2.0，意味着：

• 应用程序使用 MongoDB 驱动连接任何 MongoDB 兼容服务（社区版、Atlas、DocumentDB、Azure Cosmos）时，不受 SSPL 约束；
• SSPL 只影响运行 MongoDB 服务本身的实体，不影响使用它的应用程序。

这是一种经过精心设计的条款结构：保护商业护城河的同时，最大化生态里的应用开发者基数。

MongoDB 的贡献者许可协议（Contributor License Agreement，简称 CLA）也值得一提。所有向 MongoDB 主仓库贡献代码的贡献者必须签署 CLA，把他们的贡献版权的双许可授权权让渡给 MongoDB Inc.，这使得 MongoDB 能持续以 SSPL + 商业双许可模式运作——包括未来再次切换许可证的能力。

3.5 Amazon 的回应：DocumentDB

2019 年 1 月，AWS 发布 Amazon DocumentDB（with MongoDB compatibility）。关键技术事实：

1. 不是 Fork：DocumentDB 并未基于 MongoDB 源码二次开发，而是 AWS 从零实现了一个兼容 MongoDB Wire Protocol 的数据库系统；
2. 底层不同：DocumentDB 底层据公开资料是基于 Aurora 的分布式存储，与 MongoDB 的 WiredTiger 存储引擎架构完全不同；
3. 兼容性有限：DocumentDB 对 MongoDB 3.6 和 4.0 的 API 兼容性较好，但高级特性（如聚合管道后期算子、事务跨分片）初期有缺失；
4. 许可不受 SSPL 约束：既然没有使用 MongoDB 代码，SSPL 就没有管辖权。

MongoDB 在 2019 年提起过对 DocumentDB 的公开批评，但未提起版权诉讼——因为 AWS 没有复制代码。MongoDB 的主张更多是”商标和品牌混淆”类型的间接主张。

这个案例揭示了一个基本事实：Wire Protocol 和 API 本身并不受著作权法保护（参考美国最高法院 Oracle v. Google 案的结论），因此云厂商总能通过”从零实现兼容层”的方式绕开任何基于版权的许可证。SSPL 的威慑力有限。

四、Elastic/Kibana 改协议（2021）与 OpenSearch

4.1 事件经过

2021 年 1 月 14 日，Elastic N.V. 宣布将 Elasticsearch 和 Kibana 的许可证从 Apache 2.0 迁移至双许可：SSPLv1 和 Elastic License v2（ELv2）。这是继 MongoDB 之后，又一次”明星级”Apache 项目转向源可得许可证。

Elastic CEO Shay Banon 在公开信中把这件事的起因直接指向 AWS：

1. AWS 自 2015 年起推出 Amazon Elasticsearch Service（AES），作为托管版 Elasticsearch；
2. Elastic 指控 AWS “误导用户”，让用户以为 AES 是 Elastic 官方服务；
3. Elastic 还提到 AWS 推出的 Open Distro for Elasticsearch（2019）——一个把 Elastic 的 X-Pack 商业功能用开源方式重新实现的 Fork；
4. 2019—2020 年间 Elastic 与 AWS 在商标层面多次交锋。

Elastic 的改协议，本质是”如果不能阻止 AWS 做托管，那就让 AWS 无法继续用最新源码”。

4.2 ELv2（Elastic License v2）

ELv2 是一份比 SSPL 简短得多、更聚焦的源可得许可证。它的核心限制有三条：

1. 不得作为托管/管理服务提供给第三方：你不能把软件功能的”实质全部或重要部分”作为托管服务对外提供；
2. 不得绕过许可证执行机制：不能修改或禁用软件内置的许可证校验逻辑；
3. 不得去除/修改版权与许可证声明：必须保留原始许可证文本。

ELv2 不要求像 SSPL 那样披露全部服务源码，它采用的是”禁止性”而非”传染性”路径。对大多数企业内部自用、SaaS 应用内嵌、客户侧部署都非常宽松；仅对”直接与 Elastic Cloud 竞争的托管服务提供商”构成限制。

从工程合规的角度看：

• 可以：在你的 SaaS 应用里使用 Elastic 做搜索（你卖的是应用不是 Elastic）；
• 可以：企业内部日志分析；
• 不可以：把 Elastic 本身打包成托管服务卖给别人（这就是 AWS 想做的事情）；
• 不可以：破解 Elastic 商业版的授权校验。

但 ELv2 仍然不是开源许可证。OSI 未认证，FSF 也未认证。

4.3 OpenSearch Fork（2021）

Elastic 宣布改协议后不到 4 个月，2021 年 4 月 12 日，AWS 宣布将 Open Distro for Elasticsearch 升级为独立 Fork，命名为 OpenSearch。关键事实：

1. Fork 来源：基于 Elasticsearch 7.10（最后一个 Apache 2.0 版本）及 Kibana 7.10；
2. 许可证：OpenSearch 保持 Apache 2.0；
3. 治理：初期由 AWS 主导，2024 年转为 Linux 基金会下的 OpenSearch Software Foundation，成员包括 AWS、阿里云、SAP、Uber、Canonical 等；
4. 兼容层：OpenSearch 保留了与早期 Elasticsearch 版本的 API 兼容，但此后分叉路线逐渐独立。

从这次 Fork 起，搜索引擎生态被一分为二：

• Elastic 阵营：Elasticsearch 8.x/9.x（ELv2+SSPL）、Elastic Cloud、官方客户端；
• OpenSearch 阵营：OpenSearch 2.x/3.x（Apache 2.0）、AWS OpenSearch Service、阿里云 ES 服务、华为云搜索服务。

4.4 后续影响

2024 年 8 月，Elastic 又做了一次协议调整：将 Elasticsearch 加入 AGPLv3 作为第三种许可选项，形成 ELv2 + SSPLv1 + AGPLv3 三重许可。官方解释是”回归开源”。AGPLv3 是 OSI 认证的开源许可证，这一步让 Elasticsearch 重新可以被称为”开源”项目（在三选一场景下）。

但从工程角度看：

1. 对云厂商而言，ELv2 和 SSPL 的限制仍然存在——AGPL 不解锁托管服务的权利；
2. 对 OpenSearch 阵营的影响有限——他们已经有了 Apache 2.0 的独立代码库和社区；
3. 这更像是一次品牌/形象修复，而非实质性开放。

与此同时，Grafana Labs 在 2021 年 4 月跟进，将 Grafana、Loki、Tempo 从 Apache 2.0 迁移至 AGPLv3。Grafana Enterprise 保留商业条款。这种”双层结构”——AGPL 社区版 + 商业增强版——成为许多开源公司的新范式。

五、HashiCorp BSL（2023）与 OpenTofu

5.1 Business Source License（BSL/BUSL）简介

业务源码许可证（Business Source License，缩写为 BSL，也写作 BUSL，最新版本 1.1）由 MariaDB 公司于 2013 年前后提出，最初用于 MariaDB MaxScale 等产品。其最独特的设计是”延迟开源”：

1. Change Date（变更日期）：许可证条款中设定一个未来日期，通常为发布后 4 年；
2. Change License（变更许可证）：许可证指定一个未来将转换为的开源许可证，如 Apache 2.0 或 MPLv2；
3. Additional Use Grant（附加使用授权）：在 Change Date 之前，允许哪些非竞品用途；
4. 默认限制：除 Additional Use Grant 规定之外，Change Date 之前禁止将软件用于商业用途。

到了 Change Date，当前发布版本自动转换为 Change License。这是 BSL 与其他”源可得”许可证的最大区别——它有一个可预期的开源时间表。

5.2 HashiCorp 的决定

2023 年 8 月 10 日，HashiCorp 宣布将其旗舰开源产品 Terraform、Vault、Consul、Nomad、Boundary、Waypoint、Packer 全部从 Mozilla Public License 2.0（MPLv2）迁移至 BUSL 1.1。

关键参数：

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 产品构成竞争的托管或嵌入式服务”——这个定义在实务上覆盖了大量场景：

• Terraform Cloud 的竞品（Env0、Spacelift 等）是否被禁止？官方后续博客澄清：非纯 Terraform 托管 SaaS 的 CI/CD 集成平台通常不受影响，但仍需个案判断；
• 云厂商是否可以把 Terraform CLI 嵌入自家控制台？如果构成”以托管或嵌入方式提供 Terraform 给第三方且与 HashiCorp 竞争”，则受限；
• 企业内部使用 Terraform 管理自家基础设施？完全允许。

5.3 OpenTofu Fork

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 的关键事实：

1. 源代码基础：Terraform 1.5.x（最后一个 MPLv2 版本）；
2. 许可证：继续使用 MPLv2；
3. 治理：Linux 基金会下的独立项目，有技术指导委员会（TSC）；
4. CLI 兼容：与 Terraform CLI 命令行和模块基本兼容，tofu init 替代 terraform init；
5. Registry：独立于 HashiCorp 的 Terraform Registry，建立自己的模块/Provider 注册表。

5.4 BSL 的工程影响

对工程团队而言，BSL 的几个重要影响：

1. BUSL 不是开源：OSI 和 FSF 都不认证 BUSL。合规流程、开源公司政策、投资尽调时应按”专有许可证”处理；
2. “延迟 4 年开源”的不确定性：条款写的是”4 年后转 MPLv2”，但这个承诺在法律上是否可撤销、在公司被收购后是否仍然生效，都有争议。主流解读是：已经发布的特定版本适用的 Change Date 承诺，以 LICENSE 文件中的文本为准，不可单方面更改；但未来发布的新版本，公司有自由权改变其 Change License 或 Change Date；
3. Additional Use Grant 的解释风险：这部分由软件作者单方面定义，定义不清晰时存在解释空间。HashiCorp 的 FAQ 多次调整过解释，这在企业合规看来是不稳定信号；
4. Fork 策略的紧迫性：任何希望长期基于 BUSL 代码构建商业系统的团队，最好的策略是：Fork 最后一个开源版本，自行维护。OpenTofu、OpenSearch、Valkey 都是这个策略的产物。

5.5 其他使用 BSL 的项目

• CockroachDB：2019 年从 Apache 2.0 迁移至 BSL（Change License: Apache 2.0, Change Date: 3 年），同时推出 Cockroach Cloud 免责条款（Cockroach Labs 自己的云服务不受 Additional Use Grant 限制）；2024 年 CockroachDB 进一步收紧，开源版本停止发行，核心代码变为完全专有；
• MariaDB MaxScale：MariaDB 自家产品，BSL 的起源地；
• Sentry：错误跟踪平台，2019 年从 BSD-3-Clause 迁移至 Functional Source License（类似 BSL 但不同条款）；
• Couchbase Server：社区版使用 BUSL 1.1。

每一次 BSL 迁移，社区都会经历一次”信任重置”。即便 HashiCorp 在条款文本层面已经非常克制（明确保留了内部使用、非竞品 SaaS 嵌入等），Fork 的发生仍然几乎不可避免——因为社区方无法承担”协议条款随时可能变得更严格”的长期风险。

六、Redis 改协议（2024）与 Valkey

6.1 Redis 的许可证变化历史

Redis 项目的许可证演进在社区里被反复讨论，是一段典型的”从 BSD 出发，逐步源可得化”的历史：

2024 年 3 月 20 日的官方公告中，Redis Inc. 表示此举是为了”确保那些通过托管 Redis 赚取可观收入的云服务提供商为 Redis 的开发作出贡献”。点名对象明显指向 AWS ElastiCache、阿里云云数据库 Redis 版、Google MemoryStore 等托管服务。

6.2 RSALv2（Redis Source Available License v2）

RSALv2 与 ELv2 结构非常相似，核心限制两条：

1. 不得作为数据库即服务（Database as a Service，简称 DBaaS）对外提供：任何包装 Redis 并作为托管数据库服务销售给第三方的行为被禁止；
2. 不得绕过许可证校验机制：类似 ELv2 的反逃避条款。

允许的行为：

• 企业内部使用 Redis 作为缓存/数据库；
• SaaS 产品内嵌 Redis 作为底层组件（只要 SaaS 卖的不是”Redis 本身”）；
• 分发二进制，只要不是托管服务形式。

和 ELv2 类似，RSALv2 不是开源许可证——OSI、FSF 均未认证。双许可 RSALv2 + SSPLv1 的设计也与 Elastic 类似：用户可自选其一。

6.3 Valkey Fork（2024）

Redis 改协议公告发布仅 8 天后，2024 年 3 月 28 日，Linux 基金会宣布主持 Fork——Valkey。Fork 起点是 Redis 7.2.4（最后一个 BSD-3-Clause 版本）。

Valkey 的关键事实：

1. 许可证：继续使用 BSD-3-Clause；
2. 治理：Linux 基金会下的独立项目；
3. 主要赞助者/贡献者：AWS、Google Cloud、Oracle、Ericsson、Snap Inc.、阿里云；
4. Redis 前核心开发者加入：包括 Madelyn Olson（AWS，前 Redis 维护者）、Viktor Söderqvist（Ericsson，Redis Cluster 领域）、Ping Xie、Zhao Zhao 等；
5. Redis 7.2 兼容：协议、命令、配置基本兼容，便于从 Redis 迁移；
6. 发展节奏：Valkey 7.2、8.0 快速发布，8.0 版本在多核 IO 多线程上引入与上游 Redis 不同的优化路径。

一个引人注意的细节：Redis 项目本身在 2024 年晚些时候重新请回了原作者 antirez（Salvatore Sanfilippo），并发布了 Redis 8.0，同时在 2025 年宣布增加 AGPLv3 作为第三种许可证选项（类似 Elasticsearch 的回归尝试）。但 Valkey 社区已经形成，两个项目长期共存的可能性很高。

6.4 从阿里云视角看

阿里云 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 是成本最优的博弈结果。

七、其他”反云”许可证

7.1 Confluent Community License（2018）

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.

注意三点：

1. Apache Kafka 本身仍然是 Apache 2.0：CCL 只影响 Confluent 自家的附加组件；
2. 禁止”托管或管理服务”：精确针对”Kafka SaaS”场景；
3. OSI 未认证：与其他”反云”许可证一样是源可得。

7.2 CockroachDB BSL

Cockroach Labs 于 2019 年 6 月把 CockroachDB 从 Apache 2.0 迁移至 BSL（早期版本，非 1.1），Change Date 为 3 年后，Change License 为 Apache 2.0。

关键条款：

• 允许：内部使用、应用嵌入式使用；
• 不允许：把 CockroachDB 本身作为托管数据库服务对外提供；
• 豁免例外：Cockroach Labs 自家的 CockroachDB Cloud 不受此限制（自己不会限制自己）。

但故事没有结束：2024 年 8 月，Cockroach Labs 进一步宣布从 BSL 迁移至完全专有的 CockroachDB Enterprise License，停止开源版本发行。这被视为”开放核心”走到尽头的又一案例。

7.3 MariaDB BSL

MariaDB 作为 BSL 的发明者，自家产品 MariaDB MaxScale 长期使用 BSL。MariaDB Server 核心则仍是 GPLv2，未受影响。

7.4 FSL 与 FCL（Functional Source License / Fair Core License）

2023—2024 年间出现了一批新的”源可得”变体：

• Functional Source License（FSL）：由 Sentry 提出，2 年后转 Apache 2.0 或 MIT；限制比 BSL 更具体（仅禁止”Competing Use”，定义清楚）；
• Fair Core License（FCL）：Keygen 提出，类似 FSL；
• Elv2/RSALv2/CCL/FSL/FCL 这些都属于”Source Available”大类，工程合规流程中应一视同仁按非开源处理。

八、中国云厂商的响应策略

8.1 阿里云

阿里云作为国内最大公有云厂商，在开源许可证策略上表现得尤其谨慎。几个关键观察：

1. AGPL 策略偏保守：阿里云在其技术博客多次公开表达对 AGPL 风险的重视；内部对 AGPL 软件的引入通常需要严格的合规审批；
2. MongoDB → MongoDB 兼容/替代：阿里云 MongoDB 服务长期维护社区版兼容；在 2018 年 SSPL 事件后，阿里云一方面与 MongoDB 商业合作，另一方面推动自家 Lindorm（原 HBase 增强版，支持宽表和 KV）作为替代；
3. Elasticsearch → OpenSearch：阿里云搜索服务在 OpenSearch 可用后，快速支持 OpenSearch 版本；国际版更倾向于 OpenSearch 路线；
4. Redis → Valkey：2024 年成为 Valkey 创始赞助者；ApsaraDB 产品线同步支持 Valkey；
5. Terraform → OpenTofu 观望：阿里云提供 Terraform Provider（开源 Apache 2.0），在 HashiCorp BUSL 事件后未立即表态 Fork，主要观察 OpenTofu 发展节奏。

阿里云自身的开源策略值得一提：包括 Higress、Nacos、Dubbo、Seata、RocketMQ、Spring Cloud Alibaba 等项目绝大多数使用 Apache 2.0。这一选择不仅是对社区友好，也是让其他云厂商愿意采用的必要条件——避免国外客户因为许可证原因拒绝。

8.2 腾讯云

腾讯云的策略与阿里云类似：

1. 对 AGPL/SSPL/BSL 软件在云服务中的使用持谨慎态度；
2. 向量检索产品线（Tencent Cloud VectorDB）与向量引擎内部实现倾向于自研或基于 Apache 生态；
3. Redis 生态：支持 Valkey 方向，同时维护兼容层；
4. 开源项目：TarsFramework、KonaJDK、TencentOS Tiny 等使用 Apache 2.0 或 BSD-3-Clause，符合”让云厂商都能采用”的策略。

8.3 华为云

华为云因自身定位（运营商/政企市场为主），对许可证合规的敏感度更高：

1. OpenEuler、openGauss、MindSpore、CANN：全部使用 Mulan PSL v2（木兰宽松许可证第 2 版，与 Apache 2.0 等价）；
2. Elasticsearch 替代：OpenSearch 部署作为托管服务；
3. 公开立场：未在云服务中直接使用 SSPL 许可的最新版 MongoDB、Elasticsearch、Redis 代码；MongoDB 服务类产品倾向自研或合作模式；
4. Kunpeng 开源社区：鼓励其生态项目使用宽松许可证以最大化跨厂商适配。

8.4 OceanBase 与 TiDB 的许可证战略

国内两大自研分布式数据库的许可证选择，代表了”中国开源基础软件如何避免反云博弈困境”的两种思路。

OceanBase

• 2021 年 6 月：蚂蚁集团 OceanBase 社区版开源，最初使用 MulanPSL v2；
• 2023 年 12 月：OceanBase 调整许可策略，主线使用 Apache License 2.0，部分旧分支保留 MulanPSL；
• 底层策略考量：
  • Apache 2.0 是国际社区最熟悉、云厂商最容易接受的许可证；
  • 作为蚂蚁/阿里系产品，其”被云厂商广泛采纳”比”限制云厂商”更重要——这与 MongoDB 不同，后者是数据库纯厂商，没有云业务；
  • OceanBase 既有阿里云托管版（OceanBase Cloud），也鼓励其他云厂商（甚至竞品）合作；宽松许可是跨厂商推广的必要条件。

TiDB

• PingCAP 自 2015 年 TiDB 开源起就采用 Apache License 2.0，至今未变；
• 工程设计上把商业增强能力放在外围生态（DM、TiEM、Chaos Mesh 商业版、TiDB Cloud 等）；
• 公开立场：PingCAP 多次表达”不计划走 MongoDB/Elastic 路线”，认为 Apache 2.0 是全球化推广的基础。

为什么国内这两家选择 Apache 而不是 SSPL/BSL

从博弈角度看：

1. 市场进入策略不同：MongoDB/Elastic/Redis/HashiCorp 是全球市场的”既得利益者”，面对云厂商的挑战是”防御”；OceanBase/TiDB 是”挑战者”，要从 MySQL/PostgreSQL/Oracle 的格局中抢市场，必须最大化采纳率；
2. 云厂商依赖：国内数据库软件商的主要销售路径是与云厂商合作（以及头部金融/政企自建）。使用 SSPL 会直接把阿里云以外的云厂商变成对手，严重损害商业机会；
3. 国际化：要走出国门，Apache 2.0 是最顺滑的通行证。采用 SSPL/BSL 会在尽调阶段就被国际客户划入”高风险供应商”；
4. 贡献者生态：Apache 2.0 的 CLA/DCO 流程成熟；SSPL 会显著降低外部贡献者意愿。

这是一种”用宽松换生态、用生态换市场”的战略选择。与 MongoDB 所处阶段的策略差异本质上源于博弈位置不同。

九、工程坑点

9.1 AGPL 传染的边界判断

工程团队在合规流程中最常纠结的两个问题：

问题 A：把 AGPL 服务包装成我们 SaaS 的一部分，传染范围多大？

• 如果你未修改 AGPL 服务本体，只是在外层写了网关/配置/UI，AGPL §13 不触发；但你仍需满足”分发层面”义务（未分发时义务有限）；
• 如果你修改了 AGPL 服务（例如打了 patch、改了默认参数以外的行为、裁剪了代码），则 §13 触发——需要向远程用户披露修改版源码；
• “用户”包含所有通过网络与之交互的对象，包括你自家其他微服务的 SSO 网关、日志采集、API 调用者——除非你能证明这些都是”同一法人实体内部使用”。

问题 B：AGPL 微服务调用非 AGPL 微服务，会传染吗？

• 一般观点：独立进程 + 独立网络边界 + 明确定义的网络协议不构成 GPL 意义上的”combined work”；
• 但要注意：如果 AGPL 服务的源码里嵌入了非 AGPL 代码（例如 vendor 进来、链接进来），那就形成组合作品；
• 实务建议：严格遵守”进程边界”，AGPL 进程和非 AGPL 进程物理隔离，只通过稳定的网络协议交互；避免 Go vendor / Java shade / Python 混合打包。

Google 式策略

Google 的做法是最保守的：“AGPL 软件全面禁用”。理由不是 AGPL 违法，而是：

1. 合规边界复杂，审查成本高于替代成本；
2. 内部系统调用图极其复杂，任何一个 AGPL 进程可能触发整个服务图的披露风险；
3. 披露企业内部基础设施源码的代价远大于重写替代品。

国内头部互联网公司内部政策大多同样保守。

9.2 SSPL/BSL 不是开源——采购与合规的影响

许多国内工程师不清楚”SSPL / ELv2 / BUSL 不是开源”意味着什么。几个实际影响点：

1. 企业开源合规政策：绝大多数大型企业内部《开源软件使用政策》规定”仅允许使用 OSI 认证的许可证”。SSPL、ELv2、BUSL、RSALv2、CCL 全部不被 OSI 认证，属于”需要额外审批”的类别；
2. 投资与并购尽调：开源软件依赖表（Software Bill of Materials，SBOM）中出现 SSPL 依赖，会被尽调团队标红；买方会要求解释使用范围、是否有替代方案、是否已签商业许可；
3. 安全审计：部分企业的安全审计流程要求所有第三方代码必须可审计，SSPL 代码虽然可见但在”不能修改、不能重分发、不能构建替代”意义上比开源更受限；
4. 政府/国企招标：许多招标文件要求”使用开源软件”，OSI 认证成为事实判定。SSPL 软件可能被认定为”专有软件”而退出某些候选名单；
5. 开源基金会生态：Apache、Linux、CNCF 等基金会项目有明确政策禁止依赖非 OSI 许可证，将 SSPL 依赖引入这些项目会被打回。

9.3 许可证变更的不可逆性

这是最容易被忽视的法律事实：软件的某个特定版本一旦以某个许可证发布，该许可证永久有效。

• Redis 7.2.4 以 BSD-3-Clause 发布 → 任何人都可以永远以 BSD-3-Clause 为基础 Fork、使用、修改、分发；
• Redis 7.4 以 RSALv2+SSPL 发布 → 这个版本本身在 RSALv2+SSPL 下使用，但 7.2.4 的权利不受影响；
• 这就是 Valkey 能基于 Redis 7.2.4 合法 Fork 并独立演进的法律基础。

Fork 策略的关键：

1. fork at last open version：找到最后一个宽松许可证版本，从这里起 Fork；
2. git history 考古：git log -p path/to/LICENSE 可以看到 LICENSE 文件的历史；使用 git show <commit>:path/file 查看特定版本的文件许可证；
3. 保留证据：Fork 时保留原始 LICENSE、COPYRIGHT、NOTICE 文件不变；新增贡献的版权声明单独组织。

一个具体的命令示例：

# 以 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 的”。

9.4 双许可（Dual License）模型的陷阱

MongoDB、Redis、Elastic、MySQL 都是双许可模型的典型：社区版 + 商业版。工程使用时的常见陷阱：

1. 你拿到的软件适用哪个许可证？：通常看你的分发渠道——从官方网站下载社区二进制，适用社区许可证；从销售签的商业合同，适用商业许可证。开源版和商业版不能混用！
2. CLA 的影响：以 MongoDB 为例，所有贡献者签 CLA，把双许可授权权让渡给 MongoDB Inc.。这意味着贡献者的代码可能被 MongoDB 以商业许可卖给第三方——即便你本意只希望它开源；
3. 依赖的可替换性：同一份代码既是 SSPL 又是商业版，你以为自己在用 SSPL，但如果 SSPL 后续再被 Relicense 到更严格的协议，你只能选择”停留在旧版”或”签商业合同”；
4. 再分发限制：双许可模式下，SSPL/商业版代码不能被下游合并到 Apache 2.0 项目中——这会污染下游的许可证纯度。

9.5 Change Date 的法律稳定性

BSL/BUSL 的 Change Date 承诺：

• 对已发布的特定版本：在该版本的 LICENSE 文件中明确写出的 Change Date 是合同性承诺，一般认为不可单方面撤回；
• 对未来版本：上游可自由调整 Change Date、Change License、Additional Use Grant——下游只能以 Fork 应对；
• 公司破产/被收购：法律上新所有者一般继承原公司条款义务，但实际执行路径复杂，社区通常认为”公司不等于项目”，提前 Fork 是更稳妥的策略。

9.6 微服务 SBOM 与许可证传染图

对于微服务架构的企业，建议在 CI 流水线中：

1. 生成 SBOM：使用 Syft、CycloneDX 等工具生成每个服务的软件清单；
2. 扫描许可证：用 FOSSology、ScanCode 等工具识别；
3. 构建许可证传染图：把服务间调用关系与各服务内部依赖的许可证映射出来——AGPL 节点要特别标注；
4. 策略引擎：Open Policy Agent（OPA）等工具可以在 PR 合并时阻断引入禁止类许可证的变更。

9.7 常见许可证对比速查表

为方便工程师在代码评审、合规审批、SBOM 扫描时快速判断，下面给出一张”反云博弈”语境下常见许可证的对比表。

9.8 合规流程建议：一个可落地的检查清单

对于中大型企业的工程与法务团队，建议把下列项固化到合规流程中：

1. SBOM 生成与归档：每次发布前生成完整 SBOM，归档至少 10 年；
2. 许可证策略分级：将许可证分为”允许”、“需审批”、“禁止”三类，清单随更新同步；
3. 许可证扫描工具：集成 ScanCode、FOSSology、Syft + Grype、license-checker 等工具；
4. PR 级门禁：在 CI 中对新增依赖自动检查许可证；若引入禁止类许可证，直接阻断合并；
5. 定期依赖审计：每季度全面扫描，捕获上游项目的许可证变更；
6. 贡献者协议：自家开源项目统一选 DCO 或 CLA，并保留变更许可证的能力（类比 MongoDB、HashiCorp 的 CLA）；
7. 法务储备意见库：对 AGPL §13、SSPL §13、BUSL Additional Use Grant 等高争议条款，预先准备内部法务的使用解读文档；
8. 变更预案：重要依赖（如数据库、消息队列、观测系统）制定”许可证突变应急方案”——即”如果明天上游改协议，我们怎么办”。

9.9 一个真实场景演练：Redis 改协议后一家 SaaS 公司的决策

假设你是一家 SaaS 公司的架构负责人，2024 年 3 月 20 日晨间看到 Redis Inc. 的公告：核心 Redis 从 BSD-3-Clause 改为 RSALv2+SSPLv1。你的生产系统：

• 使用 Redis 作为应用缓存层（大量）；
• 使用 Redis Sentinel 做高可用；
• Redis 托管在自建集群（非 ElastiCache）；
• Redis 版本是 7.2.3（最新）。

第一步：评估 RSALv2 对当前场景的影响

• RSALv2 限制的是”提供 DBaaS 给第三方”；
• 你是 SaaS 公司，卖的是应用不是 Redis → 并不构成 DBaaS；
• 结论：即便升级到 Redis 7.4（RSALv2 版本），你的业务场景不违反 RSALv2 条款。

第二步：评估合规与尽调风险

• 如果你即将经历 IPO/并购尽调：RSALv2 会出现在 SBOM 中并被标红，需准备解释说明；
• 如果你出售给对非开源敏感的客户（如部分政企）：可能需要向客户额外解释；
• 如果你自己的产品打算”开源”其中某些组件：SSPL 依赖可能污染你的开源主张。

第三步：评估 Valkey 替换的工程成本

• Redis 7.2 与 Valkey 7.2 协议/命令层面基本兼容 → 替换成本低；
• 客户端驱动：大多数 Redis 客户端（redis-py、lettuce、go-redis）与 Valkey 无缝兼容；
• 运维工具链：Sentinel 协议兼容，Cluster 模式兼容；
• 高级特性（Redis Stack 的 RediSearch、RedisJSON 等）：Valkey 正在推进替代模块（如 valkey-bloom），但生态尚需时间。

第四步：决策矩阵

典型务实结论：中短期锁定 Redis 7.2.x 保持稳定，并行在测试环境验证 Valkey，6—12 个月内完成生产切换。

9.10 FAQ：容易搞错的几个问题

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：几个真实案例的路径：

• 如果想保持”OSI 认证的开源”身份 → AGPLv3（限制有限，但不会被基金会拒绝）；
• 如果愿意放弃”开源”身份换取更强的防御 → BUSL（有时间表）或 ELv2/RSALv2（无时间表）；
• 如果希望彻底排除云厂商用最新版 → SSPL（但面临 OSI 拒绝、社区反弹、基金会不接纳的代价）。

没有一个免费午餐选项。更深层的建议是：靠产品力而不是条款。真正的反云护城河，是云厂商的托管版做不到你 SaaS 版的功能，而不是禁止他们使用。

Q7：Valkey / OpenSearch / OpenTofu 会不会再被改协议？

A：一般认为不会，原因：

• 这几个项目都在 Linux 基金会名下，基金会的 IP Policy 明确要求项目维持开源许可证；
• 治理结构是多厂商共治，单一实体无法单方面改协议；
• 代码的版权分散在众多贡献者和公司手中，没有统一的 Copyright Assignment，重新授权在法律上几乎不可能；

这恰恰是基金会模式相对”单一公司主导开源”的核心价值：治理中立性带来许可证稳定性。

9.11 与 Copyleft 传统项目的关系

值得单独说明的一个误区：很多工程师把 AGPL、SSPL、BSL 都混在一起叫”限制性许可证”，但它们的法律属性差异巨大：

1. AGPL 是 Copyleft：强制传染，但允许任何用途（包括商业）；它是 OSI 认证的自由软件。
2. SSPL 是”超级 Copyleft”：试图把传染扩展到”服务全栈”。但 OSI 认为它违反 OSD #9，因此不是开源。
3. BUSL 是”延迟开源”：本质是专有许可证，加一个时间开关；完全不是 Copyleft——不要求下游披露任何源码。
4. ELv2/RSALv2/CCL 是”禁止性源可得”：源码可见，但禁止特定竞品用途；不是 Copyleft，不是开源。

在内部合规政策中，应该明确区分这四类，而不是笼统地按”限制”强度排序。

9.12 如何跟上变化：许可证监控实践

许可证变更常常在数天之内就从公告发展到 Fork。工程团队应建立监控：

1. 上游仓库 LICENSE 文件的 commit：使用 GitHub 的 Watch / RSS 订阅；
2. 关键依赖的 release notes：订阅主要依赖的官方博客、邮件列表；
3. OSI license-review 邮件列表归档；
4. Linux 基金会新项目公告：基金会接纳新项目常常意味着”上游改协议，Fork 成立”；
5. SPDX 标识符更新：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 中接入此脚本，就能把许可证合规从”人工审查”升级为”自动门禁”。

9.13 观察：Fork 成功的共同模式

分析 OpenSearch、OpenTofu、Valkey 三次 Fork 的共同点，可以抽取”成功 Fork”的模式：

1. 多厂商联盟而非单一厂商：OpenSearch 由 AWS 牵头但 Linux 基金会承接；OpenTofu 由 10+ 公司联署；Valkey 由 AWS、Google、阿里、Oracle 等联合支持；
2. 基金会中立治理：三者最终都归属到 Linux 基金会或其子基金会；
3. 保留兼容性窗口：Fork 不走”颠覆式重构”路线，而是保留与上游最后开源版本的 API/协议兼容，降低迁移成本；
4. 快速建立 Registry/生态：OpenTofu 快速建立独立 Registry；OpenSearch 快速建立 Plugin 目录；Valkey 继承 Redis 客户端生态；
5. 吸纳上游核心贡献者：Valkey 直接吸纳了 Redis 前核心维护者；OpenSearch 吸纳了部分原 Elastic 贡献者；
6. 明确的治理边界：从一开始就建立 TSC（Technical Steering Committee）或类似决策机构，避免未来单一公司再次”协议劫持”。

反过来，失败或半死的 Fork 往往在上述一点或多点缺位——例如只有一家厂商推动、没有基金会背书、兼容性断裂、Registry 重建慢等。

十、选型建议

10.1 根据产品形态选择

10.2 以”谁是你的用户”为核心决策

• 目标是让更多人用你的代码 → Apache 2.0；
• 目标是形成生态、让云厂商接入 → Apache 2.0 / MIT；
• 目标是限制直接竞争对手（同为数据库厂商、观测性厂商等）→ BUSL 或 RSALv2；
• 目标是”修改后必须回馈”但允许嵌入使用 → GPLv3 或 LGPL；
• 目标是”作为服务运行也必须回馈” → AGPLv3；
• 目标是”完全排除云厂商使用” → SSPL（但接受 OSI 不认证、OSS 基金会拒绝、大量用户犹豫的代价）。

10.3 中国开源基础软件的建议

对于国内做基础软件（数据库、中间件、编排、观测性）并希望：

1. 被阿里云、腾讯云、华为云同时采纳；
2. 被 AWS、Azure、GCP 在国际市场采纳；
3. 进入 Apache / CNCF / Linux 基金会孵化；

必选 Apache 2.0。没有第二个选项。

这也解释了为什么 OceanBase、TiDB、OpenTelemetry 中国贡献方（如阿里、腾讯、字节）发起的开源项目几乎清一色 Apache 2.0——这是进入国际生态的入场券。

10.4 “开放核心”模型的务实建议

如果你希望商业化但又想开源：

1. 核心组件：Apache 2.0（最大化采纳率）；
2. 企业级增强功能：商业许可证（完全闭源）；
3. 云原生附加件：MPLv2（适度 Copyleft，仍属 OSI 开源）；
4. 客户端 SDK / Driver：Apache 2.0 或 MIT——这一点至关重要，SDK 的许可证决定了应用开发者的合规成本；
5. CLA 或 DCO：早期选择 DCO（Developer Certificate of Origin）对社区更友好；有明确商业化路径时再升级到 CLA。

10.5 避免”一步到位的协议变更”

许多企业从 Apache 2.0 直接跳到 SSPL / BUSL 的剧烈变更，都带来了显著的社区反弹——不仅因为条款本身变严，也因为变更过程中的沟通不透明。MongoDB、Elastic、HashiCorp、Redis 都经历过类似风波。如果你计划协议变更，建议：

1. 提前公开沟通：在变更前 3—6 个月发布意向声明，征求社区反馈；
2. 清晰界定 Additional Use Grant：用精确语言定义哪些用例不受影响；
3. 考虑双许可而非单许可：保留 Apache 2.0 作为可选项，对内部使用和非竞品场景更友好；
4. 承诺版本稳定性：对已发布版本的许可证不回溯、不撤销；
5. 准备好社区 Fork 的可能：Fork 不是失败，是生态成熟的标志。如果 Fork 不可避免，争取通过技术领先维持上游地位，而不是试图以法律手段打压 Fork。

附录 A：AGPL §13 条款原文与工程注解

为了让工程师能够把许可证文本与实际场景对应起来，下面给出 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 代码的对应源码也必须纳入披露范围。

A.1 “修改”的判定谱系

从 MongoDB、Elastic、Redis 的案例看，业界对”modification”的典型判断标准：

A.2 披露范围实务

AGPL §1 定义的 “Corresponding Source” 包括：

1. 源代码：可以重建二进制所需的全部代码；
2. 构建脚本：Makefile、CMakeLists.txt、build.gradle、package.json 等；
3. 接口定义文件：头文件、protobuf、IDL；
4. 控制脚本：部分运行时所需的脚本（如 shell 启动脚本）；
5. 不含：通用系统库、操作系统、编译器、JVM 等”System Libraries”。

对于微服务场景，常见混淆：

• AGPL 服务本体 → 必须披露；
• 部署该服务的 Helm chart / K8s manifest → 一般不强制披露（这些是”部署运维”而非”构建”层）；
• 监控该服务的 Prometheus 规则 → 不披露（外部系统，独立）；
• 该服务的配置文件 → 若修改版要求特定配置才能运行，配置文件作为”控制脚本”一部分建议披露。

附录 B：SSPL §13 与 AGPL §13 的对照分析

SSPL §13 由 MongoDB 起草时，以 AGPLv3 §13 为基础但显著扩展。对比两者的触发条件与披露范围，就能直观看出 SSPL 的激进程度。

从这张对照表清晰可见：AGPL 在”触发”和”披露”两个维度都是”适度 + 聚焦”，而 SSPL 则是”宽触发 + 全披露”。SSPL 的设计本意不是让云厂商”服从披露”，而是让云厂商”放弃使用”。

B.1 为什么 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. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

SSPL §13 要求披露”所有用于提供服务的其他软件”的源码。这些”其他软件”可能是：

• 企业自有的运维自动化平台；
• 商用 APM（如 Dynatrace、Datadog Agent）；
• 商用备份系统（如 Commvault、Veeam）；
• 自建的身份认证、计费、告警系统。

SSPL 通过 §13 把对这些完全独立的软件的披露义务绑到了 MongoDB 上，这正是 OSD #9 想禁止的”对其他软件施加限制”。因此 OSI license-review 的结论是 SSPL 不符合开源定义。

B.2 SSPL 对”内部使用”的豁免

SSPL 本身有对”internal use”的隐含豁免——从 §13 的措辞看，只有”作为服务对第三方提供”才触发。如果你用 MongoDB SSPL 为自己公司的系统提供后端服务，原则上不触发 §13。

但”第三方”与”内部”的边界仍模糊：

• 母公司与其他子公司共享服务 → 通常认为是内部，不触发；
• 集团内关联公司通过 API 访问 → 争议，保守解读为外部；
• 对公司客户的门户系统（客户通过浏览器使用）→ 构成”对第三方提供服务”，可能触发。

附录 C：各大云厂商许可证合规政策公开信息汇总

以下信息基于各云厂商公开的开源使用政策、开源委员会声明、开发者文档。

C.1 Google

• AGPL：Google 开源合规政策明确把 AGPL 列为 “Restricted”。内部禁止使用、修改、引入 AGPL 代码到生产系统。例外需开源项目办公室（Open Source Programs Office, OSPO）单独审批；
• SSPL/BUSL/ELv2：按”non-open-source proprietary”处理，企业合同条款约束；
• 首选许可证：Apache 2.0、BSD、MIT。

C.2 AWS

• AGPL：AWS 内部政策类似 Google，对 AGPL 在自研服务中的使用高度保守；
• SSPL/ELv2/RSALv2：AWS 直接发起或联合发起了 OpenSearch、Valkey 两个 Fork 项目，表达了”不接受非 OSI 源可得许可证”的立场；
• 首选许可证：Apache 2.0（AWS 自家大量开源项目如 Smithy、CDK、Firecracker、Bottlerocket、Karpenter 全部 Apache 2.0）。

C.3 Microsoft / Azure

• AGPL：Microsoft 早期政策严格禁止；近年相对放宽（尤其 GitHub 收购后），但生产系统仍保守；
• SSPL：不在 Azure 官方托管服务中使用最新版 MongoDB；改用与 MongoDB 的 OEM 合作路线（Azure Cosmos DB for MongoDB API 是兼容层，非使用 MongoDB 代码）；
• 首选许可证：MIT（VS Code、TypeScript 等多数项目都是 MIT）、Apache 2.0。

C.4 阿里云

• AGPL：内部合规流程对 AGPL 使用严格管控；
• SSPL/BUSL：阿里云自家开源项目全部使用 Apache 2.0，包括 Dubbo、RocketMQ、Nacos、Sentinel、Seata、Higress、Spring Cloud Alibaba、Dragonwell JDK；
• 生态响应：作为 OpenSearch Foundation 和 Valkey 的创始支持方。

C.5 腾讯云

• AGPL/SSPL：云服务中避免直接使用 SSPL 许可的最新版本数据库；
• 自家开源：TARS、TBase、Kona JDK、ncnn、TDengine（部分组件）等偏向 Apache 2.0 / BSD；
• 生态响应：在 Valkey、OpenTofu 等社区 Fork 中积极参与。

C.6 华为云

• Mulan PSL v2：自家核心开源项目（openEuler、openGauss、MindSpore、openHarmony）使用 Mulan PSL v2，该许可证 2020 年获 OSI 认证，与 Apache 2.0 基本等价；
• AGPL/SSPL：云服务中倾向于使用 OpenSearch、自研替代；
• 基金会参与：活跃于 OpenSearch、Linux Foundation、CNCF 等生态。

附录 D：开源项目方视角的”协议变更手册”

如果你是一家以开源项目为核心的公司，正在考虑协议变更，下面是基于过去十年案例总结的教训清单（反面教材和正面经验）。

D.1 变更前的自问清单

1. 你想解决的问题是”竞争”还是”贡献不足”？两者的解决路径完全不同。竞争问题靠产品力和品牌；贡献不足靠社区激励；协议变更两者都难根治。
2. 有没有更轻的路径？例如：商标保护、产品差异化、专利组合、合作协议，都可能比协议变更风险小。
3. 是否准备好 Fork 发生？一旦协议变更，Fork 是常态。你的回应策略是什么——技术领先、品牌差异、生态护城河？
4. 是否准备好 OSI 认证争议？切到 SSPL/BUSL/ELv2 意味着放弃”OSI 认证开源”身份，你的市场话术是否做好准备？
5. 是否让贡献者参与讨论？单方面宣布变更，无论条款多合理都会引发社区反弹。

D.2 条款设计的务实建议

1. Additional Use Grant 尽量具体：HashiCorp 早期的 AUG 比较宽泛，引发很多解读争议；Sentry 的 FSL 则把”Competing Use”定义得非常具体；
2. 保留版本化承诺：明确”已发布版本的许可证不回溯”，这是最基本的信任承诺；
3. 考虑时间窗口：BUSL 的 Change Date 是”时间换信任”的聪明设计，社区更容易接受；
4. 避免针对特定公司：条款应该基于行为（如”不得提供 DBaaS”），而不是针对特定厂商名字；
5. 和 OSI 沟通再决定：如果确实想保留开源身份，AGPLv3 是唯一 OSI 认证的”反云”选项。

D.3 变更过程的沟通建议

1. 提前 3—6 个月发布意向声明；
2. 公开条款草案征集反馈；
3. FAQ 覆盖所有可预见场景：企业内部使用、SaaS 嵌入、咨询服务、培训、教育等；
4. 提供迁移工具和文档：如果部分用户希望退出，帮助他们迁移到可替代产品（比如 Fork 版）；
5. 保持专业克制：避免在公告中对云厂商的”道德谴责”——这会激化博弈，让 Fork 更快发生。

D.4 变更后的持续运营

1. 监控 Fork 动向：Fork 出现后，技术节奏要跟上（bug fix、安全补丁速度不能落后）；
2. 在商业版上加速差异化：开源部分放开的功能，在企业版上做更深的集成、更好的性能、更好的支持；
3. 投入生态补偿：让社区看到你对开源的持续投入，比如资助独立贡献者、举办社区活动、赞助开源基金会；
4. 对 Fork 保持开放态度：公开支持 Fork 社区的标准（如协议兼容性），而不是用法律手段打压——后者只会败坏口碑。

附录 E：术语表

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。

附录 F：按时间线整理的重大事件详表

下面将主线时间线中的事件按时间顺序、以更细粒度的信息进一步展开，便于做培训或合规宣讲的引用。

F.1 2007：AGPLv3 发布

• 2007 年 11 月 19 日：GPLv3 与 AGPLv3 同日发布；
• 背景：AGPLv1（2002）以 GPLv2 为基础，加入”网络交互披露”条款；AGPLv3 与 GPLv3 协调，相容性更好；
• 意义：开源许可证首次正式覆盖”网络服务”场景。

F.2 2013：MariaDB 提出 BSL 概念

• MariaDB 为自家 MaxScale 等产品起草 Business Source License 原型；
• 特点：延迟开源时间表；
• 影响：为 2019 年之后 Cockroach、HashiCorp 等公司的协议变更提供模板。

F.3 2018：MongoDB 切换 SSPL，Confluent Community License 发布

• 10 月 16 日：MongoDB Inc. 宣布从 AGPL 切换到 SSPL；
• 12 月：Confluent 宣布 KSQL、Schema Registry 等组件采用 Confluent Community License；
• 背景：AWS、阿里云、Azure Cosmos 对 MongoDB 兼容服务陆续推出；AWS MSK 对 Kafka 托管服务开始布局。

F.4 2019：AWS DocumentDB、CockroachDB BSL

• 1 月：AWS 发布 Amazon DocumentDB（with MongoDB compatibility），技术上是兼容层而非 Fork；
• 3 月：MongoDB 从 OSI license-review 撤回 SSPL 认证申请；
• 6 月：CockroachDB 从 Apache 2.0 迁移至 BSL（Change Date 3 年，Change License Apache 2.0）；
• 意义：Elastic 此时尚未变阵，观察到 MongoDB 路径的效果好坏。

F.5 2021：Elastic、Grafana 连续变阵，OpenSearch 诞生

• 1 月 14 日：Elastic 宣布 Elasticsearch、Kibana 从 Apache 2.0 切到 SSPL + ELv2；
• 1 月 21 日：AWS 宣布将 Open Distro for Elasticsearch 升级为独立 Fork，意向初现；
• 4 月 12 日：OpenSearch 1.0 项目宣告正式启动；
• 4 月 21 日：Grafana Labs 将 Grafana、Loki、Tempo 全部迁移至 AGPLv3；
• 意义：同年内两条路线同时发生——Elastic 走出开源、Grafana 回到 Copyleft 开源；可以理解为”向云厂商收紧”的两种策略。

F.6 2022—2023：过渡期与 BSL 成熟

• 2022 年：OpenSearch 1.x/2.x 完成与 Elasticsearch 7.x 的分叉差异化；
• 2023 年 6 月：Akka 从 Apache 2.0 切到 BSL（Change Date 3 年）；
• 2023 年 8 月 10 日：HashiCorp 宣布 Terraform、Vault、Consul、Nomad、Boundary、Waypoint、Packer 全部切到 BUSL 1.1；
• 2023 年 8 月 15 日：OpenTF Manifesto 发布；
• 2023 年 9 月 20 日：OpenTF 项目启动，随后更名 OpenTofu；
• 2023 年 12 月：OpenTofu 正式加入 Linux 基金会，发布 1.6 Alpha。

F.7 2024：Redis、Valkey、回归开源潮

• 3 月 20 日：Redis Inc. 宣布 Redis 核心从 BSD-3-Clause 切到 RSALv2 + SSPLv1；
• 3 月 28 日：Linux 基金会宣布 Valkey Fork（基于 Redis 7.2.4）；
• 4 月 16 日：OpenTofu 1.7 GA；
• 8 月 29 日：Elastic 宣布 Elasticsearch 新增 AGPLv3 作为第三许可选项（“回归开源”）；
• 8 月：CockroachDB 进一步收紧，社区版停止发行，全面走商业路线；
• 9 月：Valkey 8.0 发布，Redis 8.0 发布，两条路线事实上长期共存。

F.8 2025 及以后：可能的下一步

未来值得关注的几条线索：

1. 下一个大项目变阵：候选领域包括向量数据库（Milvus、Qdrant、Weaviate）、流处理（Flink 相对稳定，RisingWave 等新秀）、数据湖（Delta、Iceberg、Hudi）；
2. 监管与政策：欧盟 CRA（Cyber Resilience Act）、数据主权要求对开源与源可得软件的合规影响；
3. AI 模型许可证：与”开源”概念的冲突，部分厂商用”Open Weights”概念绕过传统定义；
4. 基金会模式普及：更多项目主动选择基金会治理，预防未来协议变更风险；
5. 中国云厂商主导 Fork 可能性：目前 Fork 都由国际云厂商牵头，未来国内云厂商是否会主导某次 Fork 值得关注。

附录 G：选型决策树

下面用一个简化的决策树帮助工程团队快速判断：“在我的项目里，应该选择什么许可证？”

                        你的项目核心类别是？
                                |
         +----------------------+----------------------+
         |                                             |
     基础库/SDK                                 服务端软件/数据库
         |                                             |
   最大化采纳优先？                          需要保护商业化？
     /        \                              /           \
   是          否                          是             否
    |          |                           |              |
 Apache 2.0   MIT                    是否希望保留           Apache 2.0
 / MIT       / BSD                     OSI 认证身份？         （默认推荐）
                                       /           \
                                     是             否
                                      |              |
                                  AGPLv3        BUSL / ELv2 / RSALv2
                                                   （放弃开源标签）
                                                      |
                                               精确定义 AUG / 禁止条款
                                                      |
                                           准备社区 Fork 风险并制定回应策略

这个决策树的核心信息：绝大多数场景下 Apache 2.0 是最优解。只有当你明确要”约束服务化使用”，并愿意承担社区反应代价时，才考虑 AGPL 或源可得方向。

附录 H：协议名缩写速查

• AGPL = Affero GPL = 网络 Copyleft；
• BSL = BUSL = Business Source License / Business User Source License；
• ELv2 = Elastic License v2；
• SSPL = Server Side Public License；
• RSAL = Redis Source Available License；
• CCL = Confluent Community License；
• FSL = Functional Source License；
• FCL = Fair Core License；
• Mulan PSL v2 = 木兰宽松许可证第 2 版（OSI 认证）；
• Mulan PubL v2 = 木兰公共许可证第 2 版（弱 Copyleft，未 OSI 认证）。

记住一条简单的直觉：名字里含”Source Available”、“Business Source”、“Community License”的，基本都不是 OSI 意义上的”开源”。遇到要当作专有许可证处理。

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。

十一、参考资料

1. GNU Affero General Public License, Version 3, Free Software Foundation, 2007.
2. MongoDB Server Side Public License, Version 1, MongoDB Inc., 2018.
3. Eliot Horowitz, “MongoDB Now Released under the Server Side Public License,” MongoDB Blog, October 2018.
4. Open Source Initiative, “The SSPL is Not an Open Source License,” OSI Blog, 2019.
5. Shay Banon, “Doubling Down on Open, Part II,” Elastic Blog, January 2021.
6. Elastic License v2, Elastic N.V., 2021.
7. AWS, “Stepping up for a truly open source Elasticsearch,” AWS Open Source Blog, January 2021.
8. OpenSearch Project, announcement and project charter, 2021; OpenSearch Software Foundation announcement, Linux Foundation, 2024.
9. HashiCorp, “HashiCorp adopts Business Source License,” HashiCorp Blog, August 2023.
10. Business Source License 1.1, MariaDB Corporation.
11. OpenTofu Manifesto and project announcement, 2023; Linux Foundation adoption, December 2023.
12. Redis Inc., “Redis Adopts Dual Source-Available Licensing,” Redis Blog, March 2024.
13. Redis Source Available License v2 (RSALv2), Redis Ltd.
14. Linux Foundation, “Linux Foundation Launches Open Source Valkey Community,” March 2024.
15. Confluent Community License, Confluent Inc., 2018.
16. Cockroach Labs, “Why We’re Relicensing CockroachDB,” June 2019; “CockroachDB licensing changes,” August 2024.
17. Grafana Labs, “Grafana, Loki, and Tempo will be relicensed to AGPLv3,” April 2021.
18. Apache License 2.0, The Apache Software Foundation, 2004.
19. Mozilla Public License 2.0, Mozilla Foundation, 2012.
20. 木兰宽松许可证第 2 版（Mulan Permissive Software License, Version 2），2020.
21. PingCAP, TiDB 项目 LICENSE 文件及公开声明。
22. OceanBase 社区版开源公告，蚂蚁集团，2021；许可证变更公告，2023。
23. OSI Open Source Definition v1.9, Open Source Initiative.

上一篇：GPLv2、GPLv3、LGPL：Linux 内核为什么停在 v2

下一篇：木兰许可证与国产开源许可