前言：一个「开源成功故事」的突变

Redis 曾是开源世界的明星。

它以极简的内核、惊人的性能和清晰的 API 设计，成为全球缓存与内存数据库的事实标准。无论是初创项目还是大型云平台，Redis 几乎是标配组件。

然而，从 2024 年初开始，一场关于「Redis 许可证变更」的风波在全球技术圈持续发酵。

这场风波不仅改变了 Redis 的法律地位，也撼动了整个基础软件行业对于“开源商业模式”的信任与理解。

本篇文章将系统梳理 Redis 许可证的历史、核心变更、争议焦点，以及它对不同类型企业的真实影响。

---

Redis 许可证演变：从宽松到限制的十年

我们先从历史脉络看起——Redis 的授权模式从 2018 年起，经历了三次重大转向。

• 在 2024 年 3 月 20 日，Redis 官方宣布：从 v7.4 起，Redis 将不再采用 BSD-3 许可，而转为 RSALv2 或 SSPLv1 双许可。

• 官方明确指出，此次变更 **不具溯及力**：也就是 v7.2 及以前仍然在 BSD-3 下。

• 到 2025 年 5 月 1 日，Redis 再次调整：加入 AGPLv3 作为可选许可之一。

从 BSD 到 RSAL：分水岭的那一天

2024 年 3 月 20 日，Redis 官方宣布了一项震动业界的决定：

自 Redis 7.4 起，核心不再以 BSD-3 授权发布，而是改为 **双重 Source-Available 许可**：

“Redis will be dual-licensed under RSALv2 and SSPLv1, effective from version 7.4 onward.”

—— Redis 官方公告（2024-03-20）

这意味着，Redis 从“真正的开源项目”（BSD）正式转向“源代码可见但商业受限”的阵营。

---

三种许可的核心差异

理解这场风波的关键，在于厘清三种主要许可的差异。

许可类型	开源认可度	是否允许托管服务商业化	代码披露要求	实际影响
BSD-3	✅ OSI 认证	✅ 允许	❌ 无	云厂商可自由托管
RSALv2	❌ 非 OSI	❌ 禁止商业托管	❌ 无	限制竞争性托管服务
SSPLv1	❌ 非 OSI	⚠ 允许但须开源整个服务栈	✅ 严格	云厂商无法闭源托管
AGPLv3（2025 加入）	✅ OSI 认证	✅ 允许（需遵守 copyleft）	✅ 部分	重回开源阵营

📝 备注：RSAL（Redis Source Available License）是 Redis 官方自定义的许可证，用于保护其商业利益；SSPL（Server Side Public License）最初由 MongoDB 推出，意在防止云厂商免费“二次分销”。

---

为什么 Redis 要这么做？

Redis 官方的说法是：

“云厂商从 Redis 获益巨大，却没有回馈社区。我们需要一个可持续的商业模式来支持核心开发。”

这话在逻辑上无可厚非——云厂商确实长期将 Redis 托管成盈利服务（如 AWS ElastiCache、Azure Cache for Redis、Google Memorystore），而开源作者未获收益。

但问题在于，Redis 的核心长期被视为“公共基础设施”，大量企业、框架和项目都基于它构建。

突然改变授权，让无数商业系统陷入法律不确定性。

于是，社区分裂开始了。

---

分裂：Valkey 的诞生

Redis 改许可后的三周内，一个新名字出现了——**Valkey**。

这是由 Linux Foundation 牵头的社区 fork，目标明确：

“延续 Redis 在 BSD 许可下的开源精神，让开发者不必担心商业限制。”

Valkey 继承了 Redis 7.2 的 BSD 代码，并由多家大型公司（包括 AWS、Google Cloud、Snap、Elastic 等）支持。

这场 fork 直接表明，**部分核心贡献者与云厂商不再信任 Redis 官方的治理结构**。

在开源史上，这类分裂并不罕见：MySQL → MariaDB，Elasticsearch → OpenSearch，如今轮到了 Redis → Valkey。

---

Redis 再次转向：2025 的修复动作

到了 2025 年 5 月，Redis 官方显然意识到社区信任的流失。

他们在 Redis 8 的发布声明中表示：

“Redis 8 将新增 AGPLv3 许可选项，以便那些需要 OSI 认证开源版本的用户继续安心使用。”

这意味着，Redis 用户可以在 RSALv2 / SSPL / AGPLv3 之间选择最符合自己场景的许可。

Redis 同时宣布会将 Redis Stack 的模块（JSON、Search、Vector 等）并入核心，从而提供更完整的统一发行版。

在某种意义上，Redis 正在尝试回到“开源+商业并行”的平衡点。

---

你是否受影响？

从法律与工程角度出发，判断你是否受影响可以简化为以下几个问题。

使用场景	是否受影响	建议行动
公司内部缓存、Session、消息队列用途，不对外提供 Redis 服务	❌ 不受影响	可继续升级使用
向客户提供“Redis 托管服务”或 Redis API	✅ 受影响	需签 Redis 商业授权或迁移至 Valkey
在 SaaS 中嵌入 Redis 作为付费功能	⚠ 视情而定	建议法律评估 RSAL 条款
基于 Redis 开发竞争产品（商业版、代理版）	✅ 受影响	需商业授权或使用 BSD fork

• 如果只是“内部缓存/加速/Session”用途，将 Redis 部署于自有基础设施，**受影响较小**。

• 如果你是“向外提供基于 Redis 的托管服务（Redis-as-a-Service）”、或者“Redis 嵌入至自己的商业产品中并再对客户收费”，那么你就处于风险较高的状态。

• 与 Redis 官方或其授权渠道签署商业订阅协议、使用 Redis Enterprise 产品，会极大降低许可合规风险。

⚖️ **重点提醒**：Redis 官方声明新许可**不具溯及力**，即 v7.2 及以前仍可继续使用 BSD 授权版本。

---

风波的深层意义：开源商业的矛盾

Redis 许可证风波不仅是一次法律变动，它揭示了一个行业级矛盾：

“当开源软件成为基础设施，作者应如何获得收益？”

开发者认为开源意味着自由，厂商认为可商用是理所当然，而创始团队则面临资金与社区之间的两难。

Redis 的做法在技术上合理，但在社区信任上失分。

而 Valkey 的诞生，也许是市场自我修正机制的一部分。

---

说点实在的：应对策略

■ Valkey

这是由 Linux Foundation 推动的 Redis BSD 版本派生（fork）项目，目标是维持 BSD 授权与社区的自由。优点显而易见：授权宽松、兼容性有基础。然而，从分销商角度观察，这里存在几个潜在弱点：

• 社区成熟度尚未完全与 Redis 官方匹配：生态、商业支持、企业客户案例较少。

• 迁移成本与兼容风险：虽然兼容性宣称高，但实际在模块差异、性能、社区生态变动方面可能有未知风险。

• 支