Everyone's discussing the license and the hosting, but I think this is the truly interesting differentiator:
> In technical terms, we are focusing on stability and long-term maintenance, and on achieving excellence within our current scope. We believe that Redict is near feature-complete and that it is more valuable to our users if we take a conservative stance to innovation and focus on long-term reliability instead. This is in part a choice we’ve made to distinguish ourselves from Valkey, whose commercial interests are able to invest more resources into developing more radical innovations, but also an acknowledgement of a cultural difference between our projects, in that the folks behind Redict place greater emphasis on software with a finite scope and ambitions towards long-term stability rather than focusing on long-term growth in scope and complexity.
It'll be interesting to see what Valkey's future is with the maintainers having some lofty goals, and expressing frustration that they weren't able to move fast enough or be innovative enough under Redis. As a small-time user of Redis I kind of like the idea that I could just have what I've got now, but with a promise that someone's looking after it. I don't feel the need for millions of transactions per second, a timeseries database, etc.
Hey, I am one of the maintainers of Valkey, I'll try to answer.
I think there is a few things I would like to see in the mid to short term. We're trying to make a lot of the core datastructures more efficient (both in terms of memory and performance) as well as the main dictionary. Valkey 8.0 (or whatever first major version we have) will have lower overhead per key-value pair. Multithreading performance is nice, but as you mentioned most people don't need it. It gives folks a lot of runway if they need to scale but don't want to use clustering, and can also be a "quick fix" for certain types of P99 or higher latency spikes. Clustering is also really hard to use today, and a lot of the current folks want to fix that. It's a huge community pain point. Observability is another pain point I would like to improve. (Disclosure, I work at AWS as well) We see a lot of customers ask about "why did we see a performance issue", and Redis really doesn't provide a lot of introspection to diagnose those issues.
Another big area, which maybe will work for redict, is we want better integration with other OSS projects, especially CNCF projects like envoy, open-telemetry, K8s. There are a lot of self-developed projects floating around, we're hoping we can pull all of this together to make a more cohesive project for people to use instead of what we see today.
I think another big issue will be clients. I'm concerned Redis will try to inject a poison pill into the clients they own to make it so they can only talk to "official" Redis versions. Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open. We will likely passively support redict with our clients, so they'll get that for free.
We want to do all the cool feature stuff to (timeseries, JSON, bloom, RAG), but I would like to keep the core pretty clean.
Thank you for your work on Redis, Madelyn, and I'm sorry for the utterly unjustified abuse that's been thrown your way simply because you work at AWS.
One feature that would be very helpful would be some form of analytics and a memory profiler. At one point I'd written a python library to iterate over a RDB to identify what the top keys consuming most memory were, but Redis has added a lot of complexity and new data types since, so I doubt it still works.
We're excited to see valkey innovate in these areas! We wish you the best of luck and wish that we could have merged our forks, but alas.
>Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open
I'm not sure that this is true, at least not the commercial part. Redis clients are pretty simple (compared to Redis itself, at least). Redict is leading an effort to encourage community forks of the official Redis clients, as well as sending patches downstream to third-party clients. We set as an explicit goal to fork the ecosystem as well; we've started this work with hiredict and don't intend to stop.
I think there was some mention at some point about our two forks working together on maintenance of the protocol specification independently of Redis Ltd, which would be a good way to ensure that the clients remain broadly compatible with both of our forks.
> I'm not sure that this is true, at least not the commercial part. Redis clients are pretty simple (compared to Redis itself, at least).
I'll get on my soap box then. The redis client ecosystem is fractured and awful, and it's mostly Cluster's fault. Getting cluster right is really hard, and most clients do it inconsistently and get something wrong, if they tried at all (hiredict doesn't for example).
> I think there was some mention at some point about our two forks working together on maintenance of the protocol specification independently of Redis Ltd, which would be a good way to ensure that the clients remain broadly compatible with both of our forks.
>I'll get on my soap box then. The redis client ecosystem is fractured and awful, and it's mostly Cluster's fault. Getting cluster right is really hard, and most clients do it inconsistently and get something wrong, if they tried at all (hiredict doesn't for example).
Fair point, I think it's prudent to recognize this as a weakness in the ecosystem. But I would also say that applies generally of cluster, sentinel, etc, in all respects. I know this is a focus area for valkey for that reason.
Being copyleft, Redict can merge any contributions to Valkey. However, Valkey cannot merge any of the Redict commits (unless the contributor actively dual licenses them).
Being non-open source Redis can merge any contributions made to Valkey but not from Redict. So if you don't want your code to end up in Redis, contribute to Redict.
Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.
As someone who has extensively worked on a Redis fork at AWS and worked with the company for 6 years, I wouldn't worry about Redis merging stuff from Valkey. We believe they refused a huge number of PRs because we believe it would have messed with their internal features. (We can't prove this, because they never discussed it publicly). One of the main reasons I started contributing to Redis was to help my team at AWS get out of the business of merging conflicts.
> Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.
It's just a guy from Redis. It's not even one of the three former maintainers (Oran, Yossi, or Itamar). The number of open PRs is also dramatically down (it was around 550 when I last looked before the fork, since I've gotten a lot of notifications from old PRs of people refusing the CLA).
Valkey is under the Linux foundation umbrella, and I assume will be developed by the same people who were previously making redis. I could not find who is behind predict.
I think what are seeing here is the true power of an open license. There are now two forks with different approaches and two dedicated and competent teams and we will see not only who wins, but if any or both win (for some definition of win).
To me that's the big one, that even you an individual has the ultimate option to define "win" however you want.
Not only are you not subject to the conflict of interest between users and sellers in a commercial product, you aren't even subject to the popularity contest tyranny of the majority in a non-commercial product.
If someone takes the last open version of something and forks it and never does anything further to it and no one else ever uses it, but it does what they want, they win.
They win at life no matter what anyone thinks about that fork.
LGPL is a pretty weak copyleft license and was chosen specifically because it is amenable to almost all present-day commercial use-cases for Redis. You don't have to publish your changes to Redict in most situations, commercial or not. Check out the FAQ here:
"Tip: Commercial and non-commercial users of Redict are not required to publish or otherwise “open source” the source code of Redict, including any private modifications they make to the source code"
And very next section:
"If you compile Redict’s source code into an executable form and distribute this executable form to others you are required to include a copy of the Redict source code and any modifications to it licensed under the LGPL."
Let's be real: Especially in the EU, the definition of distribution of derivative works is typically so strong that it's super risky to use any copyleft license and I personally (e.g. consulting for large companies) see huge issues with compliance whenever this happens.
In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.
Note the careful use of private modifications as not requiring disclosure of the source code. You only have to include source in the very specific situation of building Redict and providing it in compiled form to customers directly. Like, if you give someone the ELF file. If you run it on their behalf as a cloud service or something you have no obligation to provide source, which is the most common commercial use-case of Redis.
LGPL is a very well understood license, even in the EU, and is already in use for many projects that are widely depended on commercially. Consider ffmpeg as one prominent example, which is used by virtually all multimedia software in the industry. It is very easy to comply with the LGPL, and your legal department works for you, not the other way around.
> legal department works for you, not the other way around.
Not sure what planet you live on. Unless you are one of the execs, Legal (and other compliance departments like HR) work pretty much against you. They exist to protect the company and the exec team.
They exist to serve the bottom line, and if the bottom line is best served by evaluating and approving the LGPL license (a trivial task, as it is broadly understood and the compliance requirements are negligible for most users), then that's what they will do. And in any case, no one is categorically opposed to the LGPL. Unless you think that no one is using Linux in industry, given that it uses a stronger license (GPL), which is patently absurd.
> And in any case, no one is categorically opposed to the LGPL.
That's not exactly true, take android as an example, which has a policy of "no GPL in user space", if I recall correctly.
I do however believe that due to drivers and other things, GPL is beneficial in Linux kernel, but that rather an exception. And also Linux is GPLv2, which is a big difference to GPLv3 (and so to LGPLv3).
Legal may sometimes be stubborn dicks, they can be overly conservative and afraid, but basically they are there to protect you from doing stuff that would create problems for the company and usually lead to you being fired or even being arrested in consequence. And they are working from the context of potentially fighting against a hostile legal challenge from people like them working for other companies, agencies, the law or the government. Yeah, they know that we are talking is just common-sense, but the law machinery not always work according to common-sense, and they know it far better than you.
Be cooperative with them, and they will usually try to help you. And don't try to teach them their work, after all, they don't try to teach you how to architect and code.
In my experience, legal is perfectly supportive assuming you're sane, reasonable and not a dick to them. They have expertise and constraints (ie: client contracts, bandwidth, etc.) that you are not aware of but that's different than being your enemy. If your attitude to them is that they're your enemy then they will be your enemy because why would they treat someone who is clearly antagonistic to them as a friend?
> In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.
In a non-technical firm with no relevant expertise outside the software devs, maybe. But in every software company I've worked for, legal has been more concerned with the AGPL, or Oracle's proprietary licenses, than LGPL which has always been explicitly approved.
It's a massive stretch to read "distributing the executable to people" as "distributing derivative works by somehow using this service in your network". The language is very clear.
> Especially in the EU, the definition of distribution of derivative works is typically so strong
Maybe I'm naive but how strong can it be? And is there anything that can't be solved by liberally decorating your software with links to the git repo of Redict?
Most commercial projects can safely use any of the Redis forks, whether Redis itself, Redict or Valkey. For Redict, you have to provide the source code of Redict - and Redict only! - in the case that you distribute it to customers. Redis has harsher terms, but only if you provide Redis-as-a-service. If you aren't a cloud provider and you don't modify the code of your chosen Redis variant, this is all a big nothingburger and neither of the licenses impose any important restrictions on you.
We desperately need all open questions regarding AGPL and SSPL to be clarified in court so this fearmongering can stop. It's really really bad for open source.
Open source seems to be doing fine without the clarity. Even fields that have nothing to do with software are adopting the mindset. The movement only gains in steam
Most popular OSS projects use Apache and MIT in my experience, precisely because GPLs are problematic for commercial usage and contributions from employed people.
That has been a popular opinion since FreeBSD was a complete operating system and Linux and bunch of disparate tarballs. Yet here we are.
There have been other examples where copyleft products have competed with more permissively licensed products as commercial products. The results are overwhelmingly in favor of the former.
Empirically, cooperation works much better on a level playing field where your company's work won't be included in a competitors closed fork.
This is a common misconception and source of fear/uncertainty/doubt regarding copyleft licenses. It's true that, the stronger the copyleft license, the more obligations it imposes on companies, and the AGPL is perhaps the most onerous of all and thus the least attractive to businesses. But, copyleft exists on a spectrum, and there are thousands of big-ticket FOSS projects that tens of thousands of businesses depend on and make use of that have a copyleft license. Linux itself is GPL, and pretty much everyone depends on it.
The license for Redict is one of the weaker copyleft licenses and should not pose any onerous compliance obligations on the most common commercial use-cases for Redict.
Don't know why this is downvoted, I have endlessly heard corp lawyers say this to my face while I worked there.
I have had a "popular" open source library I contributed significantly to campaigned by Microsoft to change the license to MIT, and the founder and creator decided to relicense without getting any sign offs because they felt that nobody would get mad enough to sue them.
The only thing stopping a commercial product from using copyleft software is themselves, not the copyleft.
Lawyers entire job is to make convincing arguments for any position you want, by artfully speaking only true facts, no matter what the position is and no matter what the facts are.
Of course a lawyer can and will say that you "can't" let any gpl software pollute the companys product "because the gpl prevents it", instead of saying that the company doesn't want to pay the license fee for the software.
The facts of the gpls terms may be true, and the lawyer may present them for their argument, but that still doesn't make the overall assertion true.
They can use gpl software all they want. They just don't want to. And good for them. That is better than simply stealing it which many do.
It's also merely an assertion that "most" open source software uses apache/mit/bsd wthout some numbers and citation. But that sentence could be parsed more than one way. They might have only been saying that most of the projects that use apache/mit do so for commercial compatibility reasons.
Corp lawyers job is to derisk and protect the company.
Strong copyleft risks converting private IP into something that must be shared publicly. This is what these licenses are designed to do. Blanket bans on specific licenses makes sense because they don't have the time to evaluate every potential case or usage
How many of the copyleft projects actually have a commercial offering or paid support plan?
Who said anything about a commercial or paid support plan?
The price the corp doesn't want to pay isn't money.
There are no potential edge cases to worry about if you aren't trying to live on renting copies of the same software to many people in the first place. Then you can live it even greater safety with no need to even audit anything.
Valkey has the support of various Redis developers who moved over, keeps the same license as the original Redis did, and stayed on GitHub to keep the workflow that Redis developers and contributors are used to, so I expect it'll end up winning out.
GitHub is proprietary and not ideal, but when trying to get developers on board after a fork, using GitHub and using the same license as the original avoids spending innovation tokens / weirdness budget unnecessarily.
Codeberg was chosen over other candidates because it has a workflow similar to GitHub, to ease the transition for the existing community. In my opinion, we're going through a big shake-up anyway and there's no better time than now to consider changes like this. We did discuss moving it to GitHub or another platform entirely, but as a community we decided to stay on Codeberg.
Changing the license was an absolutely essential requirement, and this is a crucial time to evaluate and commit to that change. As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd, and a fork which doesn't fix that bug isn't addressing the underlying problem.
> As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd
Disclaimer: I don’t have anything against the relicensing to LGPL. I think it’s your right and I root for you.
That said, correct me if I’m wrong, but, as far as I understand, what Redis Ltd did, they could do regardless of the license. Copyleft wouldn’t have stopped them, given the CLA.
Moreover I wouldn’t call that exploitation. To people outside of Redis Ltd who don’t want to be Redis Ltd customers this move is indistinguishable from them just closing down business and stopping development of Redis. Would that be exploitation? Are they obliged to provide free work on Redis indefinitely? They can’t retroactively change the licence of previous versions of Redis, so they can’t actually take anything away. The existence of the 2 forks is proof of that.
>That said, correct me if I’m wrong, but, as far as I understand, what Redis Ltd did, they could do regardless of the license. Copyleft wouldn’t have stopped them, given the CLA.
Redis never had a CLA and Redis Ltd does not hold the copyright for the work, it's held in aggregate by all contributors. Redis Ltd did use a CLA for their products surrounding Redis, like RedisJSON, but Redis itself did not use a CLA.
>To people outside of Redis Ltd who don’t want to be Redis Ltd customers this move is indistinguishable from them just closing down business and stopping development of Redis.
Redis Ltd was only ever responsible for about 20% of the development of Redis. If they wanted to shut down operations in good faith they would just hand it over to the other 80% to manage. Instead they used their trademark to try and do a hostile takeover of the IP.
I find it amusing that you called it "weirdness budget", but then again that pretty accurately describes the feeling I get when I see someone using a fairly niche DB instead of something like PostgreSQL, or something like NixOS instead of a regular Ubuntu LTS or RHEL-like. Not that it's a bad thing, there's plenty of specific use cases out there for sure.
Exactly. Spend your weirdness budget wisely, for the things that are really important to differ on. It's fine to spend it, but spend it where you're getting substantial value in exchange for it.
Yep, that's what the innovation tokens are probably a reference to, the talk occasionally gets brought up on the site. Such a cool talk, I agree with most of what's said there, albeit sometimes even certain "boring" technologies might have a bunch of complexity to them.
KeyDB is great, with major performance improvements, but it has also diverged from Redis and lacks most of the newer features added to Redis since the fork.
Just to be 100% I can still use Redis for free in my projects in production so long as I don’t sell a hosted version of it right given this new Redis license?
What's the track record of other projects that have gone too commercial and had their code forked like this? The only other example I can think of offhand is MySQL and MariaDB. I don't know what the market share of either is now. Do people still use MySQL? Does it generate profit for Oracle?
I think Redis Ltd. is vastly overestimating the value of their product. Redis is incredibly popular, but the vast majority of users are just looking for a simple in-memory key-value store for lightweight database use cases, caching, etc. I've used it in some way in just about all my projects for the past ~15 years.
The thing is, I don't care that it's Redis. I don't care about most of its features. I could have subbed in memcached or any number of other solutions. It would have been trivial and had no impact on my system.
I have no doubt that there are some power users who need advanced features of Redis, but I also have no doubt that Redict will be better, and that there will be companies who provide commercial support for it.
I'm just going to use Amazon ElastiCache for big projects, and continue not caring at all about what it is behind the scenes. And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it.
I can't imagine a scenario where Redis Ltd. is relevant or profitable 10 years from now. Oracle can afford to lose money on MySQL forever, and treat it as a loss-leader for acquiring new Oracle DB customers or at least new MySQL service contracts. Redis Ltd. has one product and few people need support for it or care much about it vs. alternatives.
Edit: Or Valkey instead of Redict; either way, which exemplifies the degree to which I don't care.
THANK YOU, for making images based on scratch, rather than Debian or Alpine. It makes redistribution so much easier from a license compliance perspective.
And double thanks for providing an SPDX document for the contents of the image.
MySQL never changed its license. The fork happened due to concerns of ownership and direction, not a license change or "going too commercial".
MySQL is still widely used, including by a large portion of publicly-traded tech companies. That said, most newer startups seem to be choosing Postgres instead.
MariaDB is also somewhat widely used, but not nearly as much as MySQL. And MariaDB's commercial enterprise (which was VC-backed and went public via a SPAC) is not doing well.
Your belief is incorrect. The links you have provided do not provide any data on actual use of these databases in the industry.
I've been working in the MySQL/MariaDB ecosystem for 21 years and am the creator/maintainer of a MySQL and MariaDB specific schema management utility used by hundreds of companies and with over 1.6 million downloads to date. I can tell you conclusively, MySQL usage in the industry significantly exceeds MariaDB's.
While I personally enjoy both systems and do hope MariaDB adoption increases, this doesn't change the facts on the ground. And unfortunately MRDB is a penny stock, Azure is dropping their managed MariaDB offering, Vitess has dropped MariaDB support entirely, AWS Aurora is compatible with MySQL and not MariaDB, Percona Server is based on MySQL and not MariaDB, and so forth.
I'll defer to your on the ground expertise as to the relative popularity of each, but I will point out that we're both working with anecdata here. I might also suggest that MySQL is losing a lot of ground to Postgres and I don't expect that trend to reverse in any case.
In any case it's not very relevant to this thread because you're quite right in pointing out that MySQL uses a free software license (GPL).
Yes, I mentioned the losing ground to Postgres aspect in my original comment. But that affects both MySQL and MariaDB, and still does not cause MariaDB to somehow be more popular than MySQL.
As for both working with anecdata, I mean sure, but what else is there? I'm citing my own business's direct experience with MySQL users and customers significantly outnumbering MariaDB users and customers, and seeing clear signs of that trend also being true at several much larger businesses (AWS, Azure, Percona, PlanetScale).
I suspect your view may be skewed by Linux distros / package managers having replaced MySQL with MariaDB many years ago. But even that is starting to change, see https://lwn.net/Articles/960630/ for example.
This is all fine and good, but the big question for me personally is when we can expect to see cloud providers (DigitalOcean and AWS are the ones I'm using) provide hosted versions of Redict OR Valkey with some sort of upgrade path from Redis. I'm a good full-stack developer and a mediocre server administrator, so self-managing hosting is usually not something I'd prefer to do.
I respect their choice of license. Totally agree they shouldn't let Redi$ take their work after what Redi$ have done. But still let any kind of project use it, including cloud vendors. Downside is that Valkey won't be able to use Redict code, though.
I mostly use Redis in combination with RedisJSON, and RedisInsight is a nice way to check what data is stored. I'm only using it for a handful of small documents which mirror the state of some devices.
These options (Redict, Valkey) don't seem to support JSON as a data type, so I'd like to know if there is some server specifically made for dealing with JSON documents. Something like a very lightweight MongoDB server which can be managed via a browser and where the data can be inserted/updated/removed via HTTP calls.
Big fan of couch, wish it was more popular. Its http interface basically removes the whole http translation layer of code most projects put in front of the db.
For such a small need, you might also look at PouchDB. Inspired by couch but simplified to allow it to run in-browser.
The difference is that TF is a widely-used acronym for Terraform, while Redict is a distinct word. That doesn't mean Redis won't try to put pressure, but it does mean it's not as obvious that they'd win if it came down to it.
People like having choice. The SSPL provides less choice than open source licenses. It came about because users were utilising their choice in way the project leaders didn't like, because they didn't directly financially benefit from it. But without that choice, arguably Redis would not have reached where it is today.
If it had launched as some proprietary single-vendor cloud service, people would have kept using memcached, or their relational DB or whatever for a lot of Redis use cases where it might be nice, but not essential improvements over the competition.
So it's shutting the door behind them, accusing the users of taking advantage of the very thing that let Redis get to where they are today. (Especially so for Redis, where Redis Labs started as just another hosted provider unassociated with the open source projects)
> But without that choice, arguably Redis would not have reached where it is today.
I'd honestly love to know how many people actually use any of the features added to Redis in the last... 5 or 8 years.
I'm not saying they were useless, but Redis used to be a pretty fine piece of software that could have easily been done for many use cases, 10 years ago.
What is commonly known as open source nowadays is a license that follows the definition adopted by the Open Source Initiative. SSPL is considered as not approved because it encumber unrelated programs to the one licensed by the SSPL:
So it is a combination of idealogical issue as well as being an annoyance to people who adopted it because it was released under the BSD in the first place.
For some people, yes. But for the majority, I'd say no.
In my mind a lot of the outrage is just generated through FUD that the big corps create when their ability to place themselves in a position to create false scarcity (and hence "value") is threatened. A big clue to these types of people are if they say anything about money or profit: e.g. "OSS devs need to make money too"
For the RMS believers, OSS is a more fundamental attempt to change mankind at a time before the greedy asshats could capture and restrict things. The birth of the electronic age, and software in particular was viewed as a golden opportunity to capture the value we created for EVERYONE. This is a HUGE reason you see so many OSS devs that will work thanklessly on code for years or decades for no pay, they are the doctors-without-borders of the tech world, they really give a shit about freeing humanity from usury and corporate value capture.
It's been really interesting to watch as the internet was captured, in a space where the cost of reproduction is literally zero, they've still been incredibly successful in strategically shunting a lion's share of the value for themselves where they then proceed with leveraging the artificial scarcity to capture that value monetarily.
Considering this in the face of what we've been taught about today's capitalist society, owning the means of production is really only a small part of the greedy antisocial playbook of those who market in false scarcity. Don't think for a second that this isn't an ideological war, one that will be fought with all the information weapons at the disposal of those who stand to lose in a free and open society.
Yes, it's an ideological type of thing. Meanwhile, most of the same people don't mind using closed standards like HDMI or kinda proprietary software like Android.
I'm sure there are plenty of people who do mind using HDMI and/or Android but in lack of other realistic alternatives for one or more reasons, end up with the pragmatic choice of using those things anyways.
I don't think your snarky remark about hdmi or android is pertinent.
Regardless is stuff is open or proprietary, nobody like when the terms of a contract change without their consent. People/companies have adopted redis under a specific license, which really is kind of a binding contract, then one day under a new release the terms have changed making it incompatible with their intended use. It is only natural that an alternative, and in this case a fork appears.
Substantial portions of Redis were written by AWS and Google. People are upset because Redis is a collaborative project with many people working on it and Redis Ltd wants the sole right to commercialize the work of an entire community.
Yeah, I think a key point is that Salvatore Sanfilippo, the original developer, maintainer and principle contributor[1] for 11 years, was not a founder of Redis Labs. He joined as an employee in 2015 but resigned in 2020. Perhaps he has equity in Redis Labs, but it's not clear he stands to profit at all from this switch.
AWS and Google contributed those under BSD license, being fully informed that Redis Ltd can commercialize like this.
It makes perfect sense for AWS and Google to fork immediately after the switch, but for contributions before the switch, there is no basis for AWS and Google to complain Redis Ltd, either legally or morally.
>>Substantial portions of Redis were written by AWS and Google
Employees on their own time, or paid to do it?
So I'm clear though - if I wrote a SAAS product tomorrow that under the covers used Redis, I'm OK, but if I spun up a bunch of servers and offered managed Redis as a product, I would need to pay?
>So I'm clear though - if I wrote a SAAS product tomorrow that under the covers used Redis, I'm OK, but if I spun up a bunch of servers and offered managed Redis as a product, I would need to pay?
That's the pitch of the license, essentially, but in practice the SSPL is an utter nightmare to comply with (to the point of being deliberate) and it mainly exists to put a veneer of open source on a proprietary product. In actual practice you really just cannot offer Redis as a service unless you are Redis Ltd, which is the actual point of the license in the end.
Yes, I realize I worded this poorly. I emphasized this point because this is what makes it non-free/not meet the Open Source Definition; you cannot retain exclusive right to commercialization. But I realize that was not actually something the parent commenter was asking about.
That's what many people seem to think, but it has not been legally challenged yet. We won't know for sure until Google or AWS decides to test the limits, in your jurisdiction.
You should probably ask Redis, Inc. what their intention is. Keep in mind, though, the run the risk of being re-rug-pulled. They have changed the license once and they can do it again.
Perhaps true but besides the point, actually - the same companies will happily take your code and make a saas offering out of it on their oligopolistic infrastructures, making it economically unviable to compete with.
...which, given LGPL, will be worse now as they'll simply not share their modifications because that's the legally safest option.
Redis Labs didn't start Redis, they didn't contribute most of the code. They just own the trademark. They have about as much right to extract money from AWS and Google for Redis as I have, all they are doing is that they are hijacking an open source project to make themselves rich. They're not a victim of the cloud providers, they are a leech trying to make a score while fucking over all the other contributors to Redis, who have done 80% of the work they are trying to extract a ransom for.
Hmm, so anyone can just start a company with the name of an open source project and try to monetise it? Like someone could start e.g. "Rust Labs" and sell a commercial version of Rust?
I don't know much about the genesis of Redis or Redis Labs, who key people and dates are, etc. I guess this obfuscation is part of the problem.
In Redis Labs case, they acquired the Redis trademark from the original author, who they employed for a few years after the project was well established.
There's some point in which good faith rules apply, probably even in court (although not decisively). Presumably Redis Labs works with the developer community and, critically, promotes the technology, which adds great value in terms of network effects. This is sort of the situation with Mozilla.org/com, right?
(Say you like something like Elm -- wouldn't it be better to have a relatively closely aligned commercial entity that puts significant and effective effort in making it widely used, which in turns makes it easier to find an Elm job or sell Elm-like solutions as a consultant).
Not really. As mentioned in the article, Redis has a Contributor License Agreement [0] that you have to sign if you contribute to Redis codebase, which basically gives the company behind it ownership behind everyone's contributions:
You grant to Redis and to the recipients of the software distributed by Redis a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contribution and such derivative works.
Usually, projects don't have such agreements. E.g. Linux, the kernel, would have a hard time re-licensing under different license, because of how many people actually hold the copyright to the code they contributed, and would have to agree beforehand.
The CLA is sort of a red herring in the case of permissively licensed software though. It becomes relevant for the SSPL case, where Redis don't want to be bound by the same rules as others.
Like since Rust is MIT licensed, you could make a closed source fork of Rust. The trademark guidelines would prevent you calling it Rust or anything too close, but you could describe it as Rust(TM) compatible and any of the other legally permitted uses of other people's trademarks.
> Hmm, so anyone can just start a company with the name of an open source project and try to monetise it? Like someone could start e.g. "Rust Labs" and sell a commercial version of Rust?
I'm not a lawyer, so take the following with that grain of salt.
In the specific case of Rust, no, because as another user pointed out, their licensing prohibits it.
If my understanding of the licenses is correct, the X-11, BSD 3-clause and BSD 4-clause licenses also prohibit this.
The MIT, BSD 2-clause and ISC licenses don't appear to prohibit this.
Your post mentions a few issues which I believe are legally separate:
1. Naming your company after an open-source project. I believe this is perfectly legal under the latter listed licenses, and happens in practice (for example, a brief search yields that React is MIT-licensed, and "React Labs" is a company).
2. Selling a commercial version of an open-source project. This is legal, and in fact a license isn't considered open source by OSI or free software by FSF if it disallows selling a commercial version. Whether this will be profitable is a separate question--generally people won't be willing to pay for something if they can just get it for free. There are two ways around this that I can think of: a) providing services and development around the open-source project, and b) extending the open source project with closed source code. The latter business model is prohibited by copyleft--you can only sell closed-source extensions to copyleft software if you have rights to the copyright (i.e. you created the code yourself) so attempting to do this with an existing copyleft-licensed project would be prohibited.
3. Enforcing trademark on the name of an open source project. My understanding is that enforcing a trademark created after a open source project started using it isn't possible, not because of licensing terms, but because of "priority of use" or "first to use in commerce"[1]. That is, if an open source project "Foo" exists already, I can't create "Foo Labs" and then sue the Foo project for using my name--on the contrary, the Foo project could probably sue Foo Labs. Redis Labs avoids this liability because they obtained rights for the trademark from the original Redis developer (I'm not sure what terms they obtained rights to the Redis name under--if they have exclusive rights they could sue anyone using the Redis name, but contribution to the project over time would likely make this complicated). There's a separate issue which is that "Foo" and "Foo Labs" are arguably different trademarks--Foo Labs can't inherently sue anyone using the Foo name, but they could likely sue someone who started a "Foo Labs" if they were the first ones to trade under that name.
Slightly disingenuous question, but I'll bite anyways...
No, people are not upset Redis is trying to make money. People are upset that something that used to be FOSS is no longer FOSS, and are trying to protect themselves from future pain by doing something that is very common in FOSS, which is forking a project.
Just because someone is trying to make sure the software they rely on continues to be FOSS, doesn't mean that they are out to actively hurt the original creator(s) of the original project. I don't know how you could possibly read the situation like that either.
It's essentially a do-ocracy in practice, though we have discussed the possibility of putting together a foundation to steward it, particularly if we start to get money involved. There are currently five people who have admin rights with respect to their various competencies, and anyone who establishes trust with the community and gets stuff done will also be promoted to their level of competence, as it were. Though I hesitate to describe it like this, I think of "admin" more as a clerical role than an authoritarian one. You're good at code review? Everyone generally trusts you? Then merge rights are just a tool to help you do your work better.
I don't think anyone is going to be very excited about introducing Rust unless there's a compelling reason to, but feel free to bring it up on the issue tracker for discussion and see if you can form a consensus on the matter with the rest of the community.
I wish you the best of luck and when I am able to be involved with OSS again, I will gladly help out with Redict. I think the LGPL is a good choice.
Areas where I would personally want to see Rust in a project like this, a) parsing and talking with the network b) extension mechanism moved to Wasm (Wasmtime for execution) but that plugins would be moved into a Wasm container.
It would also be a nice property if the core of the project maintained a compile to Wasm compatibility so that Redict could be run everywhere.
I think your Rust/wasm goals are a little bit dramatic for the goals we established among ourselves, but by all means start a conversation about it. Good support for compile-to-wasm is probably something that we'd be down to have upstream, though.
I read the post and it’s not clear why it’s not MIT licensed. Why not allow attempts to “create proprietary distributions?” That’s what open source would allow, no?
I honestly do not see this as being different than Redis. Do BSD or MIT and be done with it.
It seems needlessly ideological. Everyone wants to call their stuff open source but have strings attached.
> Everyone wants to call their stuff open source but have strings attached.
The term 'Open Source' is well-defined and includes licenses like the one redict picked (LGPL 3.0). It is incorrect to try and lump this in with source-available licenses that are IMO anathema to Open Source.
It’s simply a fact that MIT for instance allows things like Redict and this discussion to take place, as well as other things. It is maximally permissive.
They don't, but they were established for a singular reason, to shepherd the term "open source". A term that was chosen on terms of having little previous use. They did not succeed with the trademark application because the term was deemed too descriptive, not from a lack of trying. So we should probably respect their term if we want to use it. There are plenty of other terms you can choose instead, such as "permissively licensed software" which also has a de facto established meaning.
Sure, sure. But the term Open Source has a meaning. Ultimately terms have meaning based on their usage in the language. For 'Open Source', its usage happens to reflect the same meaning enshrined by OSI.
> It is maximally permissive.
It appears that there are now several redis forks, with several licenses. For the most part: everybody wins. If you prefer the MIT license, maybe you would prefer to contribute to the BSD-licensed Valkey. And if not, you can fork redis too.
Anyway, the Redict team are doing their thing and letting Redis and Valkey be. You’re the one insisting on Redict doing things the way you would like, so who exactly is being ideological?
Yes, Linux and Git are GPL-ed, so the parent is asking if you also feel about them in the same way as about this Redis fork ("needlessly ideological", "have strings attached" etc.).
Because "Everyone wants to call their stuff open source but have strings attached" implies GPL ( or CopyLeft, Non-BSD / MIT license ) have strings attached.
So the parent was asking isn't Linux Open Source but with strings attached? And if so are you happy with Linux?
Although I am assume what you meant was that Redis was originally a BSD / MIT, and re-licensing it to LGPL seems ideological. But I could be wrong.
Copyleft is a string. The default would be complete permissiveness.
If someone gave you something the correct presumption would be that you can do as you like with it, unless - and what follows are strings, like copy left.
It isn’t inherently bad, but it is what it is.
My happiness with Linux is irrelevant because Linux to my knowledge was not re licensed to be more restrictive.
>"I read the post and it’s not clear why it’s not MIT licensed. Why not allow attempts to “create proprietary distributions?” That’s what open source would allow, no? "
Your "That's what Open Source would allow", clearly implies anything but MIT / BSD license are not Open Source. Hence why people ask about Linux, which is Open Source but copy left aka non MIT / BSD.
>Edit: Linux was always GPL, Redis was not, so I don’t see the relevance.
Your first sentence implies GPL are not open source, the relevance here is why the parent ask "do you think Linux as Open Source" or happy with it. And:
>My happiness with Linux is irrelevant because Linux to my knowledge was not re licensed to be more restrictive.
Your happiness with Linux contradict with the first "quoted" sentence to what a lot of people think you meant.
Just in case, I am on the BSD / MIT camp but what you wrote create a lot of confusion.
> Copyleft is a string. The default would be complete permissiveness.
I have answered a similar line of questioning before.
Arguing strongly for permissive licenses is arguing for a kind of passive freedom which presents as freedom from obligations. Copyleft is the sort of active freedom which presents as a guarantee of rights.
I am going to assume this isn't impersonation, but Drew what happen to your old HN account? ( I had it on RSS feed and hasn't shown any update for ages I thought you left HN )
I don't see any reason why this is off-topic. Naturally the license change is a distinguishing feature of Redict and a reasonable subject for discussion.
>I don't see any reason why this is off-topic. Naturally the license change is a distinguishing feature of Redict and a reasonable subject for discussion.
I meant off topic as in asking you question about your account. Not the Open Source discussions which is of course perfectly valid. Sorry for the confusion.
A hypothetical license that said "no forks allowed" would not be an open source license. If Redis used the LGPL we could still fork it, we'd just have to use the LGPL for our fork; likewise anyone can fork Redict so long as they use the LGPL for their fork.*
* Technically you do have more options than this with the LGPL but this is a layman's explanation.
I did not say it would be an open source license. My point is simply that Redict takes something more permissive and makes it restrictive, which is true.
I don't think that's true. It's only true if freedom == freedom from obligation, which is a naive view of freedom. But if freedom == guarantees of rights, then Redict is more free. This is how freedoms actually work in practice: freedom of the press is guaranteed by restricting the government from censorship, workers rights are guaranteed by restricting the freedom of businesses to exploit them, etc. In practice all freedoms require someone to give something up. Even with permissive licenses, you are giving up the sole right to your IP and the sole to commercialize your software.
With all due respect I do not think that makes any sense.
You’re creating this metaphor with the government, but this isn’t the government.
In the end freedom is a spectrum and you are free to do more with MIT than LGPL.
Even if someone forked MIT and made it closed source that does not in any way stop or restrict those who prefer the project pre-fork.
Indeed, that is the very logic that has made Redict possible to begin with. This is the illustration of why MIT is maximally free.
Suppose the EU said code must be closed source, and you must distribute encrypted binaries. In this hypothetical it wouldn’t be possible to use Redict at all. This is another example of why the MIT, and permissiveness in general, is superior.
—-
As an aside your freedom of the press example is yet another reason for permissiveness. The government isn’t permissive by default, which is why “freedom of the press” is even a thing.
Governments, businesses, they're all just institutions and I see no reason not to use them as illustrative examples.
The MIT maximally enables exploitation; copyleft maximally enables freedom. From the point of a proprietary fork of a permissively licensed project onwards, users of the proprietary fork enjoy fewer freedoms than before. You are advocating for freedoms for the few (business owners making proprietary forks of free software for profit) at the expense of the freedom of many (everyone else).
Redict would also be possible if Redis used a copyleft license. The space for Redict to exist is not afforded to us because of the use of a permissive license in some way that Redict denies to anyone else through the use of a copyleft license.
I really don’t understand you. Even if there was a closed source fork, users would still be free to use the open source one. There is no restriction or diminishing of options. In fact, now there are even more options and thus more freedom.
I think you're missing the reciprocal nature of the arrangement here. Since you seem to assert that it's acceptable to release software under a proprietary license (and I agree with you, most of the time), you must believe that the authors of a work have a right to distribute it under whatever terms they like. So: is it appropriate for someone to say "I am willing to offer my labor to this collaborative project, and release the source code for free, and allow people to build from my work, under the condition that they extend the same rights back to everyone else"? It's much more generous than what proprietary software offers, after all.
Why is copyleft subject to more scrutiny than proprietary software for you? You suggest that permissive licenses are better because they allow permissive derivatives of the software, which suggests that permissive derivatives are good. But copyleft derivatives are... not good? Copyleft offers more freedoms than proprietary software.
Moreover, this line of reasoning completely disregards the social contract. Many people worked on, used, popularized Redis under the presumption that they were participating in a collaborative effort from which all participants would benefit, only -- surprise -- now the trademark holder has changed the terms so that only they benefit from a product of which, by objective measures, 80% was made by the community.
As another comment mentioned, copyleft would prevent commits to this project from being merged into Redis, intentionally making this a "hard fork". I do think it's ideological, but it's doesn't seem needless to me - there is a real ideological battle to be fought here.
I don’t understand why that is a bad thing. Perhaps a closed source fork will end up being superior through incentives only available through closing the source. Humanity still can use an open source fork. More options must be superior, no?
Why would any startup ever get idealistic again and release their product under open license when big boys can just fork it and destroy their business? I think the dual AGPL/commerical licensing will be the choice of anyone with still some idealism left.
There's nothing idealistic involved. Startups want users more than they want revenue. Thus they open source it, use VC money to cover the loses and then eventually try to squeeze those users for money.
Redis Labs also did not in any way make Redis. They came in later to exploit the already open source project for their own benefit.
Yeap it's interesting. Redis starts as a hobby project by Salvatore Sanfilippo (aka antirez) who eventually gets sponsored by VMWare as the project grows in popularity.
Then, another company that is offering a hosted Redis and support hires antirez and so becomes the 'offical' Redis company.
In 2020 antirez leaves and goes and writes a novel (called "Wohpe") instead.
Antirez hasn't been involved in Redis in a long time.
This is a common enough pattern when open-source projects leave their roots and then, eventually, alienate theiropen source base. Perhaps the time is ripe for Antirez to come back and shepherd one of the forks, a bit like mariadb?
No, they didn't, although they misleadingly claimed to be the "Home of Redis" for a number of years. Then they hired Salvatore Sanfilippo (antirez), the author of Redis, and eventually purchased the copyright from him. Very sleazy outfit that fully deserves all the scorn poured on them.
If one sells a copyright to another, how can that be considered sleazy ? Someone made the sell - to make money I presume - and another bought it, to perhaps make more money ? Seems not that out of reach ?
I don't understand the bitterness around this debate, it seems most people are frustated that they have to pay for something that was free, but at the same time, they probably made money from what was free.
I totally understand, with todays mess of maintainers not getting paid in full, that at some point, someone wants money for their work. Be it a person, a company or you doesn't matter. But right has to be right.
I think we will see a lot of this the next 10 years, simply because we cannot afford maintainers not detecting backdoors in a code-review from some bad actor.
To clarify, they did not purchase the copyright -- they purchased the trademark, and are using it to attempt to capture the practical value of the copyright. The copyright is by far the more valuable of the two, but they do not actually own it. Of the actual valuable object (the copyright, i.e. the codebase), about 80% was written by people outside of the employ of Redis Labs né Redis Ltd.
Are you sure? I'd asked antirez to clarify 6 years ago, and he said he had transferred the Redis IP to Redis Labs, without being more specific (see the comments on http://antirez.com/news/121 )
In any case, congratulations on the very fast release of Redict, rewriting references to Redis is not a simple s/Redis/Redict/g sed job. How do you feel about possible competition with the Valkey project, apart from the licensing differences?
>Are you sure? I'd asked antirez to clarify 6 years ago, and he said he had transferred the Redis IP to Redis Labs, without being more specific
Well, trademarks are a form of IP. But in any case the copyright was never antirez's to transfer to anyone. In the absence of a CLA with a copyright assignment, every contributor retains the copyright to their contributions, and licenses them to everyone else (Redis Ltd included) under the terms of the BSD license. Legally speaking, Redis Ltd's SSPL code is, in effect, a fork of the Redis BSD code, in the same way that Redict is.
>In any case, congratulations on the very fast release of Redict, rewriting references to Redis is not a simple s/Redis/Redict/g sed job. How do you feel about possible competition with the Valkey project, apart from the licensing differences?
Thanks for the congratulations!
As for Valkey, so far they've put a lot of time and energy getting the various corporate stakeholders on board with their fork and getting some marketing out (which is no small feat, to be sure, I shudder to imagine the number of lawyers involved), but they still have a lot of boots-on-the-ground work to do getting their fork up and running so it may be a while before our projects are interacting directly. From the limited communication we've had with them, it seems likely that we'll be able to collaborate insofar as reducing incompatibilities is concerned, maybe co-maintenance on the protocol specification, but not much more. Redict does plan on pulling useful patches from Valkey once they get the code going, though it's unfortunately not possible for them to pull from us unless they're on board with switching to a copyleft license -- and we encourage them to do so :)
The sleaze was in falsely claiming to be the "Home of Redis" at least 2 years before actually becoming so by hiring antirez (I remember seeing their huge billboards on Bryant & 9th in San Francisco, and it rankled).
I don't know why people think AGPL changes anything here. The very first of this wave of moves to non-FOSS licenses, and the creation of the SSPL license we are discussing here, was Mongo moving away from the AGPL.
What these companies want is licenses which prevent AWS and other cloud providers from competing with them on their specific technology, regardless of how much those same companies are contributing to the technology. Redis is the most extreme example here - by all accounts I've read, Amazon was a major contributor, not just throwing bug fixes here or there. But that doesn't help Redis Labs, they want money, not code. And the AGPL would have done less than nothing to help stop Amazon from running their own Redis service: Amazon was already doing everything (or at least most things) that the AGPL would have required of them.
SSPL is just a figleaf. No one sane redistributes third party SSPL code without having a contract with the company, it's essentially proprietary in all but name. But it allows the company to maintain this air of open source legitimacy.
Mongo didn't move away from the AGPL to keep SaaS providers from capturing value from the project, they did it so that they could capture more for themselves.
Well, I don't think they expected this change to increase the market, so they wanted to capture value from other providers to themselves. But even that was not guaranteed to happen, the only thing they can guarantee with this move is that others will capture less value.
There are lots of loosely related forms of idealism, and plenty of projects will continue to be released under mainstream FOSS licenses because the ideals of the project don't include "make money for our investors" but do include "make this cool thing widely available because we think people will like it".
For the vast majority of open source projects, being used by (and, importantly, receiving contributions from!) the "big boys" is a Good Thing and something to be aspired to.
And that's a good thing as it will provide a steady mechanism to fund the project. Of course there is the risk that it will result in an "open-core" model where the open source part is artificially slowed down to promote the commercial offering.
> In technical terms, we are focusing on stability and long-term maintenance, and on achieving excellence within our current scope. We believe that Redict is near feature-complete and that it is more valuable to our users if we take a conservative stance to innovation and focus on long-term reliability instead. This is in part a choice we’ve made to distinguish ourselves from Valkey, whose commercial interests are able to invest more resources into developing more radical innovations, but also an acknowledgement of a cultural difference between our projects, in that the folks behind Redict place greater emphasis on software with a finite scope and ambitions towards long-term stability rather than focusing on long-term growth in scope and complexity.
It'll be interesting to see what Valkey's future is with the maintainers having some lofty goals, and expressing frustration that they weren't able to move fast enough or be innovative enough under Redis. As a small-time user of Redis I kind of like the idea that I could just have what I've got now, but with a promise that someone's looking after it. I don't feel the need for millions of transactions per second, a timeseries database, etc.
I think there is a few things I would like to see in the mid to short term. We're trying to make a lot of the core datastructures more efficient (both in terms of memory and performance) as well as the main dictionary. Valkey 8.0 (or whatever first major version we have) will have lower overhead per key-value pair. Multithreading performance is nice, but as you mentioned most people don't need it. It gives folks a lot of runway if they need to scale but don't want to use clustering, and can also be a "quick fix" for certain types of P99 or higher latency spikes. Clustering is also really hard to use today, and a lot of the current folks want to fix that. It's a huge community pain point. Observability is another pain point I would like to improve. (Disclosure, I work at AWS as well) We see a lot of customers ask about "why did we see a performance issue", and Redis really doesn't provide a lot of introspection to diagnose those issues.
Another big area, which maybe will work for redict, is we want better integration with other OSS projects, especially CNCF projects like envoy, open-telemetry, K8s. There are a lot of self-developed projects floating around, we're hoping we can pull all of this together to make a more cohesive project for people to use instead of what we see today.
I think another big issue will be clients. I'm concerned Redis will try to inject a poison pill into the clients they own to make it so they can only talk to "official" Redis versions. Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open. We will likely passively support redict with our clients, so they'll get that for free.
We want to do all the cool feature stuff to (timeseries, JSON, bloom, RAG), but I would like to keep the core pretty clean.
One feature that would be very helpful would be some form of analytics and a memory profiler. At one point I'd written a python library to iterate over a RDB to identify what the top keys consuming most memory were, but Redis has added a lot of complexity and new data types since, so I doubt it still works.
>Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open
I'm not sure that this is true, at least not the commercial part. Redis clients are pretty simple (compared to Redis itself, at least). Redict is leading an effort to encourage community forks of the official Redis clients, as well as sending patches downstream to third-party clients. We set as an explicit goal to fork the ecosystem as well; we've started this work with hiredict and don't intend to stop.
I think there was some mention at some point about our two forks working together on maintenance of the protocol specification independently of Redis Ltd, which would be a good way to ensure that the clients remain broadly compatible with both of our forks.
I'll get on my soap box then. The redis client ecosystem is fractured and awful, and it's mostly Cluster's fault. Getting cluster right is really hard, and most clients do it inconsistently and get something wrong, if they tried at all (hiredict doesn't for example).
> I think there was some mention at some point about our two forks working together on maintenance of the protocol specification independently of Redis Ltd, which would be a good way to ensure that the clients remain broadly compatible with both of our forks.
Yeah, I'm still fully aligned with this.
Fair point, I think it's prudent to recognize this as a weakness in the ecosystem. But I would also say that applies generally of cluster, sentinel, etc, in all respects. I know this is a focus area for valkey for that reason.
Being non-open source Redis can merge any contributions made to Valkey but not from Redict. So if you don't want your code to end up in Redis, contribute to Redict.
Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.
> Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.
It's just a guy from Redis. It's not even one of the three former maintainers (Oran, Yossi, or Itamar). The number of open PRs is also dramatically down (it was around 550 when I last looked before the fork, since I've gotten a lot of notifications from old PRs of people refusing the CLA).
That on top of developer hours dedicated to various projects, which are probably worth multiple millions.
Not only are you not subject to the conflict of interest between users and sellers in a commercial product, you aren't even subject to the popularity contest tyranny of the majority in a non-commercial product.
If someone takes the last open version of something and forks it and never does anything further to it and no one else ever uses it, but it does what they want, they win.
They win at life no matter what anyone thinks about that fork.
https://www.linuxfoundation.org/press/linux-foundation-launc...
https://redict.io/docs/license/
And very next section:
"If you compile Redict’s source code into an executable form and distribute this executable form to others you are required to include a copy of the Redict source code and any modifications to it licensed under the LGPL."
Let's be real: Especially in the EU, the definition of distribution of derivative works is typically so strong that it's super risky to use any copyleft license and I personally (e.g. consulting for large companies) see huge issues with compliance whenever this happens.
In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.
LGPL is a very well understood license, even in the EU, and is already in use for many projects that are widely depended on commercially. Consider ffmpeg as one prominent example, which is used by virtually all multimedia software in the industry. It is very easy to comply with the LGPL, and your legal department works for you, not the other way around.
Not sure what planet you live on. Unless you are one of the execs, Legal (and other compliance departments like HR) work pretty much against you. They exist to protect the company and the exec team.
That's not exactly true, take android as an example, which has a policy of "no GPL in user space", if I recall correctly.
I do however believe that due to drivers and other things, GPL is beneficial in Linux kernel, but that rather an exception. And also Linux is GPLv2, which is a big difference to GPLv3 (and so to LGPLv3).
Be cooperative with them, and they will usually try to help you. And don't try to teach them their work, after all, they don't try to teach you how to architect and code.
In a non-technical firm with no relevant expertise outside the software devs, maybe. But in every software company I've worked for, legal has been more concerned with the AGPL, or Oracle's proprietary licenses, than LGPL which has always been explicitly approved.
Is minimized JavaScript considered an executable?
What about html and css?
Maybe I'm naive but how strong can it be? And is there anything that can't be solved by liberally decorating your software with links to the git repo of Redict?
We desperately need all open questions regarding AGPL and SSPL to be clarified in court so this fearmongering can stop. It's really really bad for open source.
There have been other examples where copyleft products have competed with more permissively licensed products as commercial products. The results are overwhelmingly in favor of the former.
Empirically, cooperation works much better on a level playing field where your company's work won't be included in a competitors closed fork.
The license for Redict is one of the weaker copyleft licenses and should not pose any onerous compliance obligations on the most common commercial use-cases for Redict.
I have had a "popular" open source library I contributed significantly to campaigned by Microsoft to change the license to MIT, and the founder and creator decided to relicense without getting any sign offs because they felt that nobody would get mad enough to sue them.
Lawyers entire job is to make convincing arguments for any position you want, by artfully speaking only true facts, no matter what the position is and no matter what the facts are.
Of course a lawyer can and will say that you "can't" let any gpl software pollute the companys product "because the gpl prevents it", instead of saying that the company doesn't want to pay the license fee for the software.
The facts of the gpls terms may be true, and the lawyer may present them for their argument, but that still doesn't make the overall assertion true.
They can use gpl software all they want. They just don't want to. And good for them. That is better than simply stealing it which many do.
It's also merely an assertion that "most" open source software uses apache/mit/bsd wthout some numbers and citation. But that sentence could be parsed more than one way. They might have only been saying that most of the projects that use apache/mit do so for commercial compatibility reasons.
Strong copyleft risks converting private IP into something that must be shared publicly. This is what these licenses are designed to do. Blanket bans on specific licenses makes sense because they don't have the time to evaluate every potential case or usage
How many of the copyleft projects actually have a commercial offering or paid support plan?
The price the corp doesn't want to pay isn't money.
There are no potential edge cases to worry about if you aren't trying to live on renting copies of the same software to many people in the first place. Then you can live it even greater safety with no need to even audit anything.
Or get hosted redis services from someone other than Redis Labs. That isn't fearmongering about the SSPL, it is literally the point of the SSPL.
GitHub is proprietary and not ideal, but when trying to get developers on board after a fork, using GitHub and using the same license as the original avoids spending innovation tokens / weirdness budget unnecessarily.
Changing the license was an absolutely essential requirement, and this is a crucial time to evaluate and commit to that change. As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd, and a fork which doesn't fix that bug isn't addressing the underlying problem.
Disclaimer: I don’t have anything against the relicensing to LGPL. I think it’s your right and I root for you.
That said, correct me if I’m wrong, but, as far as I understand, what Redis Ltd did, they could do regardless of the license. Copyleft wouldn’t have stopped them, given the CLA.
Moreover I wouldn’t call that exploitation. To people outside of Redis Ltd who don’t want to be Redis Ltd customers this move is indistinguishable from them just closing down business and stopping development of Redis. Would that be exploitation? Are they obliged to provide free work on Redis indefinitely? They can’t retroactively change the licence of previous versions of Redis, so they can’t actually take anything away. The existence of the 2 forks is proof of that.
Redis never had a CLA and Redis Ltd does not hold the copyright for the work, it's held in aggregate by all contributors. Redis Ltd did use a CLA for their products surrounding Redis, like RedisJSON, but Redis itself did not use a CLA.
>To people outside of Redis Ltd who don’t want to be Redis Ltd customers this move is indistinguishable from them just closing down business and stopping development of Redis.
Redis Ltd was only ever responsible for about 20% of the development of Redis. If they wanted to shut down operations in good faith they would just hand it over to the other 80% to manage. Instead they used their trademark to try and do a hostile takeover of the IP.
I find it amusing that you called it "weirdness budget", but then again that pretty accurately describes the feeling I get when I see someone using a fairly niche DB instead of something like PostgreSQL, or something like NixOS instead of a regular Ubuntu LTS or RHEL-like. Not that it's a bad thing, there's plenty of specific use cases out there for sure.
https://boringtechnology.club/
https://github.com/Snapchat/KeyDB
Not randos on HN
I think Redis Ltd. is vastly overestimating the value of their product. Redis is incredibly popular, but the vast majority of users are just looking for a simple in-memory key-value store for lightweight database use cases, caching, etc. I've used it in some way in just about all my projects for the past ~15 years.
The thing is, I don't care that it's Redis. I don't care about most of its features. I could have subbed in memcached or any number of other solutions. It would have been trivial and had no impact on my system.
I have no doubt that there are some power users who need advanced features of Redis, but I also have no doubt that Redict will be better, and that there will be companies who provide commercial support for it.
I'm just going to use Amazon ElastiCache for big projects, and continue not caring at all about what it is behind the scenes. And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it.
I can't imagine a scenario where Redis Ltd. is relevant or profitable 10 years from now. Oracle can afford to lose money on MySQL forever, and treat it as a loss-leader for acquiring new Oracle DB customers or at least new MySQL service contracts. Redis Ltd. has one product and few people need support for it or care much about it vs. alternatives.
Edit: Or Valkey instead of Redict; either way, which exemplifies the degree to which I don't care.
>And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it
FYI we're publishing to registry.redict.io, so s:redis:registry.redict.io/redict:g
https://redict.io/docs/redis-compat/containers/
Not that it detracts from your point in any way :)
And double thanks for providing an SPDX document for the contents of the image.
MySQL is still widely used, including by a large portion of publicly-traded tech companies. That said, most newer startups seem to be choosing Postgres instead.
MariaDB is also somewhat widely used, but not nearly as much as MySQL. And MariaDB's commercial enterprise (which was VC-backed and went public via a SPAC) is not doing well.
I believe this is factually false. Consider just one datapoint:
https://repology.org/project/mysql/versions
https://repology.org/project/mariadb/versions
I've been working in the MySQL/MariaDB ecosystem for 21 years and am the creator/maintainer of a MySQL and MariaDB specific schema management utility used by hundreds of companies and with over 1.6 million downloads to date. I can tell you conclusively, MySQL usage in the industry significantly exceeds MariaDB's.
While I personally enjoy both systems and do hope MariaDB adoption increases, this doesn't change the facts on the ground. And unfortunately MRDB is a penny stock, Azure is dropping their managed MariaDB offering, Vitess has dropped MariaDB support entirely, AWS Aurora is compatible with MySQL and not MariaDB, Percona Server is based on MySQL and not MariaDB, and so forth.
In any case it's not very relevant to this thread because you're quite right in pointing out that MySQL uses a free software license (GPL).
As for both working with anecdata, I mean sure, but what else is there? I'm citing my own business's direct experience with MySQL users and customers significantly outnumbering MariaDB users and customers, and seeing clear signs of that trend also being true at several much larger businesses (AWS, Azure, Percona, PlanetScale).
I suspect your view may be skewed by Linux distros / package managers having replaced MySQL with MariaDB many years ago. But even that is starting to change, see https://lwn.net/Articles/960630/ for example.
These options (Redict, Valkey) don't seem to support JSON as a data type, so I'd like to know if there is some server specifically made for dealing with JSON documents. Something like a very lightweight MongoDB server which can be managed via a browser and where the data can be inserted/updated/removed via HTTP calls.
For such a small need, you might also look at PouchDB. Inspired by couch but simplified to allow it to run in-browser.
(EDIT: Genuine question - I'm trying to understand if this is a license purity issue or something else).
If it had launched as some proprietary single-vendor cloud service, people would have kept using memcached, or their relational DB or whatever for a lot of Redis use cases where it might be nice, but not essential improvements over the competition.
So it's shutting the door behind them, accusing the users of taking advantage of the very thing that let Redis get to where they are today. (Especially so for Redis, where Redis Labs started as just another hosted provider unassociated with the open source projects)
I'd honestly love to know how many people actually use any of the features added to Redis in the last... 5 or 8 years.
I'm not saying they were useless, but Redis used to be a pretty fine piece of software that could have easily been done for many use cases, 10 years ago.
https://web.archive.org/web/20230411163802/https://lists.ope...
So it is a combination of idealogical issue as well as being an annoyance to people who adopted it because it was released under the BSD in the first place.
In my mind a lot of the outrage is just generated through FUD that the big corps create when their ability to place themselves in a position to create false scarcity (and hence "value") is threatened. A big clue to these types of people are if they say anything about money or profit: e.g. "OSS devs need to make money too"
For the RMS believers, OSS is a more fundamental attempt to change mankind at a time before the greedy asshats could capture and restrict things. The birth of the electronic age, and software in particular was viewed as a golden opportunity to capture the value we created for EVERYONE. This is a HUGE reason you see so many OSS devs that will work thanklessly on code for years or decades for no pay, they are the doctors-without-borders of the tech world, they really give a shit about freeing humanity from usury and corporate value capture.
It's been really interesting to watch as the internet was captured, in a space where the cost of reproduction is literally zero, they've still been incredibly successful in strategically shunting a lion's share of the value for themselves where they then proceed with leveraging the artificial scarcity to capture that value monetarily.
Considering this in the face of what we've been taught about today's capitalist society, owning the means of production is really only a small part of the greedy antisocial playbook of those who market in false scarcity. Don't think for a second that this isn't an ideological war, one that will be fought with all the information weapons at the disposal of those who stand to lose in a free and open society.
Regardless is stuff is open or proprietary, nobody like when the terms of a contract change without their consent. People/companies have adopted redis under a specific license, which really is kind of a binding contract, then one day under a new release the terms have changed making it incompatible with their intended use. It is only natural that an alternative, and in this case a fork appears.
LWN has a good overview:
https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/
Redis Ltd is only responsible for about 20% of the work.
[1] https://github.com/redis/redis/graphs/contributors
It makes perfect sense for AWS and Google to fork immediately after the switch, but for contributions before the switch, there is no basis for AWS and Google to complain Redis Ltd, either legally or morally.
Employees on their own time, or paid to do it?
So I'm clear though - if I wrote a SAAS product tomorrow that under the covers used Redis, I'm OK, but if I spun up a bunch of servers and offered managed Redis as a product, I would need to pay?
That's the pitch of the license, essentially, but in practice the SSPL is an utter nightmare to comply with (to the point of being deliberate) and it mainly exists to put a veneer of open source on a proprietary product. In actual practice you really just cannot offer Redis as a service unless you are Redis Ltd, which is the actual point of the license in the end.
Isn’t this exactly what the person you’re replying to was saying?
You should probably ask Redis, Inc. what their intention is. Keep in mind, though, the run the risk of being re-rug-pulled. They have changed the license once and they can do it again.
...which, given LGPL, will be worse now as they'll simply not share their modifications because that's the legally safest option.
I don't know much about the genesis of Redis or Redis Labs, who key people and dates are, etc. I guess this obfuscation is part of the problem.
No, because the Rust trademark guidelines prohibit that (https://foundation.rust-lang.org/policies/logo-policy-and-me...)
In Redis Labs case, they acquired the Redis trademark from the original author, who they employed for a few years after the project was well established.
Nobody could start "Rust Labs" without the agreement of the Rust Foundation, because they own the Rust trademark.
(Say you like something like Elm -- wouldn't it be better to have a relatively closely aligned commercial entity that puts significant and effective effort in making it widely used, which in turns makes it easier to find an Elm job or sell Elm-like solutions as a consultant).
[0] https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md
Like since Rust is MIT licensed, you could make a closed source fork of Rust. The trademark guidelines would prevent you calling it Rust or anything too close, but you could describe it as Rust(TM) compatible and any of the other legally permitted uses of other people's trademarks.
http://antirez.com/news/121
I'm not a lawyer, so take the following with that grain of salt.
In the specific case of Rust, no, because as another user pointed out, their licensing prohibits it.
If my understanding of the licenses is correct, the X-11, BSD 3-clause and BSD 4-clause licenses also prohibit this.
The MIT, BSD 2-clause and ISC licenses don't appear to prohibit this.
Your post mentions a few issues which I believe are legally separate:
1. Naming your company after an open-source project. I believe this is perfectly legal under the latter listed licenses, and happens in practice (for example, a brief search yields that React is MIT-licensed, and "React Labs" is a company).
2. Selling a commercial version of an open-source project. This is legal, and in fact a license isn't considered open source by OSI or free software by FSF if it disallows selling a commercial version. Whether this will be profitable is a separate question--generally people won't be willing to pay for something if they can just get it for free. There are two ways around this that I can think of: a) providing services and development around the open-source project, and b) extending the open source project with closed source code. The latter business model is prohibited by copyleft--you can only sell closed-source extensions to copyleft software if you have rights to the copyright (i.e. you created the code yourself) so attempting to do this with an existing copyleft-licensed project would be prohibited.
3. Enforcing trademark on the name of an open source project. My understanding is that enforcing a trademark created after a open source project started using it isn't possible, not because of licensing terms, but because of "priority of use" or "first to use in commerce"[1]. That is, if an open source project "Foo" exists already, I can't create "Foo Labs" and then sue the Foo project for using my name--on the contrary, the Foo project could probably sue Foo Labs. Redis Labs avoids this liability because they obtained rights for the trademark from the original Redis developer (I'm not sure what terms they obtained rights to the Redis name under--if they have exclusive rights they could sue anyone using the Redis name, but contribution to the project over time would likely make this complicated). There's a separate issue which is that "Foo" and "Foo Labs" are arguably different trademarks--Foo Labs can't inherently sue anyone using the Foo name, but they could likely sue someone who started a "Foo Labs" if they were the first ones to trade under that name.
[1] https://www.avvo.com/legal-answers/does-prior-art-apply-to-t...
Are there any instances where an SSPL license or similar is warranted?
It's the "build your userbase on open source, then lock them in" that bothers people.
Open source does not make a difference who uses it.
No, people are not upset Redis is trying to make money. People are upset that something that used to be FOSS is no longer FOSS, and are trying to protect themselves from future pain by doing something that is very common in FOSS, which is forking a project.
Just because someone is trying to make sure the software they rely on continues to be FOSS, doesn't mean that they are out to actively hurt the original creator(s) of the original project. I don't know how you could possibly read the situation like that either.
What is the stance on incorporating Rust into the codebase?
I don't think anyone is going to be very excited about introducing Rust unless there's a compelling reason to, but feel free to bring it up on the issue tracker for discussion and see if you can form a consensus on the matter with the rest of the community.
I wish you the best of luck and when I am able to be involved with OSS again, I will gladly help out with Redict. I think the LGPL is a good choice.
Areas where I would personally want to see Rust in a project like this, a) parsing and talking with the network b) extension mechanism moved to Wasm (Wasmtime for execution) but that plugins would be moved into a Wasm container.
It would also be a nice property if the core of the project maintained a compile to Wasm compatibility so that Redict could be run everywhere.
I think your Rust/wasm goals are a little bit dramatic for the goals we established among ourselves, but by all means start a conversation about it. Good support for compile-to-wasm is probably something that we'd be down to have upstream, though.
I honestly do not see this as being different than Redis. Do BSD or MIT and be done with it.
It seems needlessly ideological. Everyone wants to call their stuff open source but have strings attached.
The term 'Open Source' is well-defined and includes licenses like the one redict picked (LGPL 3.0). It is incorrect to try and lump this in with source-available licenses that are IMO anathema to Open Source.
It’s simply a fact that MIT for instance allows things like Redict and this discussion to take place, as well as other things. It is maximally permissive.
Sure, sure. But the term Open Source has a meaning. Ultimately terms have meaning based on their usage in the language. For 'Open Source', its usage happens to reflect the same meaning enshrined by OSI.
> It is maximally permissive.
It appears that there are now several redis forks, with several licenses. For the most part: everybody wins. If you prefer the MIT license, maybe you would prefer to contribute to the BSD-licensed Valkey. And if not, you can fork redis too.
Anyway, the Redict team are doing their thing and letting Redis and Valkey be. You’re the one insisting on Redict doing things the way you would like, so who exactly is being ideological?
Edit: Linux was always GPL, Redis was not, so I don’t see the relevance.
So the parent was asking isn't Linux Open Source but with strings attached? And if so are you happy with Linux?
Although I am assume what you meant was that Redis was originally a BSD / MIT, and re-licensing it to LGPL seems ideological. But I could be wrong.
If someone gave you something the correct presumption would be that you can do as you like with it, unless - and what follows are strings, like copy left.
It isn’t inherently bad, but it is what it is.
My happiness with Linux is irrelevant because Linux to my knowledge was not re licensed to be more restrictive.
>"I read the post and it’s not clear why it’s not MIT licensed. Why not allow attempts to “create proprietary distributions?” That’s what open source would allow, no? "
Your "That's what Open Source would allow", clearly implies anything but MIT / BSD license are not Open Source. Hence why people ask about Linux, which is Open Source but copy left aka non MIT / BSD.
>Edit: Linux was always GPL, Redis was not, so I don’t see the relevance.
Your first sentence implies GPL are not open source, the relevance here is why the parent ask "do you think Linux as Open Source" or happy with it. And:
>My happiness with Linux is irrelevant because Linux to my knowledge was not re licensed to be more restrictive.
Your happiness with Linux contradict with the first "quoted" sentence to what a lot of people think you meant.
Just in case, I am on the BSD / MIT camp but what you wrote create a lot of confusion.
I have answered a similar line of questioning before.
Arguing strongly for permissive licenses is arguing for a kind of passive freedom which presents as freedom from obligations. Copyleft is the sort of active freedom which presents as a guarantee of rights.
I am going to assume this isn't impersonation, but Drew what happen to your old HN account? ( I had it on RSS feed and hasn't shown any update for ages I thought you left HN )
I lost the password to my old account.
I meant off topic as in asking you question about your account. Not the Open Source discussions which is of course perfectly valid. Sorry for the confusion.
A hypothetical license that said no forks allowed wouldn’t allow Redict, for instance.
* Technically you do have more options than this with the LGPL but this is a layman's explanation.
You’re creating this metaphor with the government, but this isn’t the government.
In the end freedom is a spectrum and you are free to do more with MIT than LGPL.
Even if someone forked MIT and made it closed source that does not in any way stop or restrict those who prefer the project pre-fork.
Indeed, that is the very logic that has made Redict possible to begin with. This is the illustration of why MIT is maximally free.
Suppose the EU said code must be closed source, and you must distribute encrypted binaries. In this hypothetical it wouldn’t be possible to use Redict at all. This is another example of why the MIT, and permissiveness in general, is superior.
—-
As an aside your freedom of the press example is yet another reason for permissiveness. The government isn’t permissive by default, which is why “freedom of the press” is even a thing.
The MIT maximally enables exploitation; copyleft maximally enables freedom. From the point of a proprietary fork of a permissively licensed project onwards, users of the proprietary fork enjoy fewer freedoms than before. You are advocating for freedoms for the few (business owners making proprietary forks of free software for profit) at the expense of the freedom of many (everyone else).
Redict would also be possible if Redis used a copyleft license. The space for Redict to exist is not afforded to us because of the use of a permissive license in some way that Redict denies to anyone else through the use of a copyleft license.
In any case we can agree to disagree.
Why is copyleft subject to more scrutiny than proprietary software for you? You suggest that permissive licenses are better because they allow permissive derivatives of the software, which suggests that permissive derivatives are good. But copyleft derivatives are... not good? Copyleft offers more freedoms than proprietary software.
Moreover, this line of reasoning completely disregards the social contract. Many people worked on, used, popularized Redis under the presumption that they were participating in a collaborative effort from which all participants would benefit, only -- surprise -- now the trademark holder has changed the terms so that only they benefit from a product of which, by objective measures, 80% was made by the community.
That's what a permissive license would allow, which is a subset of Open Source.
> I honestly do not see this as being different than Redis.
Redis doesn't give you the 4 freedoms; in point, "The freedom to run the program for any purpose".
> Everyone wants to call their stuff open source but have strings attached.
This literally is open source.
Redis Labs also did not in any way make Redis. They came in later to exploit the already open source project for their own benefit.
Then, another company that is offering a hosted Redis and support hires antirez and so becomes the 'offical' Redis company.
In 2020 antirez leaves and goes and writes a novel (called "Wohpe") instead.
https://en.wikipedia.org/wiki/Redis_(company)#History
Antirez hasn't been involved in Redis in a long time.
This is a common enough pattern when open-source projects leave their roots and then, eventually, alienate theiropen source base. Perhaps the time is ripe for Antirez to come back and shepherd one of the forks, a bit like mariadb?
I don't understand the bitterness around this debate, it seems most people are frustated that they have to pay for something that was free, but at the same time, they probably made money from what was free.
I totally understand, with todays mess of maintainers not getting paid in full, that at some point, someone wants money for their work. Be it a person, a company or you doesn't matter. But right has to be right.
I think we will see a lot of this the next 10 years, simply because we cannot afford maintainers not detecting backdoors in a code-review from some bad actor.
In any case, congratulations on the very fast release of Redict, rewriting references to Redis is not a simple s/Redis/Redict/g sed job. How do you feel about possible competition with the Valkey project, apart from the licensing differences?
Well, trademarks are a form of IP. But in any case the copyright was never antirez's to transfer to anyone. In the absence of a CLA with a copyright assignment, every contributor retains the copyright to their contributions, and licenses them to everyone else (Redis Ltd included) under the terms of the BSD license. Legally speaking, Redis Ltd's SSPL code is, in effect, a fork of the Redis BSD code, in the same way that Redict is.
>In any case, congratulations on the very fast release of Redict, rewriting references to Redis is not a simple s/Redis/Redict/g sed job. How do you feel about possible competition with the Valkey project, apart from the licensing differences?
Thanks for the congratulations!
As for Valkey, so far they've put a lot of time and energy getting the various corporate stakeholders on board with their fork and getting some marketing out (which is no small feat, to be sure, I shudder to imagine the number of lawyers involved), but they still have a lot of boots-on-the-ground work to do getting their fork up and running so it may be a while before our projects are interacting directly. From the limited communication we've had with them, it seems likely that we'll be able to collaborate insofar as reducing incompatibilities is concerned, maybe co-maintenance on the protocol specification, but not much more. Redict does plan on pulling useful patches from Valkey once they get the code going, though it's unfortunately not possible for them to pull from us unless they're on board with switching to a copyleft license -- and we encourage them to do so :)
What these companies want is licenses which prevent AWS and other cloud providers from competing with them on their specific technology, regardless of how much those same companies are contributing to the technology. Redis is the most extreme example here - by all accounts I've read, Amazon was a major contributor, not just throwing bug fixes here or there. But that doesn't help Redis Labs, they want money, not code. And the AGPL would have done less than nothing to help stop Amazon from running their own Redis service: Amazon was already doing everything (or at least most things) that the AGPL would have required of them.
SSPL is just a figleaf. No one sane redistributes third party SSPL code without having a contract with the company, it's essentially proprietary in all but name. But it allows the company to maintain this air of open source legitimacy.
And if it grew organically, well OpenSearch is not exactly thriving. One of my clients are using it and it's a massive PITA to be on it.
No idea how badly it affected enterprise revenue for ElasticSearch though, but ES is going to win that fight in the long term.
For the vast majority of open source projects, being used by (and, importantly, receiving contributions from!) the "big boys" is a Good Thing and something to be aspired to.