I can understand that, but the thing about the BSD license is that such value never gets lost. People are able to fork, and after a fork for the original project to still lead will be require to put something more on the table. Inside Redis it was tried very hard to don't change license. For years it was some kind of "dogma", something one could not even speak about. Then after all the kind of attempts, and following the experiences of MongoDB and others, finally this choice was made. (Disclaimer: I saw the switch as an outsider, so my information is not complete about the final decisions -- I for sure know how this was always considered to avoid if other setups were possible).
However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.
Redis Ltd. broke the social contract. They decided that the short-term profitability of the company was more important than the project as a whole, the community which had grown around Redis and the future of the software. Probably a wise decision from a business perspective, but that doesn't make it any less of a rug pull from a community perspective.
You're right that no pre-relicense code was lost. People could and did fork. But something far more valuable was lost: the community's trust. First they relicensed the code solely for their own benefit, now they tried to take over third-party libraries and started behaving in a hostile way towards the community forks. Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers? After all, what's the next shady move going to be?
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-...
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.
Nothing could be construed in such a way, because such a reneging is not possible.
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.
You are absolutely right—context! matters, especially when we are talking about something from so long ago. It does seem like the post reflects the confusion and tensions of that time, which may have influenced the eventual license change.
Looking back, it is interesting how the decisions align with what he has shared, both back then and here in this thread. It really gives perspective on how things evolved.
Thanks for pointing that out!
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.
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.
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.
[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.
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.
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.
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.
Get Lost
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.
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.
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.
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.
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey.
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.
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.
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.
> “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 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.
> 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 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.
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'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)
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?
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.
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:
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
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.
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).
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...
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.
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.)
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.
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
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.)