“闭源”13个月后,Redis再开源!开发者怒了:一回生二回熟,真当我们忘了?

Doug Brown 2025-05-08 10:36:34
开源多年后义无反顾地走向”闭源“,如今辗转一年后又重拾开源大旗,作为主流的实时数据平台 Redis 的最新动态再次搅动技术圈,引发了不少关注。

 

很多人好奇,从「开源 → 闭源 → 再开源」,Redis 的策略是否过于儿戏,此番转变,究竟是对市场的妥协,还是一次迟到的修正?还有多少开发者愿意为此回归?

 

 

一、从 Redis 8 起,重新开源!

 

还记得去年三月,Redis 公司 CEO Rowan Trollope 在官网发布了一则《Redis 采用双源许可证》的公告,宣布从 Redis 7.4 起,Redis 将放弃长期采用的开源 BSD 三条款许可证,改为采用 RSALv2(Redis 源代码可用许可证)与 SSPLv1(服务器端公共许可证)的“双重授权”策略。

 

令很多人不太能接受的是,这两种许可证都不是 OSI(开放源代码促进会)认可的开源许可,并且各自都有其限制。其中,RSALv2 要求使用者不能将软件商业化或作为管理服务提供给他人,以及不能删除或隐藏任何许可、版权或其他声明;SSPLv1 则要求如果你将产品作为服务提供,则必须在 SSPL 下公开发布任何修改以及管理层的源代码。

 

简而言之,Redis 更改开源许可之后,在 OSI 定义下不再被视为开源软件。

 

时隔一年,在刚刚过去的五一假期间,Redis 生态中的两位关键人物——项目创始人 Salvatore Sanfilippo(网名 antirez)与 Redis 现任 CEO Rowan Trollope 前后脚发文,分别发布《Redis is open source again》(Redis 再次开源)和《Redis is now available under the AGPLv3 open source license》(Redis 现已在 AGPLv3 开源许可证下提供),宣布从 Redis 8 开始,Redis 正式“重新开源”。

 

开发者现下可以从三种许可证中任选其一来使用 Redis 8 及后续版本:

 

 

  • RSALv2:由 Redis 公司制定的源代码可见但不自由的许可证。用户可以查看和使用源代码,但用途受到严格限制。

     

  • SSPLv1:由 MongoDB 开发的一种源自 GPLv3 的许可证,添加了针对“托管服务”的额外限制,旨在防止云服务商获利却不给社区回馈。

     

  • AGPLv3 :是 GNU 公共许可证(GPL)的一个变体,由自由软件基金会(FSF)发布,主要针对“通过网络提供服务的软件”(如 SaaS)的使用场景。修改后的软件必须在同样的 AGPLv3 下发布,包括运行在服务器上的代码。

 

 

二、Redis CEO:选择 SSPL 后,我们后悔了!

 

而之所以有这样的转变,Redis CEO Rowan Trollope 在最新博文中坦言,“这个改变(当初选择闭源的方式)损害了我们与 Redis 社区的关系。”话语中透露出几分悔意。

 

其实从商业视角来看,许多企业其实也能理解 Redis 当初的选择。Redis 团队长期投入开发与维护,最终却眼睁睁看着项目被云厂商用作基础设施层加以商业化,却鲜有回馈。

 

正如 Trollope 所言:“AWS 和 GCP 等超大规模云厂商的崛起,为初创公司和大型企业带来了前所未有的速度与规模。但对于那些以开源为根基的公司来说,这也带来了一个根本性的挑战:当云服务商在没有对项目做出相应回馈的情况下,从开源项目中获利并掌控基础设施时,我们该如何继续对这些项目进行创新与投入?为了解决这个问题,MongoDB 和 Elastic 等公司采用了 SSPL(服务器端公共许可证),以防止云厂商在不做回馈的情况下攫取价值。”

 

受此启发,Redis 团队最初则选择了一条看似折中的路线:推出 Redis Stack,将部分高级功能放入独立发行版中,并使用更具限制性的许可证。

 

不过,这种策略在短期内的确在某种程度上保护了 Redis 的创新能力,但也带来了明显副作用:维护两个版本(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 比 SSPL 更合适。虽然 Redis 最终选择了 SSPL,但内部的讨论并没有停止。

 

我试图为支持 AGPL 的一方增添力量。在我看来,SSPL 在实际应用中并没有被社区接受。OSI(开放源代码促进会)不承认它,软件社区也不认为它是一个开源许可证。很快,这个想法在公司各个层级获得了越来越多的支持。

 

我必须坦白地说:我真心希望我为新的 Vector Sets 数据类型编写的代码能以开源许可证发布。编写开源软件已经深深融入了我的职业生涯,我几乎从来没有写过闭源的东西。现在要我改变太迟了。也许这听起来有点幼稚,但我正是因为知道 Redis(以及我的新工作)将再次成为开源项目,才带着极大的热情写了 Vector Sets。

 

我理解,我们的核心工作是让 Redis 变得更好——一个有用、简单、能随软件栈需求而变化的优秀系统。但回归开源许可证,是让这些努力与 Redis 项目本身保持一致、获得用户接受、并融入大于任何一家公司的集体努力的基础。

 

所以说,虽然我无法把许可证更改的功劳归于自己,但我希望我多少贡献了一点点。因为今天我很开心——Redis 再次成为开源软件了,以 AGPLv3 许可证的形式。

 

现在,是时候回到终端里,通过写出我能写出的最好代码,向 Redis 用户致敬了。我还想继续改进 Vector Sets,让它更有用、更实用。我的脑子里还有不少点子,也希望你们的反馈能激发出更多(其实已经开始发生了)。」

 

当前,除了宣布 Redis 8 再次开源之后,Redis 公司也最新做出了一些关键决定,以推动 Redis 未来的发展:

 

  • 引入多年未见的全新数据类型——vector sets,由 Salvatore 设计实现;

     

  • 将 Redis Stack 的技术(包括 JSON、时序数据、概率数据类型、Redis 查询引擎等)整合进 AGPL 授权下的 Redis 8 核心;

     

  • 推出 30 多项性能优化,某些命令速度提升最高达 87%,整体吞吐量翻倍;

     

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

 

四、开发者:被骗一次是无知,被骗两次就是愚蠢

 

Redis 这一转变虽被包装为“重新拥抱开源精神”,却难掩质疑声浪。对于 Redis 反复无常的变更,更多开发者的态度是:太迟了。

 

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

 

“我曾在 Redis 还是原始许可证时贡献过一个小改进(虽然微小,但我觉得还挺不错的)。当他们突然宣布转向 SSPL 许可证时,我选择转向使用 redict——作为一个曾为这个真正自由开源项目做出贡献的人,那一刻我感到被背叛了。(说实话,如果他们一开始就转向 AGPL,从道义上讲我完全可以接受。)

 

我非常尊重 antirez,也认为他是自由开源社区中一个善良而仁慈的人。但无论 Redis 公司宣布什么、做了什么,他们已经彻底失去了我的信任。只要还有 Redis 的分支项目存在,我就会一直用下去。”

 

另一位网友 lolinder 也表示,「这整出戏我们刚刚在 Elastic 那里看过一遍:[0] 公司擅自更改许可证,社区群起反对,最后公司顶不住压力又改回来了。两家公司甚至连借口都一样:“虽然过程很痛苦,但它奏效了”,“我们达成了目标”。

 

但不管是哪家,他们都没有建立任何法律上的保护机制来防止以后再次翻脸,而且两家公司也都已经证明了自己并不是值得信赖的维护者。他们在发现社区的支持确实很重要后,才低声下气地回来求和,但这已经是“被骗一次是无知,被骗两次就是愚蠢”的局面了。」

 

甚至有网友 elAhmo 指出,「我也是这样想的。虽然我尊重 antirez 以及他所做的一切,但这次把他重新请回来,感觉更像是 Redis 公司在做出荒唐决定之后,想用这种方式把开发者们哄回来。考虑到现在已经有不少可行的替代方案,我实在看不出还有什么理由要继续在 Redis 上投入时间(我们已经用 Valkey 替代了)。」

 

毋庸置疑,Redis 此番“回归开源”,意义非凡。但信任一旦失去,就难以修复。对于不少开发者来说,Valkey 等分叉项目已成为新的主力。而 Redis 是否真能用诚意和行动挽回流失的社区,还需时间来检验。

 

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

 

 

>>>>

参考资料

 

  • https://antirez.com/news/151

  • https://redis.io/blog/agplv3/

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

 
 
 

 

作者 | Doug Brown   翻译 | 郑丽媛

出品 | CSDN

 

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

图片
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告