Redis“叛逃”开源,得罪了几乎所有人

Java架构师社区

共 4990字,需浏览 10分钟

 ·

2024-06-04 07:40

来自公众号:51CTO技术栈
整理丨诺亚       
内存数据库供应商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
到此文章就结束了。Java架构师必看一个集公众号、小程序、网站(3合1的文章平台,给您架构路上一臂之力)。如果今天的文章对你在进阶架构师的路上有新的启发和进步,欢迎转发给更多人。欢迎加入架构师社区技术交流群,众多大咖带你进阶架构师,在后台回复“加群”即可入群。



这些年小编给你分享过的干货


1.idea2023.3.4永久激活码(亲测可用)

2.优质ERP系统带进销存财务生产功能(附源码)

3.优质SpringBoot带工作流管理项目(附源码)

4.最好用的OA系统,拿来即用(附源码)

5.SBoot+Vue外卖系统前后端都有(附源码

6.SBoot+Vue可视化大屏拖拽项目(附源码)


转发在看就是最大的支持❤️

浏览 78
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报