For me, the license change upset me mainly for two reasons:
1. Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc - and when they did that it was under the understanding that project would remain under the same open source license. It honestly felt like a betrayal of trust.
2. From a purely selfish point of view, my favourite thing about open source licenses is that they let me know exactly what I'm allowed to do and build on that software without having to consult a license. Licenses like the new Redis one leave me potentially needing to get my own legal advice depending on what I'm building on the software. I don't want to spend my time, energy or money on that stuff!
I do also see these kinds of license trends as harmful to open source generally. It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms. That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects. I'm sad about that.
(And yes, I do understand and dislike the trend of businesses building on open source without contributing back. There are no clearly correct answers here.)
"Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc"
I can understand that, but the thing about the BSD license is that such value never gets lost. People are able to fork, and after a fork for the original project to still lead will be require to put something more on the table. Inside Redis it was tried very hard to don't change license. For years it was some kind of "dogma", something one could not even speak about. Then after all the kind of attempts, and following the experiences of MongoDB and others, finally this choice was made. (Disclaimer: I saw the switch as an outsider, so my information is not complete about the final decisions -- I for sure know how this was always considered to avoid if other setups were possible).
However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
With open-source software, a license is as much a social contract as it is a legal one. People contribute because they want to be part of a community building something which is beneficial to everyone. Everyone contributes where they can, and in turn takes what they need.
Redis Ltd. broke the social contract. They decided that the short-term profitability of the company was more important than the project as a whole, the community which had grown around Redis and the future of the software. Probably a wise decision from a business perspective, but that doesn't make it any less of a rug pull from a community perspective.
You're right that no pre-relicense code was lost. People could and did fork. But something far more valuable was lost: the community's trust. First they relicensed the code solely for their own benefit, now they tried to take over third-party libraries and started behaving in a hostile way towards the community forks. Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers? After all, what's the next shady move going to be?
I'm embarrassed to admit that I hadn't fully taken into account that those contributions do at least remain under the BSD license and hence stay open under those original terms. Thanks for reminding me of that.
That is true, and that is how Valkey and other forks are moving forward. But the value wasn't just in the code- many folks contributed value by writing blog posts, making videos, and writing books or otherwise promoting "Redis". The Redis trademark owners had every legal right to change what "Redis" means by changing the license, but it creates a massive headache and a practically impossible task for everyone that gave so much to promoting the project to change all of these references.
Folks like to cite MongoDB as some great example, but Redis had significant community contributions in recent years. And AWS never used any Mongo code.
In a sense valkey is the main line and redis is now the fork. Valkey is about the same except losing the trademark. It’s similar to Hudson and Jenkins. It’s not so clear cut with OpenSearch.
"I can understand that, but the thing about the BSD license is that such value never gets lost."
That is one side of the coin: value never gets lost!
The other side is that the BSD license is very clear what it allows. It's a good thing that there are licenses that allow what Redis did.
It is also a good thing that there are other licenses which can help prevent what Redis did.
It is our choice as developers and we should never blame others for exercising the rights we granted them.
Put another way, many people have contributed to Bezos' bottom line for free. The restriction is annoying but there should probably be a better way to get a piece of that huge value for everyone who generates it, mostly thanklessly. Some kind of OSS tax proportional to profitability would make some sense, as annoying as that might be to implement or deal with.
> However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
You can do this without fucking over past contributors. Just... Don't change the license. Then still do all that other stuff. They're not contradictory.
What I dislike about the license change is that by trying to extract an extra dollar from Amazon&Google, the entire community gets hurt in the process.
Can I "dnf/apt install redis" on my Fedora or Debian install? I cannot, it's no longer packaged because it's no longer open source.
Can I go buy a shared hosting plan and get Redis? Or a small PaaS that sits on top of AWS? I cannot, because we have decided that every hoster is now as exploitative as Amazon, regardless of their margin.
For decades we lived in a world where someone could sell you an Apache server and a MySQL instance without having to pay money to Apache or MySQL. We can change that social contract, but like all tariffs, this one will be paid by the end users, not by the companies providing the service.
> For decades we lived in a world where someone could sell you an Apache server and a MySQL instance without having to pay money to Apache or MySQL. We can change that social contract, but like all tariffs, this one will be paid by the end users, not by the companies providing the service.
Yeah, but the Internet community at large took care about funding. MySQL always had the commercial support leg to stand on, and Apache httpd... looking at the contributor list [1], it's a healthy mix of universities, large companies (IBM, HP), ISPs (Vodafone, Cable & Wireless), hosters (Rackspace), small consultancies and individual private contributors.
In contrast, the megacorporations are largely absent from FOSS contributions (the exceptions being Netflix and partially, where it suits them, Google, Microsoft and Apple).
> Many people had contributed their efforts to the Redis project for free
It's worth noting that the bulk of the code was written by antirez with only ~12 others exceeding 100+ commits [1]. And if you continue scrolling the number of commits-per-user drops off fast. It's striking given how famous the project is.
As one of those 12 other people, number of commits is not a good metric in this context. When you have a single maintainer, like antirez was for a long time, he could commit 10+ commits for a single small feature but I needed to get someone else to approve my commit before merging.
>there are a number of other high-profile license rug-pulling projects. I'm sad about that.
It also severely sets the industry back every time one of these rug pulls happens and we have to scramble to find a replacement. Sure it might drive some minor innovation, but it also wastes a ton of resources by splitting communities and leading to tons of rewrote just to get back to a place of stability.
The question of what constitutes a "service" seems very murky, and although it's obviously not the intention of all these source-available, BSL style things, in a dark timeline it seems like there's a lot of room for litigious actors to behave very badly. The uncertainty is what makes it scary, I'd also like a lot more clarity.
The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).
No one is expected to use any of the code licensed in this way commercially. You enter a contract with the vendor, tell them what you need, and negotiate a price. At that point, it doesn't really matter what the copyright license says.
AFAIK, the reason for these changes is basically "prevent AWS from eating our business". Is that right?
If so, are these trends harmful to open source? Are we not choosing between:
1. A world where all revenue in OSS infrastructure ultimately flows to a few big platform companies.
2. A world where these carve-outs are commonplace.
Meta's carve-out with Llama is so interesting because it practically calls the big companies out by name. Should there be a similar standard license for open source infrastructure?
> Should there be a similar standard license for open source infrastructure?
Yes, I think there should be. The tech world is basically a monopoly at this point, and that's dangerous for a thousand reasons. The least those monopoly owners can do is financially contribute if they want to use these tools.
It's sad to me that the tech world is rallying around Valkey, which is Big Tech's fork: AWS et al are the ones behind it. We continue to give more and more power to the biggest players.
Affero GPL-style copyleft licenses are an option, although they are treated as radioactive by most companies. A clause that triggers the extensions over GPL only for companies beyond a certain size might make them more platable.
I think it comes down to the initial choice to make something open source. At that point you're well aware that big companies might use your code and profit more than you ever will. If you don't want that, don't open source and they will never use your code.
It's having your cake and eating it when you get popular by being open source and then add restrictions when you have success.
I think there should be a change to licenses where the trademark is tied to the license. You can go proprietary but you can't take back the name.
> I do also see these kinds of license trends as harmful to open source generally
I've re-read this a few times and I'm still not sure what "harmful to open source" means in this sentence, could you expand on this a bit when you have time? (readings I considered: this will dissuade people from using OSI licenses, this will dissuade people from trying to monetize open source components, this will dissuade people from using open source components in their products all together, this will dissuade people from contributing to open source)
> Many people had contributed their efforts to the Redis project for free
This one is not directly addressed at OP but I would be interested to see what the contribution numbers are like for Redis and other projects post-license change.
In my own limited experience (project with >10k, <100k end users), I received no meaningful code contributions when the project was MIT licensed, but contributions of significant features and large bug fixes skyrocketed after switching away from it (not saying that the license change is the reason for that, just that it didn't dissuade some people who are willing to contribute significant effort from contributing to the project).
Editing this post to say thanks for the response and clarity, I don't have anything else to add!
I see the open source movement as being about developers sharing their work in order to raise all ships and dramatically accelerate the rate at which participants in that community can build cool software.
A lot of that benefit comes from not having to worry about licenses: pick platform components with known open source licenses, build cool things with them.
I think the rise in not-quite-open-source licenses (especially projects switching to those licenses) undermines the things that I value about open source, and further encourages more projects to make those decisions in the future.
> this will dissuade people from using OSI licenses
Yes, because other projects will follow the pattern of successful ones.
> this will dissuade people from using open source components in their products all together,
Yes, because now there is a very real risk that after you have invested in using an open source license, the owner might change the license on you, which makes potential users more wary of open source projects.
> this will dissuade people from contributing to open source
Successful open source projects historically involve a bunch of companies lowering their costs by commoditizing expensive commercial functionality. Server operating systems, version control, programming environments used to be very expensive.
Linux, git, Python, Postgres, etc weren’t about getting rich, but about making something cheap and easy.
The paradox of these single company backed OSS projects is somehow making a big chunk of it free/open but collecting money off of other services. To me, I’m not sure that’s worked yet. Many will even say that these companies aren’t really doing open source in the traditional sense, but acting as commercial vendors that let you look at the code.
In this matter, that pretty phrase “social contract” is at root a demand for ego massage from a) contributors that don’t actually believe in the freewheeling spirit of the BSD/MIT licenses but used it anyway, and b) noncontributors whose sense of entitlement is projecting as loss aversion.
The revised license is nevertheless a problem for component selection. Usage caveats are a landmine and thereby a coherent motivation for the Valkey fork.
> It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms.
I'm not familiar with what's happening in this Redis licence change.
But if it was Open Source at version N, and you built your business (or stack, etc) on top of that, N will remain forever available to you as FLOSS, not?
Is the problem maybe that ppl expect future updates, maintenance to remain Open Source? Something that, AFAIK, no Open Source licence guarantees? So, misaligned expectations?
> That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects.
It's not new. MySQL, Redhat and many others have done this for ages in the floss community.
Note his "build a business on it" angle. It's not an open source problem. Greedy techbros want free support forever from the community while contributing almost nothing back. Same for large corporations.
They see this as "rug pulling". I think developers need to do a lot more of that for things to change.
>Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc - and when they did that it was under the understanding that project would remain under the same open source license. It honestly felt like a betrayal of trust
I'm not seeing this being a factor in the broader community of users. Redis is still 'go-to' solution in its space. Haven't yet had anyone bring this up.
>I do also see these kinds of license trends as harmful to open source generally. It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms. That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects. I'm sad about that.
I think the biggest thing is - that you acknowledge- that companies (particularly big businesses, like the cloud and service providers) build entire lines of business on this tech without contributing back, monetarily or otherwise, or even worse, try to shorehorn a project into prioritizing what they want over what may be better for the long term health of the community.
These license changes I've seen so far are all attempts to address that. How else are they able to do it with any long term success? They already aren't getting the funding they're looking for, clearly, while businesses build multi million and in some cases billion+ dollar businesses on top of the technology.
I'd argue that old permissive licenses aren't sustainable in the long run for any project like Redis
> It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms.
By "used to be" you mean for a brief period in the 2000s, right? Because this extremely generous open source landscape we have seen in the past 20 years were not the normal state of software for most of software's existence.
A generous open source landscape is something we -- you, I, the readers of HN -- have to actively maintain by shouldering the burden of maintaining the correctly licenced software. We cannot trust this important job to profit-making corporations.
> 1. Many people had contributed their efforts to the Redis project for free - both in terms of code [...] it was under the understanding that project would remain under the same open source license.
The whole point of the MIT/BSD licenses versus licenses like the GPL is to not be limited by that.
> It honestly felt like a betrayal of trust.
It feels like total ignorance from. If such license change bother you, you should only contribute to projects that are licensed under GPL or similar licenses and that don't force contributors to sign a CLA.
I don't like current Redis license, but nobody lost any code and any contributor can still contribute to any fork that started using the last open source version.
The license change is a necessary evil, otherwise BigCo will continue EEE and extract value from the project without giving anything back. It's time to hit them where it hurts. The world will be a better place if Google collapsed tomorrow. FOSS must adapt to SaaS and the modern rent-seeking behaviors of BigCos.
> However, during the “writing years” (I’m still writing, by the way), I often returned to coding, as a way to take breaks from intense writing sessions (writing is the only mental activity I found to be a great deal more taxing than coding)
This has been my experience too. With both "Game Programming Patterns" and "Crafting Interpreters", writing the code was a joy while writing the prose was hard work. Gratifying, but mentally draining in a way that programming isn't.
Totally agree. It's very hard, especially since when writing fiction, and the kind of fiction I wanted to write, there are a lot of things you doubt about yourself: is my style as good as I wish? Are my stories and my characters strong enough, with the right motivations? And I bet many of this ingredients are still there even when writing technical books if the goal is to do a very good job. Teaching in written form, with a book, is like a long story that must fit, chapter after chapter, sentence after sentence.
Please keep writing, I want to read your fiction. I cal tell you have style from your blog entries. Lean into the style and readers will love you for it.
It's because the audiences for each are different. The audience of programs are CPU cores that have a well defined set of behaviors. An i7 isn't going to one day decide it doesn't like the SHL instruction or offended by having to perform too many MOVs.
The human by comparison is more taxing to write for as your brain is the compiler and checker for the instructions of your language. You write, proof read, correct, proof read again, correct more, delete, re-write, etc. I get why AI tools for writing are in high demand. Hell, sometimes I spend what feels like forever writing some of the comments here on HN as I have to compress a lot of thought into a few, clearly written sentences.
"Game Programming Patterns" has been of huge help throughout my career and it's always my go to recommendation for new game programmers and reading your comment makes me feel even more grateful that you made the effort of writing it, thanks for writing such a great book!
Does it have something to do with the ambiguity of our language (english, spanish, _et cetera_) in contrast with formal languages? Like, it would require more mental effort to describe something in the English language, compared to describe an algorithm using language constructs: you know the constructs, and you know your restrictions in the programming language; in the English language, you don't know in advance what can you say and what you cannot, and you have to imagine what is your message going to get across in reader's minds. Well, who knows?
Anyway, absolutely love your books, have the Crafting Interpreters print copy (which has been inadvertently unboxed by my friend; did want it to be still in the plastic) despite using only the website version, and looking forward to buy the Game Programming Patterns.
I hope you continue to be successful in your endeavours (especially if they result in legendary books like these :D). Also, could we be looking forward to a version of yours of a CPU architecture book, a la Nand2Tetris ( ͡° ͜ʖ ͡°)?
Our language centers evolved to build our "natural" languages and our "natural" languages evolved to take the best (most?) use of our language centers. Whether or not it is ambiguity or simplified context or some other "complexity mechanism", if you agree with the Chomsky hierarchy that our "formal" languages are pure subsets of our "natural" languages, then that alone would imply we use only a smaller subset of our language centers when working in "formal" languages.
Though yeah, that does feel awfully reductive as an argument, and leans on a lot of assumptions in Chomsky's theories. I know that there are axes where "formal" languages feel more orthogonal to "natural" languages than "pure subsets". Some parts of "formal" languages to me feel a lot more visual like poetry than linguistic in the same way as prose.
I have had the same experience. With coding I can be in that coveted state of flow for 10 hours straight. With creative writing, I feel exhausted after 3 or 4 hours. I didn’t expect this and don’t fully understand why.
There are a couple of reasons as far as I can tell. Programming can be adequately gamified or fulfill basic dopaminergic feedback loops in a way that “true” creative expression (outside of an effort-action-reward feedback loop) cannot. With fiction, the value is strictly non-instrumental or context-specific. While the parsimony of the (formal) language you deploy can be (reflexively) satisfying to look back on, the real joy of art for its own sake is the response from the reader, which is necessarily slower than that of a computer, as it requires a more complicated system of evaluation than pure utility.
Would Game Programming Patterns help someone who wants to build a slot machine? I’ve built a wall mounted machine for my home but I never got the software side done. I think a book could help but most of them cover very different mechanics these days.
Why the down-votes? Are people specifically opposed to gambling or is it something else I said? I'm just wanting to write a hobby slot machine because they fascinate me but the mechanics of a slot machine UI are quite different than a 2D scroller or a 3D game engine.
That's really interesting - was chatting to a few friends who are very into using tools like cursor to generate code. They've been complaining of feeling extremely drained after a day of prompt writing.
I'm really interested in this bit: "the fracture with the community is not about licensing, or at least it’s not mainly about licensing"
I wish he'd elaborated a bit more on what he thought it was about. My understanding is that it's 100% about the license. That's certainly why I'll reach for valkey instead of redis next time I need it. That's also what I've heard from everyone else in a similar position. What else would the community split be about?
For somebody, like you and many others, it was very important to retain an OSI license. But I feel that in general given that the new license is IMHO good for almost every user, from the POV of what they can do with the code, and that the cloud situation was quite self evident, I believe that with better communication, and immediate developments/merges in the core, to counter balance the license switch, many people would understand the license matter.
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.
> is IMHO good for almost every user, from the POV of what they can do with the code
I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't. We're trying to figure out our migration path right now and it's almost surely going to be Valkey.
Large vendors were never going to pay up and so it's all loss for everyone involved. I have to do work, every project that works with Redis has to do work to support Valkey now, the eventual divergence will force people to pick a side which will probably also be Valkey for everything other than the client libraries Redis Labs personally develops. It's a mess.
Open core proprietary add-one for new fancy AI features could have avoided the split and gotten you in the door with big cloud vendors willing to sell your add-on in the marketplace with revenue sharing. They did it with Bedrock and Anthropic is making bank off it.
It sounds like your opinion is that the communication around the relicensing was the issue rather the relicensing itself, but from the standpoint of the people who decided there was enough of an issue to switch away from Redis, is that the case? As an outsider to the Redis community both before and after the schism, I don't know that you're wrong, but I have to imagine that if I were someone concerned enough to consider forking (or switching to a fork), I wouldn't be happy with someone involved in the project making a blanket statement about whether my motivations were actually about the licensing or not. Ironically, this seems like it's exactly the type of communication that could exacerbate concerns around licensing.
I hear you, but at the same time it was badly done. I’ve been referring to Redis as “a proprietary fork of Valkey,” and that message has clearly resonated.
> But I feel that in general given that the new license is IMHO good for almost every user
That is the nub of the sticking point.
The new is OK for people who only care about getting things done. But for people interested in building and being part of a community, giving as well as taking, not so much
This:
You may not make the functionality of the Software or a Modified version
available to third parties as a service or distribute the Software or a
Modified version in a manner that makes the functionality of the
Software available to third parties.
I'm a vendor of some packaged on-premise solution. We are using a Redis as a cache layer inside. Risk of being forced to GPL out our installer is unacceptable for us.
also, lack of japanese and korean support... and non-willingness to integrate this when developers native speakers even want to and volunteer to improve it.
you can see there is shift from roots in redis. original over-the-write protocol was human-redable by design. now more and more over last couple years API and instrumentation, docs, gets non-human readable at all (mix of ASCII and hex binary encoding, say in FT.SEARCH, speaking of FT.SEARCH it is barely readable even when in non-binary form...)
Yeah, even if the split isnt entirely about licensing (and I do think it mainly is), the rest is a result of the licensing changes as well in terms of the implications and side-effects. Its the way people felt rug pulled and eroding the trust, which is now forever lost.
Techbros and large corporations still have the original source code they built their business on. What they want is free community updates and support forever while they give almost nothing back. So it's not a licensing problem. It's not a free software problem. It's a "free as in beer" support problem.
AGPL only slightly prevents this by forcing them to share their changes to the source. And usually this is not very useful to the community, anyway. And very little effort. And the same people scream it's an evil license. They want free (as in beer) stuff forever and it's not just the source code. It's very ungrateful of them.
That's not been my experience. My limited experience at a large corporation was "throw money at vendors for enterprise support"
The bigger issue was startups and small/medium sized companies with limited technical support and limited money to buy enterprise support or in-house experts. These are the same companies heavily leaning on managed services from vendors like AWS.
I appreciate redis, but believe me when I say, I never considered using redis under anything but its original license, and I am just as grateful for valkey as I am for redis. It is very easy to move and I will keep moving anytime there is a license switch-up like this. I prefer a fork rather than an alternative, but if a good fork hadn't emerged, I would have moved to something different with its own technical advantages and drawbacks.
Love this, welcome back Salvatore -- hopefully it's fulfilling and fun. You authoring some new vector primitives seem to indicate to me you might be back in your sweet spot.
Getting a 100x engineer back to making new things is great for the world.
Some thoughts on vectors and embeddings and etc; there was a spate of companies that launched RAG-related "new" databases a couple of years ago, and obviously we have plugins to major databases now. I appreciate the idea that some low level tools, properly tuned, will be maximally useful. There was a lottt of overhead playing with those vector dbs, and often in testing I would just want to throw up like 10,000 embeddings and do some things with them; I didn't want to have to choose a pytorch variant in a docker image to do so.
Anyway. It makes me wonder what else would be useful to have on the AI support side. I'll look forward to playing around with the module.
Another thing that kinds of sucks about this whole "license rug-pull" kind of business is that other teams (like ours) who are publishing open-source software/tools are now suspects too.
Folk ask themselves, why contribute to this thing (MIT/GPL licenses) if there some for-profit entity involved?
Folk can't take us at face-value (I'd argue demonstrated value) and level (unfounded) accusations at us; because some other player did things "dirty".
Well, other folk wanted to pay for support/customisation and in USA you make a for-profit entity to do that.
So the corporate part of the open-source project is, nearly, a requirement.
"Folk ask themselves, why contribute to this thing (MIT/GPL licenses) if there some for-profit entity involved?"
You put MIT or GPL in the same bucket here, but really shouldn't because the difference is all that matters.
There is no "rug-pull" as you call it. What happened with Redis is what the BSD license allows and what people should expect to happen.
The combination of GPL (or AGPL) with a large enough and diverse set of contributors who keep their rights in their contributions is a proven way to prevent what happened with Redis.
It is our decision as publishers of open-source projects which way we want to go. It is our decision as contributors which open-source projects we support.
Both ways are fine, but blaming others that you regret your decision is not.
> The combination of GPL (or AGPL) with a large enough and diverse set of contributors who keep their rights in their contributions is a proven way to prevent what happened with Redis.
Also the lack of a CLA (and/or copyright assignment) because many "modern" projects under the GPL ask you to waive your rights away, thus nullifying the license. Do not contribute to them if you have any self-respect.
It is not even the for-profit thing, it is the VC, because they will be expect to make millions and millions off the project and that is not really possible with just support contracts and similar
You don't need to ask people to rely on your promises. Just make sure that you are not able to do a rug pull, and explain that. It's generally pretty easy (just don't require a CLA) but you can make it clearer. For example, clarify that you don't own everyone's copyright by writing a copyright notice which includes all of the project's contributors.
What would you feel if you did all the work, but other companies made all the money by redistributing your software? Wouldn't you find that unmaintainable in the long run?
Reading between the lines. Redis is Hurting, Valkey is making a real difference at pulling the customers away. Elastic and OpenSearch were in similar situation, so Elastic went on to change license back to (more restrictive) Open Source License.
Redis went different route by bringing Redis founder back. I wonder if they go back on their license change next or do they think Redis founder endorsing license change, despite his previous promises of Redis being Open Source forever is enough ? Time will tell.
Except this is not true: I mean, I asked to rejoin, not because I evaluated the situation of the company, but since I wanted to do more hacking / community stuff. So you see what happens trying to read too much between the lines? That you invent what satisfies your needs as a reader, but drives you away from what actually happened. P.S. at Redis they didn't expected this at all and were really surprised.
And about switching to a more open license, who knows? Maybe we will be doing that as well if it offers enough protection - I'm not in charge for such decision but... I can suggest things -, so thank you for the idea (kidding apart, I was already talking about this possibility inside the company).
Perhaps. I've seen people seen/write all kind of stuff when serious money are involved, and I also was offered to just just that on number of occasions.
I appreciate your honesty in disclosing what you still have Redis Labs stock, and assuming it is anything reasonable their value at future IPO would be much larger than any cash compensation which you might be getting as the part of the deal.
Reality is you did not fulfil (chose to or could not, I do not know) your public promise to keep Redis Open Source https://antirez.com/news/120
I hope your return will positively impact Redis as Open Source Project. Yet I'm disappointed to read your position on the Redis License - seeing cloud non compete license "basically as good as open source", as I far as I'm concern for many users which want to have software ran for them, and consume it as DBaaS it is no different to proprietary license, as it prevents competition.
> At some point my daughter, who is now 12, and is a crucial person in my life, enlightening my days with her intelligence, creativity and love, wanted to visit NYC for her birthday.
I know this wasn't the point of the post, but it was the most beautiful thing I've read all week, and really sums up how I feel about my own children. A small aside in a much longer post but incredibly humanizing and wonderful.
I'm not a christmas person. Lights are pretty and I may throw up a piece of tinsel and a reef to make it seasonal but overall not a fan of the holiday.
I went down to the cafeteria today at work and they had school children carol singers. Seven/Eight years old singing Christmas tunes. I have to say it touched me, they were really putting their hearts in to it. The warm innocent spirit of something they believed in.
I then grabbed my styrofoam tasting lunch and then fell back in to my cynical self for the rest of the day. But it's pleasant to keep memory of.
Readit News
1. Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc - and when they did that it was under the understanding that project would remain under the same open source license. It honestly felt like a betrayal of trust.
2. From a purely selfish point of view, my favourite thing about open source licenses is that they let me know exactly what I'm allowed to do and build on that software without having to consult a license. Licenses like the new Redis one leave me potentially needing to get my own legal advice depending on what I'm building on the software. I don't want to spend my time, energy or money on that stuff!
I do also see these kinds of license trends as harmful to open source generally. It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms. That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects. I'm sad about that.
(And yes, I do understand and dislike the trend of businesses building on open source without contributing back. There are no clearly correct answers here.)
I can understand that, but the thing about the BSD license is that such value never gets lost. People are able to fork, and after a fork for the original project to still lead will be require to put something more on the table. Inside Redis it was tried very hard to don't change license. For years it was some kind of "dogma", something one could not even speak about. Then after all the kind of attempts, and following the experiences of MongoDB and others, finally this choice was made. (Disclaimer: I saw the switch as an outsider, so my information is not complete about the final decisions -- I for sure know how this was always considered to avoid if other setups were possible).
However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
Redis Ltd. broke the social contract. They decided that the short-term profitability of the company was more important than the project as a whole, the community which had grown around Redis and the future of the software. Probably a wise decision from a business perspective, but that doesn't make it any less of a rug pull from a community perspective.
You're right that no pre-relicense code was lost. People could and did fork. But something far more valuable was lost: the community's trust. First they relicensed the code solely for their own benefit, now they tried to take over third-party libraries and started behaving in a hostile way towards the community forks. Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers? After all, what's the next shady move going to be?
Folks like to cite MongoDB as some great example, but Redis had significant community contributions in recent years. And AWS never used any Mongo code.
That is one side of the coin: value never gets lost!
The other side is that the BSD license is very clear what it allows. It's a good thing that there are licenses that allow what Redis did. It is also a good thing that there are other licenses which can help prevent what Redis did.
It is our choice as developers and we should never blame others for exercising the rights we granted them.
You can do this without fucking over past contributors. Just... Don't change the license. Then still do all that other stuff. They're not contradictory.
Can I "dnf/apt install redis" on my Fedora or Debian install? I cannot, it's no longer packaged because it's no longer open source.
Can I go buy a shared hosting plan and get Redis? Or a small PaaS that sits on top of AWS? I cannot, because we have decided that every hoster is now as exploitative as Amazon, regardless of their margin.
For decades we lived in a world where someone could sell you an Apache server and a MySQL instance without having to pay money to Apache or MySQL. We can change that social contract, but like all tariffs, this one will be paid by the end users, not by the companies providing the service.
Disclaimer: I work for a PaaS.
to be fair that's more an issue with linux distrib than with redis
Yeah, but the Internet community at large took care about funding. MySQL always had the commercial support leg to stand on, and Apache httpd... looking at the contributor list [1], it's a healthy mix of universities, large companies (IBM, HP), ISPs (Vodafone, Cable & Wireless), hosters (Rackspace), small consultancies and individual private contributors.
In contrast, the megacorporations are largely absent from FOSS contributions (the exceptions being Netflix and partially, where it suits them, Google, Microsoft and Apple).
[1] https://httpd.apache.org/contributors/
It's worth noting that the bulk of the code was written by antirez with only ~12 others exceeding 100+ commits [1]. And if you continue scrolling the number of commits-per-user drops off fast. It's striking given how famous the project is.
[1] https://github.com/redis/redis/graphs/contributors
It also severely sets the industry back every time one of these rug pulls happens and we have to scramble to find a replacement. Sure it might drive some minor innovation, but it also wastes a ton of resources by splitting communities and leading to tons of rewrote just to get back to a place of stability.
If so, are these trends harmful to open source? Are we not choosing between:
1. A world where all revenue in OSS infrastructure ultimately flows to a few big platform companies.
2. A world where these carve-outs are commonplace.
Meta's carve-out with Llama is so interesting because it practically calls the big companies out by name. Should there be a similar standard license for open source infrastructure?
Yes, I think there should be. The tech world is basically a monopoly at this point, and that's dangerous for a thousand reasons. The least those monopoly owners can do is financially contribute if they want to use these tools.
It's sad to me that the tech world is rallying around Valkey, which is Big Tech's fork: AWS et al are the ones behind it. We continue to give more and more power to the biggest players.
It's having your cake and eating it when you get popular by being open source and then add restrictions when you have success.
I think there should be a change to licenses where the trademark is tied to the license. You can go proprietary but you can't take back the name.
I've re-read this a few times and I'm still not sure what "harmful to open source" means in this sentence, could you expand on this a bit when you have time? (readings I considered: this will dissuade people from using OSI licenses, this will dissuade people from trying to monetize open source components, this will dissuade people from using open source components in their products all together, this will dissuade people from contributing to open source)
> Many people had contributed their efforts to the Redis project for free
This one is not directly addressed at OP but I would be interested to see what the contribution numbers are like for Redis and other projects post-license change.
In my own limited experience (project with >10k, <100k end users), I received no meaningful code contributions when the project was MIT licensed, but contributions of significant features and large bug fixes skyrocketed after switching away from it (not saying that the license change is the reason for that, just that it didn't dissuade some people who are willing to contribute significant effort from contributing to the project).
Editing this post to say thanks for the response and clarity, I don't have anything else to add!
A lot of that benefit comes from not having to worry about licenses: pick platform components with known open source licenses, build cool things with them.
I think the rise in not-quite-open-source licenses (especially projects switching to those licenses) undermines the things that I value about open source, and further encourages more projects to make those decisions in the future.
Yes, because other projects will follow the pattern of successful ones.
> this will dissuade people from using open source components in their products all together,
Yes, because now there is a very real risk that after you have invested in using an open source license, the owner might change the license on you, which makes potential users more wary of open source projects.
> this will dissuade people from contributing to open source
Yes, for similar reasons to the above.
Linux, git, Python, Postgres, etc weren’t about getting rich, but about making something cheap and easy.
The paradox of these single company backed OSS projects is somehow making a big chunk of it free/open but collecting money off of other services. To me, I’m not sure that’s worked yet. Many will even say that these companies aren’t really doing open source in the traditional sense, but acting as commercial vendors that let you look at the code.
The revised license is nevertheless a problem for component selection. Usage caveats are a landmine and thereby a coherent motivation for the Valkey fork.
I'm not familiar with what's happening in this Redis licence change.
But if it was Open Source at version N, and you built your business (or stack, etc) on top of that, N will remain forever available to you as FLOSS, not?
Is the problem maybe that ppl expect future updates, maintenance to remain Open Source? Something that, AFAIK, no Open Source licence guarantees? So, misaligned expectations?
> That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects.
It's not new. MySQL, Redhat and many others have done this for ages in the floss community.
They see this as "rug pulling". I think developers need to do a lot more of that for things to change.
I'm not seeing this being a factor in the broader community of users. Redis is still 'go-to' solution in its space. Haven't yet had anyone bring this up.
>I do also see these kinds of license trends as harmful to open source generally. It used to be that you could pick an open source project and build a business on it and expect that the project would stay available to you under those well understood terms. That's not the case any more - not just because of Redis, there are a number of other high-profile license rug-pulling projects. I'm sad about that.
I think the biggest thing is - that you acknowledge- that companies (particularly big businesses, like the cloud and service providers) build entire lines of business on this tech without contributing back, monetarily or otherwise, or even worse, try to shorehorn a project into prioritizing what they want over what may be better for the long term health of the community.
These license changes I've seen so far are all attempts to address that. How else are they able to do it with any long term success? They already aren't getting the funding they're looking for, clearly, while businesses build multi million and in some cases billion+ dollar businesses on top of the technology.
I'd argue that old permissive licenses aren't sustainable in the long run for any project like Redis
By "used to be" you mean for a brief period in the 2000s, right? Because this extremely generous open source landscape we have seen in the past 20 years were not the normal state of software for most of software's existence.
A generous open source landscape is something we -- you, I, the readers of HN -- have to actively maintain by shouldering the burden of maintaining the correctly licenced software. We cannot trust this important job to profit-making corporations.
Deleted Comment
The whole point of the MIT/BSD licenses versus licenses like the GPL is to not be limited by that.
> It honestly felt like a betrayal of trust.
It feels like total ignorance from. If such license change bother you, you should only contribute to projects that are licensed under GPL or similar licenses and that don't force contributors to sign a CLA.
I don't like current Redis license, but nobody lost any code and any contributor can still contribute to any fork that started using the last open source version.
Why not just stay on the last version with the license of your original choice?
This has been my experience too. With both "Game Programming Patterns" and "Crafting Interpreters", writing the code was a joy while writing the prose was hard work. Gratifying, but mentally draining in a way that programming isn't.
I have hardcopies of both and "Crafting" remains my all-time favorite programming book.
It's delightful, educational, and beautiful.
As far as I was aware, there are only paperbacks.
The human by comparison is more taxing to write for as your brain is the compiler and checker for the instructions of your language. You write, proof read, correct, proof read again, correct more, delete, re-write, etc. I get why AI tools for writing are in high demand. Hell, sometimes I spend what feels like forever writing some of the comments here on HN as I have to compress a lot of thought into a few, clearly written sentences.
It's sort of like trying to write a program that is simultaneously valid Perl, C, Ruby, etc.
Anyway, absolutely love your books, have the Crafting Interpreters print copy (which has been inadvertently unboxed by my friend; did want it to be still in the plastic) despite using only the website version, and looking forward to buy the Game Programming Patterns. I hope you continue to be successful in your endeavours (especially if they result in legendary books like these :D). Also, could we be looking forward to a version of yours of a CPU architecture book, a la Nand2Tetris ( ͡° ͜ʖ ͡°)?
Though yeah, that does feel awfully reductive as an argument, and leans on a lot of assumptions in Chomsky's theories. I know that there are axes where "formal" languages feel more orthogonal to "natural" languages than "pure subsets". Some parts of "formal" languages to me feel a lot more visual like poetry than linguistic in the same way as prose.
Huh, I own this in a print copy. Thank you so much for writing it :)
I do appreciate the author answering. Thank you.
I wish he'd elaborated a bit more on what he thought it was about. My understanding is that it's 100% about the license. That's certainly why I'll reach for valkey instead of redis next time I need it. That's also what I've heard from everyone else in a similar position. What else would the community split be about?
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.
I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't. We're trying to figure out our migration path right now and it's almost surely going to be Valkey.
Large vendors were never going to pay up and so it's all loss for everyone involved. I have to do work, every project that works with Redis has to do work to support Valkey now, the eventual divergence will force people to pick a side which will probably also be Valkey for everything other than the client libraries Redis Labs personally develops. It's a mess.
Open core proprietary add-one for new fancy AI features could have avoided the split and gotten you in the door with big cloud vendors willing to sell your add-on in the marketplace with revenue sharing. They did it with Bedrock and Anthropic is making bank off it.
That is the nub of the sticking point.
The new is OK for people who only care about getting things done. But for people interested in building and being part of a community, giving as well as taking, not so much
This:
You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.
something is off in redis execution
hope with this guy comes back it improves!
AGPL only slightly prevents this by forcing them to share their changes to the source. And usually this is not very useful to the community, anyway. And very little effort. And the same people scream it's an evil license. They want free (as in beer) stuff forever and it's not just the source code. It's very ungrateful of them.
The bigger issue was startups and small/medium sized companies with limited technical support and limited money to buy enterprise support or in-house experts. These are the same companies heavily leaning on managed services from vendors like AWS.
Getting a 100x engineer back to making new things is great for the world.
Some thoughts on vectors and embeddings and etc; there was a spate of companies that launched RAG-related "new" databases a couple of years ago, and obviously we have plugins to major databases now. I appreciate the idea that some low level tools, properly tuned, will be maximally useful. There was a lottt of overhead playing with those vector dbs, and often in testing I would just want to throw up like 10,000 embeddings and do some things with them; I didn't want to have to choose a pytorch variant in a docker image to do so.
Anyway. It makes me wonder what else would be useful to have on the AI support side. I'll look forward to playing around with the module.
Folk ask themselves, why contribute to this thing (MIT/GPL licenses) if there some for-profit entity involved?
Folk can't take us at face-value (I'd argue demonstrated value) and level (unfounded) accusations at us; because some other player did things "dirty".
Well, other folk wanted to pay for support/customisation and in USA you make a for-profit entity to do that. So the corporate part of the open-source project is, nearly, a requirement.
You put MIT or GPL in the same bucket here, but really shouldn't because the difference is all that matters.
There is no "rug-pull" as you call it. What happened with Redis is what the BSD license allows and what people should expect to happen.
The combination of GPL (or AGPL) with a large enough and diverse set of contributors who keep their rights in their contributions is a proven way to prevent what happened with Redis.
It is our decision as publishers of open-source projects which way we want to go. It is our decision as contributors which open-source projects we support.
Both ways are fine, but blaming others that you regret your decision is not.
Also the lack of a CLA (and/or copyright assignment) because many "modern" projects under the GPL ask you to waive your rights away, thus nullifying the license. Do not contribute to them if you have any self-respect.
https://drewdevault.com/2021/04/12/DCO.html
I have no interest in engaging with that product just to have a new pricing model thrown my way and disrupt everything.
There are some practical suggestions at https://reuse.software/tutorial/
Reading between the lines. Redis is Hurting, Valkey is making a real difference at pulling the customers away. Elastic and OpenSearch were in similar situation, so Elastic went on to change license back to (more restrictive) Open Source License.
Redis went different route by bringing Redis founder back. I wonder if they go back on their license change next or do they think Redis founder endorsing license change, despite his previous promises of Redis being Open Source forever is enough ? Time will tell.
And about switching to a more open license, who knows? Maybe we will be doing that as well if it offers enough protection - I'm not in charge for such decision but... I can suggest things -, so thank you for the idea (kidding apart, I was already talking about this possibility inside the company).
I appreciate your honesty in disclosing what you still have Redis Labs stock, and assuming it is anything reasonable their value at future IPO would be much larger than any cash compensation which you might be getting as the part of the deal.
Reality is you did not fulfil (chose to or could not, I do not know) your public promise to keep Redis Open Source https://antirez.com/news/120
I hope your return will positively impact Redis as Open Source Project. Yet I'm disappointed to read your position on the Redis License - seeing cloud non compete license "basically as good as open source", as I far as I'm concern for many users which want to have software ran for them, and consume it as DBaaS it is no different to proprietary license, as it prevents competition.
I know this wasn't the point of the post, but it was the most beautiful thing I've read all week, and really sums up how I feel about my own children. A small aside in a much longer post but incredibly humanizing and wonderful.
I went down to the cafeteria today at work and they had school children carol singers. Seven/Eight years old singing Christmas tunes. I have to say it touched me, they were really putting their hearts in to it. The warm innocent spirit of something they believed in.
I then grabbed my styrofoam tasting lunch and then fell back in to my cynical self for the rest of the day. But it's pleasant to keep memory of.