Well, I see this as great news. I've been tinkering with vector search myself and really don't like the APIs, query structures, even the embedding steps required. Anything that makes it simpler (and faster) is most welcome.
I do hope Salvatore keeps doing emulators for MCUs, though :)
Thank you Rui, my target is: API that can be learned and used under 120 seconds. I don't think more of this is needed, for the basic usage. Then there could be other stuff, but it must be incremental. Easy things must be easy.
And so forth. However there are nice things you can enable, if you want. For instance VADD has the [REDUCE] option that implements random projection in order to reduce the dimensionality of your embeddings. Less memory, and it is faster. And so forth.
Will work on it during xmas, it's quite fun.
It implements on-insertion normalization and int8 quantization. The algorithm to insert nodes inside the HNSW attempts to never leave isolated nodes and to get good quality links and so forth. More hacking needed.
yes loving this! please PLEASE be the hero we need in unfucking the unholy mess of misdirection and useless abstraction that is storing some vectors somewhere for similarity search right now
I'll try very hard to not disappoint you. The AI things I'm doing for Redis are truly low level and minimal. HNSWs rewritten from scratch in C caring about every bit of performance and memory usage optimization, with a trivial API. Embeddings are useful even if you don't like LLMs and generative AI, it is really a different field. Also I'll be doing a lot of the old stuff too, but with a more "informative" profile, that is, I'll do as I share what I'm experimenting with. And I'll handle the community. My things will not be limited to AI stuff. Thanks for your comment, I understand the sentiment.
World does need unlimited amount of software and I think it can even be mathematically proven. Amount of software required grows exponentially because every piece of software then requires even more software on top of it - just like managing security issues in al the software built, etc.
If you don't like the productivity boost AI gives programmers, how do you feel about the productivity boost that open source gives programmers?
I would argue that the open source community is responsible for WAY more of a free/cheap productivity boost for programmers than generative AI, and we've been providing that productivity boost for decades.
Open source mostly enhances devops productivity. AI directly plagiarizes. I do not see anything wrong with not having to write your own shell, but regurgitating laundered code and algorithms is wrong and should be illegal.
With AI the original authors do not even get credit, with open source they do.
If a human plagiarizes open source directly, it is also wrong. Even then, the scale of theft is limited to one person and not happening on an industrial scale.
I don't think it changes the negative business actions that the company Redis has been doing. But it likely means that Redis may actually evolve now, rather than being a static target.
I worked with antirez a bit before he left the project in 2020, and I still look fondly back on that time since he was a wonderful person and he helped me learn a lot. I wish he had considered coming to work with Valkey instead of Redis, but maybe we'll find some some way to work together that benefits both communities.
I think antirez has made very rational economic decision. For Open Source Redis/Valkey community though it would be better if he had joined Valkey of course.
Note though it is not certain he even could - the Non Compete when you have significant compensation in cash or equity can be much stronger and run a lot longer than employment related
Appreciate your kind words, and I'm very happy it was a good experience to work together, it was cool for me too. I hope there will be ways to exchange infos and hack :)
Everything we do is open-source, so you're free to take it and incorporate it back into Redis. (Although I'm more into rewriting the data structures to more efficient on modern CPU hardware). Keep some comments out in the open like your discussion about vector sets to keep the conversation going. For the record, I really don't like the vector set idea, but I'm not one to dish out hot takes on hacker news.
Thank you, I'll encourage my colleagues to take everything we can from ValKey, because this is how it works: as the BSD allowed the fork, the BSD allows less liberal licenses to take back. The magic of very liberal licenses is that: they speed up human evolution (and we tried hard to retain the BSD for this reason).
About Vector Sets: it's absolutely ok to disagree here; but what is a good thing about having multiple forks of the original Redis is that you can see it as an optimization to search for the better Redis :D The Vector Set stuff, just to be clear, was not "company stimulated", it's something that I really want and I which I strongly believe.
I suspect he is going to make a lot of money coming back to save Redis from the negative press they have been having recently as well as the threat of Valkey. I sort of have to view it in light of all the other events that have been happening to Redis.
I covered this in the blog post: no big money involved, I asked to rejoin and without a big paycheck on purpose because to be free to act you should not get too much money, otherwise it's all fake.
But if you wanted to have influence without a big pay check, why not join Valkey? Redis, the company, in your absence has gotten a reputation as a predatory company that has attacked open source projects in other to further those goals.
I want to help Redis to find a good path forward (while I respect the work of everybody). I was sponsored by this company for ages, I know the core hackers there, and they are strong and are good people. I talked with the CEO and he is very interested in finding novel ways to play, so I rejoined Redis and not ValKey.
Honestly even if Redis public image has not been stellar recently, I know the people that work at Redis, many engineers are there since the start, and I believe they have huge design abilities and can do what is needed to make Redis more useful for the community.
What motivated me was the company idea that with the license change the attitude could change significantly towards providing as much value as possible back to Redis. So merging what is super useful and has been, so far, only available to paying customers, and so forth. Also the company is interested in changing attitude. All these things made me feel that my efforts were better spend doing some bridging work between the community and the company.
The player in this context has an outsized influence on the game, the people managing the game are using their work, and contributing more to it is effectively influencing the game in a big way.
I don't really hate or care about anyone in this game, but it's a non-trivial move in the game.
Valkey is making it possible for hyperscalers to continue appropriating open source and charging fat margins to everyone else.
In a sense, Valkey is the bad guy here.
And just look at all the support Valkey is getting from Amazon, Google, Oracle, etc. They're perpetuating the problem.
The same thing happened with Elasticsearch. Unfortunately ICs without decision-making power started lambasting the Elasticsearch leadership for attempting to fend off AWS and their ilk from absorbing all of the revenues derived from their hard work.
Open source is just a commodity feature for hyperscalers. It's time we stop giving it to them for free.
This is all about power. We're ceding it to trillion dollar companies because we've been trained that "open source" is ethical. Meanwhile, we don't question the ethics of these companies profiting off of this work while charging us absurd margins. None of the hyperscaler infra is open source.
Many of the Redis developers left to form Valkey, so that they could keep working on the Open Source project they wanted to work on. Valkey is continuing a project that was released under Open Source terms, after the original company rugpulled the Open Source project in favor of a proprietary one.
Or, in other words, Valkey is Jenkins here, and Redis is Hudson.
> Many of the Redis developers left to form Valkey
What's the point of spreading informations that are not true?
I believe there is a single person that was in Redis and works there now, at least AFAIK. And this person stopped working at Redis long time ago (and was not a core developer). So I'm not understanding who joined ValKey from Redis folks.
Everybody is working at Redis: me, Oran, Yossi, Meir, many others.
> I believe there is a single person that was in Redis and works there now, at least AFAIK. And this person stopped working at Redis long time ago (and was not a core developer).
It is probably more correct to say a bunch of Redis contributors left the Redis GitHub project and moved over to Valkey.
You can see there are a bunch of contributors listed on this page who seem to predate the fork and who have continued to contribute:
> Nearly all of them work at cloud providers so they literally just followed their income stream.
Sure. And same for Redis employees who continue to work on the Redis Github project. All my significant contributions to open source have had financial incentives as well.
I know this doesn't mean much, but I spent a lot of time outside of work helping to maintain the Redis codebase. I attended our meetings and responded to issues on vacation because I cared about the community, it was more than just a paycheck for me. I don't regret doing any of that.
as much as I dislike the hyperscalers parasitising open source...
"redis ltd" the company did not originate redis
"redis ltd" was originally "Garantia Data": a company that offered hosted redis as a service
fundamentally they are/were doing the same thing as AWS/Google: taking an existing open source product they did not originate, and selling hosting for it
they may have hired its creator (several years after he wrote it), and since then changed their name to "redis", but they're not any different to GCP/AWS
other than the complaining about others more successful business models
Yes, past Redis venture provided me covered enough that I can avoid trying to maximize the money side. Money still useful of course but one has to balance I believe.
No one organization in the world funds the LF in a way that is more than 1% of the total LF revenue... it has nearly ~2000 members across the world. You can usually get some of this from the LF Annual Report: https://www.linuxfoundation.org/resources/publications/linux...
> Why isn't the entire stack of AWS infra open source, again?
This line of argument is untethered from reality.
The Linux Foundation actually is the parent of the Cloud Native Computing Foundation (https://www.cncf.io/about/join/), which actually is infrastructure for cloud services: containers, envoy, etcd, helm, istio, Kubernetes, prometheus, etc.
> This line of argument is untethered from reality.
You had a business that was acquired by Amazon. I don't know if you're giving this a fair assessment.
When the copyright holders of large open source infrastructure projects want revenue from their hard work, Amazon forks them or provides funding to their direct competitors.
Amazon can strategically launch free and open source competition to commercialized open source products as a means of keeping more of the cloud spend budget for themselves.
The hyperscalers want to commoditize anything that impinges upon their margins. The software should be free, it should run on their clouds, and it should lead to increased cloud spending. Other companies shouldn't dip their hands into the pot.
Moreover, hyperscalers get to hoover up "managed" versions of open source software and collect even thicker margins. Redis, Elasticsearch, etc. fly in the face of this strategy, which is why they attack it so relentlessly.
The Linux Foundation and CNCF serve its industry contributors. The microservice ecosystem is booming business for AWS, Azure, and GCP.
I don't see how this is "untethered from reality". This is cutthroat business, and it's how the trillion dollar companies throw their weight around.
If you build open source infrastructure products and don't have an anti-cloud provision, you'll get picked clean by the hyperscalers.
As sibling comments have said, you can pay per month to use the web interface, pay for use of the API via self-signup or you can even use them via openrouter.
Claude is available for free (with usage limits) if you register for an account. Then you can pay for a $20/month Claude Pro account as an individual.
You can also create a paid API account as an individual and use it via their API, which is almost certainly cheaper than the $20/month Pro account for personal use.
I use the Pro account because I really like the Claude Artifacts and Claude Projects features.
Welcome Back. Antirez! ( Surprised This blog post is submitted just 2 min after it was posted )
I am wondering if Valkey has moved so far off from Redis the codebase couldn't be merged again? I am reading the top contributor to ValKey are now from Tencent Cloud, Google, Amazon and Ericsson.
Could someone help with me with SSPL, is it essentially AGPL v3 except instead of releasing the source code only you have to release the whole system that is able to run the services you are currently operating on top of ?
Just wondering these things from the sideline. As I am still on the memcached camp.
Hi ksec! Thanks. ValKey and Redis are not so different codebases so far, but I have the feeling they will diverge more and more. I hope that at least at protocol level they will stay compatible, to be able to use the same clients. I doubt the projects can be rejoined, because the backers have different goals. Amazon / Google / Alibaba / ... wants to keep using it without any revenue sharing, and Redis instead does not want Redis to be sold SAAS style since the cloud three-poly makes it very hard to penetrate the market without any agreement. I'm not a business person but this is how I see the current matter.
You have to release the whole system under the SSPL. So there could be a reading where you can't use Linux, you can't use systemd, you can't use glibc, etc.
I am a big fan your work, including your lua c64 coding thing which actually was a great educational tool for my small cousins and for some friends. Also works well on the go. Just wanted to say that.
I appreciated a lot reading your comment. I feel silly sometimes when I use months of time to write something like LOAD81, I question my sanity, but then I see that other people had some good time with it and I'm so happy: and also I'm sure that I used my time in the best way.
I for one partially wrote a few mobile games with LOAD81 ; I was travelling and only had my Pandora with me; I wrote all the logic tested them all out with load81. Of course I had to actually get them on a mobile platform device and create a better UI, however all the logic and most of the UX was all done in lua on load81.
Given that you probably already have retirement-sized exit from Redis. Isn't it more liberating to start something completely new? Or maybe forked Redis as the foundation of something new? Is there a need to re-join the old company?
That's a good question. The problem is that: I would end doing something in the vector search space probably, or other stuff that are tangent to AI. I can do the same but in public, as examples of hacking with this stuff, to share with the community. In the process I can add a solid vector indexing capability to Redis. It looks like a nice way to continue hacking.
From the blog post, looks like he contemplated that (I'm sure that while playing around with code, he would've thought of that) but ended up going in another direction. You can disagree, but you've got to respect his decision to try and do what is best for him, and what he believes is best for Redis.
Is Claude really that much better than ChatGPT? I Use ChatGPT Plus on a daily basis and have no complaints but is it worth cancelling it and get one for Claude?
If you find ChatGPT useful, pay just one month of Claude AI and use both. I bet you'll discover that Claude AI can help you a great deal more. If that will be the case, you gained a much better AI assistant. Otherwise it's just 20 bucks... For me the difference is huge.
I have used Claude(Free) for coding and architecture-related questions and found it pretty solid but I found chatGPT a generalist LLM that is good at many things. Is Claude the same? Or you found Claude better for coding related tasks?
I think both are really capable. However anecdotally, I notice myself doing way less of the "annoyed, cancel response, extend prompt instructions, regenerate" cycles with Claude as compared to chatgpt.
Also, I am not sure if it has my writing style preferences saved somewhere, but Claude uses the terse style I prefer to read explanations in, without me needing to mention it. ChatGPT can do it too but it needs to be prompted lest it do the whole "repeat question, bullet points, summary" ceremony. ChatGPT gets really annoying when you have do the "slightly more detailed, slightly more terse, there we go" ceremony as well. For similar reasons, I prefer it for code.
One place where ChatGPT absolutely takes the cake though is mathematical proofs heavy with symbols. Nothing else comes close in my experience. It's also better at latex typesetting (seems to be more fluent with common packages like amsmath).
We use both, in my anecdotal experience it depends on what you use them for. The engineering teams which build solar plants use them as “an extra set of eyes” for increased quality control, and they chose ChatGPT. It discovered something to do with cable sizes and efficiency which ended up saving/making a lot of money. I’m sorry I can’t be more precise than that, but I know they had a much better result rate with ChatGPT. For my team which is software development, we favour Claude. It’s obviously rather anecdotal but it has been much better at Go than ChatGPT. For other languages like Python I don’t think there is any real difference. If you feed them both the same prompt they’ll often give you an extremely similar output, and neither will consistently be better than the other.
So I think it’s mainly to work with the one which works for you. I’ve seen some of our more junior developers first use Claude and then ChatGPT to refine their output, or the reverse.
I was in the same boat. I gave Claude a try, just to see what I was missing, and I ended up never returning to ChatGPT except to generate pictures (which Claude can't do). Give it a try for a month. It's worth a shot. They have improvements beyond just generally being smarter. For instance, Claude can _edit_ a prior code block rather than just emitting a new one. It can build React components and show them to you, rather than just giving you the code.
For writing code, I've found Claude far better at conventional/framework based code. I've found ChatGPT better at reasoning about more complex/nuanced code.
As other commenters have said, that is just my personal opinion, I have zero evidence to back that up lol
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.
Redis remains my favorite database. I've had the opportunity to work extensively with it, not only professionally but also through open-source projects like redis-dict[0], a Python dictionary with Redis as the backend.
How can we follow your progress on the vector set feature?
I really appreciated the section about OSI licenses as someone who this year stopped using them entirely for new work.
(Snippets from the article below)
> I wrote open source software for almost my whole life. Yet, as I’m an atheist and still I’m happy when I see other people believing in God, if this helps them to survive life’s hardships, I also don’t believe that open source is the only way to write software.
> Moreover, I don’t believe that openness and licensing are only what the OSI tells us they are. I see licensing as a spectrum of things you can and can’t do.
See, I read that and immediately was reminded that I don't exactly love the OSI being the one true definer of Open Source... but somehow the only people who ever argue that immediately try to use it as an excuse to pretend their stuff is open for marketing reasons while avoiding actually giving users the same rights. Besides, it's not that "openness and licensing are only what the OSI tells us they are"; it's that the OSI and FSF and DFSG all agree.
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.
Very exciting!
I sympathise with the Redis "lego" way. But don't you think that hybrid search ha meaningful use cases? E.g searches that combines BM25 or piplned search in more sophisticated way than simple filter + knn / hnsw then filter?
Or maybe its more for a search engine than a cache
I think that hybrid is useful in many contexts, but that providing hybrid as a bundle with other filtering techniques, API-side, is not necessarily the best way. Just a trivial example, you want to filter by documents year for similarity. With Redis vector indexes you didn't even care about hybrid, you create different keys for different years. This is the usual Redis tradeoff, it's very similar to the past but applied to a novel field.
However I don't deny that in the future maybe, if elements of vector sets happen to be JSON documents (maybe just with the attributes you want to filter with, and a document ID), it may be useful to have VSIM options to filter by such scalars.
> more extensively thanks to Redis Labs later: a freaking Robin Hood of open source software, where I was well compensated by a company and no, not to do the interests of the company itself, but only to make the best interests of the Redis community.
Governments should do this and tax companies to pay for it.
Re: vector embeddings, two projects I've had recent exposure to--Memgraph and FalkorDB (previously RedisGraph)--are implementing similar functionality. I think the lego approach is really awesome, I wish this concept was more broadly adopted. All that is to say, this seems exciting!
> 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.
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.
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.
"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!
There are only paperbacks. By "hardcopy", they meant "printed".
I sell print editions through Amazon KDP and IngramSpark. Amazon is the lion's share, so I designed the print edition based on the formats they offer. At the time I started working on it, KDP only supported soft covers. They added hard covers right as I was finishing the book, and I didn't want to have to go back and redo everything.
I have to admit that "Crafting Interpreters" is pushing the limits for what you can get away with on a soft cover. When I first started writing the book, I expected it to be (much) shorter, but I just estimated wrong.
If I had a time machine, I might go back and tell myself to print it as two separate volumes.
I'm not sure how these services work, but are you planning to offer hard covers as well for a "next print"?
I've had my eye on Crafting Interpreters for a bit now, and I don't mind paying extra for a nicer version — especially if it's going into the pockets of an independent writer.
If I do a second edition, I'll probably think about it then. I don't have any plans to touch the book any time soon. I worked on it every single day for six years, so when it was done, I was really ready to be done working on it.
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.
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.
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.
This type of genuine openness mixed with the excitement of passion is so joyful to read, especially from a high achiever with strong technical capabilities and a history of business success.
Salvatore is definitely high on my list of role models.
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.)
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).
the issues of sspl have been frequently and loudly been brought up previously, and nothing has happened. just to reiterate, this section is ridiculously expansive:
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. of course none of the major sspl-using vendors are even pretending to themselves to follow these rules.
sspl would be much better license if it just simply forbids providing services, instead of hiding behind this thin veneer of fake copyleft.
> You can even still sell Redis as a service if you want, as long as you release all the orchestration systems under the same license (something that nobody would likely do, but this shows the copyleft approach of the license).
note that this is not right, the "copyleft" is not limited to orchestration systems, it covers all programs that you use
I believe that the original reason why they didn't just say "you're not allowed to provide this program as a service" is that MongoDB were trying to get SSPL approved by the OSI. The OSI didn't approve it because as you mention, it's basically impossible for a cloud provider to actually attempt to comply with the SSPL. Not only would they have to release the code to all software used to make the program available, they would have to do so under the SSPL. I'm not sure why MongoDB didn't change the wording when they gave up on getting the license classified as "open source".
> it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere.
It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL.
I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure).
I'm sorry, but how is this a good answer? If you really only care about "two/three users in the world" and don't want users to worry about legal implications, why not explicitly write that in the license?
It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will not rule on what your feelings are of what the license was meant to do but instead what was actually written and agreed to. That's why an existing, well-understood and symmetrical copyright license is going to beat out weirdo "business" licenses any day, and why they will never be considered OSI-compliant, which is fine, because if we all really hated big tech they're already allergic to the AGPL anyway.
I know I'm not going to score any points by disagreeing with you here of all places, but I genuinely wonder if you really do believe this or if you mostly just don't care to actually confront the reality.
This whole thing could be a nothingburger forever, or, alternatively, Redis, Inc. could some day be acquired by Oracle. Absolutely no way for any of us to know for sure. Unfortunately, that leaves me with little other option but to stick to the forks.
> Redis, Inc. could some day be acquired by Oracle
This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
I personally have wondered if Oracle's behavior with MySQL is partly motivated by the fact that if they try to rug-pull it will most likely just push all of the cloud providers over to MariaDB anyways, which has been doing just fine, and I think is already supported by Amazon RDS anyways. Ultimately I am totally fine with a fork-heavy ecosystem, the only thing I would erase if I could is the normalization of signing CLAs, as I think they make the normally-symmetrical prospect of contributing to open source projects highly asymmetrical, and the consequences are not always so obvious to people.
MariaDB is one of the biggest ironies to me: it was started because people claimed Oracle was going to do Oracle things with it, and somehow make it not open any more.
What actually happened is:
- Oracle has just made MySQL better, and continues to release new tooling (e.g. mysql router) for it under the same license (gpl2).
- MariaDB releases the bare minimum database engine under the GPL, and uses closed licenses for the tooling which is, to quote them: "an essential element to any production database environment".
I wouldn't really put too much weight into the marketing speak, MariaDB feels like the same MySQL offering that always existed, at least to me (and I do run it in production, albeit only on a small scale.) And MariaDB has done plenty of work that is available in the open source product: performance improvements, new storage engines and so on. The only thing that's surprising is that MySQL continued to do the same.
I don't think what MariaDB is doing today is what everyone was really worried about Oracle doing. Rather, Oracle simply never did what everyone thought they would. Personally, I think MariaDB keeps them honest, and if MariaDB ceased to exist as a serious alternative there is a good chance the lawnmower would fire back up.
Though who knows. Maybe Oracle is different. However, I would prefer not to waste the openness of my mind. I reckon if they thought they could pull the rug they would do so.
I wasn't suggesting it's the exact same scenario, but it definitely seems a little disingenuous to create a fork of something that you chose to sell, and complain (https://web.archive.org/web/20201003111459/https://www2.comp...) about it becoming "open core", only to then make everything you do a paid product with the one exception.
That's before we get into his claims about maintaining drop-in compatibility "as long as MySQL has a larger user base than MariaDB".
MySQL and MariaDB have diverged over the years. They each have some interesting major features that the other one lacks, and there's an ever-growing list of incompatibilities between them.
Amazon RDS does offer a MariaDB option, but Amazon Aurora does not. And other clouds often don't offer it. As far as I can tell from a quick search, Google CloudSQL does not offer a managed MariaDB product. Azure offers one, but they're officially retiring it next year.
This discussion is also a bit ironic because MariaDB created the BSL (for use in their proxy product), which is typically attacked alongside SSPL in these types of threads.
Not taking sides here, to be clear. I use both MySQL and MariaDB and am glad they both exist. And personally I have no problems with BSL (or SSPL etc) software, since I am not a cloud hosting provider.
I would like to clarify since I am one of the people who is always present in these threads debating these licenses:
I think these licenses suck compared to even kind-of-bad open source licenses, like AGPL, though some suck more than others. For example, the SSPL is a poorly-conceived liability nightmare. BUSL, on the other hand, may not be much better, but it is pretty interesting. Software that is BUSL today is theoretically open source eventually. As long as this holds up in court, it is an intriguing alternative to other "business" licenses.
However: it was never about this. My complaints always center squarely around two things:
- One, deception. If you release a product and you call it "open source" or otherwise try to imply it is open, but actually it is not open source, this is bad. This is bad because like it or not, people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this while also deceiving people into thinking it's the same thing they've come to know.
- Two, violation of expectations. I get that the contributions made by open source contributors rarely compares much to the contributions made by those employed at companies, but even still, the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to, and I think that this aspect of CLAs is troublesome. That aside, I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day. Don't get it twisted, I think Redis is great software that can stand on its own, but it doesn't matter: it didn't. It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
However, despite that... I am not ideologically opposed to closed-source, source-available, or any other kind of software. It's fine. I use software that is "non-free". I pay for software. I pay for JetBrains Toolbox. This does not bother me and is not my issue. It's literally just those two things that bother me.
So why don't I care about MaxScale? Honestly, it's pretty simple: It's outside of my purview. It may very well be an important project used by a lot of people, but it just doesn't seem like it was ever a huge open source project: according to GitHub, it has a total of 39 all-time contributors, most of which seemingly after the relicensing, versus Redis's 729. I've never used MaxScale and I'm not sure what depends on it. If someone else is mad about this relicensing, I do not necessarily blame them, but I just simply have no dog in the race.
MySQL and MariaDB themselves remain as open as ever, and that's really all most people are concerned with IMO.
> people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this
That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
> the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to
It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
> I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day.
A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
> It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
But I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
> That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
> And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
As far as I can tell, the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998, so while it does sort of sound like a generic term, I don't think they were conflating much with any existing term in widespread use. The OSI themselves[1] also seem to suggest that they believe they were responsible for making the phrase ineligible for trademark:
> Ironically, we were partly a victim of our own success in bringing the “open source” concept into the mainstream.
> It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
Personally, I only contribute to projects with CLAs when I have pretty much no other choice, due to constraints outside of my control. Example: I have begrudgingly made contributions to Qt because I have no control over the upstream that KDE uses.
To be fair, I guess this does technically still count as a mutually beneficial relationship, but to me, it feels a lot more like a toxic one. But yes, that's true.
> A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
> So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
Well, from my perspective, a perfectly-reasonable, common assumption became an unreasonable without much warning.
As much as people have misgivings about how Red Hat has handled RHEL, they still proved for a very long time that it is possible to run a sustainable business even when the primary thing you do is work on open source projects. They are not alone: there are others. Off the top of my head, Collabora, Ltd. is often right alongside Red Hat. I think all of the misgivings people have with Red Hat are...
You've made a lot of great points above, more than I can reply to, so please excuse my cherry-picking of just a few in my response here.
> the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998
There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.
> a perfectly-reasonable, common assumption became an unreasonable without much warning
In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
> In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
> ZIRP led to all sorts of unsustainable businesses...The company needs to recapture some of that value to remain in operation.
Absolutely 100% agree with all of this. VC money got real silly for a minute there, like actually investing dollars on the basis of github stars, but now the party's over and it's just about hangover time. A similar thing happens when you inject a bunch of temporarily abundant food into a closed ecosystem. You get a big spike in population growth followed by a really bad time.
> There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.
Thanks for the link. I'm a bit blown away. I believed the OSI story, because many major open source figures had endorsed or been a direct part of the OSI, so I didn't think there was any reason to doubt the veracity of what they were saying, and I never saw any direct contradictions, personally. However, the evidence is pretty damning. The OSI did not coin the term open source. Wow.
I guess it's more tangential since, either way, for better or worse, they won. But, I guess it is time to stop repeating that falsehood.
> In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
That's fair. I think from my perspective, it feels like it's been rapid because it's only been a few years since it really kicked off, whereas architectural decisions to depend on a database or cache lasts a long time... I'm pretty sure software I've written 10+ years ago at companies using Redis is still in production.
> Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
> Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
> I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
It's possible that nobody ever really planned it. I honestly don't believe Hashicorp or Redis, Inc. ever planned it. That said, every company that executed one of these re-licensing efforts does have something in common: they all reserved the right to do so from the beginning. I'm not sure if they did so with the intent to ever actually use it, but I'm sure it had to be a consideration. Otherwise, why bother with a CLA over something more lightweight like a DCO? (Admittedly, I already answered that to some degree. Though, there are alternatives. My understanding is that the Apache Software Foundation CLA allows you to retain copyright ownership while still achieving most of the other functions of a CLA.)
Ultimately, I agree with you 100% regarding ZIRP. Even I, someone ...
A cynical view is that it's not just 2-3 providers, its any competition to their cloud-hosting business. See for example the recent wordpress drama, which concerns a small competitor.
SSPL and related licenses are ambiguous and scary enough to ward off anyone potentially competing with the copyright owner, and I doubt that's seen as a downside.
This is a really good example of why software with a license that is basically "this could hurt you but, like, trust me bro" isn't worth building with/extending/learning. It feels a LOT like a landmine waiting to detonate.
Even if I'm doing completely non commercial work I never ever ever will want to productize in any way I'd rather build my skills and familiarity with something portable (and I don't want to have to remember when I can and can't safely use each part of my stack). Anything else is just asking for a future nightmare.
The oracle and wordpress stuff recently are devastating. Can you imagine having to grind your entire company to a halt looking for anything that uses anything that uses anything that uses redis/java/whatever?
I'm an engineer. I can't justify a fixed amount of upside for an unbounded downside if I ever get on some stranger's bad side for whatever reason.
This feature could actually be the overwhelming value of acquiring the copyright. When trillion dollar companies go to war with each other this kind of thing is a fantastic weapon in the arsenal.
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.
So the entire license is just a bad faith trap? I could see it being used that way, potentially, but I don't believe that's actually Confluent's, MongoDB's, Elastic's, Hashicorp's, or Redis Labs' intent. In fact they've all explicitly stated the opposite. Are they all lying?
I don't think it's in bad faith. A lot of people still believe that they have to pay one of AdaCore/Baylibre/Embecosm/Red Hat/SUSE/Wind River if you want to use GCC commercially, to cover GPL-related risk.
"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.
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.
> Yep. It is still a bit ironic that the community rallied behind Big Tech instead of a small startup though. Just saying.
The community rallied behind the project that ensures the software they care about remains free and open and available to all without the risk of being blind-sided.
Redis from Redis Labs, available under a choice of its own license or the SSPL, is pretty close to truly open-source, IMO closer to it than the BUSL, which is another source-available license. It is pretty similar to the AGPLv3, and they even credibly applied to get it OSI-approved.
What it isn't close to is the original license, which is a permissive open source license.
The license switch-up is why a fork was needed. Matrix did a similar thing with the AGPL which alas, doesn't have a major fork. https://element.io/blog/element-to-adopt-agplv3/ Although it's technically still open source, they didn't do right by the contributors to it.
Every license is a unique snowflake, but if you're going to stay sane and get on with your life you need some categories and lines. Redis is not available under a license that is open-source in any of the usual senses - not OSI-approved, not DFSG-compatible, not FSF-approved. That is a big deal. Matrix remains open source under a license that meets all those criteria. It's not a technical distinction, it's the line in the sand that stops open-source from being whittled away to nothing.
If the new license is so similar to the AGPL, why did they not pick AGPL as one of the license options in order to keep a well known OSI-aproved license?
I hate that people feel the need to so strongly attach the generic term open source to Open Source InitiativeⓇ OSI Certified™ license's marketing (anti Stallman) propaganda as the one and only true open source. Redis' license is open in all the ways that matter.
OSI has nothing to do with being anti-Stallman. (I think the most anti-Stallman person is, unfortunately, Stallman himself, having done so much to destroy his own reputation.)
Even Stallman would agree that nothing can be open source if the freedom 0, freedom to use software for any purpose, is not provided. SSPL does not grant this freedom.
That’s a nice way of looking at it. It’s quite an influential project. I’m just now thinking of taking more direct inspiration from it for a micro-library for webassembly.
I wish you success in Redis Labs and thanks for Redis. In my other comment I said I never considered using Redis under the new license, but I didn’t say that I never would consider it, and I think I would if I found myself on a project that needs a key value database with enterprise support or more bells and whistles. I think it has its place, and to me it is an awful lot like postgres and EnterpriseDB, especially if Redis Labs gives its blessing, directly or tacitly, to adding this new vector type to valkey.
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.
It's not an error at all, Simon! Because different setups in the past lead exactly to the scenario that you depicted. Examples: projects that requested signed copyright transfer for each patch (even GNU projects required this). But also what is more insidious is that very complex projects, while sometimes BSD or similarly licensed, were made completely proprietary (and not under the MongoDB / Redis circumstances, but just to turn proprietary for other reasons) but they were so complex internally that basically you can't do anything with the code, without paying like... 50 engineers to study it for six months. So it is an actual danger, but not in the case of BSD + projects that have an acceptable barrier to entry to be understood, fixed, modified, ...
Note though, the code is not Music, it rots quickly without maintenance. The "social contract" of contributing the code is what it will be maintained by collective community, otherwise many companies would just keep it as private forks.
It is wonderful thing though, with Open Source, people can band together and "pull Valkey" to create well maintained fork based on all those past contributions
That may be true of node.js codebases, but last time I checked Redis was written in C and only depends on ISO and POSIX standardized stuff. I doubt there's been any leftpads that have broken the old versions by now.
Which makes rot a good metaphor actually. The DNA of a tree which becomes infected with a new mutation of a fungus didn't change, the fungus did.
Code in which a vulnerability is discovered is in the same position. It's developed a susceptibility to a new force malevolent to its purpose. It doesn't have to change to rot, it suffices for the world to change around it.
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?
It is really hard to believe that no one defends antirez&co as protecting themselves from greedy overpriced SaaS businesses who were parasiting others hard work. What about them saases breaking a social contract of giving reasonable prices adequate to the effort put into a product (or a wrapper around the product)?
Erm I am not sure if I was understood correctly - I meant legal consequences from the perspective of redis guys on one side, and saas guys on the other side..
One simply can't admit that they both were doing a valid thing
Yeah, this is weird. The one restriction is one you probably dont care about because you're not amazon or azure yet some people still freak out like youve taken their toys away.
It's not that weird. With a FOSS license, I know I can use a program for anything I choose to and the terms will never change. I might launch a startup with a friend tomorrow using a package and complying with its license terms, and a million dollars later we're still legally entitled to use it.
Adding constraints later is a non-fallacious slippery slope. The restrictions Redis added aren't directly onerous to 99.999% of users, but now the world is divided into people who are allowed to use it at will, and people who can only use it in certain ways (or not at all). That's an enormous change from a FOSS license. And if they change it today specifically to lock out Amazon, will they change it again tomorrow to lock out my startup? The thing is, now that they've established precedent, there's no way of knowing what'll happen later.
Again, I know I can use GPL or MIT or BSD software for anything I want as long as I play by the exact same rules as everyone else. There's nothing that says you can use it but I can't. The difference between Free to non-Free is vast, even when I'm not affected (yet).
Lots of people defend these licenses on exactly those grounds. I, too, find it pretty mystifying that this seems to be a minority perspective here. At least this seems to be the case among the people who speak up when this comes up here. It's hard to know if there is a less noisy majority who feels differently about it.
I think the "silent majority" is just fine with this change. The OSS "extremists" will certainly be the noisiest about this - everyone else will continue on with life as usual, especially if they have an understanding of the concept of business pressures.
If you just call SaaS "hosting" does that change your view of things? Because I remember when commercial hosting for free software was actively encouraged.
> But something far more valuable was lost: the community's trust.
But before that the community turned its back on Redis Ltd., when it let those cloud offerings from others thrive. Once the “community” got that going, these consequences were inevitable.
Open source is a gift economy. Receiving a gift does not form a social contract that entitles you to future gifts. It is not a "rug pull" for someone to stop giving you gifts. The old versions of Redis are yours for all time. No one can take that away from you. In fact, Redis is still giving you gifts to this day, just with a different wrapping. The new license seems perfectly reasonable, given how much companies like Amazon have exploited the gift economy to the point where it threatens these startups survival.
> Open source is a gift economy. Receiving a gift does not form a social contract that entitles you to future gifts
I think op was talking about contributors, who essentially gifted back. One might take offense if they were exchanging gifts with someone, and they open a pop-up store and sell what was gifted.
Also, it's also a tiny bit hypocritical to expect revenue sharing with Amazon without doing the same for contributors.
Even without a CLA, Redis was originally licensed BSD. Releasing code under a BSD license is making a promise that you are OK with people using your code for commercial purposes. If you as a developer express personal feelings of dissatisfaction that someone is doing with your gift what you gave them permission to do, in such a way that could be construed as reneging on your promise, then that would make you dishonorable and untrustworthy.
Well in this case, antirez literally promised[1] they wouldn't change the license of the core away from BSD, and then Redis Labs did just that, and now antirez is speaking favorably of that decision.
That post was from literally thousands of days ago and seems to be in relation to some confusion at that time.
Honestly to me you can see the tensions that led to the license change in that post. It’s largely consistent with what antirez has said in the post and in this thread.
Ok so just because something is in the past it's become irrelevant? So no promises are ever worth trusting? The creator of redis LITERALLY said "Redis will remain BSD licensed". And it's no longer BSD licensed.
You can try to be a smartass and add random caveats but that's not how language works.
Imagine if everyone thought like you did: "Sure I promise to do X" (not saying that I mean for the next 5 minutes and will then ignore my past promise)
The post title in its original context is clearly referring to the confusion discussed in the very first sentence: "Today a page about the new Common Clause license in the Redis Labs web site was interpreted as if Redis itself switched license." The title is saying that Redis core's license was not switched to Common Clause at that time in 2018. That's all. It is not titled "I promise that Redis will remain open source forever".
> This is not the case, Redis is, and will remain, BSD licensed.
True, he doesn't explicitly say for how long, but I don't think it is unreasonable to read "will remain" as "will remain indefinitely" and not as "will remain so until we change our minds".
> I don't think it is unreasonable to read "will remain" as "will remain indefinitely"
That's a reasonable interpretation. But it involves an assumption on behalf of the reader, of words that are not there. I think it's a stretch to consider that specific post a "literal promise" by Antirez.
That said, I just did more research and must admit I am completely wrong with regards to the bigger picture there. My genuine apologies. In the HN commentary on that same post [1], the cofounder/CTO of Redis Labs (Yiftach) apparently made a much more direct statement that "Redis remains and always will remain, open source, BSD license". Due to use of the word "always", that I think can unambiguously be called a literal promise that was broken by the Redis company.
People sometimes change their mind about decisions over time. That isn't the same thing as breaking a promise. You can infer a promise from any declarative statement, but that doesn't mean your inference is correct.
> Releasing code under a BSD license is making a promise that you are OK with people using your code for commercial purposes.
That's just a microcosm of the larger issue, isn't it? Contributors : Redis :: Redis : AWS - Redis gave Amazon the permission to host and make money off of Redis, but Redis was evidently salty about the state of affairs. I think contributors have reason to be salty too.
Cannot speak for the community, but I'd assume that the right thing would be to handover Redis brand to a FOSS foundation.
Anything else just complicates things, like we see today, where Valkey and others are referenced as being Redis compatible (at least as far as RESP is concerned), and we either have specific clients (such as valkey-go), or existing Redis clients, that seem to want to maintain compatibility with most (all?) of them.
I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
It's honestly pretty horrible that a group of people can take centuries of man hours away from the community and tell the community to kick rocks when the software they're stealing would NEVER NEVER NEVER have had the traction it has if it were not OPEN SOURCE SOFTWARE TO BEGIN WITH.
There is a rash of thefts going on in broad daylight, and I think people need to start litigating. Its obscene and soulless and doesn't belong as an acceptable thing to do in society.
It is absurd to call this license change stealing when the previous work is still available under the original license. This is more like someone who is giving to the community, still continuing to give, but with a slightly more strict license. Do you expect someone who is doing philantropic work, gets contributions from others, but later becomes less philantropic to change their name?
> NEVER NEVER NEVER have had the traction
There is plenty of even closed source software which has traction in many domains, let alone software released under a license which as anti-rez points out allows the users to freely run their websites on redis, modify and redistribute code etc.(with the exception of running hosting services like Amazon).
For instance, it would be amazing and a great improvement if there was a top-quality CAD program with a similar license to Redis.
You clearly feel very strongly about this topic; out of curiosity, are you a Redis contributor? If so, was your contribution done via your day job (paid time) or was it an outside/independent contribution?
> I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
Who should enforce such a requirement, and under what mechanism?
Open source licenses are copyright licenses, whereas product names are trademarks. These are separate legal concepts. Meanwhile "the community" isn't even a legal entity at all. As I understand it, there's nothing to "start litigating" here, and no one to litigate it.
Are you proposing that the OSI should change the OSD such that open source licenses must include mandatory trademark assignment to an independent nonprofit foundation? That's a rather extreme view if so.
If a company's survival is threatened by people using its open-source software, then maybe it shouldn't be open source. Open source software (to me) says I should be able use the software for any purpose, including commercial ones.
I agree. It seems that "open core"[1] is a failed experiment. I'm hopeful the idea will be replaced either by governments being smarter about the computers, or companies agreeing to sponsor foundations, or... something. But clearly taking venture investment to build OSS and turn it into a profitable enterprise is an idea that has been thoroughly shown to be flawed.
[1] aptly named if you think about the nuclear power analogy :)
It’s the entire premise of public goods, and the sustainable funding model for that would be through government funding or funding of open source foundations like the CNCF. For example, the IETF standards body is founded by the global charitable organization the Internet Society. How do we continue to build on this public goods funding model for projects like this?
> seems that "open core"[1] is a failed experiment.
I don't think the jury is out. If you look at nginx, you won't see a lot of complains over nginx plus. The nginx brand still has a lot of goodwill and a few open source projects seem to be peacefully building upon it without any issue.
That isn't really the case here. It didn't start with a company. The company came along independently, effectively took control of an open source project that was already well established. They found that support alone wasn't enough to be profitable on and have been lashing out at the community that built around the original project, including independent opensource clients.
It's not that the company shouldn't have the code as open source. The company shouldn't exist in the first place and we're all suffering for it.
> Receiving a gift does not form a social contract that entitles you to future gifts.
Certainly, but if you exchange gifts with someone every christmas, have been doing so for a decade, and they suddenly stop giving you one, or give you an unpolished one where they previously cleaned it to a shine, you are perfectly within your rights to be a bit miffed at that, and withold your own.
People can say the new license is reasonable (and by all reasonable measures it probably is) but that’s not how it feels, and that’s the important part.
Open source is not a gift economy, and is in fact a different, and long established social contract. Never has this misplaced metaphor been used to describe open source, nor do the contributers demand any return that amounts to an "entitlement to future gifts".
It absolutely is though. Do you not see any value in bug fixes? Do you think software never needs to be updated? We all know security updates are crucial, and pretending you can just run the old version forever is insane. If I contributed to redis in the past I did so under the assumption that I was contributing to a product that I could actually keep using. But instead they took all those contributions and gave the contributors a huge middle finger by denying them security updates and fixes.
And sure, you can say "just do the bug fixes yourself". But if I knew that was going to be the case, I'd never have bothered to contribute.
> If I contributed to redis in the past I did so under the assumption that I was contributing to a product that I could actually keep using
It sounds like you also have an assumption that the maintainers will spend the effort to maintain your contribution forever, after already spending the initial effort to review and integrate your contribution. This all takes time and money, which has to come from somewhere.
You're asking "Do you not see any value in bug fixes? Do you think software never needs to be updated?" from the contributors' and users' point of view. But the same exact issue exists from the maintainers' point of view.
A lot of people in this thread are commenting as if an open source contribution is a purely altruistic act by the contributor which then solely benefits the maintainers. That's far from the case in reality. Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
> It sounds like you also have an assumption that the maintainers will spend the effort to maintain your contribution forever, after already spending the initial effort to review and integrate your contribution. This all takes time and money, which has to come from somewhere.
Correct, that's generally how open source works. You make a contribution, they merge it, and then the assumption is that it is maintained by the maintainers. You seem to act like this is an odd assumption, even though it is and has been the reality for pretty much every open source project ever.
> But the same exact issue exists from the maintainers' point of view.
Right, it's their "job". Maintaining the software. It's pretty much in the name. That's what happens when you accept contributions. They get merged into the software project, and then you (the maintainer) are responsible for maintaining it, or removing the functionality in a subsequent release. That's why code review happens where you consider the maintenance burden, and features sometimes don't get merged.
If this doesn't sound appealing then don't become the maintainer of an open source project.
> Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
Sure, and they could've kept it private so it only benefits them and/or their employer. But instead they chose to open source it in the hopes that
1) The maintainers will maintain it
2) It might benefit someone else
That's the whole deal. You're essentially trading your contributions for future maintenance.
I'm well acquainted with open source maintenance; one of my open source projects has been downloaded over 2 million times, and another is imported by over 8000 other repos on GitHub. I'm not "acting like this is an odd assumption" but rather my point was to consider the economic side from the maintainers' point of view, which many people in this thread are completely ignoring.
As you said above, maintainers don't have to accept your contribution, and if they do, they always have the option of removing it in a future release. And if the maintainers use a CLA or other copyright assignment mechanism, they also have the option of changing the license for future releases. So why are you assuming you can keep using future versions of the product forever if you contribute to it and sign a CLA?
> Sure, and they could've kept it private so it only benefits them and/or their employer
But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.
My point in all this is that contributing to open source often benefits the contributor more than the maintainer, and yet people act like it primarily is an altruistic gift from the contributor which solely benefits the maintainer / product owner.
> But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.
Well yeah, that's the point. Trading contributions vs maintenance burden.
> My point in all this is that contributing to open source often benefits the contributor more than the maintainer
I said it provides more benefit to the contributor than the maintainer, but I did not say that it provides no benefit to the maintainer. Your question doesn't logically follow.
That's exactly my point: It still benefits the maintainer. So they benefited from contributors, then fucked them over later, violating the social contract (but not necessarily the software license because CLAs yadda yadda).
Again, my point in response is that the contributor received more benefits (in the form of code review and ongoing maintenance) than the maintainer. We're talking in circles here.
As long as the contributor isn't a cloud provider, they can continue to use the software unimpeded under the new license. Their contribution continues to be maintained by the maintainers. The contributor hasn't been "fucked over" in any way.
If the contributor is a cloud provider, they can choose to enter into a commercial licensing / revenue share agreement and continue to use the software unimpeded. Or they can decline and use/create a fork, in which case any so-called fucking-over is clearly mutual, because the contributor wants to profit from the software explicitly without making its ongoing development financially sustainable for its original maintainers. That's parasitic behavior.
I must ask, have you contributed to Redis? Or are you just expressing outrage on behalf of other people who actually contributed to Redis and may not actually even share in said outrage?
If the latter, why are you so emotionally invested in this topic? And have you ever been on the other side of the coin, maintaining a widely-used open source project?
> It is not a "rug pull" for someone to stop giving you gifts.
I'm not sure that the developers contributing code from outside the company see it that way. An easy way to tell if contributors see a license change as a rug pull is if the forks that happen after the rug pull get traction.
> The new license seems perfectly reasonable, given how much companies like Amazon have exploited the gift economy to the point where it threatens these startups survival.
Most of the time, though, open source limits growth - and doesn't threaten the original author's startup. This is a really important distinction because there is a trade-off in choosing open source as a marketing strategy - you do potentially face competition from other contributors, users and parasites that will moderate growth.
> With open-source software, a license is as much a social contract as it is a legal one
Funny how when these license changes started happening people said the exact opposite - that the license is the license and if they didn’t want to be Jeff’d they should have used a difference license.
No well-known permissive open software license includes any promise to do future development, much less to make it available under the same license terms. A key draw of permissive licensing is that anyone can fork and put new work under new and different terms.
Who would promise perpetual maintenance for nothing? What organization would sign up to be the only one that can't change terms for improvements?
I don't think "social contract" makes sense here. There's no sovereign power involved. In the sense used, "social contract" essentially means "not in the contract"---as in not in the terms. It's a back door for saying things that were never put down ought to be treated like they were in the license file, just because one side really wants them and doesn't want to DIY or pay for them.
If there are disappointed expectations, that's another thing. But being even very disappointed, and being able to find other like-minded people who would prefer no disruption and new freebies forever, doesn't make unfounded expectations enforceable, nor should it.
I'd be extremely careful speaking of any singular "community". And of assuming that everyone in it expected Redis or another similar project to work just like Linux or other exceptional projects. Most devs dealing with open source have a project relicense---among many others than simply grind to a halt---at some point in their career. For some devs, Redis may have been the first. Others "adopted" Redis knowing the risk and accepting it.
> With open-source software, a license is as much a social contract as it is a legal one
Says who? I completely disagree. A license only applies to the current work done. It does not compel someone to keep dedicating time to a project for free because they also did that in the past. People are allowed to change, even if they once released some code under a different license.
Is the old code still available under the same license ? That’s the only contract I care about , both legal and social.
I am just as much a member of this FLOSS community as others , and I never got the memo about this social contract story. I don’t think it’s true. My trust hasn’t been affected at all.
I understand your point I just get annoyed being lumped into it. Not everyone feels that way.
(But of course my opinion does matter less than actual contributors to Redis ! That’s totally fair.)
You gave us a bunch of stuff for free. You are now putting some conditions on that for new stuff you do. And that makes me sad.
I get the "feelings" part of this. When the world changes, even for the better, it can make us sad.
Equally this license better supports the stuff I am getting for free, and penalizes some giant corporation with buckets of money. And I keep getting stuff for free. So (frankly) I'm happy.
So meh. Is trust broken? Is the community harmed? Should we expect more moves along these lines? Do I see all decisions as clearly black and white - good or evil? Or is there more nuance?
For those upset at AWS no longer getting Redis for free, you can of course fork it and carry on developing for AWS. Those who don't like new redis can carry on running the old one. Those who want new redis can, well, download and use it.
Frankly they didn't hurt my feelings. They're developing. I still get it. I'm happy, not sad.
> 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?
Thing is, this sentence could equally be applied to the big cloud free riders.
Why should anyone, business or volunteer, write software that benefits FAANGs that don't pay their fair share?
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.
"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.
This idea is similar to what some countries do around music: artist register with an government identity that collects copyright fees from venues that play music - live or otherwise (bars, clubs, theatres included).
The government identity then distributes those monies to the artists according to playlists collected from said venues.
It works for big acts, for small acts the overhead tends to consume the payouts.
> 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.
> 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.
One of the motivations of copyleft licenses like GPL which are a part of open source, was the freedom for users to see and modify code. The fact that the user works with the software in a browser rather than inside a native app is a technicality which shouldn't mean that the principle becomes invalid.
Of course, this makes it harder for developers to monetize their work. But, instead of framing the discussion in terms of these conflicting interests and finding a balance, the term 'open source' becomes a debate target (even though the OSI definition includes AGPL which is also radioactive if one wants to monetize the work.)
So we have three parties 1) Users 2) App Developers who write commercial closed source code for the user facing app 3) Dependency Developers who write code used by App Developers.
(There is a simplification here as 2 can be a startup writing selling a closed source dependency used by other developers)
Just as App developers would like to monetize via user payments, some licenses allow the same option for Dependency developers while simultaneously allowing source code to be available and modified.
The basic idea behind such a license is 'free of cost and inspectable/modifiable code for almost all users, but commercial for large companies making a significant revenue from the software'.
There needs to be some work done, to make the license predictable - which users it requires to pay, and the price involved.
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.
"A demand for ego massage" is a pretty rude way to try to dismiss away someone's expressed feeling about something they cared about fundamentally changing.
I think it's a stretch to attack everyone who liked the idea of a totally open license as either disingenuous or selfish.
I agree, it would be, so I take issue with the extreme interpretation of the remark. These are merely two cases of foolishness. The first is of one’s choices not actually being in harmony with one’s preferences, the latter is simply a common cognitive bias. I’m not characterising talk of a “social contact” as malicious, but naive. Folks who want community obligations attached to their contributions can and probably should choose a copyleft license. Realising this in hindsight is a matter of personal growth.
I advise against relating to software as an emotional construct. Certainly for noncontributors but also even for contributors and primary authors. Redis is not your cat.
I'm ruffled by your repeated dismissals and arrogance BUT now I really want to name a pet redis so maybe you're coming out ahead in my personal calculus.
You taking issue with my "extreme interpretation" seems like a bad faith statement. Perhaps you really do feel mistreated by it; if that's the case I'm sorry because my intent is directly addressing the language you're using but not you personally.
To ape some of your phrasing, I advise against taking offense when others disagree with your approach or severity when you are attacking strangers, dismissing their reactions, gatekeeping who should get to care, patronizing them about personal growth, and calling them foolish at best.
> 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
Initially to a PolyForm license[1], which I then forked to create my own[2]. I informally refer to it as an "edu source" license (the source available is primarily available for educational purposes).
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.
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?
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.
AFAIK, the main issue of the GPL family of licenses is that they are rather poorly drafted. The GNU project has great evangelists but ideological-minded people make bad lawyers. Their licenses are long winded and hard to interpret, and often make assumptions about unsettled bits of copyright law. Their legal theories (eg. "GPL is not a contract") have been rejected by courts.
In short, if you're a company wanting to use some AGPL-like license, you'd probably want to use a license that's better drafted over the original AGPL.
If it gets to court you've got a plaintiff either claiming that defendant violated copyright or the defendant failed to follow the terms of GPL.
In both cases the defendant will respond that they followed the terms of GPL.
In both cases the court has to determine what the license means and then whether or not defendant followed the terms of the GPL. To do that the court has to decide what those terms actually mean.
For that I don't think it matters if GPL is considered to be a "contract" or "license" because as far as I have been able to tell the rules of interpretation are the same no matter how you characterize the document.
Maybe it could make a difference in the remedies that are available if plaintiff wins. If it is seen as not being a contract then it might be that the only remedies would be those under copyright law. Those would generally be an injunction ordering defendant to stop infringing and monetary damages. Actual monetary damages would be near zero so plaintiff would probably ask for statutory damages.
If it is seen as being a contract then potentially the remedy could include an order that the defendant release their source code. If the GPL infringement was distributing binaries without making source available this would probably be the remedy plaintiff wants.
Ordering the defendant to obey the terms of the contract is called "specific performance" and I believe is usually disfavored by courts if monetary damages are sufficient but since infringing GPL generally doesn't cause any monetary losses to the copyright owner and the whole point of the contract was to make source available I'd expect a decent chance plaintiff could get specific performance.
Note that this means that it is actually better for GPL to be seen as a contract.
Historically collecting damages were not the goal of GPL enforcement. Specific performance, or stop infringement by no longer distributing the software were the remedies. The latter is not always an option for the infringing party, and that's what submits them into compliance.
That the GPL is a contract hardly came as any surprise to people familiar with the law. Lawyers and judges view any collection of terms as a contract, and tear-open licenses are the norm these days. But the FSF had its own reasons to say it’s a license, reasons that might be more important to the philosophy of Free Software than the court.
Contracts require consent between two parties who join in the contract, if they are to be enforced. The GPL (and many other licenses that come with products) doesn’t have a signature page, so there is no explicit consent. If there is consent at all, it’s the implied consent that has become standard for “tear-open” licenses. Your acceptance of the license is indicated by some action, in this case integrating the code into your product.
The default under copyright law is all rights reserved, which means “you can’t do anything with this” with some minor exceptions that are called “fair use”. Thus, if you integrate the software into your product, distribute it, or perform some other action that is restricted by copyright, you must have accepted the license because your alternative would be all rights reserved. Thus, the FSF asserts that the GPL is a license because they feel consent isn’t really necessary, they don’t want to argue about consent in court, and they believe that they can do all of the enforcement they need using a complaint of copyright infringement. Also, tear-open licenses were a much more foggy issue in law when the GPL came about. And then there’s the philosophical matter:
> 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.
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.
What is wrong with a non-commercial open source license for those that want to use your software for personal use and a paided up commercial license (something like Business Source License[1]) for the big tech corporations of the world?
How much open source software is being incorporated into closed source software and then being resold back to the original open source developers - to get an idea, check the licenses on a Apple phone (Settings -> General -> Legal & Regulatory -> Legal Notices)[2]. It's the who's who of open source licenses! I wonder how much Apple has contributed to those projects? Perhaps each FOSS developer mentioned there should receive - at least - a free iPhone ...
The argument of "social contract" or "moral rights" or whatever else a FOSS developer faces when changing their license to something that prevents BigTech making money off their work is unfair and unnecessary. Its their work, their choice. Just as politicians aren't held to the promises they made yesterday, so too are FOSS developers human and can change their direction/mind and license.
In addition to this, many have vested interests in these companies continuing their use of "free" (in the sense of money) software since they are themselves shareholders or employees. License fees effect the bottom line of those corporations. Imagine AWS paying a license fee for their Linux boxes ...
A corporation also has a "social contract" to fulfil, yet its the FOSS developer that needs to fulfil theirs first. Or perhaps a corporation only faces "legal contract" and for the sake of profit, a "social contract" isn't applicable to a corporation. In which case, neither should a "social contract" be applicable to a FOSS developer - when dealing with corporations.
>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.
> 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.
Agree. Writing code is (TBH, only a tiny) part of the project - creating packages for different OSes and distros, testing, filling bug reports, promoting project, writing tips and ticks, articles... Many projects remain unpopular not because the authors aren’t actively maintaining them but because these essential components are missing.
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.
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.
> 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.
> 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.
> The license language is almost the same as the AGPL, with changes regarding the SAAS stuff. So, not OSI approved? Yes, but I have issues calling the SSPL a closed license.
What is it that changed from AGPL in SSPL that was absolutely needed? Why can't we have an AGPL 1.1 or 2.0 if it is a breaking change? I am not saying anyirez is wrong. I would like to learn why this was necessary, if at all.
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).
Valkey, the Redis fork, is currently sponsored by Ampere, AlmaLinux OS Foundation, Broadcom, DigitalOcean, Memurai, NetApp, Aiven, Alibaba Cloud, AWS, Canonical, Chainguard, Ericsson, Heroku, Huawei, Google Cloud, Oracle, Percona, Snap Inc and Verizon[0].
There is enough interest in sponsoring the development of infrastructure software. But if you want to build a "commercial arm", get VC funding[1][2] and earn millions, then it will never be enough. And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
> Valkey, the Redis fork, is currently sponsored by Ampere, AlmaLinux OS Foundation, Broadcom, DigitalOcean, Memurai, NetApp, Aiven, Alibaba Cloud, AWS, Canonical, Chainguard, Ericsson, Heroku, Huawei, Google Cloud, Oracle, Percona, Snap Inc and Verizon[0].
Took 'em long enough to realize. I 'member the Heartbleed catastrophe and what pittances OpenSSL got [1]. And as always, there's an XKCD fitting just too damn well [2].
> And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
That's the thing... conflicting interests, incentives and most especially expectations. Let's say I'm unhappy with the current state of managing a fleet of hardware servers and VMs, especially after the VMware disaster.
I could bite the bullet and pay VMware. I could go and get OpenStack running. It would be an utter pain to set up and run (because it is funded primarily by universities who don't have the constraint of "administration time effort" because that's what you have aspiring student volunteers for, but instead do have the constraint that it's hard to get hardware so OpenStack has to be flexible enough to support a ton of crap that any enterprise would have sent off to e-waste a decade ago). I could go and get Proxmox up and running, but it's AGPL so corporate legal may chew up my ass. Or I could whip up my own orchestrator, fit to work for my needs, and say I open-source it... and it might even be decent enough others may want to use it as well.
But then, many of these "others" won't be willing to pay for support, but they'll flood the Github issue tracker with all kinds of stuff that I now have to care about (because who wants to present a Github repository with dozens if not hundreds of open issues?), tons of feature wishes and demands (because obviously while I may run Cisco network gear for SDN, someone else may be a Juniper or whatever shop, and wants integration for that), and in the worst case someone gets 0wned because of some vulnerability that I might not even have realized - and I get the shitstorm for it, my name gets dragged through the mud like it was for OpenSSL or log4j.
So, basically I'm left with the choice between either accepting being labeled "lazy" (for not caring about "my project" enough) or to raise enough money to get the product competitive with what the other players are offering, and the only way for that is to go the VC route. And unfortunately, unlike old-school "startup capital", modern VCs want (or rather, because they're following spray-and-pray in their hunt for the 1-out-of-100 unicorn chance, have to aim for) the expectation of insane hyper-growth.
And then, one day, Amazon might go and say "hey, this FOSS thing is pretty cool, we'll add some glue code to integrate with IAM, backups and high availability, a fancy web UI and sell it on towards our customers". And suddenly, people would flock towards Amazon, who'd not be required to contribute back (because I chose either the MIT or GPL license to make adoption by others easier)... but I as well as the investors who enabled the product to grow to the stage where it was usable and popular enough for Amazon to commoditize would not see a single cent of it.
And everyone but Amazon loses out. I may be lucky enough to have gotten a few years worth of salary from VC funding (the reality is, most startup founders prioritize ramen lifestyle), the VC and their investors in turn lose out because why contract with me when they already got a frame contract with AWS, and the developers who worked with me also lose out for the same reason.
One of my clients is using OpenSearch instead of Elastic.
Big mistake. It's already behind elastic search, and worse too. It has bugs, weird behaviour and updates are already slowing.
On top of that, elastic have cunningly changed parts of their offerings to mean OpenSearch users can't use the elastic examples. For example they completely changed their .Net Core library so all new documentation in elastic is totally useless for OpenSearch.
They've added a way in the dashboard to run SQL for quick queries, etc. The OpenSearch version of that is buggy as hell, and for all intents and purposes useless because if you get the SQL wrong it just shows a blank screen instead of the error.
I'd be very aware of those problems, which appeared pretty rapidly, when going to these big corporation supported branches.
You are asking for trouble and are totally dependant on the company keeping that branch going who have little incentive to maintain or improve it now you're locked into their PaaS.
Sort of. "Locked in" is a strong word, considering Redis will run on AWS just fine, either by buying their product or spinning up a couple EC2s and `docker run redis` (which is allowed under the license since you aren't reselling it). Yes, harder than clicking a button in the AWS console, but it's not like you're stuck completely.
I understand it more for OpenSearch, because scaling that is annoying, but Redis has built in cluster mode stuff that works fine without having Amazon's magic control plane.
(we're also using OpenSearch hosted by AWS but not for anything complicated, so haven't encountered what you have. seems like Elastic 7.10, frozen in time, which is fine for us. they forked the old version of the .NET library for people to continue using, but I guess you need to use the archived docs.)
How do they manage the payout to the individual contributors?
If I fix a typo, do I get a payout at the end of year for my work?
IMO that’s what it comes down to, that contributors that work for these companies have they contributions reimbursed through their salary. Other contributors might not earn that salary.
How much did AWS and those contribute until they got locked out of using Redis? That's what's interesting. That they now have to sponsor an alternative isn't exactly surprising.
> 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.
>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
471 comments
[ 4.0 ms ] story [ 324 ms ] threadI do hope Salvatore keeps doing emulators for MCUs, though :)
VADD key [VALUES <float float ...> | FP32 <binary blob>] element
VSIM key [VALUES ... | FP32 ... | ELE ...] [COUNT <count>] [EPSION <max distance>]
VCARD key (number of elements)
VDIM key (dimension of the vectors)
VDEL key <ele>
And so forth. However there are nice things you can enable, if you want. For instance VADD has the [REDUCE] option that implements random projection in order to reduce the dimensionality of your embeddings. Less memory, and it is faster. And so forth.
Will work on it during xmas, it's quite fun.
It implements on-insertion normalization and int8 quantization. The algorithm to insert nodes inside the HNSW attempts to never leave isolated nodes and to get good quality links and so forth. More hacking needed.
I would argue that the open source community is responsible for WAY more of a free/cheap productivity boost for programmers than generative AI, and we've been providing that productivity boost for decades.
Open source mostly enhances devops productivity. AI directly plagiarizes. I do not see anything wrong with not having to write your own shell, but regurgitating laundered code and algorithms is wrong and should be illegal.
With AI the original authors do not even get credit, with open source they do.
If a human plagiarizes open source directly, it is also wrong. Even then, the scale of theft is limited to one person and not happening on an industrial scale.
I worked with antirez a bit before he left the project in 2020, and I still look fondly back on that time since he was a wonderful person and he helped me learn a lot. I wish he had considered coming to work with Valkey instead of Redis, but maybe we'll find some some way to work together that benefits both communities.
Note though it is not certain he even could - the Non Compete when you have significant compensation in cash or equity can be much stronger and run a lot longer than employment related
About Vector Sets: it's absolutely ok to disagree here; but what is a good thing about having multiple forks of the original Redis is that you can see it as an optimization to search for the better Redis :D The Vector Set stuff, just to be clear, was not "company stimulated", it's something that I really want and I which I strongly believe.
https://arstechnica.com/information-technology/2024/04/redis...
https://news.ycombinator.com/item?id=39858144
https://news.ycombinator.com/item?id=42239607
Honestly even if Redis public image has not been stellar recently, I know the people that work at Redis, many engineers are there since the start, and I believe they have huge design abilities and can do what is needed to make Redis more useful for the community.
Could you not have stayed separate from them while contributing again?
I don't really hate or care about anyone in this game, but it's a non-trivial move in the game.
Valkey is making it possible for hyperscalers to continue appropriating open source and charging fat margins to everyone else.
In a sense, Valkey is the bad guy here.
And just look at all the support Valkey is getting from Amazon, Google, Oracle, etc. They're perpetuating the problem.
The same thing happened with Elasticsearch. Unfortunately ICs without decision-making power started lambasting the Elasticsearch leadership for attempting to fend off AWS and their ilk from absorbing all of the revenues derived from their hard work.
Open source is just a commodity feature for hyperscalers. It's time we stop giving it to them for free.
This is all about power. We're ceding it to trillion dollar companies because we've been trained that "open source" is ethical. Meanwhile, we don't question the ethics of these companies profiting off of this work while charging us absurd margins. None of the hyperscaler infra is open source.
Or, in other words, Valkey is Jenkins here, and Redis is Hudson.
What's the point of spreading informations that are not true? I believe there is a single person that was in Redis and works there now, at least AFAIK. And this person stopped working at Redis long time ago (and was not a core developer). So I'm not understanding who joined ValKey from Redis folks.
Everybody is working at Redis: me, Oran, Yossi, Meir, many others.
It is probably more correct to say a bunch of Redis contributors left the Redis GitHub project and moved over to Valkey.
You can see there are a bunch of contributors listed on this page who seem to predate the fork and who have continued to contribute:
https://github.com/valkey-io/valkey/graphs/contributors
Particularly these contributors standout:
https://github.com/enjoy-binbin
https://github.com/madolson
https://github.com/soloestoy
https://github.com/hwware
https://github.com/zuiderkwast
https://github.com/hpatro
https://github.com/pizhenwei
Sure. And same for Redis employees who continue to work on the Redis Github project. All my significant contributions to open source have had financial incentives as well.
Are all the open source libraries that Redis depends on [1] also evil? Or are we just focused on declaring Redis competitors evil today?
[1] https://github.com/redis/redis/tree/unstable/deps
"redis ltd" the company did not originate redis
"redis ltd" was originally "Garantia Data": a company that offered hosted redis as a service
fundamentally they are/were doing the same thing as AWS/Google: taking an existing open source product they did not originate, and selling hosting for it
they may have hired its creator (several years after he wrote it), and since then changed their name to "redis", but they're not any different to GCP/AWS
other than the complaining about others more successful business models
this is very different to e.g. sentry
The pot calling the kettle black
https://www.linuxfoundation.org/press/linux-foundation-launc...
BTW are you an employee of Redis? You seem to have created this account just to reply to me.
Any thoughts on CSPs making money from open source projects while the open source developers (e.g., Redis, Mongo, Hashi) suffer)?
They're using the deceptive good feels to stop you from questioning their fat margins.
Why isn't the entire stack of AWS infra open source, again?
Open source has been twisted against us. The big players know where the money and value and power accumulates.
This line of argument is untethered from reality.
The Linux Foundation actually is the parent of the Cloud Native Computing Foundation (https://www.cncf.io/about/join/), which actually is infrastructure for cloud services: containers, envoy, etcd, helm, istio, Kubernetes, prometheus, etc.
You had a business that was acquired by Amazon. I don't know if you're giving this a fair assessment.
When the copyright holders of large open source infrastructure projects want revenue from their hard work, Amazon forks them or provides funding to their direct competitors.
Amazon can strategically launch free and open source competition to commercialized open source products as a means of keeping more of the cloud spend budget for themselves.
The hyperscalers want to commoditize anything that impinges upon their margins. The software should be free, it should run on their clouds, and it should lead to increased cloud spending. Other companies shouldn't dip their hands into the pot.
Moreover, hyperscalers get to hoover up "managed" versions of open source software and collect even thicker margins. Redis, Elasticsearch, etc. fly in the face of this strategy, which is why they attack it so relentlessly.
The Linux Foundation and CNCF serve its industry contributors. The microservice ecosystem is booming business for AWS, Azure, and GCP.
I don't see how this is "untethered from reality". This is cutthroat business, and it's how the trillion dollar companies throw their weight around.
If you build open source infrastructure products and don't have an anti-cloud provision, you'll get picked clean by the hyperscalers.
I like Redis, it was my first queue system and it worked great. I used it for this project https://edwarddeaver.me/portfolio/control-my-lights to pass messages from multiple inputs into a central funnel.
Looking forward to reading more of your posts.
Is there a good way to use the Anthropic models as a private person? It's my understanding you can only pay for them as a business.
Edit: Go here and create an account: console.anthropic.com
You're using Claude since a "couple of years". You really must be an early adopter ; )
You can also create a paid API account as an individual and use it via their API, which is almost certainly cheaper than the $20/month Pro account for personal use.
I use the Pro account because I really like the Claude Artifacts and Claude Projects features.
I am wondering if Valkey has moved so far off from Redis the codebase couldn't be merged again? I am reading the top contributor to ValKey are now from Tencent Cloud, Google, Amazon and Ericsson.
Could someone help with me with SSPL, is it essentially AGPL v3 except instead of releasing the source code only you have to release the whole system that is able to run the services you are currently operating on top of ?
Just wondering these things from the sideline. As I am still on the memcached camp.
Thank You. That makes a lot more sense why certain people dont like SSPL.
[1]: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro... , though just read until you get to https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro... .
Given that you probably already have retirement-sized exit from Redis. Isn't it more liberating to start something completely new? Or maybe forked Redis as the foundation of something new? Is there a need to re-join the old company?
Also, I am not sure if it has my writing style preferences saved somewhere, but Claude uses the terse style I prefer to read explanations in, without me needing to mention it. ChatGPT can do it too but it needs to be prompted lest it do the whole "repeat question, bullet points, summary" ceremony. ChatGPT gets really annoying when you have do the "slightly more detailed, slightly more terse, there we go" ceremony as well. For similar reasons, I prefer it for code.
One place where ChatGPT absolutely takes the cake though is mathematical proofs heavy with symbols. Nothing else comes close in my experience. It's also better at latex typesetting (seems to be more fluent with common packages like amsmath).
So I think it’s mainly to work with the one which works for you. I’ve seen some of our more junior developers first use Claude and then ChatGPT to refine their output, or the reverse.
As other commenters have said, that is just my personal opinion, I have zero evidence to back that up lol
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.
Redis remains my favorite database. I've had the opportunity to work extensively with it, not only professionally but also through open-source projects like redis-dict[0], a Python dictionary with Redis as the backend.
How can we follow your progress on the vector set feature?
[0] https://github.com/Attumm/redis-dict
(Snippets from the article below)
> I wrote open source software for almost my whole life. Yet, as I’m an atheist and still I’m happy when I see other people believing in God, if this helps them to survive life’s hardships, I also don’t believe that open source is the only way to write software.
> Moreover, I don’t believe that openness and licensing are only what the OSI tells us they are. I see licensing as a spectrum of things you can and can’t do.
However I don't deny that in the future maybe, if elements of vector sets happen to be JSON documents (maybe just with the attributes you want to filter with, and a document ID), it may be useful to have VSIM options to filter by such scalars.
Governments should do this and tax companies to pay for it.
Re: vector embeddings, two projects I've had recent exposure to--Memgraph and FalkorDB (previously RedisGraph)--are implementing similar functionality. I think the lego approach is really awesome, I wish this concept was more broadly adopted. All that is to say, this seems exciting!
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.
I sell print editions through Amazon KDP and IngramSpark. Amazon is the lion's share, so I designed the print edition based on the formats they offer. At the time I started working on it, KDP only supported soft covers. They added hard covers right as I was finishing the book, and I didn't want to have to go back and redo everything.
I have to admit that "Crafting Interpreters" is pushing the limits for what you can get away with on a soft cover. When I first started writing the book, I expected it to be (much) shorter, but I just estimated wrong.
If I had a time machine, I might go back and tell myself to print it as two separate volumes.
I've had my eye on Crafting Interpreters for a bit now, and I don't mind paying extra for a nicer version — especially if it's going into the pockets of an independent writer.
I know Amazon is a must for authors, but as an Amazon avoider, I was delighted to able to order it through my local bookshop.
I do appreciate the author answering. Thank you.
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 :)
Salvatore is definitely high on my list of role models.
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.)
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. of course none of the major sspl-using vendors are even pretending to themselves to follow these rules.
sspl would be much better license if it just simply forbids providing services, instead of hiding behind this thin veneer of fake copyleft.
> You can even still sell Redis as a service if you want, as long as you release all the orchestration systems under the same license (something that nobody would likely do, but this shows the copyleft approach of the license).
note that this is not right, the "copyleft" is not limited to orchestration systems, it covers all programs that you use
It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL.
I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure).
[0] https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
The key enabler in that whole business is still Redis, so the knowledge exchange appears fair.
It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will not rule on what your feelings are of what the license was meant to do but instead what was actually written and agreed to. That's why an existing, well-understood and symmetrical copyright license is going to beat out weirdo "business" licenses any day, and why they will never be considered OSI-compliant, which is fine, because if we all really hated big tech they're already allergic to the AGPL anyway.
I know I'm not going to score any points by disagreeing with you here of all places, but I genuinely wonder if you really do believe this or if you mostly just don't care to actually confront the reality.
This whole thing could be a nothingburger forever, or, alternatively, Redis, Inc. could some day be acquired by Oracle. Absolutely no way for any of us to know for sure. Unfortunately, that leaves me with little other option but to stick to the forks.
This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
What actually happened is:
- Oracle has just made MySQL better, and continues to release new tooling (e.g. mysql router) for it under the same license (gpl2).
- MariaDB releases the bare minimum database engine under the GPL, and uses closed licenses for the tooling which is, to quote them: "an essential element to any production database environment".
I don't think what MariaDB is doing today is what everyone was really worried about Oracle doing. Rather, Oracle simply never did what everyone thought they would. Personally, I think MariaDB keeps them honest, and if MariaDB ceased to exist as a serious alternative there is a good chance the lawnmower would fire back up.
Though who knows. Maybe Oracle is different. However, I would prefer not to waste the openness of my mind. I reckon if they thought they could pull the rug they would do so.
That's before we get into his claims about maintaining drop-in compatibility "as long as MySQL has a larger user base than MariaDB".
Amazon RDS does offer a MariaDB option, but Amazon Aurora does not. And other clouds often don't offer it. As far as I can tell from a quick search, Google CloudSQL does not offer a managed MariaDB product. Azure offers one, but they're officially retiring it next year.
This discussion is also a bit ironic because MariaDB created the BSL (for use in their proxy product), which is typically attacked alongside SSPL in these types of threads.
Not taking sides here, to be clear. I use both MySQL and MariaDB and am glad they both exist. And personally I have no problems with BSL (or SSPL etc) software, since I am not a cloud hosting provider.
I think these licenses suck compared to even kind-of-bad open source licenses, like AGPL, though some suck more than others. For example, the SSPL is a poorly-conceived liability nightmare. BUSL, on the other hand, may not be much better, but it is pretty interesting. Software that is BUSL today is theoretically open source eventually. As long as this holds up in court, it is an intriguing alternative to other "business" licenses.
However: it was never about this. My complaints always center squarely around two things:
- One, deception. If you release a product and you call it "open source" or otherwise try to imply it is open, but actually it is not open source, this is bad. This is bad because like it or not, people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this while also deceiving people into thinking it's the same thing they've come to know.
- Two, violation of expectations. I get that the contributions made by open source contributors rarely compares much to the contributions made by those employed at companies, but even still, the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to, and I think that this aspect of CLAs is troublesome. That aside, I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day. Don't get it twisted, I think Redis is great software that can stand on its own, but it doesn't matter: it didn't. It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
However, despite that... I am not ideologically opposed to closed-source, source-available, or any other kind of software. It's fine. I use software that is "non-free". I pay for software. I pay for JetBrains Toolbox. This does not bother me and is not my issue. It's literally just those two things that bother me.
So why don't I care about MaxScale? Honestly, it's pretty simple: It's outside of my purview. It may very well be an important project used by a lot of people, but it just doesn't seem like it was ever a huge open source project: according to GitHub, it has a total of 39 all-time contributors, most of which seemingly after the relicensing, versus Redis's 729. I've never used MaxScale and I'm not sure what depends on it. If someone else is mad about this relicensing, I do not necessarily blame them, but I just simply have no dog in the race.
MySQL and MariaDB themselves remain as open as ever, and that's really all most people are concerned with IMO.
That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
> the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to
It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
> I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day.
A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
> It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
But I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
> And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
As far as I can tell, the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998, so while it does sort of sound like a generic term, I don't think they were conflating much with any existing term in widespread use. The OSI themselves[1] also seem to suggest that they believe they were responsible for making the phrase ineligible for trademark:
> Ironically, we were partly a victim of our own success in bringing the “open source” concept into the mainstream.
[1]: https://opensource.org/pressreleases/certified-open-source.p...
--
> It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
Personally, I only contribute to projects with CLAs when I have pretty much no other choice, due to constraints outside of my control. Example: I have begrudgingly made contributions to Qt because I have no control over the upstream that KDE uses.
To be fair, I guess this does technically still count as a mutually beneficial relationship, but to me, it feels a lot more like a toxic one. But yes, that's true.
> A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
> So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
Well, from my perspective, a perfectly-reasonable, common assumption became an unreasonable without much warning.
As much as people have misgivings about how Red Hat has handled RHEL, they still proved for a very long time that it is possible to run a sustainable business even when the primary thing you do is work on open source projects. They are not alone: there are others. Off the top of my head, Collabora, Ltd. is often right alongside Red Hat. I think all of the misgivings people have with Red Hat are...
> the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998
There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.
> a perfectly-reasonable, common assumption became an unreasonable without much warning
In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
> In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
Absolutely 100% agree with all of this. VC money got real silly for a minute there, like actually investing dollars on the basis of github stars, but now the party's over and it's just about hangover time. A similar thing happens when you inject a bunch of temporarily abundant food into a closed ecosystem. You get a big spike in population growth followed by a really bad time.
Thanks for the link. I'm a bit blown away. I believed the OSI story, because many major open source figures had endorsed or been a direct part of the OSI, so I didn't think there was any reason to doubt the veracity of what they were saying, and I never saw any direct contradictions, personally. However, the evidence is pretty damning. The OSI did not coin the term open source. Wow.
I guess it's more tangential since, either way, for better or worse, they won. But, I guess it is time to stop repeating that falsehood.
> In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
That's fair. I think from my perspective, it feels like it's been rapid because it's only been a few years since it really kicked off, whereas architectural decisions to depend on a database or cache lasts a long time... I'm pretty sure software I've written 10+ years ago at companies using Redis is still in production.
> Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
> Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
> I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
It's possible that nobody ever really planned it. I honestly don't believe Hashicorp or Redis, Inc. ever planned it. That said, every company that executed one of these re-licensing efforts does have something in common: they all reserved the right to do so from the beginning. I'm not sure if they did so with the intent to ever actually use it, but I'm sure it had to be a consideration. Otherwise, why bother with a CLA over something more lightweight like a DCO? (Admittedly, I already answered that to some degree. Though, there are alternatives. My understanding is that the Apache Software Foundation CLA allows you to retain copyright ownership while still achieving most of the other functions of a CLA.)
Ultimately, I agree with you 100% regarding ZIRP. Even I, someone ...
SSPL and related licenses are ambiguous and scary enough to ward off anyone potentially competing with the copyright owner, and I doubt that's seen as a downside.
Even if I'm doing completely non commercial work I never ever ever will want to productize in any way I'd rather build my skills and familiarity with something portable (and I don't want to have to remember when I can and can't safely use each part of my stack). Anything else is just asking for a future nightmare.
The oracle and wordpress stuff recently are devastating. Can you imagine having to grind your entire company to a halt looking for anything that uses anything that uses anything that uses redis/java/whatever?
I'm an engineer. I can't justify a fixed amount of upside for an unbounded downside if I ever get on some stranger's bad side for whatever reason.
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.
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey.
LevelDB is a key-value storage library that writes to disk. It's the sort of thing you could use as the storage layer for a relational database.
On the other hand, Redis is an in-memory key-value database server.
The community rallied behind the project that ensures the software they care about remains free and open and available to all without the risk of being blind-sided.
[0]: https://redis.io/blog/introducing-azure-managed-redis
https://blog.tidelift.com/what-i-learned-from-the-server-sid... https://opensource.stackexchange.com/questions/11291/how-to-...
What it isn't close to is the original license, which is a permissive open source license.
The license switch-up is why a fork was needed. Matrix did a similar thing with the AGPL which alas, doesn't have a major fork. https://element.io/blog/element-to-adopt-agplv3/ Although it's technically still open source, they didn't do right by the contributors to it.
Even Stallman would agree that nothing can be open source if the freedom 0, freedom to use software for any purpose, is not provided. SSPL does not grant this freedom.
I wish you success in Redis Labs and thanks for Redis. In my other comment I said I never considered using Redis under the new license, but I didn’t say that I never would consider it, and I think I would if I found myself on a project that needs a key value database with enterprise support or more bells and whistles. I think it has its place, and to me it is an awful lot like postgres and EnterpriseDB, especially if Redis Labs gives its blessing, directly or tacitly, to adding this new vector type to valkey.
It is wonderful thing though, with Open Source, people can band together and "pull Valkey" to create well maintained fork based on all those past contributions
Code in which a vulnerability is discovered is in the same position. It's developed a susceptibility to a new force malevolent to its purpose. It doesn't have to change to rot, it suffices for the world to change around it.
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?
Or please explain.
One simply can't admit that they both were doing a valid thing
Truly odd.
Adding constraints later is a non-fallacious slippery slope. The restrictions Redis added aren't directly onerous to 99.999% of users, but now the world is divided into people who are allowed to use it at will, and people who can only use it in certain ways (or not at all). That's an enormous change from a FOSS license. And if they change it today specifically to lock out Amazon, will they change it again tomorrow to lock out my startup? The thing is, now that they've established precedent, there's no way of knowing what'll happen later.
Again, I know I can use GPL or MIT or BSD software for anything I want as long as I play by the exact same rules as everyone else. There's nothing that says you can use it but I can't. The difference between Free to non-Free is vast, even when I'm not affected (yet).
Well, Id say in that case youve got waaaay bigger problems than a license.
>Adding constraints later is a non-fallacious slippery slope.
No, it's very much a fallacious slippery slope. Constraints are the very essence of licenses and contracts.
But before that the community turned its back on Redis Ltd., when it let those cloud offerings from others thrive. Once the “community” got that going, these consequences were inevitable.
I think op was talking about contributors, who essentially gifted back. One might take offense if they were exchanging gifts with someone, and they open a pop-up store and sell what was gifted.
Also, it's also a tiny bit hypocritical to expect revenue sharing with Amazon without doing the same for contributors.
https://redis.io/legal/redis-software-grant-and-contributor-...
Nothing could be construed in such a way, because such a reneging is not possible.
[1]: https://antirez.com/news/120
Honestly to me you can see the tensions that led to the license change in that post. It’s largely consistent with what antirez has said in the post and in this thread.
It's a post from 2018, about a specific license confusion situation that occurred in 2018. Context matters.
You can try to be a smartass and add random caveats but that's not how language works.
Imagine if everyone thought like you did: "Sure I promise to do X" (not saying that I mean for the next 5 minutes and will then ignore my past promise)
The post title in its original context is clearly referring to the confusion discussed in the very first sentence: "Today a page about the new Common Clause license in the Redis Labs web site was interpreted as if Redis itself switched license." The title is saying that Redis core's license was not switched to Common Clause at that time in 2018. That's all. It is not titled "I promise that Redis will remain open source forever".
True, he doesn't explicitly say for how long, but I don't think it is unreasonable to read "will remain" as "will remain indefinitely" and not as "will remain so until we change our minds".
That's a reasonable interpretation. But it involves an assumption on behalf of the reader, of words that are not there. I think it's a stretch to consider that specific post a "literal promise" by Antirez.
That said, I just did more research and must admit I am completely wrong with regards to the bigger picture there. My genuine apologies. In the HN commentary on that same post [1], the cofounder/CTO of Redis Labs (Yiftach) apparently made a much more direct statement that "Redis remains and always will remain, open source, BSD license". Due to use of the word "always", that I think can unambiguously be called a literal promise that was broken by the Redis company.
[1] https://news.ycombinator.com/item?id=17818647
That's just a microcosm of the larger issue, isn't it? Contributors : Redis :: Redis : AWS - Redis gave Amazon the permission to host and make money off of Redis, but Redis was evidently salty about the state of affairs. I think contributors have reason to be salty too.
antirez gave
community gave
most people assume that this create a new thing, a group, which has a shared past and value .. and should continue (i would agree to that personally)
"pure" open source advocacy would claim "nothing is ever to be expected in any future" (i can understand that too but find it a bit sad)
1. Redis Inc creates a fork of Redis and names it say RedisNext or anything else(xyz) without a reference to Redis name at all.
2. Announces that, xyz is a fully compatible next gen version of Redis with enterprise features but it is only available under SSPL license.
3. Also announces that original Redis software is feature complete and will be under maintenance with only critical bug fixes.
This will be them playing by the same rules as any other third-party.
Will the community still manage to find fault with Redis Inc?
Will it feel entitled to continued updates or the Redis brand demanding a project handover to a different "group"?
Anything else just complicates things, like we see today, where Valkey and others are referenced as being Redis compatible (at least as far as RESP is concerned), and we either have specific clients (such as valkey-go), or existing Redis clients, that seem to want to maintain compatibility with most (all?) of them.
I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
It's honestly pretty horrible that a group of people can take centuries of man hours away from the community and tell the community to kick rocks when the software they're stealing would NEVER NEVER NEVER have had the traction it has if it were not OPEN SOURCE SOFTWARE TO BEGIN WITH.
There is a rash of thefts going on in broad daylight, and I think people need to start litigating. Its obscene and soulless and doesn't belong as an acceptable thing to do in society.
> NEVER NEVER NEVER have had the traction
There is plenty of even closed source software which has traction in many domains, let alone software released under a license which as anti-rez points out allows the users to freely run their websites on redis, modify and redistribute code etc.(with the exception of running hosting services like Amazon).
For instance, it would be amazing and a great improvement if there was a top-quality CAD program with a similar license to Redis.
> I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
Who should enforce such a requirement, and under what mechanism?
Open source licenses are copyright licenses, whereas product names are trademarks. These are separate legal concepts. Meanwhile "the community" isn't even a legal entity at all. As I understand it, there's nothing to "start litigating" here, and no one to litigate it.
Are you proposing that the OSI should change the OSD such that open source licenses must include mandatory trademark assignment to an independent nonprofit foundation? That's a rather extreme view if so.
[1] aptly named if you think about the nuclear power analogy :)
I don't think the jury is out. If you look at nginx, you won't see a lot of complains over nginx plus. The nginx brand still has a lot of goodwill and a few open source projects seem to be peacefully building upon it without any issue.
It's not that the company shouldn't have the code as open source. The company shouldn't exist in the first place and we're all suffering for it.
Certainly, but if you exchange gifts with someone every christmas, have been doing so for a decade, and they suddenly stop giving you one, or give you an unpolished one where they previously cleaned it to a shine, you are perfectly within your rights to be a bit miffed at that, and withold your own.
People can say the new license is reasonable (and by all reasonable measures it probably is) but that’s not how it feels, and that’s the important part.
And sure, you can say "just do the bug fixes yourself". But if I knew that was going to be the case, I'd never have bothered to contribute.
It sounds like you also have an assumption that the maintainers will spend the effort to maintain your contribution forever, after already spending the initial effort to review and integrate your contribution. This all takes time and money, which has to come from somewhere.
You're asking "Do you not see any value in bug fixes? Do you think software never needs to be updated?" from the contributors' and users' point of view. But the same exact issue exists from the maintainers' point of view.
A lot of people in this thread are commenting as if an open source contribution is a purely altruistic act by the contributor which then solely benefits the maintainers. That's far from the case in reality. Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
Correct, that's generally how open source works. You make a contribution, they merge it, and then the assumption is that it is maintained by the maintainers. You seem to act like this is an odd assumption, even though it is and has been the reality for pretty much every open source project ever.
> But the same exact issue exists from the maintainers' point of view.
Right, it's their "job". Maintaining the software. It's pretty much in the name. That's what happens when you accept contributions. They get merged into the software project, and then you (the maintainer) are responsible for maintaining it, or removing the functionality in a subsequent release. That's why code review happens where you consider the maintenance burden, and features sometimes don't get merged.
If this doesn't sound appealing then don't become the maintainer of an open source project.
> Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
Sure, and they could've kept it private so it only benefits them and/or their employer. But instead they chose to open source it in the hopes that
1) The maintainers will maintain it
2) It might benefit someone else
That's the whole deal. You're essentially trading your contributions for future maintenance.
As you said above, maintainers don't have to accept your contribution, and if they do, they always have the option of removing it in a future release. And if the maintainers use a CLA or other copyright assignment mechanism, they also have the option of changing the license for future releases. So why are you assuming you can keep using future versions of the product forever if you contribute to it and sign a CLA?
> Sure, and they could've kept it private so it only benefits them and/or their employer
But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.
My point in all this is that contributing to open source often benefits the contributor more than the maintainer, and yet people act like it primarily is an altruistic gift from the contributor which solely benefits the maintainer / product owner.
Well yeah, that's the point. Trading contributions vs maintenance burden.
> My point in all this is that contributing to open source often benefits the contributor more than the maintainer
And yet they choose to do it... Why?
As long as the contributor isn't a cloud provider, they can continue to use the software unimpeded under the new license. Their contribution continues to be maintained by the maintainers. The contributor hasn't been "fucked over" in any way.
If the contributor is a cloud provider, they can choose to enter into a commercial licensing / revenue share agreement and continue to use the software unimpeded. Or they can decline and use/create a fork, in which case any so-called fucking-over is clearly mutual, because the contributor wants to profit from the software explicitly without making its ongoing development financially sustainable for its original maintainers. That's parasitic behavior.
I must ask, have you contributed to Redis? Or are you just expressing outrage on behalf of other people who actually contributed to Redis and may not actually even share in said outrage?
If the latter, why are you so emotionally invested in this topic? And have you ever been on the other side of the coin, maintaining a widely-used open source project?
I'm not sure that the developers contributing code from outside the company see it that way. An easy way to tell if contributors see a license change as a rug pull is if the forks that happen after the rug pull get traction.
> The new license seems perfectly reasonable, given how much companies like Amazon have exploited the gift economy to the point where it threatens these startups survival.
Most of the time, though, open source limits growth - and doesn't threaten the original author's startup. This is a really important distinction because there is a trade-off in choosing open source as a marketing strategy - you do potentially face competition from other contributors, users and parasites that will moderate growth.
Funny how when these license changes started happening people said the exact opposite - that the license is the license and if they didn’t want to be Jeff’d they should have used a difference license.
Who would promise perpetual maintenance for nothing? What organization would sign up to be the only one that can't change terms for improvements?
I don't think "social contract" makes sense here. There's no sovereign power involved. In the sense used, "social contract" essentially means "not in the contract"---as in not in the terms. It's a back door for saying things that were never put down ought to be treated like they were in the license file, just because one side really wants them and doesn't want to DIY or pay for them.
If there are disappointed expectations, that's another thing. But being even very disappointed, and being able to find other like-minded people who would prefer no disruption and new freebies forever, doesn't make unfounded expectations enforceable, nor should it.
I'd be extremely careful speaking of any singular "community". And of assuming that everyone in it expected Redis or another similar project to work just like Linux or other exceptional projects. Most devs dealing with open source have a project relicense---among many others than simply grind to a halt---at some point in their career. For some devs, Redis may have been the first. Others "adopted" Redis knowing the risk and accepting it.
Says who? I completely disagree. A license only applies to the current work done. It does not compel someone to keep dedicating time to a project for free because they also did that in the past. People are allowed to change, even if they once released some code under a different license.
Is the old code still available under the same license ? That’s the only contract I care about , both legal and social.
I am just as much a member of this FLOSS community as others , and I never got the memo about this social contract story. I don’t think it’s true. My trust hasn’t been affected at all.
I understand your point I just get annoyed being lumped into it. Not everyone feels that way.
(But of course my opinion does matter less than actual contributors to Redis ! That’s totally fair.)
You gave us a bunch of stuff for free. You are now putting some conditions on that for new stuff you do. And that makes me sad.
I get the "feelings" part of this. When the world changes, even for the better, it can make us sad.
Equally this license better supports the stuff I am getting for free, and penalizes some giant corporation with buckets of money. And I keep getting stuff for free. So (frankly) I'm happy.
So meh. Is trust broken? Is the community harmed? Should we expect more moves along these lines? Do I see all decisions as clearly black and white - good or evil? Or is there more nuance?
For those upset at AWS no longer getting Redis for free, you can of course fork it and carry on developing for AWS. Those who don't like new redis can carry on running the old one. Those who want new redis can, well, download and use it.
Frankly they didn't hurt my feelings. They're developing. I still get it. I'm happy, not sad.
Thing is, this sentence could equally be applied to the big cloud free riders.
Why should anyone, business or volunteer, write software that benefits FAANGs that don't pay their fair share?
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.
The government identity then distributes those monies to the artists according to playlists collected from said venues.
It works for big acts, for small acts the overhead tends to consume the payouts.
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.
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.
Of course, this makes it harder for developers to monetize their work. But, instead of framing the discussion in terms of these conflicting interests and finding a balance, the term 'open source' becomes a debate target (even though the OSI definition includes AGPL which is also radioactive if one wants to monetize the work.)
So we have three parties 1) Users 2) App Developers who write commercial closed source code for the user facing app 3) Dependency Developers who write code used by App Developers.
(There is a simplification here as 2 can be a startup writing selling a closed source dependency used by other developers)
Just as App developers would like to monetize via user payments, some licenses allow the same option for Dependency developers while simultaneously allowing source code to be available and modified.
The basic idea behind such a license is 'free of cost and inspectable/modifiable code for almost all users, but commercial for large companies making a significant revenue from the software'.
There needs to be some work done, to make the license predictable - which users it requires to pay, and the price involved.
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 think it's a stretch to attack everyone who liked the idea of a totally open license as either disingenuous or selfish.
I advise against relating to software as an emotional construct. Certainly for noncontributors but also even for contributors and primary authors. Redis is not your cat.
You taking issue with my "extreme interpretation" seems like a bad faith statement. Perhaps you really do feel mistreated by it; if that's the case I'm sorry because my intent is directly addressing the language you're using but not you personally.
To ape some of your phrasing, I advise against taking offense when others disagree with your approach or severity when you are attacking strangers, dismissing their reactions, gatekeeping who should get to care, patronizing them about personal growth, and calling them foolish at best.
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.
[1]: https://polyformproject.org/licenses/strict/1.0.0/ (hn discussion: https://news.ycombinator.com/item?id=24804223)
[2]: https://github.com/LGUG2Z/komorebi-license
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.
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?
Isn't this reason enough to not consider it an option?
In short, if you're a company wanting to use some AGPL-like license, you'd probably want to use a license that's better drafted over the original AGPL.
If it gets to court you've got a plaintiff either claiming that defendant violated copyright or the defendant failed to follow the terms of GPL.
In both cases the defendant will respond that they followed the terms of GPL.
In both cases the court has to determine what the license means and then whether or not defendant followed the terms of the GPL. To do that the court has to decide what those terms actually mean.
For that I don't think it matters if GPL is considered to be a "contract" or "license" because as far as I have been able to tell the rules of interpretation are the same no matter how you characterize the document.
Maybe it could make a difference in the remedies that are available if plaintiff wins. If it is seen as not being a contract then it might be that the only remedies would be those under copyright law. Those would generally be an injunction ordering defendant to stop infringing and monetary damages. Actual monetary damages would be near zero so plaintiff would probably ask for statutory damages.
If it is seen as being a contract then potentially the remedy could include an order that the defendant release their source code. If the GPL infringement was distributing binaries without making source available this would probably be the remedy plaintiff wants.
Ordering the defendant to obey the terms of the contract is called "specific performance" and I believe is usually disfavored by courts if monetary damages are sufficient but since infringing GPL generally doesn't cause any monetary losses to the copyright owner and the whole point of the contract was to make source available I'd expect a decent chance plaintiff could get specific performance.
Note that this means that it is actually better for GPL to be seen as a contract.
Maybe bad lawyering. Or some aversion to anything that looks like an EULA or that kind of radical-ideological shit.
PS: I found this link when digging in my archives:
https://www.technollama.co.uk/us-court-declares-gpl-is-a-con...
That the GPL is a contract hardly came as any surprise to people familiar with the law. Lawyers and judges view any collection of terms as a contract, and tear-open licenses are the norm these days. But the FSF had its own reasons to say it’s a license, reasons that might be more important to the philosophy of Free Software than the court. Contracts require consent between two parties who join in the contract, if they are to be enforced. The GPL (and many other licenses that come with products) doesn’t have a signature page, so there is no explicit consent. If there is consent at all, it’s the implied consent that has become standard for “tear-open” licenses. Your acceptance of the license is indicated by some action, in this case integrating the code into your product. The default under copyright law is all rights reserved, which means “you can’t do anything with this” with some minor exceptions that are called “fair use”. Thus, if you integrate the software into your product, distribute it, or perform some other action that is restricted by copyright, you must have accepted the license because your alternative would be all rights reserved. Thus, the FSF asserts that the GPL is a license because they feel consent isn’t really necessary, they don’t want to argue about consent in court, and they believe that they can do all of the enforcement they need using a complaint of copyright infringement. Also, tear-open licenses were a much more foggy issue in law when the GPL came about. And then there’s the philosophical matter:
https://sfconservancy.org/copyleft-compliance/vizio.html
I said the FSF had a legal theory that "GPL is a license, not a contract", which was rejected by the courts.
Some reading: https://www.technollama.co.uk/us-court-declares-gpl-is-a-con...
Further cases: https://news.ycombinator.com/item?id=24478769
https://sfconservancy.org/copyleft-compliance/vizio.html
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.
How much open source software is being incorporated into closed source software and then being resold back to the original open source developers - to get an idea, check the licenses on a Apple phone (Settings -> General -> Legal & Regulatory -> Legal Notices)[2]. It's the who's who of open source licenses! I wonder how much Apple has contributed to those projects? Perhaps each FOSS developer mentioned there should receive - at least - a free iPhone ...
The argument of "social contract" or "moral rights" or whatever else a FOSS developer faces when changing their license to something that prevents BigTech making money off their work is unfair and unnecessary. Its their work, their choice. Just as politicians aren't held to the promises they made yesterday, so too are FOSS developers human and can change their direction/mind and license.
In addition to this, many have vested interests in these companies continuing their use of "free" (in the sense of money) software since they are themselves shareholders or employees. License fees effect the bottom line of those corporations. Imagine AWS paying a license fee for their Linux boxes ...
A corporation also has a "social contract" to fulfil, yet its the FOSS developer that needs to fulfil theirs first. Or perhaps a corporation only faces "legal contract" and for the sake of profit, a "social contract" isn't applicable to a corporation. In which case, neither should a "social contract" be applicable to a FOSS developer - when dealing with corporations.
[1] https://mariadb.com/bsl11/
[2] can also be viewed online --> https://gist.github.com/gorenje/a775f44bb9307852911f7f353466...
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.
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
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.
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.
> The license language is almost the same as the AGPL, with changes regarding the SAAS stuff. So, not OSI approved? Yes, but I have issues calling the SSPL a closed license.
What is it that changed from AGPL in SSPL that was absolutely needed? Why can't we have an AGPL 1.1 or 2.0 if it is a breaking change? I am not saying anyirez is wrong. I would like to learn why this was necessary, if at all.
https://opensource.stackexchange.com/a/8028
Big cloud players would put a thin layer on top and ignore the AGPL.
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.
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/
There is enough interest in sponsoring the development of infrastructure software. But if you want to build a "commercial arm", get VC funding[1][2] and earn millions, then it will never be enough. And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
[0] https://www.linuxfoundation.org/press/valkey-welcomes-new-pa...
[1] https://redis.io/press/redis-labs-raises-100-million-series-...
[2] https://redis.io/press/redis-labs-110-million-series-g-led-b...
Took 'em long enough to realize. I 'member the Heartbleed catastrophe and what pittances OpenSSL got [1]. And as always, there's an XKCD fitting just too damn well [2].
> And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
That's the thing... conflicting interests, incentives and most especially expectations. Let's say I'm unhappy with the current state of managing a fleet of hardware servers and VMs, especially after the VMware disaster.
I could bite the bullet and pay VMware. I could go and get OpenStack running. It would be an utter pain to set up and run (because it is funded primarily by universities who don't have the constraint of "administration time effort" because that's what you have aspiring student volunteers for, but instead do have the constraint that it's hard to get hardware so OpenStack has to be flexible enough to support a ton of crap that any enterprise would have sent off to e-waste a decade ago). I could go and get Proxmox up and running, but it's AGPL so corporate legal may chew up my ass. Or I could whip up my own orchestrator, fit to work for my needs, and say I open-source it... and it might even be decent enough others may want to use it as well.
But then, many of these "others" won't be willing to pay for support, but they'll flood the Github issue tracker with all kinds of stuff that I now have to care about (because who wants to present a Github repository with dozens if not hundreds of open issues?), tons of feature wishes and demands (because obviously while I may run Cisco network gear for SDN, someone else may be a Juniper or whatever shop, and wants integration for that), and in the worst case someone gets 0wned because of some vulnerability that I might not even have realized - and I get the shitstorm for it, my name gets dragged through the mud like it was for OpenSSL or log4j.
So, basically I'm left with the choice between either accepting being labeled "lazy" (for not caring about "my project" enough) or to raise enough money to get the product competitive with what the other players are offering, and the only way for that is to go the VC route. And unfortunately, unlike old-school "startup capital", modern VCs want (or rather, because they're following spray-and-pray in their hunt for the 1-out-of-100 unicorn chance, have to aim for) the expectation of insane hyper-growth.
And then, one day, Amazon might go and say "hey, this FOSS thing is pretty cool, we'll add some glue code to integrate with IAM, backups and high availability, a fancy web UI and sell it on towards our customers". And suddenly, people would flock towards Amazon, who'd not be required to contribute back (because I chose either the MIT or GPL license to make adoption by others easier)... but I as well as the investors who enabled the product to grow to the stage where it was usable and popular enough for Amazon to commoditize would not see a single cent of it.
And everyone but Amazon loses out. I may be lucky enough to have gotten a few years worth of salary from VC funding (the reality is, most startup founders prioritize ramen lifestyle), the VC and their investors in turn lose out because why contract with me when they already got a frame contract with AWS, and the developers who worked with me also lose out for the same reason.
[1] https://news.ycombinator.com/item?id=7575210
[2] https://xkcd.com&#...
Big mistake. It's already behind elastic search, and worse too. It has bugs, weird behaviour and updates are already slowing.
On top of that, elastic have cunningly changed parts of their offerings to mean OpenSearch users can't use the elastic examples. For example they completely changed their .Net Core library so all new documentation in elastic is totally useless for OpenSearch.
They've added a way in the dashboard to run SQL for quick queries, etc. The OpenSearch version of that is buggy as hell, and for all intents and purposes useless because if you get the SQL wrong it just shows a blank screen instead of the error.
I'd be very aware of those problems, which appeared pretty rapidly, when going to these big corporation supported branches.
You are asking for trouble and are totally dependant on the company keeping that branch going who have little incentive to maintain or improve it now you're locked into their PaaS.
I understand it more for OpenSearch, because scaling that is annoying, but Redis has built in cluster mode stuff that works fine without having Amazon's magic control plane.
(we're also using OpenSearch hosted by AWS but not for anything complicated, so haven't encountered what you have. seems like Elastic 7.10, frozen in time, which is fine for us. they forked the old version of the .NET library for people to continue using, but I guess you need to use the archived docs.)
If I fix a typo, do I get a payout at the end of year for my work?
IMO that’s what it comes down to, that contributors that work for these companies have they contributions reimbursed through their salary. Other contributors might not earn that salary.
to be fair that's more an issue with linux distrib than with redis
Why not just stay on the last version with the license of your original choice?
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.
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