Redict 7.3.0, a copyleft fork of Redis, is now available
redict.io
redict.io
> 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...
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.
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?
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?
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.
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.
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.
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.
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.
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.
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:
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.
LWN has a good overview:
https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/
Redis Ltd is only responsible for about 20% of the work.
...which, given LGPL, will be worse now as they'll simply not share their modifications because that's the legally safest option.
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.
(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.
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.
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.
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.
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.
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.
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
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.
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).
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...
Open source does not make a difference who uses it.
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.
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 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.
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.
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.
>"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.
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.
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.
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 :)
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?
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.
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.