整理 | 华卫、核子可乐

近日，Redis-rs （适用于 Rust 的 Redis 库）的创建者 Armin Ronacher 在该项目的 Issues 区更新了一条评论，表示 Redis 公司正在要求其将项目转让给他们，而他本人最近没有在该项目作出更多贡献、也并不想因商标侵权的争议卷入法律纠纷，所以向其他的项目维护者们求助相关问题和解决建议。

与此同时，Predis 的维护者 Till Krüss 透露，Redis 公司也向他提出了同样的要求。Predis 是一个适用于 PHP 7.2 及更高版本、灵活且功能齐全的 Redis 客户端。

这些消息传出后，一众开源企业家和维护者们都“警铃大作”。

“看起来 Redis 正试图接管所有 OSS Redis 库。Jedis、Lettuce 和 redis-py 宕机了，他们现在正在威胁 redis-rs。”SvixHQ 的创始人兼 CEO Tom Hacohen 率先表示。

紧接着 Percona 创始人 Peter Zaitsev 发出更深的疑问，“它们接下来是否会进行优化以不再与 Valkey 兼容？”

对此，Clipsource 的首席技术官 Erik Hoffman 评价道，“Redis 现在对所有事情都采取了 Wordpress 的态度。任何东西都不允许以 Redis 命名… 这样摧毁自己的社区是悲剧性的。”

开源 Redis 库面临转让 or 侵权难题

以下为 Redis-rs 项目创建者 Armin Ronacher 发布的完整内容：

用户们好，我已经很久没有主动维护过这个库了，你们可能也注意到了，但我仍与 redis 发布团队以及 @badboy 一起单独控制着 crates.io 上的项目。

在我看来，这个项目没有我也能做得很好，你应该认为那个项目与我无关。不过，我现在收到了一封来自目前控制 redis 的公司 （Redis， Inc.） 的电子邮件，我还和他们的人打了 45 分钟的电话，了解了他们的想法。

目前他们给我提供了一些选择，基本上归结为以下几种：

1. 商业收购并转让给 Redis 公司；

2. 重新命名 crates.io 上的软件包，因为在他们看来，该库的名称构成了商标侵权；

3. 在 Redis 项目的管理下继续维护。

作为一个已经不再活跃于这个板块的人，而且从历史上看，它主要是为我自己的用途而构建的，我觉得自己没有资格对此发表意见。不过，从这次通话中我可以清楚地看出，Redis 对客户端库的兴趣与日俱增。他们现在有一些客户想要 Rust 支持，他们需要以某种方式解决这个问题。他们还将 Python 和 Go 客户端库转移到了 Redis，不确定是根据哪些条款，但他们正试图将其余感兴趣的库也转移到 Redis。

当我创建这个项目时，我并没有想到要在商业企业之间做出决定，所以我更希望让库的实际用户和当前的维护者参与进来。

我个人已经开始使用 Valkey，我有一个宠物项目就是使用这个库来连接它的。最近在 #1409 中也有一些讨论说 Valkey 应该成为 CI 矩阵中的测试目标。我不知道 Redis 公司是否有兴趣支持 Valkey，我也不知道这个库的用户是否关心 Valkey。

说明一下背景：crate 是我为学习 Rust 专门编写的部分。在 2015 年左右，它被标注为 redis.io 上的推荐 Rust 库，当时的作者是 antirez。不管当时的商标政策是什么，我想这种使用客户端库的做法在当时是可以接受的。但现在情况可能不同了，所以法律上可能会有争议。

虽然这个 crate 可能是 Rust 最受欢迎的一个，但从宏观上讲，与 Redis 的其他库相比，我想它并不是特别受欢迎或者对业务至关重要。我不确定 Redis 公司对它的关心程度。就我个人而言，我并不想卷入法律纠纷，所以我的愿望是让自己远离 Redis 公司可能想要实施的任何潜在商标强制措施。

据 Ronacher 介绍， Redis 公司给另一位 Redis-rs 的项目控制者 Jan-Erik Rediger （@badboy ）和他本人都先后发送了邮件。

这是 Jan-Erik Rediger 最先收到的邮件内容：

我很乐意了解这个项目的实际情况，最近它的热度着实不低。简单来讲，其已经成为 Rust 生态下最受欢迎且贡献量最大的客户端库，似乎也是我们值得向用户推荐的最佳选择。

但为了保证提供官方支持，我们需要先充分了解这个库、再规划如何为客户提供完善支持。之后我们才能规划路线图和发布时间，及时提交 bug 修复并为其做出贡献。我不想以分叉的方式夺取控制权并跟 redis-rs 竞争。在我看来，这种用照搬过往成果的方式在社区中引发混乱没什么意义。

我不希望在社区驱动库中引入 Redis Enterprise（商业）功能，相反，我们将坚持只引入与 Redis 社区版完全兼容的企业级功能。对于由 Redis 控制但得到社区持续贡献的成功实施意见库，我们也坚持同样的思路。Jedis、Lettuce、redis-py 等项目确实归 Redis 所有，但获得了社区的积极贡献和支持。

另一种路线则是通过商业协议讨论收购。出于多种原因，这也是个行之有效的替代方案。我们的法务团队就经常遇到需要经 Redis 批准的商标使用问题。但我觉得在邮件中不太适合讨论这个问题。

如果你和 Armin 也能参与讨论，我将不胜感激。期待您抽出 30 分钟的宝贵时间跟我聊聊，越快越好。如果您没空，也希望您能推荐一下 Armin 的联系方式，我实在是找不着渠道

这是 Armin Ronacher 收到的邮件内容：

我作为 Redis 客户端库和生态系统的项目经理写信给您。

我正在寻找方案来支持一些对 Redis 的 Rust 客户端感兴趣的客户。我知道你和 Jan-Erik Rediger 是 redis-rs 库的所有者/维护者，这是 Rust 最受欢迎的客户端库。

我们长期以来一直为开源客户端库提供社区贡献，并且在社区的帮助下维护最受欢迎的库。不过，我们可以控制路线图和发布版本，这是授予库可支持性地位的必要条件。我们希望了解为客户提供支持并为 redis-rs 库做出重大贡献的选项，这些选项具有即将推出的 Redis 8 发布的功能以及安全性、性能等方面的更多企业级功能。

你们是否愿意进行快速同步以讨论 redis-rs 客户端库的选项/合作？我们看到了两条通往目标的路径，但我认为最好还是以非正式对话的方式进行交流。为此，我希望能占用您 30 分钟的时间。

现在，Ronacher 最在意的问题是：有人在将这个 crate 和 Valkey 一起使用吗？将该 crate 转让给 Redis 公司是否存在风险？

项目维护者们的解决思路

Redis-rs 作为 Rust 的高级 Redis 库，通过一个非常灵活的底层应用程序接口，方便地访问所有 Redis 功能。它使用可定制的类型转换特征，因此任何操作都能以用户所期望的类型返回结果，能够带来非常愉快的开发体验。

在 Ronacher 的建议请求发出后，有积极的维护者迅速响应并提出了解决办法。

维护者 Dirkjan Ochtman 表示，“考虑到源代码采用的是三条款 BSD 许可（因此可以很容易地进行分叉），我认为最合理的的做法是由当前的团队以新的名称继续使用当前的 crate，而将旧名称留给 Redis Inc。”

Ronache 也马上回应了这一解决思路：

有不同的几种方法可以做到：

1.只需以新名称发布并提交注册即可，无论 redis 发布哪个分叉，用户都会自然而然地接受。

2.删除所有现有库，以新名称发布废弃版本，告知用户新软件包。

3.就像第 2 步，但没有删除。

我不确定注册机构是否有一套程序，可以通知用户某个名称被用于其他用途或被不同的所有者使用。

同时，Ronacher 发问道：“如果 crate 要重命名，新名称是什么？我假设显而易见的是将其重命名为 valkey-rs，我们需要了解一下 Valkey 的人对此有何看法，在这一点上，我们可能会遇到同样的情况。”

对此，Valkey 维护者 Shachar Langbeheim 第一时间出现在评论区，表示“我不确定 Redis 团队是否具备所需的 Rust 能力，也不确定他们是否真的关心 crate 的维护。我见过他们的团队为其他语言的 crate 贡献功能，但从来没有在这里做过。”

换句话说，这些项目进入到 Redis 的“保护伞”后，会发展得更好吗？

另一位 Valkey 维护者 Viktor Söderqvist 则向 Ronacher 发出了邀请：“关于新名称的问题，不妨考虑 valkey-rs 并归入 Valkey 项目官方。请注意，Valkey 同样拥有商标并归 Linux 基金会所有。Valkey 项目由来自 6 家不同企业的 6 名开发人员组成的技术指导委员会管理。我们的核心价值只有一个：坚持开源。”

Redis“保护伞”能使社区受益吗？

大家讨论得不可开交之际，Redis 公司的产品经理 Mirko Ortensi 出来说话了，称“让 Redis 及背后社区共同支持并贡献同一个库这种集中力量办大事的思路才是正确的”，但似乎不仅没有得到开源维护者们的认同和支持，还引来了更多的犀利质疑。

我注意到人们对于 Rust 语言版本 Redis 客户端库的关注度正与日俱增。跟其他客户端库的情况类似，除了为库的本体做出贡献之外，我还愿意为 Redis 用户（和客户）提供发布周期、bug 修复、快速升级支持以及切实可行的路线图等多方面保证。同样的，跟其他客户端库一样，我们也欢迎社区积极发挥作用，并保证贡献质量与我们的标准和创新要求相契合。

关于贡献，我们期待提供一套能够支持这些功能的 Rust 客户端库（支持传统与向量搜索的二级索引、JSON、时间序列和概率数据结构）。所有这些都将在 Redis 8 中推出，而且目前已经以里程碑版本的形式发布。鉴于 redis-rs 已经拥有庞大的用户社区，我不会考虑对该库做分叉来与其本体相竞争。在我看来，让 Redis 及背后社区共同支持并贡献同一个库这种集中力量办大事的思路才是正确的。我们正在为此做好各项准备。

把 crates.io 上的包重新命名一下，因为他们觉得库名称构成了商标侵权

这话不是我说的，也不是我想表达的意思。只是在一次私人通话中，我提到使用品牌名称来命名一个库感觉很奇怪。毕竟这个库会无限期支持所有分叉，而且不保证产品本身的兼容性。我还说过，单纯用重新命名 crate 的方式拿同样的软件或者替代库将其替换，只会加重混乱和沮丧情绪，并没什么实际意义。

当然，企业在声誉受到挑战时肯定会考虑保护自己的商标资产，这事没有任何问题。在我跟 Armin 的私人通话中，我也强调了这一点。当然，我们并没有就商标采取实际行动的计划，只是想找个合理且能够达成共识的前进方向。

首先 Langbeheim 直言道：“你说你想要一个开放的开发社区，但你也想要控制权。我希望你明白，鉴于 Redis 最近在授权方面的行为，这两个目标被认为是相互排斥的。”

另一位 Valkey 的维护者 Madelyn Olson 表示，“我最初的希望是，我们能够同时支持 valkey 和 redis，让它们能够在一个开放的开发社区中继续发展。各个项目之间仍有很多重叠之处，因此将它们分叉似乎有些浪费。”

Redis-rs 项目贡献者 James Lucas 则称，“ 你认为目前 crate 的维护者无法满足这一要求吗？这个 crate 在很大程度上（如果不是主要）是由整个社区的贡献驱动的。我认为没有任何理由认为核心 redis 团队的贡献会在这方面会得到不同的处理，我们不会响应您团队的请求。”

还有人更为直接地表示：“我不相信这个项目在转入 Redis 旗下后会变得更好。在我看来，你们的团队忽视了许多社区讨论和 go-redis 问题。你们关心的是客户，而不是社区或任何贡献者。你可以给予客户支持，但不能给予社区支持。”

这一说法也得到了其他用户的赞同，认为“将该项目转移到 Redis 旗下不会给社区（甚至也不会给公司）带来好处，而只会解决潜在的商标问题。”

来自 Apache OpenDAL 社区的 PMC 主席、ASF 成员 @Xuanwo 则担心，“如果将这一代码仓库转交至 Redis，我担心 Redis 可能会对其协议或者客户端本体做出重大更改，阻止用户使用此客户端访问其他与 Redis 兼容的服务。”其提出，“不知道能不能给 Redis 协议起一个正式的名称，并围绕它建立起一整个生态系统。比如我们可以称之为 xxx，它将与 xxx 和 xxx 相兼容，允许 Redis 同一切与 Redis 兼容的系统进行通信。”

事实上， 与 Redis 类似的问题也在其他开源项目上出现过，但处理情况却截然不同。

例如， Apache Kafka 项目也不在 Confluent 旗下（当然他们不能这样做，因为商标属于 ASF），但他们的做法是积极参与社区活动，通过在社区中的贡献赢得用户信任。与此同时，他们仍然可以为其客户提供支持，他们拥有“官方 Confluent 支持的客户端”。

Valkey 发展势头强劲

长期以来，Redis 已经成为众多开发人员工作流程中不可或缺的组成部分。其受到欢迎的一大原因在于其出色的灵活性，虽然主要作为缓存方案存在，但开发人员也经常将其用作键值存储、数据库和消息队列。如今的 Redis 经过充分发展，已经能够适应各类细分市场的具体需求。

毫不夸张地说，Redis 可能是技术历史上使用范围最广，至少在开发者群体当中得到评价最高的软件基础设施方案之一。

对于此番事件，不少人都在猜测 Redis 公司的出发点：“他们希望从中得到什么？这岂不是只会给自己的用户带来不便吗？”

而被提及最多的就是针对“Valkey 兼容”的担忧，“我怀疑 Redis 会将各种流行的 Redis 库纳入他们的保护伞下，并使它们与 Valkey 不兼容。这似乎是对 Valkey 的防御性举动。”

今年 3 月，在 Linux 基金会宣布支持 Redis 的“Valkey”开源分叉之时，Redis 公司 CEO Rowan Trollope 就对此嗤之以鼻，称其是云服务商为了避免支付许可费而采取的卑劣手段。Trollope 表示，“各大主流云服务商都从 Redis 开源项目中获得了商业利益，因此在基金会内部发起分叉并不奇怪。”

当时，System Initiative 联合创始人 Adam Jacob 公开评价称，Redis“现在有了一位资金充足的竞争对手”。而 Percona 最近公布的调查结果表明，市场对于 Valkey 表现出了浓厚的兴趣。上个月，谷歌宣布旗下 Memorystore 将支持 Valkey，亚马逊云科技也表示将在 ElastiCache 和 MemoryDB 中支持 Valkey。Aiven 于 6 月发布了 Aiven for Valkey。

从 2024 年 3 月 Valkey 发布至今，谷歌搜索趋势显示，该项目的势头总体上优于其他替代方案。当然，这种短期内的关注激增恐怕不可能长期持续。

维基百科搜索历史数据显示，在过去 90 天内，Valkey 的关注度已经达到 Redis 的约六分之一，表现颇为强劲。通过这些指标，可以看到技术社区对于 Valkey 的关注度和参与度都在强劲增长。

Valkey 也在用实际行动表明，它将继续追求自身独有的技术观点与优先事项，而不仅仅是作为 Redis 的开放及兼容版本。随着在该项目首个 8.0 版本中引入 IO 多线程等功能，Valkey 显然不打算去跟 Redis 的风，而是一套拥有自主路线规划能力的强大解决方案。

未来是无法保证的，但若有足够的资金和资源，开源分叉项目或也能够赢得人心和用例量。

参考链接：

https://github.com/redis-rs/redis-rs/issues/1419

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

https://redmonk.com/rstephens/2024/10/11/valkey-momentum/

https://thenewstack.io/linux-foundation-forks-the-open-source-redis-as-valkey/