3月21日，Redis Ltd. 宣布，Redis“内存数据存储（in-memory data store）”项目将从Redis 7.4版本开始，采用非免费、源代码可用的许可协议。这一消息不令人满意，但并不完全出乎意料。

然而现在的情况有些不同寻常，Redis 的替代品数量众多，对于那些希望继续使用免费软件的人来说，至少有四种替代方案（包括现有的 KeyDB 分支和 Linux 基金会新宣布的 Valkey 项目）。

那么，Linux 发行版、用户和服务提供商会选择哪个（或哪些）替代品来替换 Redis？

Redis的背景故事颇为复杂。

Salvatore Sanfilippo（也被称为“antirez”）最初是为了一个名为LLOOGG的实时日志分析应用程序，将 Redis 用作“一种不同的数据库”，因为MySQL无法满足他的需求。antirez 没有创建关系型数据库，而是将 Redis 设计为一个简单的字典数据库，该数据库将键值对存储在内存中——它的名字是“远程字典服务器（remote dictionary server）”的缩写。

当然，随着时间的推移，Redis 已经成熟并积累了更多功能。Redis 作为 NoSQL 运动的一部分迅速流行起来，antirez 在2010年被 VMware 聘用从事 Redis 的开发工作。2013年，他转到了VMware 的衍生公司 Pivotal，并继续从事该项目的工作。

彼时，Redis 的受欢迎程度与日俱增，包括 Twitter 和 Pinterest 等知名公司都在使用它，并开始在 Linux 发行版中出现。它被打包进 Ubuntu 12.04（2012年4月）版本、Fedora 18（2013年1月）版本以及其他版本。2013年9月，Amazon Web Services（AWS）的 ElastiCache 服务增加了对Redis的支持，这既借势于 Redis 的普及度，又提升了 Redis 的知名度。

2013年初，一家名为 Garantia Data 的初创公司开始提供Redis服务，将自己定位为“开源Redis”的更好替代品。2013年11月，Garantia 完成了第一轮融资，并考虑将公司名称更改为 RedisDB。然而，在 antirez 的反对下，该公司于2014年初将名称改为 Redis Labs。

2015年，antirez 加入 Redis Labs，担任开源开发负责人，直到2020年离职。

2018年，Redis Labs 对其提供核心数据库的附加模块采用了新的许可协议。该公司选择使用经过修改的 Apache License 2.0 版本，并增加了一个名为 Commons Clause 的条款，该条款限制销售软件或收取服务费用。做出这种转变的理由是，云提供商通过销售基于他们未开发的开源代码的服务来“利用开源社区”。当时，该公司承诺 Redis“是 BSD 协议，并将永远是 BSD 协议”。

Redis Labs 并非唯一一家开始尝试使用限制性许可协议的公司，尤其是获得风险投资支持的数据库公司，它们开始尝试采用新的许可协议，确保能够独家销售使用该软件的服务。MariaDB 在2016年为名为 MaxScale 的产品创建了商业源代码许可协议（BSL），而 MongoDB 则在2018年底推出了服务器端公共许可协议（SSPL）。最终，Redis Labs 为其模块采用了 SSPL 和自身 Redis 源代码可用许可协议（RSAL）的双许可协议方案。

2021年中，Redis 公司从名称中去掉了“Labs”。在宣布名称变更时，Redis 再次承诺将坚持开源，并表示公司名称的更改“不会影响开源Redis的许可协议，该协议一直是 BSD 许可协议，并将继续是 BSD 许可协议”。

该公司还建立了一种治理模型，将 Redis 的“架构、设计或理念”等重大决策权交给社区的“核心团队”，人们期望该团队的职责包括管理 Redis 本身的许可协议。虽然 Redis 的网站上已不再有治理页面的链接，但该页面仍可在网站“互联网档案馆”的 Wayback Machine 上找到。页面上列出了五位核心团队成员，其中三位来自 Redis（Yossi Gotlieb、Oran Agra和Itamar Haber），另外两位分别是来自阿里巴巴的赵钊（Zhao Zhao）和来自 AWS 的 Madelyn Olson。

3月20日，Redis 宣布“所有未来的 Redis 版本都将使用源代码可用许可协议”，具体来说是SSPL 和 RSAL。Redis CEO Rowan Trollope 写道，维持 BSD 许可协议现在“与我们成功推动Redis未来版本发展的能力相悖”。所谓“未来版本”指的是 Redis 7.4 及以后的版本。公告中的常见问题解答（FAQ）指出，根据公司的安全政策，安全补丁将在原始三条款 BSD 许可协议下反向移植到以前的版本。

使用限制性许可协议（如 SSPL 和 Redis 的 RSAL）的支持者试图将此次事件定位为 AWS 等大型云厂商与开源之间的战斗，其中使用限制是唯一合乎逻辑的选择，而云厂商是唯一的输家。2019年，Redis Labs 时任 CEO Ofer Bengal 被引述称，Redis 为 Redis 模块采用源代码可用许可协议后，存在“许多不同的观点”，但为了与云提供商竞争，这是必要的。

“有些人谴责这种‘许可协议变更’。但在最初的争议平息之后——尤其是一些其他公司提出类似概念之后——社区现在理解到，原始的开源概念必须得到修正，因为它已不再适合当下时代。在这个时代，云公司利用其垄断力量采用任何成功的开源项目，而不为其做出任何贡献。”

在3月20日的公告中，Redis 现任 CEO Trollope 写道，“云服务提供商只能在与 Redis（Redis代码的维护者）达成许可条款后，才能交付 Redis 7.4”，但“对于 Redis 开发者社区来说，情况没有任何改变，他们将继续在双重许可下享受宽松的许可”。

使用“宽松许可”这一说法具有误导性。Redis 能够为7.4及后续版本采用非免费许可方案，是因为外部开发者在宽松的 BSD 许可下授予了他们的贡献。SSPL 和 RSAL 的条款与开源社区中“宽松”一词的常见用法不太符合。

此外，云厂商未对Redis存储库做出提交（commit）贡献的说法也站不住脚。

因此，很明显，代码贡献并不是（变更开源协议的）关键因素。Redis 是一家由风险投资支持的公司，自2011年以来经过多轮融资，已经筹集了超过3.5亿美元的资金。该公司及其投资者似乎认为，他们可以安全地脱离开源，以尝试获得更多的收入。

如果他们有理由相信这是可行的，那么 MongoDB 的情况或许能够提供一些指导。该公司在2017年上市，一年多后转向了 SSPL。此后不久，主要的 Linux 发行版停止打包 MongoDB，因为该数据库不再符合它们许可标准。但当时，MongoDB 已经瞄准了一个平台模型，该模型将鼓励开发人员（及其雇主）使用MongoDB和辅助产品并为其付费。分发 MongoDB 的源代码可用版本可以被视为一种 Loss Leader 策略（又称赊本定价），以吸引他们打赌“不关心”开源的开发者。

正如 Redmonk 创始人 Stephen O'Grady 在2017年所写的那样：

“随着越来越多的开发者开始主张对技术选择和方向的控制权，即使在专有替代方案在技术上更优越的情况下，开源软件的易用性也赋予了它巨大的市场优势。在即时下载的充足选项 A 和理论上更优越的、但需要通过销售人员才能获得的选项 B 之间做出选择，实际上并不是一个真正的选择。”

但是，Grady 指出，开源“通常不如基于服务的替代方案方便”，如果方便性的优先级更高，那么开源就显出短板了。尤其是当像 MongoDB 这样的供应商从专有供应商那里学到“锁定客户对业务有好处”时。

这对业务有好处吗？MongoDB 的业务持续增长，客户不断增加，并在上一个财年实现了16.8亿美元的收入。这一增幅超过 30%，其 Atlas 数据库服务收入也增长了30%以上，这表明许多公司宁愿付费使用服务，也不愿尝试自行托管。尽管如此，该公司仍然处于亏损状态——同期亏损超3.45亿美元。

但是，投资者可能更关心股价而不是实际利润。该公司上市时的股价约为每股33美元，但现在已超过每股350美元。如果Redis能产生类似的结果，投资者可能会很高兴。

正如 Redmonk 创始人 O'Grady 去年所写的那样，风险投资支持的供应商似乎已达成共识，他们可以脱离开源。特别是如果他们没有“受到其他商业利益、基金会和其他感兴趣的行业参与者的积极反对”。在这方面，Redis 可能误判了行业情绪。

去年 Hashicorp 为其项目采用 BSL 时，Terraform 项目的分支在几天内就出现了，并被 Linux 基金会以 OpenTofu 的名称接纳。3月28日，该基金会宣布支持 Valkey（Redis 7.2.4的直接分支），亚马逊网络服务（AWS）、谷歌云、甲骨文、爱立信和 Snap 等公司都是该项目的支持者。

Redis 许可证变更后几天，Valkey 分支就出现了。开发者Olson写道，她和“一些前Redis贡献者”已经开始使用一个原始的三条款 BSD 许可证来开发一个分支，并暂时命名为“placeholderkv”。Olson、Zhao、Viktor Söderqvist和Ping Xie被列为维护者。据 Olson说，这并不是 AWS 的 Redis 分支，而是“我试图保持与社区的连续性”。KeyDB 也曾被考虑过，但它已经偏离到“缺少社区习惯使用的很多功能”的程度。

2019年出现的 KeyDB 分支，其创建主要是由于技术原因，而非许可原因。该项目自称是“比 Redis 更快的替代方案”，由 John Sully 和 Ben Schermel 创建。他们想要一个多线程版本，但未能说服Redis维护者朝这个方向发展。Sully 和 Schermel 创办了一家同名公司 KeyDB，提供专有企业版。2022年，KeyDB 被 Snap 公司收购后，整个代码库完全在三条款 BSD 许可证下开源。

KeyDB 作为直接替代方案的问题是，自从分支以来，它就没有跟上 Redis 的步伐，它仍然缺少Redis 7 中的许多功能。Sully 表示，他几乎没有时间处理“不直接影响 Snap ”的问题，尽管该项目“当然欢迎外部帮助，如果有社区兴趣帮助，我们当然可以指定其他维护者”。3月22日，Sully 更新了另一个问题，表示他正在讨论“可能”增加维护者，以使 KeyDB 更接近 Redis 7。目前尚不清楚 Valkey 是否会取代 KeyDB，但 Snap 公司的参与使得这一可能性在长期内看起来很大。

SourceHut 的创始人和 CEODrew DeVault，也创建了一个名为 Redict 的分支，该分支基于Redis 7.2.4，但选择使用 LGPLv3 许可证。在他的公告帖子中，他表示选择这种许可证是“经过深思熟虑的，平衡了许多考虑因素”。

DeVault 希望选择一个既是具备 copyleft（著佐权，无论是否进行修改，任何人都可以重新分发软件，但必须同时保留软件所具有的自由特性）又“尽可能易于用户遵守”的许可证，并简化与 Redis 兼容的模块或用于在Redis中执行操作的 Lua 插件集成。他还指出，Redict 将不会有贡献者许可协议（CLA），但会要求贡献者使用开发人员起源证书来验证其贡献。尽管他与 SourceHut 有关联，但 DeVault 选择在 Codeberg 上托管Redict，以“为熟悉 Redis 的 GitHub 社区的用户提供舒适和熟悉的使用体验”。

另一个值得一提的竞争者是微软在3月18日宣布推出的 Garnet。根据公告，Garnet 自2021年以来一直由微软研究院开发，它是一种远程缓存存储，可以缓存和管理与 Redis 相同类型的数据，旨在与Redis序列化协议兼容。Garnet 使用 MIT许可证，使用 .NET C# 编写，并不能直接替换Redis。然而，其 API 兼容性页面声称，它可以被视为一个“足够接近的起点”，可以“无需修改即可与许多 Redis 客户端一起使用”。尽管如此，并非所有Redis客户端都与Garnet完全兼容。例如，有用户尝试将 NodeJS 应用程序切换到 Garnet，但发现 Redis 的 FLUSHALL 命令目前尚不支持。目前在项目的路线图中，可以看到“添加对缺失 API 的支持”的功能建议。

在 Linux 发行版面对不得不清理的乱局之际，Neal Gompa 在 Fedora 开发列表上发起讨论，指出了许可证变更以及从 Fedora 中移除 Redis 的必要性。Jonathan Wright 回应说，KeyDB可能是一个替代方案；在许可证变更之前，他一直在“松散地打包”这个项目。然而，他后来表示，对于那些希望替换Redis后续版本的人来说，KeyDB 将是一个“倒退并引发头痛”的选择。尽管如此，他在3月23日写道，他已经准备好测试 Fedora 以及 EPEL 8 和9 的构建版本。

Valkey 宣布后不久，Wright 写道，他将在标记版本发布后尽快进行打包。他还表示，“预计Valkey 在大多数地方将成为 Redis 的‘事实上的’替代方案”。

Gompa 还在 openSUSE 的 Factory 讨论列表上提出了这个问题。Dominique Leuenberger 在回复中列出了 18 个依赖 Tumbleweed 中 redis 软件包的软件包。最初的讨论提到了 Redict 和 KeyDB 作为可能的替代品，但 Valkey 尚未公布。

对于社区发行版来说，寻找 Redis 的替代品并非唯一问题。Jacob Michalskie 指出了 openSUSE 项目中使用的多个服务也将需要 Redis 的替代品，其中包括用于 code.opensuse.org 的 Pagure 代码托管软件（Fedora 也创建并使用了该软件），以及 Discourse 论坛软件。

Debian 贡献者 Guillem Jover 为 KeyDB 提交了软件包请求（RFP），作为潜在的 Redis 替代品。Jover 表示，他不确定自己是否能够独自承担维护工作，但很乐意帮忙。在与 Jover 的电子邮件交流中，他告诉我，他的公司已经从 Redis 6 迁移到 KeyDB，并且“过渡非常顺利”。据Jover 称，“与 Redis 7 相比，KeyDB 可能在某些功能上有所欠缺，但我们既没有注意到我们缺少任何功能，也没有觉得我们错过了什么。”

Jover 表示，现在判断新的分支会否继续得到维护还为时尚早，而且 Redict 的 LGPLv3 许可“也可能对生态系统造成问题”。在 Valkey 宣布之后的一封后续电子邮件中，他说：“我认为我们会进一步为 Debian 打包 KeyDB，如果它失败了，至少可以随时从那里移除或过渡。”

当然，现在预测这些分支中哪一个或多个会获得显著的吸引力还为时过早——但看起来Valkey很可能成为一个可靠的替代方案。拥有广泛社区和行业支持的快速分支的可能性，应该让那些期望在放弃开源后就能够一帆风顺的厂商停下来三思。