这是啥骚操作？Redis要对redis-rs下手了

摘要：近日，Webhook 即服务公司 Svix 创始人兼 CEO Tom Hacohen 在社交媒体 X 上发布了一条消息，说 Redis 似乎正在尝试全面控制所有开源 Redis 库。Jedis、Lettuce 和 redis-py 都已经被接管，现在它们开始威

近日，Webhook 即服务公司 Svix 创始人兼 CEO Tom Hacohen 在社交媒体 X 上发布了一条消息，说 Redis 似乎正在尝试全面控制所有开源 Redis 库。Jedis、Lettuce 和 redis-py 都已经被接管，现在它们开始威胁 redis-rs 了。

redis-rs 是一个用 Rust 编写的 Redis 客户端库，它可以让开发者在 Rust 中操作 Redis。这个库是通过 crates.io 分发的。

链接是：https://crates.io/crates/redis

Tom Hacohen 发表这段话的原因是因为 Python 社区著名的开发者和开源贡献者，同时也是 Flask Web 框架的共同创建者之一 Armin Ronacher，在 GitHub 上发表了一段关于 Redis 与他联系的情况以及 Redis 对于 redis-rs 库未来发展方向的建议。

他是这么说的：

大家好，你们可能已经注意到了，我已经很长时间没有积极维护这个库了。我仍然与 Redis 发布团队和 Jan Erik Rediger（redis-rs 项目的关键维护者）一起在 crates.io 上管理它的条目。

就我个人而言，我认为这个项目完全可以在没有我的情况下继续运行，你们应该认为这个项目和我没有关系。不过，最近我收到了来自当前控制 Redis 的公司（Redis Inc.）的邮件，基本上告知我这个库当前的状态对他们来说是不可接受的。我还与那边的一位工作人员进行了 45 分钟的通话，详细了解了他们的想法。虽然他们提供了一些选项，似乎可以归结为以下几点：

商业收购并转交给 Redis Inc.在 crates.io 上重命名包名，因为他们认为这个库名构成商标侵犯在 Redis 项目的治理下继续维护

作为一个现在已经不再活跃在这个库上的人，而且这个库最初主要是为我自己使用而开发的，我觉得自己并不适合做出决定。但从那次通话中我非常清楚地认识到，Redis 正在越来越重视客户端库。他们现在有一些客户需要 Rust 支持，必须找到一个解决方案。同时，他们也已经将 Python 和 Go 客户端库交给 Redis 管理，不清楚是以什么条款，并且他们正在尝试做同样的事处理其他受关注的库。

当我创建这个项目时，我并没有预料到要在商业公司之间做出选择。因此，我更希望实际使用这个库的用户和当前的维护者们参与讨论，做出决定。

个人而言，我已经开始使用 Valkey 并在自己的项目中接入了这个库。之前我也说过了，Valkey 应该是 CI 测试矩阵中的一个目标。虽然没有得到确切的承诺，Redis 公司是否有意支持 Valkey，我也不清楚这个库的用户是否关心 Valkey。

一些背景信息：redis-rs 是我当初为了学习 Rust 而编写的。大约在 2015 年左右，它被标记为 redis.io 上推荐的 Rust 库，当时由 antirez 负责管理。不知道当时的商标政策是什么，但我猜那时使用这个客户端库是可以的。如今可能不行了，所以法律部门可能会对此提起诉讼。

虽然这个 crate 是 Rust 中最受欢迎的 Redis 客户端库之一，但从整体来看，它并不算特别流行或对商业有决定性影响，相较于其他 Redis 库来说，应该不算特别重要。对于 Redis Inc. 是否在意它，我也不清楚。

就我个人而言，我不想卷入任何法律纠纷，所以我希望自己能够避免与 Redis Inc. 可能展开的商标执法行为相关的任何事务。

Armin Ronacher 也跟其他贡献者一起讨论了这件事情。

一位贡献者说，尽管我仍然被列为发布团队成员，但我已经有一段时间没有积极维护这个库了。

鉴于源代码采用 3-clause BSD 许可证（因此可以轻松分叉），我认为最合理的做法是继续由现有团队在一个新名字下维护当前的 crate，将原来的名字留给 Redis Inc.。

Redis 产品经理 Mirko Ortensi 也做了解释，他说除了为库本身做贡献之外，他们愿意为 Redis 用户（和客户）提供发布周期、错误修复、快速升级支持和切实可行的解决方案方面的保证。同样也支持社区发挥作用，并保持质量与他们的标准和创新保持一致。而且鉴于 redis-rs 已经拥有庞大的用户社区，不会考虑分叉该库来与 redis-rs 竞争。

他是这么说的：

我注意到，越来越多的人对 Rust 语言的 Redis 客户端库产生了兴趣。与其他客户端库类似，除了为库本身做贡献，我希望能为 Redis 用户（以及客户）提供关于发布周期、错误修复、快速支持和升级处理，以及现实的开发路线图等保障。再次强调，就像其他客户端库一样，我们会依靠社区的力量，确保质量与我们的标准和创新保持一致。

关于贡献，我们计划提供一个支持以下功能的 Rust 客户端库：传统和向量搜索的二级索引、JSON、时间序列和概率数据结构。这一切将在 Redis 8 中推出，并已经作为里程碑版本发布。鉴于 redis-rs 已经拥有庞大的用户社区，我并不打算分叉该库与 redis-rs 本身竞争。在我看来，最有意义的做法是由 Redis 和社区共同支持和贡献一个库。我们也已经为此做好了准备。

关于在 crates.io 上重命名包名的问题，因为他们认为库名构成商标侵权。

这些话并非我所说，也不是我想表达的意思。在一次私人通话中，我表示，继续使用品牌名来支持所有的分叉，同时又不为 Redis 本身提供兼容性，感觉非常奇怪。我还提到，假装重命名一个 crate，并用相同的软件或其他替代库替代它，这样做只会带来混淆和挫败感，毫无意义。

但是，企业确实会在品牌声誉受到挑战时考虑保护其商标，这一点无需多言。在我与 Armin 的私人通话中，我强调了这一点。当然，目前并没有计划采取任何商标行动，重点是找到一种理性且达成共识的前进方式，避免引入另一个 Redis Rust 客户端库，确保可以在其中加入更改、改进和创新。

如果有计划支持 Redis 的分叉，保留 Redis 的 crate 并为分叉提供其他 crate 是有意义的。没有任何 Redis 替代品能够长期保证与 Redis 的兼容性。Valkey 已经表示了保持独立开发的意图，这完全可以理解，发布 Glide Rust 库的决定也同样可以理解，这个库也许会在未来推出。

令人奇怪的是，试图保留一个 Redis 品牌的库并为 Valkey 提供完全兼容，但又不为 Redis 提供兼容性，这样做对任何人都没有帮助。

我非常期待听到大家的想法，以便我们能就如何朝着正确的方向前进达成一致。

X 上用户对 Redis 的行为表示质疑和失望。

有人说 Redis 误解了开源和社区。