阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 51CTO技术栈 「诺亚」欢迎转载，保留摘要，谢谢！

• 不是第一次变更，替代方案已经就绪
• 本欲“制裁”云厂商，但几乎所有人都感觉“被背叛”
• Redis也许在“自掘坟墓”，大多数人会转向分叉版本

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

内存数据库供应商Redis近日在开源界砸下了一块“巨石”。

Redis即将转向双许可模式，并实施更为严格的许可条款。官方对此次变更的公告直截了当：

从Redis 7.4版本开始，Redis将在Redis源可用许可（RSALv2）和服务器端公共许可（SSPLv1）下采用双重许可。

截图来自：https://redis.com/legal/licenses/

在此之前，Redis的源代码是在BSD 3条款许可下提供的，这是一个允许开发者无需付费即可进行商业用途的宽松许可。

虽然官方强调“Redis源代码将继续通过Redis社区版免费提供给开发人员、客户和合作伙伴”，但收紧开源许可的举措依然引发了绝大多数人的不满。

不是第一次变更，替代方案已经就绪

这不是Redis首次更改其许可条款。早在2018年，它就对其部分模块的许可进行了调整，当时这种调整就令不少开源界知名人士感到不满。

在那之后不久，另一家大型NoSQL数据库供应商MongoDB也改变了其许可，试图减少其代码被商业利用的情况。MongoDB创建了一个名为服务器端公共许可（SSPL）的新许可，该许可并不受到一些开源社区成员的欢迎。即便如此，几年后，Elasticsearch也采用了SSPL，再次引发了某些开源纯粹主义者的失望。

现在，引起争议的SSPL正是Redis在其双许可策略下采纳的两个许可之一，另一个则是自2018年起用于部分模块的同款RSALv2许可。

这一变更将从Redis 7.4版本开始生效，业内人士预计多个Linux发行版将会从它们的代码库中移除Redis。关于此问题的讨论已经在openSUSE和Fedora邮件列表上开始了。

然而，预料中的影响可能是温和且暂时的，因为已经存在替代方案，例如仍然采用BSD许可的分支KeyDB。此外还有微软的Garnet，尽管其缺点在于它是用C#编写的。

另一个Redis替代品Dragonfly不太可能成为主流选择，因为它遵循BSL许可，这是HashiCorp最近所采用的许可模式。

对于Redis的决定，可以预见的一种回应类似于HashiCorp的Terraform所经历的情况：Terraform的代码被分叉并形成了OpenTF，后来更名为OpenTofu。

本欲“制裁”云厂商，但几乎所有人都感觉“被背叛”

Redis官方显然也预见到了这一变更会引起的争议。因此在官方声明中，尽可能地解释变更后主要的影响对象实际是——托管 Redis 产品的云服务提供商，并旗帜鲜明地指出：

“Redis 的大部分商业销售都是通过最大的云服务提供商进行的，这些提供商将 Redis 的投资及其开源社区商品化。尽管我们努力支持社区主导的治理模式，并且我们希望维护 BSD 许可证，但同时交付多个软件发行版——跨开源、源代码可用以及针对不同本地和云平台优化的商业软件——与我们成功推动 Redis 走向未来的能力不一致。”

“根据新许可证，托管 Redis 产品的云服务提供商将不再被允许免费使用 Redis 的源代码。例如，云服务提供商只有在与Redis代码的维护者Redis同意许可条款后才能交付Redis 7.4。这些协议将支持现有的集成解决方案，并提供对即将到来的 Redis 创新的完全访问。”

在常见问题解答中，也强调了三个“没有变化”。

1.“对于使用 Redis 开源版本的 Redis 和使用双许可证供其内部或个人使用的新版本的最终用户，没有变化。”

2.“对于使用 Redis 构建客户端库或其他集成的集成合作伙伴，没有变化。”

3.“对于 Redis 的商业客户，没有变化。这些客户根据单独协商的许可条款获得我们的技术。”

但实际上，并没有多少人对此买账。毕竟连Redis自己也不得不承认：“这一变化意味着 Redis 不再是 OSI 定义下的开源。”

截图来源：https://redis.com/blog/redis-adopts-dual-source-available-licensing/

Redis也许在“自掘坟墓”，大多数人会转向分叉版本

在相关事件的评论下，有网友一针见血地指出：最终受到伤害的不会是大型企业团队，而是广大用户。

“个人认为要么保持代码专有，要么坚持采用‘Apache 或 MIT’许可……这种半途改变许可协议的做法真的很糟糕，看起来注定会适得其反。无论喜欢与否，Redis一直是一个采用宽松许可的开源项目，这也是它取得成功的原因。改变这一点就意味着在这个层面上改变了游戏规则，并预示着未来所有相关人员都将面临不良后果。”

此外，还有人提到Redis此举颇有“自掘坟墓”的味道。

“在我看来，这一举动可能会像Hashicorp面临的困境一样重创Redis Labs，并且无法阻止任何人剽窃Redis Labs的成果，真正受苦的其实是那些只想无拘无束地使用Redis缓存的小型创业公司。而对于AWS来说，分叉Redis完全可行，他们甚至可以将分叉后的版本采用更宽松的许可协议，这样一来，Redis Labs突然间就在许可方面变成了较差的选择。”

当然，也有人表示理解，但理解并不等于认同。

“我能理解他们为什么这样做，只是不同意这种方式能长期有效。大多数Redis用户，包括我在内，从未向Redis背后的公司支付过分毫。因此，我能理解他们这么做是为了赚取一些利润。但是，这并不会改变我的行为；我会转而使用分叉版本。就像绝大多数其他的Redis用户、外部Redis贡献者、当前所有提供商业Redis服务的云服务商一样，估计到这一过程结束时，许多现有的Redis员工也会加入其中……要点在于，这件事最终只会有一个结果：那就是出现一个Redis分叉版本，被当前绝大多数Redis用户所采用。”

参考链接：

https://www.theregister.com/2024/03/22/redis_changes_license/

https://redis.com/blog/redis-adopts-dual-source-available-licensing/

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