Redis 又双叒叕改开源协议了，微软提前推出高性能替代方案 Garnet

Redis 官宣：是的，我们又改开源协议了

3 月 20 号，Redis 商业公司 CEO Rowan Trollope 在公司官方博客上宣布了一项重大变革。Redis 核心软件将从 BSD 3-Clause 许可证过渡到双重许可证模式，这一变化将从 Redis v7.4 版本开始，贯穿到未来所有的 Redis 发布版本。新的许可证模式使用了 Redis Source Available License version 2 (RSALv2) 或 Server Side Public License version 1 (SSPLv1)。

BSD 3-Clause 许可证，也称为“新 BSD 许可证”或“修改版 BSD 许可证”，是一种常用的开源软件许可证。它是原始 BSD 许可证的修改版，由加州大学伯克利分校（University of California, Berkeley）创建。与 MIT 许可证类似，BSD 3-Clause 许可证对源代码的使用、修改和分发施加了很少的限制，因此被认为是一种非常宽松的许可证。它鼓励代码共享和重用，同时为开发者提供了很大的自由度。它允许自由使用、修改和分发，被许可的源代码可以自由地使用、修改和分发，无论是以源代码形式还是二进制形式。也允许闭源使用，允许将源代码集成到闭源的专有软件中。

BSD 3-Clause 许可证是一个是被开源促进会（Open Source Initiative，OSI）认可的开源许可证。OSI 是一个非营利组织，致力于推广开源软件和开源理念。他们维护了一个被认可的开源许可证列表，这些许可证满足了 OSI 的开源定义（Open Source Definition），这个定义包括了十个关键条款，如自由再分发、源代码可获得、允许修改和衍生作品等。根据 OSI 的定义，只有采用了 OSI 认可的许可证，才能被称为开源软件（Open Source Software，OSS）。因此，如果一个软件项目采用了未经 OSI 认可的许可证，即使该许可证允许源代码的获取和修改，也不能被正式称为开源软件。

而 Redis 的新开源协议，RSALv2 和 SSPLv1，都并未被 OSI 正式认可。OSI 认为，这两种协议包含了一些限制性条款，这些条款与开源定义(OSD)不完全兼容。因此可以认为 Redis 在修改许可证后，已经不再是开源软件（OSS）。Redis 的官网已经修改为“Redis is source-available software”。

这已经不是 Redis 商业公司第一次修改许可证了

这已经不是 Redis 商业公司第一次修改许可证了。早在 2018 年，Redis 就修改过其开源协议，将公司开发的 Redis 模块（例如 RediSearch、Redis Graph、ReJSON、ReBloom 和 Redis-ML）从 AGPL 迁移到将 Apache v2.0 与 Commons Clause 相结合的许可证，这些模块提供了额外的功能，扩展了 Redis 的应用场景。这个变更引起了社区的一些争议,因为"Commons Clause"限制了这些模块在某些商业场景下的使用。

2019 年 3 月，为了回应社区的反馈，Redis Labs 宣布将这些模块的许可证改为 Redis Source Available License （RSAL），取消了之前的"Commons Clause"。RSAL 允许自由使用、修改和再分发这些模块，但在提供基于这些模块的数据库产品或服务时，需要获得商业许可证。

2022 年 11 月 15 日，Redis Labs 再次调整了许可证策略，宣布将一些模块（如 RediSearch、RedisJSON、RedisGraph、RedisTimeSeries 和 RedisBloom）改为双重许可证，即 RSAL 和商业许可证并行。这一变更旨在应对云服务提供商使用开源软件的商业模式问题。Redis Labs 称，“一些云服务提供商将 Redis 及其模块作为服务提供，但没有为 Redis 的开发做出相应的贡献。许可证的改变旨在鼓励这些公司为 Redis 的开发提供支持。”

在此前的许可证修改中，Redis 的核心项目一直使用宽松的 BSD 3-Clause 许可证。这个许可证没有发生过变更，一直保持稳定。厂商的信心来自于此前修改许可证带来的商业收益，Redis CEO 表示：“我们已经在 Redis Stack 分发中对我们的高级 Redis 模块实施了双重许可证，这得到了社区的好评。事实上，redis.io 下载中超过 50%（从 Redis 6 开始）来自 Redis Stack。我们相信，将此许可证扩展到 Redis 本身，能够让我们继续为用户提供最全面的数据模型、处理引擎和开发者功能。”

此次修改 Redis 核心项目的许可证，应该是 Redis 针对云厂商发起的一轮终极进攻。谁会被这次修改许可证影响呢？提供 Redis 竞争性产品的机构（例如，云厂商）将不再被允许免费使用新版本的 Redis 源代码。“竞争性产品”是指通过付费支持安排等方式出售给第三方的产品，该产品源自 Redis 的代码库，并且与 Redis 商业产品的功能显着重叠。例如，此定义将包括托管或嵌入 Redis 作为解决方案的一部分，该解决方案的销售与 Redis 商业版本（Redis Enterprise Software 或 Redis Cloud）具有竞争力。此前，Redis Labs 的 CTO Yiftach Shoolman 表示：“多年来，云提供商通过销售基于开源项目的云服务，可从中获利数亿美元，可这些项目实际上并不是他们自己开发的，如 Docker，Elasticsearch，Hadoop，Redis 和 Spark。这阻碍了社区投资开发开源代码，因为任何潜在的好处都归云提供商而不是代码开发人员或他们的赞助商。”

Redis Labs 并不是唯一一家做出这样改变的公司。在 2018 年，紧跟 Redis，MongoDB 将其开源许可证从 GNU AGPLv3 切换到 Server Side Public License (SSPL)。2018 年 5 月，Neo4j 图数据库在其 AGPL 许可证中添加了 Commons Clause。2021 年，Elasticsearch 背后的公司 Elastic 也宣布从 Apache 许可证改到 SSPL 许可证。这些厂商修改许可证的主要动力都来自商业策略，随着开源项目的增长和流行，公司决定改变许可证以与其商业策略保持一致。希望对软件的使用增加额外的限制或限制，以产生收入或保护其知识产权。

云厂商的反击：基于兼容协议自研

非常凑巧的是，两天前，微软刚刚开源一款 Redis 兼容的，但性能远高于 Redis 的平替 Garnet。Garnet 是一个全新缓存存储系统，虽然是 C# 开发，但宣称针对现代硬件进行了优化，能更大限度发挥硬件功能，考虑了现代多核处理器和高速网络的特点，能够在单节点内进行线程扩展，能够更有效地利用处理器缓存，从而提高性能，且在处理大量客户端连接和小批量数据时能够提供更高的吞吐量和更低的延迟。Garnet 支持分片集群执行，具备复制、检查点、故障转移和事务处理功能。可以在主内存以及分层存储（如 SSD 和 Azure 存储）上运行。

从评测数据来看，Garnet 的性能在吞吐和延迟两个方向上都表现的非常优异。在吞吐上，Garnet 和 Dragonfly（另一个以高性能著称的 Redis 平替开源项目）相比，有数量级的优势，而在延迟上，不管是 50% 还是 99.9% 中位数的延迟，Garnet 都略好于 Dragonfly。当然在评测数据里，Garnet 和 Dragonfly 都远超过 Redis。这一性能分数对于一个用 C# 开发的项目来说，显得非常亮眼。因为 Redis 和 Dragonfly 是 C/C++ 开发的。

除了微软的替代方案，国内公司也开发了一些 Redis 的替代品。这些产品旨在提供与 Redis 类似的功能和性能，同时避免了某些许可证的限制。Tair 是阿里云开发的一个高性能、分布式的持久化 KV 存储系统。它提供了与 Redis 兼容的 API，同时还支持更多的数据结构和功能，如 GeoHash、JSON 等。阿里云在其云服务中集成了 Tair，为客户提供了一种替代 Redis 的选择。Pika 是 360 开发的一个兼容 Redis 的高性能 KV 存储系统。它的目标是提供与 Redis 类似的功能和性能，同时优化了某些方面，如内存使用效率和大容量支持。Pika 采用 BSD 3-Clause 许可证，也是一个开源项目。这使得其他公司和开发者可以自由地使用、修改和分发 Pika。360 在其云服务和内部系统中使用了 Pika。

Hacker News 内容以及网友评论

Redis 修改开源协议，以及微软开源 Garnet，这两条新闻都引起了 Hacker News 社区网友的热议（吃瓜群众从来不会错过这样的新闻）：

有些网友态度相对宽容。

1. 这些项目主要还是通过托管获取收入，这也是推动许可证变更的原因。无论如何，我确信，我们还将继续看到流行开源软件的兴起和衰落（或许可证变更）。对开发者和公司来说，开源带来了太多的好处。但它同时也带来了种种压力，使他们不得不做出改变。至少，应该称赞 Redis 给世界带来的巨大价值，这已经远远超出了他们本身所获得的东西。路很难，我不知道标准答案是什么。希望有一种让宽松开源许可证适用于复杂程序的模式，但我目前还没有找到什么好方法。接下来，我们可以看看过多久会出现一个 fork，以及它是否能取得成功。还有看看 Redis 的收入增长曲线在 5 年内会是什么样子。
2. 这件事说明， Redis 正面临与日俱增的利润压力。此外，Redis 在性能方面的竞争优势正在下降，特别是在Dragonfly 和 Garnet 这样的替代品出现之后。

也有网友为 Redis 的未来感到担忧。

3. 微软近日才公布了 Garnet......如果这成为了 Redis 的丧钟，也太令人唏嘘了。或者按照 YC（Y Combinator，硅谷的一个初创公司孵化器） 的精神，他们是否可能正在酝酿一种名为 yarcdis（yet-another-redis-clone-dis）的替代品。

有网友出谋划策，认为最可行的商业化途径是“open core”，然而也被其他网友质疑。

4. 免费开源软件（FOSS）最可行的商业化途径似乎是"open core"，比如 Android、SQLite、GitLab、VSCode、Docker 等。

• Open core 的公司，包括 Redis 也在内，都在转向虚假的开源许可证。
• 确实，Redis 在转变之前是 open core。但仅仅 open core 对他们来说是不够的......也许这就是基础开源服务软件的命运吧... 如果它是“云化的”，那么就无法产生足以盈利的业务。
• Redis 在商标被 Garantia Data 从 antirez 处收购之前是开源的，后来 Garantia Data 将它重新品牌化为 RedisLabs，之后又更名为 Redis。这绝对不是命中注定的结果，有很多基础的开源代码服务器软件转向了软件基金会。我在 Redis 核心团队工作期间，也曾主张将其移至一个基金会。
• 基金会也不付钱，看看 Linkerd （一个知名的 service mesh 开源软件）就知道了。

开源许可证为开发者提供了广阔的自由度，鼓励了代码的共享和重用，为软件的创新和发展提供了无限可能。然而，开源许可证却往往无法给予软件的开发者和维护者足够的经济回报，这使得许多开源项目面临资金匮乏、人力不足的问题。近年来，在云服务的环境下，一些云厂商通过提供开源软件的服务赚取大量利润，但却无法约束他们为开源软件的开发和维护付出什么成本。这在一定程度上剥夺了开源项目的生存空间，威胁到了开源生态的健康发展。因此，许多开源项目，包括Redis在内，都在探索如何通过修改许可证，引入商业化的元素，以解决这一矛盾。然而，这种做法往往会引起社区的反对和争议，因为它在一定程度上限制了开源的自由度，并且刺激云厂商fork开源项目进行自研，以降低License更换的风险。

如何平衡开源和商业化，是当前软件行业整体面临的一个重大挑战