摘要
Redis自2024年起从BSD开源协议转向RSAL、SSPL及AGPL，引发行业广泛争议。本文系统解析Redis许可证变更历程、核心差异及企业合规影响，并对Valkey、旧版本锁定与Redis Enterprise等应对方案进行深入分析。
前言：一个「开源成功故事」的突变
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 的诞生，也许是市场自我修正机制的一部分。
九、说点实在的：应对策略
1. Valkey
这是由 Linux Foundation 推动的 Redis BSD 版本派生（fork）项目，目标是维持 BSD 授权与社区的自由。优点显而易见：授权宽松、兼容性有基础。然而，从分销商角度观察，这里存在几个潜在弱点：
- 社区成熟度尚未完全与 Redis 官方匹配：生态、商业支持、企业客户案例较少。
- 迁移成本与兼容风险：虽然兼容性宣称高，但实际在模块差异、性能、社区生态变动方面可能有未知风险。
- 支持体系分散：不像 Redis 官方产品那样有全球统一支持、合作伙伴认证、商业订阅保障。
因此，若选择 Valkey 作为“节省许可成本”路线，我们建议务必评估迁移风险、社区支持状态、长期维护责任。
2. 固定旧版本 BSD-3 路线
还有一种常见路径：继续使用 Redis 7.2.x 或以前版本（BSD-3 许可版本），锁定不更新至 v7.4 以后的版本。优点是许可清晰、无需购买商业订阅。但缺点也明显：
- 安全补丁、性能改进、功能演进会受限；
- 长期来看可能产生“技术债务”；
- 若你未来需要商业托管服务或收费模式，可能仍需迁移或补授权。
3. 转向 Redis Enterprise
Redis 的许可变更，让许多企业重新审视其在生产环境中的使用模式。对于大多数开发者而言，社区版 Redis 足以支撑日常测试或内部系统。但当系统进入规模化运营，尤其涉及到“商业化”“托管服务”或“客户数据”，选择便不再只是“功能对比”，而是“合规与可持续性”的平衡。
从我们的经验来看，**Redis Enterprise** 在这些关键点上表现更稳健：
Redis Enterprise 最大的优势，并不只是“商业版”这一身份，而是它提供了**一条清晰、合规、可演进的路径**。当社区版因许可变更而陷入灰色地带时，Enterprise 用户仍然能够安心升级、获得官方支持，不必担心被迫停留在旧版本或面临授权争议。
此外，它在架构能力上也更贴近企业级场景。例如，多活（Active-Active）部署让跨地域业务不再依赖外层同步机制；自动故障转移与集群级监控减少了自维护风险；内置安全与身份认证机制，也能直接满足部分行业合规要求。这些特性对于需要长期运行、对 SLA 有要求的系统，是现实意义上的保障。
成本并非只看“初始购买”。
免费开源方案可能在部署初期成本最低，但其隐藏成本往往体现在后期：
- 缺乏官方支持导致的宕机延时；
- 自行维护集群的工程人力开销；
- 一旦误用许可造成的合规风险。
相比之下，Redis Enterprise 提供的是一种“确定性”——授权明确、版本清晰、支持可追溯。对于正在建设生产环境、或计划以 Redis 为核心服务基础的企业，这是更稳妥的长期选择。
十、Redis 的明天
Redis 的许可证变动，像一记警钟。
它提醒我们：在依赖开源软件的商业世界中，**“许可策略”已经成为基础设施风险的一部分**。
如今的 Redis，站在三岔口：
- 商业 Redis（RSAL / SSPL） 走向强授权与闭环生态；
- 社区 Redis（AGPL / Valkey） 尝试延续自由与透明；
- 企业用户 则必须在两者之间，谨慎平衡。
无论你是工程师、架构师还是 CTO，
是时候在你的软件清单中，为许可证风险这一列预留更多的思考空间了。
