I maintain the main Redis client for Ruby, and similarly was contacted by Redis Inc a couple months back.
They asked about adding some features (client side caching, and support for various extensions they’re bringing in core), told them they could submit PRs like anyone else, haven’t seen anything from them yet.
They then asked about co-ownership of the package, I told them if they want it they could have it for themselves but that I wouldn’t co-maintain with someone I don’t know, they immediately backtracked, suggesting they don’t have the means to maintain it themselves.
My understanding is that they’re selling support and get various requests from their customers that require client side support. I don’t think they particularly want to own the clients, but if some key features are missing it’s a problem for them. From what I understand (might be wrong) redis-rs is somewhat in low maintenance mode, which may be what prompted them to try to take ownership.
All this to say, I don’t think they have a grand strategy to get ownership of all the clients, I think they only want clients to implement support for the features they add to the server, otherwise their offering is useless.
NB: I’m only guessing on their motivation, I’m not defending their use of trademark to get what they want.
So, you’re saying that there’s a company whose proprietary builds on open source without giving back? Have you considered changing the license on the Ruby redis client so that they can’t use it anymore? That seems to be the fashion these days 😉
As for changing the license, I don’t see what it will achieve except harm Ruby users. A Redis client can be used with actual Redis or plenty of alternatives including ValKey. If Redis Inc submit PRs to the Ruby client I’ll happily merge them if they make sense, to me they’re just like any other user/contributor.
It just seems that Redis Inc is doing the exact thing that they say motivated them to stop licensing Redis under an open source license. I don’t actually think you should do that (hence the wink-emoji), and I don’t think that Redis Inc should done it with the code they maintain either.
It’s just entirely predictable that these companies that claim that they’re being exploited by bigger players end up doing the same thing to smaller players.
I don’t feel exploited though. Maybe they tried to exploit me, but I’m not even sure of that.
I write OSS because I want to, and am perfectly aware people and companies can use that code and make money out of it. If I minded I wouldn’t release code under such licenses.
IMO the problem with Redis Inc isn’t that they’re a private company, it’s that they’ve raised lots of money and now need to justify their valuation, and found their 900 employees.
I don’t think the old, and much more “lean”, support contract model would have caused them to do that license change.
As far as I’m aware, there’s no FSF-, OSI-, or DFSG-approved license which would restrict usage on the opposite end of a socket.
The whole “once it’s in another process, it’s out of scope for this license” is an intentional feature, not a bug. (See “Running GOG.com games on the Linux kernel”, “GPLed archiver GUIs shelling out to unrar despite its GPL-incompatible license, being able to make a GPLed HTTP server/client and connect it to GPL-incompatible HTTP clients/servers, etc. etc. etc.)
(And people generally don’t want dependencies that the Debian and Fedora legal teams reject. It’s bad enough that Open Watcom C/C++ has that forced share-your-changes clause that keeps the best DOS/DPMI/Win16/NetWare/etc. toolchain for retro projects out of the repos by contravening debian-legal’s “desert island test”.)
They then asked about co-ownership of the package, I told them if they want it they could have it for themselves but that I wouldn’t co-maintain with someone I don’t know, they immediately backtracked, suggesting they don’t have the means to maintain it themselves.
To me, this is the most telling/annoying thing. They’re probably making money hand-over-fist providing consulting services for Redis, but yet don’t want to re-invest some of those profits to make the client libraries better. They want control, but don’t want to put in the effort.
Redis Inc wants control over the crate to guarantee that their customers receive fixes and new features in a timely manner (quote from Mirko Ortensi, a Redis Inc employee):
I have observed an increased interest in a Redis client library for the Rust language. Similarly to what has happened for other client libraries, besides contributing to the library itself, I’d love to offer Redis users (and customers) guarantees on the release cycle, bug fixing, fast support in escalations, and a realistic roadmap.
…but the community at large is worried that Redis Inc will hinder support for Redis-compatible databases. Support for Valkey (a direct fork of Redis owned by the Linux Foundation) is obviously not a priority for Redis Inc (quote from Madelyn Olson, a Valkey maintainer):
I’m more worried about the lack of an open governance and Redis priorizing their functionality at the expense of others. An example is client side caching in redis-py, https://github.com/redis/redis-py/blob/3d45064bb5d0b60d0d33360edff2697297303130/redis/connection.py#L792. I’ve tested it and it works just fine on valkey 7.2, but there is a gate that checks if it’s not Redis and throws an exception. I think this is the behavior that might spread.
There is also more context on this issue in the thread.
Ultimately this seems to have been settled amicably, with the current maintainers retaining control of the crate and its releases and Redis Inc working with the rest of the community.
To me it looks like Redis Inc wants to have their cake and eat it too, with them probably not having enough manpower to maintain the client libraries but also wanting strict control over the releases so that they can provide their clients with fixes when needed. They also don’t care much about compatibility with competing open source databases, which means they might either passively or actively block PRs and hinder support for those once they’re in control of the clients.
To me it looks like Redis Inc wants to have their cake and eat it too, with them probably not having enough manpower to maintain the client libraries but also wanting strict control over the releases so that they can provide their clients with fixes when needed.
It sounds like they’re pricing their product badly if they can’t afford to develop and maintain client libraries to the standards that their customers want.
Redis wants an officially maintained Rust client. This is good.
They want the redis-rs name. It has redis in the name, so they feel that they own it. That’s interesting. It is probably reasonable, right? In that they have a case. If it were named something else but stated it’s a “Redis client”, maybe that’d work?
So I suspect (2) is the scary bit. Do we hate Redis now? IDK. Like, from their perspective, hypothetically there’s some buggy, unmaintained code that uses their trademarked name to sound like it’s official. Users might use this library and have a bad experience with Redis due to these faults and think “Redis sucks”, which is bad for users and Redis. As mentioned though they could submit PRs, but it’s not exactly crazy to think that they’d want tighter control over “<company-name>-rs”.
It sounds like Redis is not explicitly “seeking” this either, they’ve just brought it up as a thing that wouldn’t be unreasonable.
Even if Sanfilippo mitigates the trademark issue, there remains the question of whether Redis Inc will still wish to acquire or fork redis-rs for its own purposes, further alienating the open source community.
Further alienating? What? Go ahead and fork it, that sounds like literally exactly how it’s supposed to work.
Note that at the time the crate was named redis-rs, it had exactly as much claim to the name as Redis Ltd (then called Redis Labs) who were just another third party host for Redis. It was 3 months after the crate was created that Redis Labs hired antirez, the Redis creator, and 3 years after that before he transferred the trademarks etc. to them
This has been rebranded as “Fair Marks” and is actually an exciting and wondrous opportunity for businesses and the broader community to safely use and build around these client libraries and have trust and confidence for the future because free riders have been thrown out of the ecosystem.
My comment was not a reply to anything. It was satirizing the recent efforts to build and promote a “Fair Source” branding around formerly-open-source projects which have switched to proprietary licensing in an attempt to monetize.
I maintain the main Redis client for Ruby, and similarly was contacted by Redis Inc a couple months back.
They asked about adding some features (client side caching, and support for various extensions they’re bringing in core), told them they could submit PRs like anyone else, haven’t seen anything from them yet.
They then asked about co-ownership of the package, I told them if they want it they could have it for themselves but that I wouldn’t co-maintain with someone I don’t know, they immediately backtracked, suggesting they don’t have the means to maintain it themselves.
My understanding is that they’re selling support and get various requests from their customers that require client side support. I don’t think they particularly want to own the clients, but if some key features are missing it’s a problem for them. From what I understand (might be wrong)
redis-rsis somewhat in low maintenance mode, which may be what prompted them to try to take ownership.All this to say, I don’t think they have a grand strategy to get ownership of all the clients, I think they only want clients to implement support for the features they add to the server, otherwise their offering is useless.
NB: I’m only guessing on their motivation, I’m not defending their use of trademark to get what they want.
So, you’re saying that there’s a company whose proprietary builds on open source without giving back? Have you considered changing the license on the Ruby redis client so that they can’t use it anymore? That seems to be the fashion these days 😉
I don’t think I’ve said that.
As for changing the license, I don’t see what it will achieve except harm Ruby users. A Redis client can be used with actual Redis or plenty of alternatives including ValKey. If Redis Inc submit PRs to the Ruby client I’ll happily merge them if they make sense, to me they’re just like any other user/contributor.
It just seems that Redis Inc is doing the exact thing that they say motivated them to stop licensing Redis under an open source license. I don’t actually think you should do that (hence the wink-emoji), and I don’t think that Redis Inc should done it with the code they maintain either.
It’s just entirely predictable that these companies that claim that they’re being exploited by bigger players end up doing the same thing to smaller players.
I don’t feel exploited though. Maybe they tried to exploit me, but I’m not even sure of that.
I write OSS because I want to, and am perfectly aware people and companies can use that code and make money out of it. If I minded I wouldn’t release code under such licenses.
IMO the problem with Redis Inc isn’t that they’re a private company, it’s that they’ve raised lots of money and now need to justify their valuation, and found their 900 employees.
I don’t think the old, and much more “lean”, support contract model would have caused them to do that license change.
As far as I’m aware, there’s no FSF-, OSI-, or DFSG-approved license which would restrict usage on the opposite end of a socket.
The whole “once it’s in another process, it’s out of scope for this license” is an intentional feature, not a bug. (See “Running GOG.com games on the Linux kernel”, “GPLed archiver GUIs shelling out to
unrardespite its GPL-incompatible license, being able to make a GPLed HTTP server/client and connect it to GPL-incompatible HTTP clients/servers, etc. etc. etc.)(And people generally don’t want dependencies that the Debian and Fedora legal teams reject. It’s bad enough that Open Watcom C/C++ has that forced share-your-changes clause that keeps the best DOS/DPMI/Win16/NetWare/etc. toolchain for retro projects out of the repos by contravening
debian-legal’s “desert island test”.)I left the wink-emoji because yes, there’s no such open source license. But that’s the game that Redis Inc has been playing with this community.
Ahh. I vote to amend English grammar to add brace-scoping for emoji modifiers. :P
Bah, English grammar is an oxymoron!
English orthography and vocabulary are oxymorons. English grammar survived the Norman conquest and the Great Vowel Shift in pretty good shape.
That’s why it’s so well-suited to humour based around it, such as “Off is the direction in which I wish you to f**k” or “Superdickery”.
To me, this is the most telling/annoying thing. They’re probably making money hand-over-fist providing consulting services for Redis, but yet don’t want to re-invest some of those profits to make the client libraries better. They want control, but don’t want to put in the effort.
Actually I suspect they’re not making that much, hence their recent moves.
Some people can’t get out of their own way. This seems like a speedrun on destroying all good will associated with the redis name.
Full-blown enshittification!
The GitHub issue where this was discussed offers some better context on this ordeal. https://github.com/redis-rs/redis-rs/issues/1419
Redis Inc wants control over the crate to guarantee that their customers receive fixes and new features in a timely manner (quote from Mirko Ortensi, a Redis Inc employee):
…but the community at large is worried that Redis Inc will hinder support for Redis-compatible databases. Support for Valkey (a direct fork of Redis owned by the Linux Foundation) is obviously not a priority for Redis Inc (quote from Madelyn Olson, a Valkey maintainer):
There is also more context on this issue in the thread.
Ultimately this seems to have been settled amicably, with the current maintainers retaining control of the crate and its releases and Redis Inc working with the rest of the community.
To me it looks like Redis Inc wants to have their cake and eat it too, with them probably not having enough manpower to maintain the client libraries but also wanting strict control over the releases so that they can provide their clients with fixes when needed. They also don’t care much about compatibility with competing open source databases, which means they might either passively or actively block PRs and hinder support for those once they’re in control of the clients.
It sounds like they’re pricing their product badly if they can’t afford to develop and maintain client libraries to the standards that their customers want.
Or maybe they’re just not willing to hire, if they figure they can use labor from the open source community instead.
Interesting. So basically,
Redis wants an officially maintained Rust client. This is good.
They want the
redis-rsname. It hasredisin the name, so they feel that they own it. That’s interesting. It is probably reasonable, right? In that they have a case. If it were named something else but stated it’s a “Redis client”, maybe that’d work?So I suspect (2) is the scary bit. Do we hate Redis now? IDK. Like, from their perspective, hypothetically there’s some buggy, unmaintained code that uses their trademarked name to sound like it’s official. Users might use this library and have a bad experience with Redis due to these faults and think “Redis sucks”, which is bad for users and Redis. As mentioned though they could submit PRs, but it’s not exactly crazy to think that they’d want tighter control over “<company-name>-rs”.
It sounds like Redis is not explicitly “seeking” this either, they’ve just brought it up as a thing that wouldn’t be unreasonable.
Further alienating? What? Go ahead and fork it, that sounds like literally exactly how it’s supposed to work.
Note that at the time the crate was named redis-rs, it had exactly as much claim to the name as Redis Ltd (then called Redis Labs) who were just another third party host for Redis. It was 3 months after the crate was created that Redis Labs hired antirez, the Redis creator, and 3 years after that before he transferred the trademarks etc. to them
Ah, that is interesting. I’m not a lawyer, I won’t even speculate on if that changes things, but it is interesting.
Just in case anyone had any doubts about the future direction of Redis, Mirko Ortensi has helpfully cleared it all up :)
This has been rebranded as “Fair Marks” and is actually an exciting and wondrous opportunity for businesses and the broader community to safely use and build around these client libraries and have trust and confidence for the future because free riders have been thrown out of the ecosystem.
Hrm; your parent has been removed (! this sounds ominous). What was the context?
My comment was not a reply to anything. It was satirizing the recent efforts to build and promote a “Fair Source” branding around formerly-open-source projects which have switched to proprietary licensing in an attempt to monetize.
Ah, my bad. It appeared under ~mqudsi’s and I misread it as being indented. Sorry for the noise, your satire is well-made!
[Comment removed by author]
I think calling the client
redis-rsis misleading. I wouldn’t search forredisif I wanted avalkeyclient. The package should be renamed./i