Redis 之父宣布“Redis 再次开源”！网友：骗我一次，算你狠；骗我两次，是我蠢

近日，作为广受欢迎的键值数据库背后的缔造者，Redis 公司已经将其同名产品重新拉回开源阵营。不过此举仍未能将某些批评者完全满意。

时隔一年，Redis 重新开源

Redis 方面表示，自 Redis 8 开始将把 GNU Affero 通用公共许可证（AGPL）作为 Redis 的附加许可选项，且正在转向由开源代码倡议（OSI）认定为开源的许可模式。也就是说，去年 3 月其转向服务器端公共许可证（SSPL v1）的退出开源决策如今正被逐步撤销。

用户可以选择以下三种许可证选项之一来使用 Redis Open Source（自 Redis 8 版本开始）及其后续版本：Redis 源代码可用许可证 v2 (RSAL v2)、服务器端公共许可证 v1 (SSPL v1) 和 GNU Affero 通用公共许可证 v3 (AGPL v3)。

上个月，Redis 公司 CEO Rowan Troolope 在接受采访时表示，“目前并没有任何迹象表明 SSPL 被广泛认可为一种有效的开源许可证。我们原本希望大家会将 SSPl 视为一种良好的许可证方案，它符合所有条件，甚至 OSI 或许也会重新考虑具体认定。但似乎结果并非如此。”

而如今这一重新开源的决定，是由 Redis 的创始人 Salvatore Sanfilippo 发帖（ Antirez）公布的。有意思的是，Antirez 的原文标题就是“Redis is open source again”。

以为为声明原文：

五个月前，我重新加入 Redis 并很快跟同事们讨论起是否该改用 AGPL 许可证。我发现公司内部早就在关注这个问题，不少人都觉得 AGPl 比 SSPl 更好。虽然 Redis 最终还是选择了 SSPL，但争议的声音从未断绝。

 

我一直在努力为 AGPL 这派的支持者争取更多空间。我个人感觉社区其实并没有真正接受 SSPL。OSI 开源代码倡议不会接受它，软件社区也不会把 SSPL 视为开放许可证。很快，我看到公司各个层级都越来越重视这个问题。

 

说实话，我真心希望自己为全新 Vector Sets 数据类型编写的代码能通过开源许可证发布。编写开源软件已经成为我根深蒂固的习惯，我在整个职业生涯几乎都在为此而努力。现在我年纪太大了，不太适合改旗易帜。听起来可能有点理想主义，但我确实是怀着极大的热情在编写 Vector Sets，前提就是 Redis 和我的工作成果能够再次开源。

 

我很清楚，我们的工作核心只是改进 Redis，持续构建一套良好、实用、简洁且能够根据软件栈需求进行调整的系统。然而，回归开源许可证能够更好地与 Redis 项目定位保持一致、扩大用户群体接受度，也是为这一人类共同努力的成果做出贡献的基础。所以回归开源许可证虽然不是我一个人能够决定的，但我仍然希望自己能为此做出一点努力。今天我高兴地看到 Redis 再次回归开源阵营，并且遵循 AGPL v3 许可证。

 

现在是时候回归终端了，用我所能写出的最佳代码来表达对于 Redis 用户的敬意，也希望 Vector Sets 能够更加实用。我还有不少改进思路，希望大家的反馈能够激发我更多的想法。总之，开源万岁！

那么，Redis 为何要添加 AGPLv3？AGPLv3 与 BSD3 许可证又有何不同？

Redis 公司解释说，之所以添加 AGPLv3 许可证，是因为之前的许可引发了社区的强烈不满。

部分社区成员对 Redis 于 2024 年 3 月将项目变更为 RSALv2 和 SSPLv1 双许可证感到不满，因为这两个许可证均未获得 OSI 批准。Redis 公司变更许可证是为了针对那些使用 BSD3 许可证下的 Redis 7.2 及之前版本，但贡献有限的托管服务提供商。此次许可证变更迫使这些提供商面临一个选择：是按照 SSPLv1 许可证共享源代码，还是直接放弃 Redis。其中一些人选择了放弃。

引用 Redis 公司 CEO 2024 年 3 月的博文：“为 Redis 提供竞争性产品的组织将不再被允许根据任何双许可证免费使用 Redis 的新版本源代码。如果您正构建的解决方案只是在使用 Redis，但并不与 Redis 本身进行竞争，则不会受到任何影响。”

BSD3 许可证和 AGPLv3 代表着不同的开源许可方式。BSD3 是一种宽松的许可证，允许用户对代码进行几乎任何操作，包括在专有软件中使用，前提是他们保留版权声明和免责声明。

相比之下，AGPLv3 是一种 copyleft 许可证，要求任何修改版本都必须遵循相同的条款分发，并且还要求必须向通过网络与软件交互的用户提供源代码。这项“网络条款”是 AGPLv3 的标志性特征，旨在确保 Web 应用程序用户可以访问源代码。

可如果 Redis 未来再次变更许可证，又该怎么办？

Redis 公司也承诺以后基本上不会再变更许可证了，他们已经意识到社区的重要性，因为社区是 Redis 生命力的基石。

“目前没有计划变更或添加当前的 Redis Open Source 许可证配置。“由于我们将许可证变改为 RSALv2/SSPLv1 的核心目标现已成功实现，因此我们可以更好地满足 Redis 社区的期望。在选择 AGPLv3 之前，我们投入了大量时间考虑不同的许可证并分析市场动态。其他公司也已将 AGPLv3 纳入其社区的选择范围

 

这里再次澄清：我们计划在 AGPLv3 许可证下保持 Redis 开源，我们认为该许可证匹配 Redis 的商业模式，而且许可证稳定性对于社区生态至关重要。我们意识到社区是 Redis 生命力的基石，我们也将永远秉持这一理念。”

社区反应如何？

Redis 此次变更许可证行为，在社区中引发了热烈讨论。

一位曾经给 Redis 做过贡献的开发者在 Hacker News 上发帖表示，即使 Redis 公司重新开源了它，但信任已不复从前。

“我曾在 Redis 的原始许可证下贡献过一个小改进（虽然不大，但我觉得还挺不错的:p）。后来当 Redis 突然宣布将许可证变更为 SSPL 时，我便转向了 Redict。作为一个真正自由/开源软件的贡献者，我感觉自己被背叛了——如果他们当时改用 AGPL，从道德角度来说，我完全可以接受这种调整（顺便一提）。

 

我非常尊重 antirez，认为他是 FOSS 社区中一位善良、仁慈的成员。但无论 Redis 公司现在或未来宣布什么、做什么，他们已经永远失去了我的信任。”

一位经历了 Elastic 和 Redis 两个许可证变革的 Hacker News 用户表示：

我们刚刚见证了 Elastic 历史的重演：一家公司单方面更改开源许可证，社区强烈反对，最终迫使公司撤回决定。讽刺的是，他们两家公司甚至使用了同样的说辞来粉饰这场闹剧——‘虽然艰难，但最终成功了’、‘这实现了我们的目标’。

 

更可悲的是，它们既没有建立任何法律约束来防止故技重施，也彻底暴露了管理层的不可信赖。直到发现社区的善意才是生存之本时，才慌忙低头认错。但这种事后补救，不过是‘骗我一次，算你狠；骗我两次，是我蠢’的尴尬局面罢了。

还有用户表示提到了 NATS 最近也差点就这么做了。幸好，在 CNCF 和社区抗议之后，他们今天终于妥协了。虽然结果很好，但这完全是一场闹剧，他们的声誉也受到了损害。

事实上，更多用户认为，类似 Redis 公司所做的事情，经常在开源项目中上演。

就拿数据库领域来说，最初，开发者们怀着理想主义的热情，基于完全开源的 OSS/FOSS 许可证构建数据库项目，吸引社区贡献和用户增长。随着项目逐渐成熟，核心团队往往会成立商业公司，持续投入多年开发，甚至引入风险投资以扩大规模。然而，当项目获得市场认可后，Oracle、Google、微软等云厂商便开始直接托管这些数据库服务，轻松获取数百万美元的收益，而原创团队却难以从中分得合理的回报。

面对这一困境，开源公司通常会尝试通过变更许可证来迫使云厂商付费合作。但这一举措往往适得其反——云厂商直接分叉项目，而社区则陷入分裂。

反对者中既有来自云厂商的员工，也有坚持 FOSS 理念的纯粹主义者。最终，在巨大的舆论压力下，公司不得不撤回许可证变更，继续陷入“为他人做嫁衣”的恶性循环。这一过程不仅消耗了开发者的热情，也让开源商业化的道路变得更加艰难。

也就不难理解，为什么开源项目背后的公司即使最后低了头，也很难挽回开发者的信任了。

“开源运动的真正成功，在于它构建了人类数字文明的公共基础设施。然而，超大规模科技企业却将其异化为一种“数字矿场”——他们贪婪地开采代码价值，却逃避建设与维护的责任。

 

我们陷入了一个认知陷阱：错误地将‘开放共享’等同于‘强者为所欲为’。

 

是时候打破这种幻觉了。单纯依靠许可证条文已远远不够，我们需要重新思考开源生态的激励机制、治理结构和抗风险能力。下一代的开放模式必须内置制衡机制——否则，所谓的‘开放’不过是科技垄断者的免费饲料罢了。”

Redis 之父的回归，加快了再次开源的进程

事实上，自去年 3 月份，Redis 公司宣布更改开源许可之后，社区里出现了多个 Redis 分支，如 Redict、Valkey 等，这其中最著名的要属 Valkey，因为它的背后是由 Redis 项目众多核心开发者支持的，且被 Linux 基金会纳入后已经成功推出了首个兼容候选版本，它允许现有 Redis 用户轻松迁移到 Valkey，而无需进行向后不兼容的 API 更改。

Redis 和社区之间的矛盾已经达到了顶峰。那时候，Redis 之父还没有回归到社区中。

2020 年 Antirez 辞去了 Redis 维护者的职务，此后很长一段时间，他再也没有看过源代码、提交消息或任何与 Redis 相关的东西。但当去年 12 月底，他注意到 Redis 社区出现了分裂，这让他感到担忧，因此，他考虑重返 Redis 生态系统，修复企业对于 Redis 社区的态度，帮助将后续的开发重点再次放在 Redis 的核心身上。

在决定回归后，Antirez 发了一封博文说明了重返 Redis 的原因。在博文中，Antirez 提到最近几年生活并不宽松，他想给女儿创造更好的生活，因此萌生了重返纽约并找份兼职工作的想法。此前，他在一次视频通话中向新任 Redis CEO Rowan Trollope 表达了这个意向，并得到了对方的积极回应。

当时，外界对 Antirez 的回归充满了各种猜测。很多人认为，除了家庭原因，一定还有其他更深层次的动机，比如巨额薪资、私下协议，甚至是对 Redis 更改许可证的不满。

Antirez 本人对此进行了澄清。他表示，是自己主动联系了 Redis，而不是公司挖角。他拿到的薪资也是“常规水平”，并没有获得额外的特殊待遇，但仍然会获得跟以前一样的 Redis 股票期权。

而对于 Redis 切换许可证的决定，他解释说虽然他自己可能会选择别的不同许可证，“毕竟我已经远离项目一线多年了，不太能感受得到业务端的压力”，但总的来讲，他完全可以理解这个决定。

而今天重新开源的决定一出，似乎从某种程度上说明了他回归社区的本质原因——缓和公司与社区间的关系，并将 Redis 重新开源。

最后，我们再次解释下这三种许可证到底是什么，以及区别是什么？

RSAL v2 是由 Redis 公司建立的宽松非版权许可证，允许用户“使用、复制、分发、交付和制作软件的衍生作品”，且只设两项主要限制。用户不得：

• 将软件商业化或以托管服务的形式提供给他人，从而向第三方提供软件的功能；以及

• 删除或隐藏任何许可、版权或其他声明。

RSALv2 不属于开源许可证。

SSPLv1 是由 MongoDB 创建的源代码可用许可证，允许免费且不受限制地使用、修改和重新分发，但有一条简单要求：如果您将产品作为服务提供给他人，则必须同时根据 SSPL 公开发布所有修改版本以及管理层的源代码。

SSPLv1 基于 GPLv3，被视为 copyleft 许可证。也就是说，如果您使用源代码并创作衍生作品，则这些衍生作品也必须根据 SSPL 获得许可并公开发布。

SSPLv1 不属于开源许可证。

AGPLv3 是由自由软件基金会 (Free Software Foundation) 推出的开源许可证，专为在网络上运行的代码而设计，要求用户在分发时公开完整的源代码及其所有修改。

AGPLv3 是一种 copyleft 许可证。也就是说，如果您使用源代码并创作衍生作品，则这些衍生作品也必须获得 AGPLv3 许可并公开发布。

AGPLv3 属于 OSI 认证的开源许可证。

参考链接：

https://antirez.com/news/151

https://redis.io/legal/licenses/

https://news.ycombinator.com/item?id=43859446