Absolutely real: focus on the community, merge things that were now in payed versions of Redis into the core, so that everybody can benefit, contribute positively to the clients space, improve the documentation, and so forth.
Except this is not true: I mean, I asked to rejoin, not because I evaluated the situation of the company, but since I wanted to do more hacking / community stuff. So you see what happens trying to read too much between the lines? That you invent what satisfies your needs as a reader, but drives you away from what actually happened. P.S. at Redis they didn't expected this at all and were really surprised.
And about switching to a more open license, who knows? Maybe we will be doing that as well if it offers enough protection - I'm not in charge for such decision but... I can suggest things -, so thank you for the idea (kidding apart, I was already talking about this possibility inside the company).
Perhaps. I've seen people seen/write all kind of stuff when serious money are involved, and I also was offered to just just that on number of occasions.
I appreciate your honesty in disclosing what you still have Redis Labs stock, and assuming it is anything reasonable their value at future IPO would be much larger than any cash compensation which you might be getting as the part of the deal.
Reality is you did not fulfil (chose to or could not, I do not know) your public promise to keep Redis Open Source https://antirez.com/news/120
I hope your return will positively impact Redis as Open Source Project. Yet I'm disappointed to read your position on the Redis License - seeing cloud non compete license "basically as good as open source", as I far as I'm concern for many users which want to have software ran for them, and consume it as DBaaS it is no different to proprietary license, as it prevents competition.
It's wild to me that the prevailing opinion seems to be "It is only TRUE Open Source if megacorps can modify the software and resell it without sharing their modifications".
The hosted vs. distributed loophole is just that, a loophole. If, when the GPL was first published, the world was cloud-hosted and SaaS-ful, the GPL would either have included some provision like the SSPL, or it would have had relatively little impact on the world.
I understand complaints about a lack of clear boundaries or overreach in these licenses. But acting like these aren't attempting to close a loophole being abused seems crazy to me.
What loophole was being abused that caused Redis the company to pull the proverbial rug?
The "big evil corporation" that usually gets referenced is AWS. One of the core comitters to the Redis project when it was open source, was paid to do so, by AWS, and continues to be paid to do so, on the open source fork, ValKey.
It's fine to make an argument about "take it and give nothing back" when comparing the potential differences of permissive vs copyleft licenses. I likely wouldn't agree with you about which is ultimately a better choice, but I think it's fine to make that argument there.
But this isn't a hypothetical. It's an actual situation, where a permissively licensed project had significant outside contributions... and still people are screaming about "the evil mega corp"... who is now even more involved in maintaining a permissively licensed fork of said software.
I'm far from an AWS fan. I avoid it whenever possible, and I've made good money migrating customers off of AWS' overpriced services, but I've yet to see a single example of them doing anything that fulfils the "evil mega corp" shoe, w.r.t Redis.
This argument about "evil megacorp" is problematic because you can't really isolate those from the small and wonderful startups.
Specifically I've been directly involved in MongoDB ecosystem with FerretDB and there are so many small indie providers worldwide would love to offer MongoDB Atlas alternative to their customers, but can't because of SSPL license.
I know, for many it is hard to make piece with it - Open Source, for real means EVERYONE can use it for ANY PURPOSE, and this means for good and for evil, both "good guys" and "bad guys"
Small indie providers should absolutely be able to sell their MongoDB / Redis / XYZ as a service, but they should absolutely also be required by the license to contribute back their modifications to the software.
Like I said, I understand the complaints about the line-drawing issues with these licenses. I don't understand the viewpoint that the current state of OSS, where hosting != distribution, is acceptable.
AGPL covers users interacting with the software remotely through a computer network which is not the same as covering hosting. There's often overlap but if it really is hosting that a project doesn't want to allow then they need something other than AGPL.
If you want to prohibit hosting then yes you're going to need a non-OSS license (by definition), but that's moving the goalposts: I was replying to a post that said others should be allowed to sell the software as a service, but that they should be forced to share their changes even if they're "hosting" and not "distributing"... AKA the exact point of the AGPL existing.
AGPL's tying that to users remotely interacting with the software over a computer network still leaves a lot of uncertainty about when it applies.
Consider this case. Suppose there is a chess server that users can interact with remotely over a computer network to play chess against other users or against a chess engine.
On the same host that is running the chess server there is a database server, which is only accessible via a Unix domain socket on that host. The chess server uses that database to store game scores, an opening database, and some endgame databases.
The database server is AGPL. Are users of the chess server entitled to the source to any local modifications that have been make to the database server?
Does it depend on whether it was the people running the chess server who modified the AGPL code or of the modified AGPL database was provided by the hosting company?
Most of the incidents I remember where a software developed was unhappy with someone offering a hosted version of their software were cases where the hosted version was mostly being used by clients of the hosting service and being accessed over the hosting services internal network rather than cases were someone was hosting a version of the software to provide that software's services to end users.
I think the "root" of the problem goes to what is the purpose of Open Source ?
I see a lot of VC Funded founder convinced what Open Source should make their business model easy, hence licenses such such as SSPL should be called Open Source.
I believe Open Source is about software users and maximizing their freedom, which among other things choice of truly independent vendors in all circumstances, as such non compete licenses as SSPL are not
Are they better than Oracle-like proprietary licenses ? Of course! but they are not Open Source
Yep. It is exactly the same as with Oracle - you can use it IF you buy the license... but this also has requirements of playing the Vendor game and as provider you really use freedom to really take care of your customers
> If, when the GPL was first published, the world was cloud-hosted and SaaS-ful, the GPL would either have included some provision like the SSPL, or it would have had relatively little impact on the world.
Well, no on the first one. We know exactly what the GPL looks like to protect users against proprietary network hosted software: the GNU Affero General Public License.
But SSPL is already a modification of AGPL, so its terms don't seem to have be sufficient.
The SSPL's network provision also requires SaaS companies to release the source of any other services and APIs they made the original software dependent on; hard to tell if that's still a valid copyright licence or more of a contract.
Contrast them with EUPL, which represents the strongest copyleft the EU commission thinks a licence, as opposed to a contract, could get away with under EU directives (ignoring its compatibility clause). I'm personally wary of AGPL/SSPL not because their terms, but because the viral claises are likely to be a legal fiction where I live.
I'm saying if a company modifies open source software and distributes it, they should be required to distribute the modified source as well. I'm further claiming that providing a hosted service is a form of distribution.
> “free for everyone… except them - they make too much money.”
Free for everyone, and if you make changes to improve it, and let others use the software you changed, you contribute those changes back. That's the basic principle of OSS, no?
It’s clearly up for debate, but I’ve always thought that imposing obligations for how people use the product/code, or implying obligations for what the project is “owed” by users, isn’t free as in freedom, or beer. So I don’t think it’s a basic principle of open source. I think some people want it to be though.
I get it though. People see aws et al making a business model of hosting FOSS and making boatloads of money doing it, and they don’t like it.
This opinion seems to require the idea that targeted license changes that are intentionally devastating (going from "do anything" to requiring relicensing all/some of your stack) will only ever be used against "the bad guys" tm and OF COURSE we agree on who "the bad guys" tm are and OF COURSE that will never be me or you _trust me bro_.
Feels like a cliche "first they came for the richest saas providers and we said nothing..."
For somebody, like you and many others, it was very important to retain an OSI license. But I feel that in general given that the new license is IMHO good for almost every user, from the POV of what they can do with the code, and that the cloud situation was quite self evident, I believe that with better communication, and immediate developments/merges in the core, to counter balance the license switch, many people would understand the license matter.
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.
> is IMHO good for almost every user, from the POV of what they can do with the code
I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't. We're trying to figure out our migration path right now and it's almost surely going to be Valkey.
Large vendors were never going to pay up and so it's all loss for everyone involved. I have to do work, every project that works with Redis has to do work to support Valkey now, the eventual divergence will force people to pick a side which will probably also be Valkey for everything other than the client libraries Redis Labs personally develops. It's a mess.
Open core proprietary add-one for new fancy AI features could have avoided the split and gotten you in the door with big cloud vendors willing to sell your add-on in the marketplace with revenue sharing. They did it with Bedrock and Anthropic is making bank off it.
> I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't.
Hum, I have not considered this aspect before - I mean I've realized that AWS probably cannot use Redis [until they pay back], but that users (customers) would be affected...likely I'm biased here cuz not using managed services of that sort, sat having Redis + Sentinel setup of our own.
It sounds like your opinion is that the communication around the relicensing was the issue rather the relicensing itself, but from the standpoint of the people who decided there was enough of an issue to switch away from Redis, is that the case? As an outsider to the Redis community both before and after the schism, I don't know that you're wrong, but I have to imagine that if I were someone concerned enough to consider forking (or switching to a fork), I wouldn't be happy with someone involved in the project making a blanket statement about whether my motivations were actually about the licensing or not. Ironically, this seems like it's exactly the type of communication that could exacerbate concerns around licensing.
How many, outside a few vocal voices, actually cares about the licensing? My company would choose Redis 100/100 times, because it's the known and trusted brand, and not some fork they've never even heard of. And the license change doesn't affect us in any way.
Additionally, I think it's a bit entitled to be so up in arms about a product everyone is using for free. There is a big issue with how open source is unmaintainable to do in our industry, and I applaud Redis' attempt at trying to fix it.
I don't personally have a strong opinion about relicenses to try to prevent competitors from selling cloud-bases services (either in the case of Redis or in general; if anything, having worked at MongoDB at the time when it was relicensed to SSPL biases me a little bit in favor of companies who do relicenses like this). My perception is that there's a non-trivial contingent of users who migrate whenever something like this occurs, but you're not wrong that this might be influenced by a smaller number of louder voices.
I do agree with you about open source developers being within their rights to maintain as they see fit. My personal philosophy is that while open source maintainers have no obligation to maintain in a way that conforms to user expectations, users still have the right to voice their opinions on that (although the maintainers are free to ignore it, per the previous point). To me, the distinction that matters isn't about whether users are "entitled" or not but whether they're voicing opinions about an open source project (including decisions about how to maintain it) versus personal insults at individuals. I don't see anything wrong with someone being vocally upset about a license change; I just also don't see anything wrong with a maintainer choosing not to care about it.
> I do agree with you about open source developers being within their rights to maintain as they see fit.
I used to agree with this, but it now seems a rather narrow view of how open source actually works. Open source projects tend to make a big deal about being a "community," and this is certainly true of many that are backed by commercial vendors. To me the use of community does imply mutual obligations between developers and users or the word has no meaning.
Unless, that is, you think community is just a synonym for "marketing funnel."
One thing is the normal user concerns, that are granted, and I understand and respect them. Another thing is forking, that in the specific case of ValKey was an effort whose impulse was provided by companies having an economic damage because of the license switch. So I think those are two orthogonal questions.
Hmm, I think I see. If I understand correctly, your opinion is that independent of the motivations of the forks, independent users switching to the forks could have been avoided with better communication? I guess that's a fair stance, although I'm not sure I fully agree with it. From what I can tell, there's a fairly large contingent of open source users who won't be happy with a license being changed to something they don't consider open source regardless of the rationale.
I hear you, but at the same time it was badly done. I’ve been referring to Redis as “a proprietary fork of Valkey,” and that message has clearly resonated.
That's like saying Xfree86 is a fork of X.org, MySQL is a fork of MariaDB, or OpenOffice is a fork of LibreOffice. "Forking" is an event that happens in time, so project A cannot be a fork of project B if A existed before B.
Valkey is as much Redis as it is Valkey? Then why isn't it called "Redis"? Clearly there's a distinction or the fork would never have happened. Is Redis also as much Valkey as it is Redis?
Names signal who has control over a project, not anything about its history/implementation/license. Otherwise every piece of software that goes through a rewrite should change its name.
Projects also don’t necessarily change names when control over them changes either. It’s the Ship of Theseus kind of thing. There is no single property that would delimit when software stops being itself. And the name is hardly the most important part.
After all, the identity of ever-changing entities is ephemeral and is only in our heads.
"Valkey" is not called "Redis" because as much as the development is shared by the community, the trademark isn't.
A lot of developers and users are sticking with the community and the license instead of sticking with the trademark holder.
> Names signal who has control over a project
Trademark is a specific form of intellectual property and there are many others. I don't understand how you got to that conclusion to be honest. A restaurant in my neighborhood had to change name recently because it was too similar to a big chain, does that mean it's a different restaurant now?
> But I feel that in general given that the new license is IMHO good for almost every user
That is the nub of the sticking point.
The new is OK for people who only care about getting things done. But for people interested in building and being part of a community, giving as well as taking, not so much
This:
You may not make the functionality of the Software or a Modified version
available to third parties as a service or distribute the Software or a
Modified version in a manner that makes the functionality of the
Software available to third parties.
I care about getting things done but don't want to take on the risk of an encumbered license and the volatility that comes with license changes.
To me, these products are booby traps that are more likely to need replaced in the future when something changes again.
Put another way, it's a sign of an unhealthy ecosystem.
There's so much gray area in these terms you have to keep the lawyers involved not only in the initial indentation but product features in the future to make sure you don't accidentally cross a very poorly defined line.
I'm a vendor of some packaged on-premise solution. We are using a Redis as a cache layer inside. Risk of being forced to GPL out our installer is unacceptable for us.
In your use case, you could not even use the AGPL, basically? Is that what you mean? Thanks. That would be an interesting point, but it goes over the borders of the SSPL itself. Would be more BSD/MIT vs all the rest.
No, we can provide proprietary scripts that install GPLed software (i.e. setup Linux machines), but can't provide proprietary scripts that install AGPL.
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
> 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 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".
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 also after the IBM acquisition, so it's hard to be sure exactly what went wrong there.
What's happening today feels very different, though. 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.
And I won't say that people shouldn't take caution and mind the risk. They are! I think a lot of people are more skeptical of business models than ever. Even on the consumer end, the mantra of "If you're not paying for the product, then you are the product" has entered the mainstream thanks to Facebook, and many are skeptical of startups like Discord as well for similar reasons.
But even then, I feel deeply that companies should take responsibility when the expectations are misaligned. If you have a CLA on your project with the explicit intent to be able to relicense the project later, please communicate this very clearly to your users and contributors. Prior to recently, a very good justification for a CLA was actually just legal book-keeping: it killed many birds with one stone, like allowing a contribution to be used in a dual-licensed product with a commercial license, additional assurance that the person who is contributing the code has the legal right to contribute it, and allowing for good-faith relicensing when it would be helpful (e.g. transitioning from GPLv2 to GPLv2+ or something like that.) I didn't expect CLAs to be used the way they are used today, and needless to say I'm pretty disappointed.
So sure. Users should beware. But, I think that doesn't absolve companies from not setting proper expectations. We should expect companies to not do things that will leave everyone feeling bamboozled. Just as arguably the people should've known better, companies like Redis, Inc. should've known better, too.
> 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 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.)
In some cases, I am legitimately not permitted to use or run SSPL software. To be clear though, it's not like I disagree: I feel like SSPL is a trash fire that, if brought from the metaphorical realm into the physical, could be seen from space. It is less a copyright license to me and more of an extended middle finger.
In other cases, I choose open source for practical reasons. For example, if I am using Linux, many distributions will flat-out not package software that is not open source. This is both for ideological and practical reasons. Working with non-open-source software in an otherwise-fully-open-source project feels like dealing with toxic waste. And it's not entirely unreasonable, as it can be surprising. If I install the Redis package one day and it's open source, then the package updates in a system upgrade and it's SSPL, that would be a rather huge problem! So this clearly can't work, and we have to very clearly distinguish what software is safe to use and what software might be quite unsafe to use.
Even if it is technically possible for me to use SSPL software, I would greatly prefer to not do so anyways. If I wanted to contribute upstream to a project I use, I'd greatly prefer it to be one that doesn't use a CLA. Valkey doesn't use a CLA. Therefore, if I use Valkey, I don't have to sign a CLA to contribute upstream.
> And meanwhile I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
Definitely, but actually, I think this sort of model is exactly what has always worked best for open source: all of the cloud providers contributing to it get to benefit equally from it. To me this is what Linux kernel development also looks like, along with many other successful projects.
Is it a bit sad that Redis, Inc. and the folks who made Redis what it is today will ultimately lose out if Valkey winds up dominating the mindshare in the long run? Absolutely, it's a terrible end result. But the way I see it, it feels like it's either that, or the rest of the world loses out on having an open source Redis-compatible database. I don't think Redis, Inc. really needs to be rewarded infinitely forever for the work that they did, even as much as I value it, so this temporary situation, as unfortunate as it may be, seems like a good tradeoff for the longer haul.
I think the story of Redis and many other such projects will wind up being a cautionary tale, and we're just now finding out to whom it will be to. Though, even if I don't like it, it's looking more and more likely that the cautionary tale is to us, the users.
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 with relatively little finance and economics knowledge, can see pretty clearly how there is a direct cause and effect relationship here.
I'm honestly very glad that there are less open source businesses popping up. As I have said, I have no problems using "unfree" software or paying for software. If "fair source" is the answer that makes everyone happy it is not a problem with me. Though, I really hope people consider not using the SSPL.
I think more companies that really do want to do OSI-approved open source but are afraid of cloud providers should consider AGPL though. It is riskier, but right now it's toxic waste to all of them that I know of, and it will still make it very easy for Linux distributions to package and distribute your software. But if they choose closed-source or fair-source first to avoid the potential to mislead people, it's pretty hard to fault them.
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.
"Many people had contributed their efforts to the Redis project for free - both in terms of code but also in advocacy, writing tutorials, publishing example code etc"
I can understand that, but the thing about the BSD license is that such value never gets lost. People are able to fork, and after a fork for the original project to still lead will be require to put something more on the table. Inside Redis it was tried very hard to don't change license. For years it was some kind of "dogma", something one could not even speak about. Then after all the kind of attempts, and following the experiences of MongoDB and others, finally this choice was made. (Disclaimer: I saw the switch as an outsider, so my information is not complete about the final decisions -- I for sure know how this was always considered to avoid if other setups were possible).
However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
With open-source software, a license is as much a social contract as it is a legal one. People contribute because they want to be part of a community building something which is beneficial to everyone. Everyone contributes where they can, and in turn takes what they need.
Redis Ltd. broke the social contract. They decided that the short-term profitability of the company was more important than the project as a whole, the community which had grown around Redis and the future of the software. Probably a wise decision from a business perspective, but that doesn't make it any less of a rug pull from a community perspective.
You're right that no pre-relicense code was lost. People could and did fork. But something far more valuable was lost: the community's trust. First they relicensed the code solely for their own benefit, now they tried to take over third-party libraries and started behaving in a hostile way towards the community forks. Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers? After all, what's the next shady move going to be?
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.
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.
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.
> 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.
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.
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.
> 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".
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.
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.
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.
> 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.
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 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
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.
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).
> 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.
> 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.
> 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?
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.
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.
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.
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, ...
That is true, and that is how Valkey and other forks are moving forward. But the value wasn't just in the code- many folks contributed value by writing blog posts, making videos, and writing books or otherwise promoting "Redis". The Redis trademark owners had every legal right to change what "Redis" means by changing the license, but it creates a massive headache and a practically impossible task for everyone that gave so much to promoting the project to change all of these references.
Folks like to cite MongoDB as some great example, but Redis had significant community contributions in recent years. And AWS never used any Mongo code.
In a sense valkey is the main line and redis is now the fork. Valkey is about the same except losing the trademark. It’s similar to Hudson and Jenkins. It’s not so clear cut with OpenSearch.
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.
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.
> 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.
"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.
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.
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.
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.
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?
Good point: the key is that, starting from now, Redis Inc. should make small changes that positively affect you.