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.
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.