DragonflyDB 许可证突变：100 vCPU 封顶，开源内存数据库的转身

新许可证核心条款：100 vCPU 封顶与修改版本授权

我是在 GitHub 上闲逛时撞见这个文件的。DragonflyDB Ltd.，一家注册在以色列的公司，把自家数据库的许可证换成了「Dragonfly Source-Available License (DSAL)」，全文 107 行、12.4 KB 来源：GitHub。第一眼看过去，它不叫 Apache 2.0 也不叫 AGPL，名字里藏着一种立场：源代码在那里摆着，但不是每个用法的自由都是白送的。

许可证第 1 条里有个数字把我钉住了。生产环境（Production Use）里，所有并发实例合计最多用 100 个 vCPU，超了就违约 来源：GitHub。这个「Usage Limit」是总账本，不管你是单机跑还是多实例分摊，一百个核是天花板。条文写得很细，授权范围覆盖「Software and any Modified Versions」，也就是原始版和你自己改过的版本，但许可性质是非排他、不可转让、不可再许可、免版税的 来源：GitHub。

更微妙的是持续合规条款。协议第 1 条要求 Licensee 一直遵守约定，包括适用使用限制，否则授权自动失效 来源：GitHub。要是你代表公司接受协议，还得声明自己有权约束那个实体，「Licensee」指的就是这家公司 来源：GitHub。换句话说，违约的后果不是罚钱，是授权直接没了。

这不是 Dragonfly BSD——一个容易被误认的独立项目

看到许可证变更消息时，我脑子里第一反应是：Dragonfly BSD 要搞什么名堂？结果 Hacker News 上的评论者 cheaprentalyeti 一句话把我拉了回来：「this is not about Dragonfly BSD」来源：HN。他承认自己一开始也差点搞混，以为这是 BSD 操作系统的新闻。名字相似到足以让技术圈的人在评论区里认错对象，这个细节让我愣了几秒。

反直觉的地方就在这里。DragonflyDB 跟 BSD 操作系统半毛钱关系没有，但项目名撞车太严重，HN 评论里有人真把许可证变更当成了 BSD 相关事件 来源：HN。我查了一下，DragonflyDB 是个内存数据库，跟 BSD 的代码血统完全不同。同名带来的误读，给这次许可证变更额外蒙了一层混淆的雾。

更让我在意的是「Source-Available」这个定位。它明晃晃地写着源代码可用，但授权范围受限制，这跟「Open Source」有本质区别 来源：GitHub。我从这个用词里读出一种转向：原本自由的数据库项目，现在开始对生产规模设限。100 vCPU 上限不是技术瓶颈，是商业边界，把大客户圈在授权范围内。

多源交叉验证：许可证条款与社区反馈的碰撞

我手上只有两份材料。一份是许可证原文，一份是 HN 上的讨论。前者讲法律条款，后者只有一个评论。107 行文本跟 1 条评论放在一起，信息不对称得刺眼 来源：GitHub。许可证原文把 100 vCPU 上限、Modified Version 授权、持续合规这些细节写得清清楚楚，但 HN 帖本身只有 1 point、1 comment，讨论热度低到可以忽略 来源：HN。

那条仅有的评论精准踩中了项目名混淆的坑，跟许可证原文里的公司名「DragonflyDB Ltd.」形成有趣的对照 来源：HN。一边是官方文件里白纸黑字的以色列注册公司，一边是社区读者差点把它当成另一个项目的调侃。这种落差让我意识到，许可证变更在技术圈还没激起大浪，但它的影响可能在更小范围里发酵。

说实话，我不确定这条 1 point 的 HN 帖能不能代表广泛社区意见。但许可证原文的严谨程度是实打实的，107 行法律文本，每一行都在划定使用边界 来源：GitHub。我倾向于认为，这种低调的许可证变更对自建数据库的中小团队影响不大，对大规模云服务商才是真正的信号。

100 vCPU 的封顶会逼着那些想用 DragonflyDB 扛大流量的人做算术题。改源代码可以，但改完还是得遵守使用限制。这不是开源社区常说的分叉自由，是带笼头的分叉。我的判断是：DragonflyDB 选择了一条中间路，保留代码可见性，同时用数字把商业风险隔开。至于这个数字定得合不合理，我看不透，只能等时间来证明。

原文：

Dragonfly License Change · 来源：Hacker News

参考来源：

• HN 评论区讨论 (item 50369369)

作者：itfan123 值班编辑 · 发布于 2026年11月5日