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.
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).
Time will tell if the version on Codeberg (https://codeberg.org/redict/redict) can compete with the fork on Github (https://github.com/valkey-io/valkey) in terms of visibility and contributions.
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.
You can see it here: https://codeberg.org/org/redict/members
It's worth noting that the Linux Foundation is a commercial consortium and the companies behind Valkey contribute over $1M to its annual budget.
> contribute over $1M to its annual budget
That on top of developer hours dedicated to various projects, which are probably worth multiple millions.
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.
If you have a commercial use-case, there is also a non copyleft fork available here
https://www.linuxfoundation.org/press/linux-foundation-launc...
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.
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.
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?
That is absurd. LGPL is widely understood. Compliance is generally pretty easy. The Linux kernel has many users, and it is GPL.
> 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.
How would you compile Redict's source code into a website? And if you somehow did, it would be an executable, yes.
> 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?
I've had to go over open source package licenses as part of due diligence when my startups were acquired, but LGPL was never an issue, unlike AGPL.
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.
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.
> If you aren't a cloud provider and you don't modify the code of your chosen Redis variant,
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.
Sure, but that's left for the hosted service providers to figure out. No one can sue you for using AWSs offering.
What about Valkey? We have 2 big forks now
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.
> innovation tokens / weirdness budget
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.
Reminds me of this from a comment yesterday
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.
Three. KeyDB forked before the recent shake-up.
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.
This is directly addressed in the blog post: https://redict.io/posts/2024-04-03-redict-7.3.0-released/#wh...
We will basically see who wins the race and gets adopted the most.
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?
To be 100% you should email redis and/or ask a lawyer.
Not randos on HN
That is the stated intent and spirit of the new license terms, but as others have said, ask a lawyer to be 100% certain.
I agree with dartos, but I will state for the record that you can use Redict for free in production even if you do sell a hosted version of it.
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.
Just passing by with a quick nit to pick:
>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 :)
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.
No problem :)
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.
>MariaDB is also somewhat widely used, but not nearly as much as MySQL.
I believe this is factually false. Consider just one datapoint:
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.
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.
AWS has ElastiCache, which is compatible with current redis, but I wonder in which direction they'll go.
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.
Lightweight is your problem here, I think, but I've used CouchDB successfully in similar situations. However, its not in-memory like Redis is.
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.
Redict is binary compatible with Redis Modules, including RedisJSON, out of the box, so you can keep using it no problem.
Hopefully they don’t get legal pressure from Redis Labs over name similarity. Didn’t OpenTF have to change to OpenTofu for that reason?
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.
I don't get the point of this - people are upset that Redis is trying to make money from companies like AWS and Google?
People are upset because Redis is not open source anymore. That is all.
Is this like a Richard Stallman ideological thing?
(EDIT: Genuine question - I'm trying to understand if this is a license purity issue or something else).
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:
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.
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.
LWN has a good overview:
https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/
Redis Ltd is only responsible for about 20% of the work.
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.
Legally, they can't complain, but morally it is icky. Redis is a leech.
If you don't want to be leeched, don't contribute to BSD licensed projects.
>>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.
And well, why not? That is the idea. It's open source.
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.
> Like someone could start e.g. "Rust Labs" and sell a commercial version of Rust?
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.
[flagged]
Redis Labs acquired the trademark from the original owner.
Nobody could start "Rust Labs" without the agreement of the Rust Foundation, because they own the Rust trademark.
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).
Mozilla Corp is (solely) owned by Mozilla Org.
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.
[0] https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md
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.
There's some context in the comments to:
You can sell a commercial version of Rust (MIT, BSD, and Apache licensed), but you'd need to change the name for trademark reasons.
> 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.
[1] https://www.avvo.com/legal-answers/does-prior-art-apply-to-t...
This makes more sense as an explanation.
Are there any instances where an SSPL license or similar is warranted?
If you want to release your project for the first time as SSPL, go right ahead. You may have difficulty getting adoption however.
It's the "build your userbase on open source, then lock them in" that bothers people.
There is open source and there is non open source. Both is fine.
Open source does not make a difference who uses it.
That’s unfortunate. I have a clause forbidding Anish Kapoor from forking or using my code.
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.
I don't see much info on the governance of the project.
What is the stance on incorporating Rust into the codebase?
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.
Great responses!
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.
Thanks! It would be great to have your help.
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.
The OSI doesn’t represent everyone.
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.
> The OSI doesn’t represent everyone.
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.
Do you feel the same way about Linux and Git?
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?
Isn’t Linux GPL? What’s the relevance?
Edit: Linux was always GPL, Redis was not, so I don’t see the relevance.
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.
Let's just recap
>"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.
Redict is LGPL, a less restrictive GPL allowing linking to projects with other licenses.
Yes, but Redis was even less restrictive to begin with.
The GPL has more strings attached than the LGPL.
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?
> That’s what open source would allow, no?
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.
[dead]
[dead]
[dead]
[flagged]
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.
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?
Ok, I was mistaken then. I thought Redis Labs folks created Redis initially.
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.
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.
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.
I don't see a fig leaf. All I see is dick.
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.
They'll just put that clause in from the start.
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.
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.
Open Source doesn't have to come from a startup with a business model based that one open source project.
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.
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.
Yeah, I'm still fully aligned with this.
>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.
Thanks for your work Madelyn and I wish you and the team the best of good fortune!