经过多年的开源历程，该平台毅然决然地转向了闭源模式，然而，一年之后，它又重新举起了开源的旗帜。作为主流的实时数据平台Redis的最新动向，这一变化再次在技术领域掀起了波澜，吸引了众多目光。

众多人士感到疑惑，对于 Redis 从“开源”到“闭源”再到“再次开源”的这种策略转变，是否显得过于轻率，这种变动是出于对市场的让步，抑或是对过往错误的弥补？又有多少开发者愿意重新加入这一行列？

从 Redis 8 起，重新开源！

去年三月，Redis公司首席执行官Rowan Trollope在官方网站上发布了一则名为《Redis采用双源许可证》的公告。该公告宣布，自Redis 7.4版本开始，Redis将不再沿用以往所使用的开源BSD三条款许可证，转而实施一种新的“双重授权”策略，即采用RSALv2（Redis源代码可用许可证）和SSPLv1（服务器端公共许可证）。

令人难以接受的是，这两种许可证并未获得 OSI（开放源代码促进会）的官方认证，作为开源许可，它们各自还设定了特定的约束条件。RSALv2 规定使用者不得将软件用于商业目的，亦不可将其作为管理服务对外提供，同时不得移除或掩饰任何许可、版权声明等；而 SSPLv1 则规定，若将产品作为服务进行提供，所有修改内容以及管理层的源代码必须在 SSPL 协议下进行公开发布。

简言之，自Redis调整了其开源许可证后，根据OSI的标准，它已不再被认定为开源软件。

经过一年的等待，在最近的五一假期，Redis 社区的两位核心成员——项目的缔造者 Salvatore Sanfilippo（昵称 antirez）以及现任 CEO 的 Roowan Trollope，相继发声，各自推出了《Redis is open source again》和《Redis is now available under the AGPLv3 open source license》两篇文章，正式对外宣布，从 Redis 8 版本起，Redis 将正式恢复开源状态。

目前，开发者有三种许可证可供选择，用以使用 Redis 8 及其后续版本。

RSALv2，这是一项由Redis公司所制定的许可证，其特点在于源代码可以被用户查阅与运用，然而，其使用范围却受到严格的约束。

SSPLv1是由MongoDB所创建的许可证，其源自GPLv3，并在原有基础上增加了对“托管服务”的特别约束，目的是为了阻止云服务提供商在未对社区做出贡献的情况下获取利益。

AGPLv3版本是一种基于GNU公共许可证（GPL）的许可形式，由自由软件基金会（FSF）所推出，主要适用于那些通过网络进行服务的软件（例如SaaS）的应用场合。按照该许可证的要求，经过修改的软件必须继续遵循AGPLv3许可证的规定进行发布，并且包括在服务器上运行的代码在内，都必须以相同的AGPLv3许可证形式公开。

Redis CEO：选择 SSPL 后，我们后悔了！

之所以出现这样的变化，Redis的首席执行官Rowan Trollope在最新的博文里坦诚表示，这种改变（当初决定闭源）对我们与Redis社区的关系造成了伤害。他的话语中流露出些许懊悔之情。

实际上，从商业的角度审视，众多企业对于 Redis 当初的决策还是能够有所认同。Redis 团队持续地投入到产品的开发与维护工作中，然而，他们却无奈地目睹着该产品被云计算服务商作为基础设施进行商业化利用，而得到的回报却寥寥无几。

正如 Trollope 所述，AWS 和 GCP 等超大规模云服务提供商的兴起，为初创企业以及大型公司带来了史无前例的迅猛发展速度和巨大规模。对于那些以开源作为其核心的公司而言，这无疑构成了一项根本性的难题：面对云服务提供商在未对开源项目给予相应回报的情况下，通过这些项目获利并掌握基础设施的情况，我们究竟该如何维持对这些项目的创新和持续投入？为了应对这一挑战，MongoDB以及Elastic等企业选择了实施SSPL（服务器端公共许可证），旨在遏制云计算服务提供商在未提供相应回馈的情况下擅自获取利益。

受到这一启示，Redis 开发团队最初决定采取一种中间策略：他们推出了 Redis Stack，将一些高级特性纳入单独的发行版本，同时采用了更为严格的授权方式。

然而，该策略虽在一定程度上确保了Redis的创新活力，却产生了显著的负面影响：维护社区版和Redis Stack两个版本，不仅增加了开发者的工作负担，还造成了社区体验的分裂，同时减缓了核心功能的进步速度。Trollope 总结道，我们迫切需求的是一种能够直接强化 Redis 核心性能的解决方案，而非仅仅维持两个版本的并存。

经过一年的综合评估，他最终在 2024 年 3 月做出了决定，即全面将 Redis 转换为采用 SSPL 许可证。他坦言，该策略在某种程度上达成了既定目标——现在，AWS和Google各自维护着各自的Redis分支，然而，这也带来了相应的代价：“SSPL并未被OSI认定为正宗的开源许可，这一变动对我们与社区的关联造成了严重的损害。”

事实表明，Redis企业对社区的反应力度估计不足。众多开发者感到了背叛，尤其是那些曾向Redis贡献过代码的成员。他们对于闭源行为本身感到愤怒，同时对Redis企业是否还值得信任“开源精神”产生了疑问。更有工程师公开发言：“如今的Redis企业并非Redis的创始人，其根源实为antirez。””

为了抵制 Redis，各种分叉项目如雨后春笋般出现：

Valkey项目由Linux基金会主导，并得到了AWS、Google、Oracle等公司的支持，其代码与Redis 7.2.4版本几乎完全相同。

KeyDB、Garnet等新项目也迅速获得关注。

一时之间，Redis 社区陷入分裂。

随着 Redis 内部与外部的冲突愈发尖锐，即便是已经淡出多年舞台的 Redis 创始人 antirez 也难以再保持沉默，于是他主动与 Rowan Trollope 取得了联系，决定重返 Redis 的生态系统，接受 Redis 公司的邀请，成为其开发者布道师，并与大家共同探讨 Redis 的未来发展方向。

Redis 之父回归五个月后，推动 Redis 再开源

Redis决定再次公开其源代码，这一举措发生在antirez加入Redis公司五个月之后。不难想象，在这段时间里，他付出了不少努力。

关于这一变化，Redis的创始人antirez在网络上发表了自己的感慨：

五个月前，我重返Redis团队，随即与同事们展开了一场关于是否将许可证更改为AGPL的讨论。令人惊讶的是，公司内部早已就此事展开了深入的探讨，并且讨论时间已经相当长了。

许多员工在公司内部认为采用AGPL协议更为适宜。尽管Redis项目最终采纳了SSPL，然而，关于这一议题的内部讨论并未因此平息。

我努力为拥护AGPL协议的阵营提供助力。据我所见，SSPL在实际运用中并未获得社区的认可。开放源代码促进会并未承认其合法性，软件社区亦不将其视为一种开源许可证。不久，这一理念在公司内部各层级逐渐赢得了广泛的赞同。

我必须坦率地表达：我衷心期望我所创作的针对新型Vector Sets数据类型的代码能够采用开源许可进行发布。实际上，开源软件开发已成为我职业生涯的核心部分，我几乎未曾涉足闭源软件的编写。然而，现在要转变这一做法，似乎已经为时过晚。或许这看似有些天真，然而我之所以满怀激情地创作了 Vector Sets，正是因为我深知 Redis（以及我的新岗位）将再度回归开源领域。

我深知，我们的主要任务是提升 Redis 的性能——打造一个实用、易用、并能根据软件栈需求灵活调整的卓越系统。然而，坚持开源许可证的原则，是确保我们的努力与 Redis 项目保持一致，赢得用户认可，以及融入超越任何单一企业努力的集体智慧之基石。

尽管我无法将许可证变更的成就归功于己，然而我仍期望自己多少做出了一些贡献。今日，我心情愉悦——Redis 重新回归开源阵营，并以 AGPLv3 许可证的形式呈现。

此刻，我打算重返终端，着手编写出我所能创作的最优代码，以此向 Redis 用户表达敬意。同时，我计划对 Vector Sets 进行进一步的优化，使其更加实用和高效。心中尚有许多想法，期待你们的反馈能够激发出更多创意（实际上，这一过程已经启动）。

目前，在宣布 Redis 8重新开放源代码的同时，Redis公司还陆续作出了一系列重要决策，旨在促进Redis未来的进步与发展。

推出了久违的全新数据类型——向量集，这一设计由Salvatore负责并完成实现。

将 Redis Stack 的技术优势，诸如 JSON 数据处理、时序数据管理、概率数据类型支持以及 Redis 查询引擎等功能，融入至 AGPL 授权协议下的 Redis 8 核心版本中。

推出了30多项性能改进措施，其中某些命令的执行速度提高了高达87%，而整体的处理能力更是实现了翻倍增长。

加强与社区的互动，特别是在客户端生态方面的合作。

开发者：被骗一次是无知，被骗两次就是愚蠢

Redis此次的调整虽以“重新回归开源理念”为名，但仍难以掩饰围绕其周边的质疑之声。面对Redis频繁的变动，众多开发者普遍持有的观点是：这样的改变来得太晚了。

一位曾经做过贡献的开发者 c0l0 在 HN 上留言：

我在 Redis 还处于原始许可阶段时，曾提出了一项小小的改进（尽管它微不足道，但我个人觉得颇具价值）。然而，当项目方突然宣布转向 SSPL 许可证时，我决定转向使用 redict——作为一名曾经为这个真正自由开源项目作出过贡献的参与者，我那一刻深感被背叛。（坦白讲，如果他们最初就选择了 AGPL 许可，从道义的角度来看，我或许能够接受。）

我对antirez充满敬意，并认同他是一位在自由开源领域里心地善良且仁慈的人。然而，不论 Redis 公司发布何种声明或采取何种行动，他们已经完全丧失了我的信任。只要 Redis 的分支项目依然存在，我都会持续使用它们。”

另一位网友lolinder也提到，我们刚刚在Elastic那里目睹了一幕：公司擅自修改了许可证，引发了社区的一致抵制，最终在压力之下，公司不得不再次更改。两家公司甚至使用的借口都如出一辙：“尽管过程充满艰辛，但结果证明是有效的”，“我们达成了预期目标”。

不论哪家公司，他们均未构建起任何法律层面的防护措施以避免未来再次发生冲突，而且两家企业亦已证实其并非值得信赖的守护者。在他们意识到社区支持的重要性并卑躬屈膝寻求和解之际，却已陷入“一骗无知，再骗愚蠢”的境地。」

有网友名为elAhmo提出观点，他表示：“我也有相同的看法。尽管我对antirez及其所取得的成就表示敬意，然而此次将他重新召回，我总觉得这更像是Redis公司在作出一个荒谬决策后，试图以此手段安抚开发者们的情绪。”鉴于目前已有众多切实可行的替代选项，我实在难以想出继续在 Redis 上耗费时间的必要（我们已采用 Valkey 取代了）。

毫无疑问，Redis此次“重返开源领域”具有重大意义。然而，一旦信任受损，便难以恢复。众多开发者已将Valkey等分叉项目作为主要选择。至于Redis能否凭借诚意与实际行动挽回流失的社区支持，还需时间的验证。

对此，你怎么看待 Redis 的“再开源”行为？

参考：

该文源自微信公众号“CSDN”，由屠敏整理，并已获得36氪的授权进行发布。