EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
14 comments
·August 18, 2025yjftsjthsd-h
gpm
The EloqKV developers could choose to pick just the AGPL one in the future and drop GPLv2 support while taking contributors dual licensed contributions with them...
I don't know that's the plan, but it's the best reason I see to dual license like this.
wahnfrieden
How do they properly accept contributions under dual licensing in a way that allows them to re-license those contributions? Through CLA? I'm not certain what you're saying is true - dropping one license might be as challenging as changing the license. Maybe I misunderstand
gpm
The same way you accept any contribution, because it isn't technically relicensing. You already granted them an AGPLv3 license when you uploaded your change to github without modifying the license file - that's what the "or" in the file means [1] - which entitles them (and anyone else) to create and distribute derivative works under only the AGPLv3 without any GPLv2 grant...
[1] Quoting the license file:
This software is provided under a dual license. You may choose to use it under the terms of either:
1. GNU General Public License, Version 2 (GPLv2), or
2. GNU Affero General Public License, Version 3 (AGPLv3).
traceroute66
I would be honestly interested to know what sort of actual paid-for legal advice they got about this.
IANAL, but dual licensing with two conflicting syles of license just stinks of something that will come back and bite them in the backside big-time in the future.
From a purely practical perspective it is also not clear what the point is ? Because quite clearly the people you want to be subject to AGPL (i.e. the big-evil cloud providers) will simply take you at your word and run under GPL.
esafak
It's weird that they don't mention similar distributed NewSQL databases like TiKV, which also has a MySQL layer (TiDB), and position themselves as a Redis replacement.
anonzzzies
Tikv is very (very) slow (compared to redis, not sure about elogkv) and it's redis layer seems unmaintained. TiDB is very interesting product ; we tried to replace our massive mysql (master with multi read replica/standby's) system and it is just so slow that it's unusable really. Maybe it's great for other goals though, I don't know; I like the idea so we tried some setups with it.
Octoth0rpe
Titan/Tidis (the redis compatible servers built on top of TiKV) don't seem to have any recent activity in their public repos: - https://github.com/yongman/tidis - https://github.com/distributedio/titan
KVRocks (which _is_ mentioned) does, as does valkey (also not mentioned, but probably only because it's not that different from redis at this point IIUC).
esafak
A person who wants transactions and a relational layer isn't going to use KVRocks, but sure, if you only care about the key-value part. I gave tikv/tidb as an example; there are others.
Writing your own Redis-like interface is trivial, so tidis et al don't matter to me. Even with Redis you should write an interface so you can swap it out.
nekitamo
Last I looked the TiKV Redis layers hadn't been updated in years, and were missing many Redis features (such as streams).
srameshc
I like the idea, KV store but not a memory store with Redis simplicity