Redis 创始人对切换开源许可证的心得


Redis 项目近日宣布再次开源,具体来看,Redis 决定在保留 RSALv2/SSPLv1 的同时,新增 OSI 批准的 AGPLv3 (Affero General Public License v3) 作为 Redis 8 及以后版本的授权选项。

Redis 创始人亲自宣布该消息后,发文总结了此次切换 Redis 开源许可证的一些心得。

以下是译文:


昨天,是一天非常紧张的日子。在意大利,5月1日是劳动节,所以早上我和朋友们去埃特纳山(Etna)走了4个小时 <3,我非常喜爱散步,我经常在编程时停下来散步,以便之后回到键盘前,双腿多走几公里。

在埃特纳山散步是非常棒的体验(埃特纳山是欧洲最大的活跃火山,而我恰好住在卡塔尼亚,那座城市就在它的山脚下)。

然后下午6点,我回到了家,发布了关于从AGPL许可证切换的博客文章,并开始查看评论、反馈、私信,过程中我学到了一些东西。

1、不管条款有多少不同,我认为这些条款确实有差别,AGPL与SSPL的主要区别在于AGPL是“被理解的”。一般来说,昨天这是我第一次意识到,在许可证方面,不仅仅是什么可以做、什么不可以做,而是某个许可证被理解、被测试、被采用的程度……

 

2、我被 Simon Willison 关于此事的言论所感动(https://simonwillison.net/2025/May/1/redis-is-open-source-again/),这种感觉很奇特——来自世界不同地区的人,但拥有相似的年龄和软件背景,对很多事情的感受竟然 如此相似我也一样,当我编写 Vector Sets 时,我一直在想:如果它不是以 AGPL(或其他我理解的开源许可证)发布,我绝不会使用它。这种情感,乘以社区中非微不足道的一小部分,最终会让开源在当今复杂的软件生态系统中取得胜利。

 

3、人们仍然非常关心软件发行版。并不是我不关心,只是过去我曾因此吃过亏。我最初使用的是Linux,可能是SlackWare 3.1之类的。在这些年里,我编写了设备驱动程序,也为内核提交了一些补丁。在那些年里,Debian 系统中可能也有我写的约 10 个软件包,从hping到访客网页日志分析器,dump1090,Redis,还有一些其他软件。

但最终,我开始看到所有这些碎片化的问题,某些过程的僵化(例如Linux内核模块的二进制兼容性),缺乏一致的设计,缺乏一种包含所有库的软件分发二进制格式,等等。我转向了MacOS用于桌面系统,而在服务器上则以一种非常务实的方式继续使用Linux,很多时候,我更愿意执行“tar xvzf software.tgz; make”而不是依赖发行版提供的内容。

也许,我对软件零依赖的执着也有一定关系。但人们仍然非常关心这一点,而且在许多希望尽可能自动化和可重复的情况下,将Redis作为发行版包可能是很重要的?现在,有很多人问Redis是否会重新进入发行版。

我的看法是:Redis 和 ValKey 已经在很多方面产生了显著差异,未来还会产生更多差异。我认为发行版应该同时提供两者,这样用户就有选择的余地,有时这种选择是由于功能差异所迫。简单来说:如果你需要进行向量相似性搜索,你就需要使用 Redis;如果你的公司有无 AGPL 政策,你就需要使用 ValKey,依此类推。

 

4、人们对我很友善。在评论中有一些严厉的言论,这很正常,甚至是有益的(毕竟这也是许多公司越来越相信他们无法使用 SSPL 或其他许可证,而必须使用 OSI 认可的许可证的原因之一)。然而,当我直接面对个人时,我看到很多积极的评价。我只想说:感谢你们所有人的支持。

 

5、我们其实生活在一种“泡沫”里。在某个论坛上,有人曾经问过:“你们有没有从 Redis 切换到其中一个分支?”然后引发了一连串的评论:“从未切换过”,“我用得上就行,管它呢”等等。ValKey 也是一样,如果人们写 apt-get install redis,而 ValKey 已经安装好了,他们使用 SET、GET、DEL 等命令,就不太关心这些。

我的意思是,软件已经不再是 1998 年的那种(用一个非常关键且象征性的日期来代表开源、互联网和我自己),那时候我们所有人都对开源软件许可证非常熟悉。但现在大多数人,尤其是新一代的人,有完全不同的、更实际的看法。所以,所有这些都很重要(对我而言至关重要),但也要理解,并不是所有的敏感度都是一样的。最后,所有事情中最重要的是,尽可能地交付高质量的软件。

 

阅读更多

Redis 再次开源

Redis 8 正式 GA

离开 1620 天,Redis 创始人 antirez 宣布回归


相關推薦

2025-04-26

对存储数据库,但在 2024 年 3 月 Redis 宣布从 7.4 版本起其许可证从 3-clause BSD 切换到商业使用需获得授权的双许可证 Redis Source Available License (RSALv2) 和 Server Side Public License (SSPLv1)。 此举意味着 Redis 不再属于 FOSS。开源社区的回应

2023-01-13

Discourse 是 Stack Overflow 的联合创始人 Jeff Atwood 推出的一个开源论坛项目,它基于 Ruby on Rails 和 Ember.js 开发,数据库使用 PostgreSQL 和 Redis。Discourse 摒弃了传统论坛的话题讨论形式,采用了全新版本的频

2021-12-01

企业或组织放弃 CLA ,采用 DCO。  2014 年,Node.js 的创始人 Timothy J Fontaine 取消了 CLA。他认为, CLA 是项目自我审核的一种方式,在必要时,CLA 会让项目在未来重新获得许可。虽然 Node.js 的 MIT 许可证已经很古老了,但未

2023-11-23

Redis 创始人 antirez 最近开源了一个小项目 BOTLIB —— 纯 C 语言代码编写的 Telegram Bot 框架 。 地址:https://github.com/antirez/botlib 顾名思义,BOTLIB 用于创建 Telegram 对话机器人。目前该项目仍处于开发阶段,请谨慎使用

2024-10-29

的解释中称其为一个打包错误,以缓解担忧。 Bitwarden 创始人兼首席技术官 Kyle Spearrin 进一步澄清了这一情况: @brjsp 再次感谢您在此提交问题。我们对 SDK 代码的组织和打包方式进行了一些调整,以便您可以在只包含 GP

2024-09-28

P Engine 访问其资源。 Automattic 首席执行官兼 WordPress 联合创始人 Matt Mullenweg 在 WordPress.org 上的一篇文章中写道,“任何 WP Engine 客户在其网站遇到问题时都应联系 WP Engine 支持并要求他们进行修复。WP Engine 需要商标许可,但他们

2021-12-13

的领导人 Bruce Perens 一起,攒了一个聚会, Linux 内核创始人 Linus Torvalds、Apache 主要开发者 Brian Behlendorf、 Sendmail 创始人 Eric Allman、Perl 语言创始人 Larry Wall、Python 语言创始人 Guido Rossum 等人都参与了,就是没请 RMS。

2022-03-21

InfoWorld 整理了一份“15 star founders of high-flying open source projects”名单,旨在了解当今一些最重要和最具创新性的开源项目背后的驱动力。 A new generation InfoWorld 指出,Linus Torvalds 是开源方面的的巨人。他如何以学生身份创建Linux

2023-11-03

Redis 创始人 antirez 用纯 C 语言代码写了一个聊天服务器的最小编程示例:Smallchat。 Smallchat 源代码已托管至 GitHub:https://github.com/antirez/smallchat 可以看到,Smallchat 的核心代码仅 300 多行。antirez 称删除空行和注释后其实只有 200

2022-02-22

西? 不光是古老,FreeBSD 还失去了活力。 FreeBSD 联合创始人 Jordan Hubbard 曾经是社区最为活跃的核心人物之一,2001 年他离开了 FreeBSD 社区,去了 Apple 公司,帮 Apple 捣鼓 Darwin。在他的辞职信中,他这么说: Another reason, and

2023-02-16

功通过开源项目赚钱的案例: Evan You: Evan You是Vue.js的创始人,这是一种开源JavaScript框架。他通过为企业客户提供支持、咨询和培训服务来赚钱。 Adam Wathan: Adam Wathan是Laravel的知名开发者之一,这是一种开源PHP框架。他通过提

2022-02-09

间的距离的同时,坚持着精英式的产品理念。正如 OpenBSD 创始人 Theo de Raadt 所言:“我们更多的时间是花在让东西更好,而不是让它符合大众的口味。” 01 被一笔带过的开源前史 当我们谈及开源起源和历史,第一个想到的

2022-08-09

Redis 的联合创始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架构师 Yossi Gottlieb、Redis Labs 的性能工程师 Filipe Oliveira 近期联合发布了一篇名为《13 年后--Redis 是否需要新的架构?》的文章,旨在分享一些有关 

2022-09-13

实现的限制,例如所需要的参数化方法、改进类型推断或切换类型。受访者表示,这些问题限制了泛型的潜在用例,或者认为它们导致泛型代码不必要地冗长。第二类涉及尚不支持泛型的事物——linter 是最常见的工具,此外还