The question of what constitutes a "service" seems very murky, and although it's obviously not the intention of all these source-available, BSL style things, in a dark timeline it seems like there's a lot of room for litigious actors to behave very badly. The uncertainty is what makes it scary, I'd also like a lot more clarity.
The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).
the issues of sspl have been frequently and loudly been brought up previously, and nothing has happened. just to reiterate, this section is ridiculously expansive:
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. of course none of the major sspl-using vendors are even pretending to themselves to follow these rules.
sspl would be much better license if it just simply forbids providing services, instead of hiding behind this thin veneer of fake copyleft.
> You can even still sell Redis as a service if you want, as long as you release all the orchestration systems under the same license (something that nobody would likely do, but this shows the copyleft approach of the license).
note that this is not right, the "copyleft" is not limited to orchestration systems, it covers all programs that you use
> it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere.
It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL.
I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure).
I believe that the original reason why they didn't just say "you're not allowed to provide this program as a service" is that MongoDB were trying to get SSPL approved by the OSI. The OSI didn't approve it because as you mention, it's basically impossible for a cloud provider to actually attempt to comply with the SSPL. Not only would they have to release the code to all software used to make the program available, they would have to do so under the SSPL. I'm not sure why MongoDB didn't change the wording when they gave up on getting the license classified as "open source".
I'm sorry, but how is this a good answer? If you really only care about "two/three users in the world" and don't want users to worry about legal implications, why not explicitly write that in the license?
It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will not rule on what your feelings are of what the license was meant to do but instead what was actually written and agreed to. That's why an existing, well-understood and symmetrical copyright license is going to beat out weirdo "business" licenses any day, and why they will never be considered OSI-compliant, which is fine, because if we all really hated big tech they're already allergic to the AGPL anyway.
I know I'm not going to score any points by disagreeing with you here of all places, but I genuinely wonder if you really do believe this or if you mostly just don't care to actually confront the reality.
This whole thing could be a nothingburger forever, or, alternatively, Redis, Inc. could some day be acquired by Oracle. Absolutely no way for any of us to know for sure. Unfortunately, that leaves me with little other option but to stick to the forks.
> Redis, Inc. could some day be acquired by Oracle
This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
I personally have wondered if Oracle's behavior with MySQL is partly motivated by the fact that if they try to rug-pull it will most likely just push all of the cloud providers over to MariaDB anyways, which has been doing just fine, and I think is already supported by Amazon RDS anyways. Ultimately I am totally fine with a fork-heavy ecosystem, the only thing I would erase if I could is the normalization of signing CLAs, as I think they make the normally-symmetrical prospect of contributing to open source projects highly asymmetrical, and the consequences are not always so obvious to people.
MariaDB is one of the biggest ironies to me: it was started because people claimed Oracle was going to do Oracle things with it, and somehow make it not open any more.
What actually happened is:
- Oracle has just made MySQL better, and continues to release new tooling (e.g. mysql router) for it under the same license (gpl2).
- MariaDB releases the bare minimum database engine under the GPL, and uses closed licenses for the tooling which is, to quote them: "an essential element to any production database environment".
I wouldn't really put too much weight into the marketing speak, MariaDB feels like the same MySQL offering that always existed, at least to me (and I do run it in production, albeit only on a small scale.) And MariaDB has done plenty of work that is available in the open source product: performance improvements, new storage engines and so on. The only thing that's surprising is that MySQL continued to do the same.
I don't think what MariaDB is doing today is what everyone was really worried about Oracle doing. Rather, Oracle simply never did what everyone thought they would. Personally, I think MariaDB keeps them honest, and if MariaDB ceased to exist as a serious alternative there is a good chance the lawnmower would fire back up.
Though who knows. Maybe Oracle is different. However, I would prefer not to waste the openness of my mind. I reckon if they thought they could pull the rug they would do so.
I wasn't suggesting it's the exact same scenario, but it definitely seems a little disingenuous to create a fork of something that you chose to sell, and complain (https://web.archive.org/web/20201003111459/https://www2.comp...) about it becoming "open core", only to then make everything you do a paid product with the one exception.
That's before we get into his claims about maintaining drop-in compatibility "as long as MySQL has a larger user base than MariaDB".
MySQL and MariaDB have diverged over the years. They each have some interesting major features that the other one lacks, and there's an ever-growing list of incompatibilities between them.
Amazon RDS does offer a MariaDB option, but Amazon Aurora does not. And other clouds often don't offer it. As far as I can tell from a quick search, Google CloudSQL does not offer a managed MariaDB product. Azure offers one, but they're officially retiring it next year.
This discussion is also a bit ironic because MariaDB created the BSL (for use in their proxy product), which is typically attacked alongside SSPL in these types of threads.
Not taking sides here, to be clear. I use both MySQL and MariaDB and am glad they both exist. And personally I have no problems with BSL (or SSPL etc) software, since I am not a cloud hosting provider.
I would like to clarify since I am one of the people who is always present in these threads debating these licenses:
I think these licenses suck compared to even kind-of-bad open source licenses, like AGPL, though some suck more than others. For example, the SSPL is a poorly-conceived liability nightmare. BUSL, on the other hand, may not be much better, but it is pretty interesting. Software that is BUSL today is theoretically open source eventually. As long as this holds up in court, it is an intriguing alternative to other "business" licenses.
However: it was never about this. My complaints always center squarely around two things:
- One, deception. If you release a product and you call it "open source" or otherwise try to imply it is open, but actually it is not open source, this is bad. This is bad because like it or not, people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this while also deceiving people into thinking it's the same thing they've come to know.
- Two, violation of expectations. I get that the contributions made by open source contributors rarely compares much to the contributions made by those employed at companies, but even still, the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to, and I think that this aspect of CLAs is troublesome. That aside, I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day. Don't get it twisted, I think Redis is great software that can stand on its own, but it doesn't matter: it didn't. It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
However, despite that... I am not ideologically opposed to closed-source, source-available, or any other kind of software. It's fine. I use software that is "non-free". I pay for software. I pay for JetBrains Toolbox. This does not bother me and is not my issue. It's literally just those two things that bother me.
So why don't I care about MaxScale? Honestly, it's pretty simple: It's outside of my purview. It may very well be an important project used by a lot of people, but it just doesn't seem like it was ever a huge open source project: according to GitHub, it has a total of 39 all-time contributors, most of which seemingly after the relicensing, versus Redis's 729. I've never used MaxScale and I'm not sure what depends on it. If someone else is mad about this relicensing, I do not necessarily blame them, but I just simply have no dog in the race.
MySQL and MariaDB themselves remain as open as ever, and that's really all most people are concerned with IMO.
> people have a perception of what open source is that has been shaped by the careful guarding of the definition of the term, and when people misuse it, it dilutes this
That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
> the CLA breaks the fundamental mutually beneficial relationship that open source contributors have with the projects they're contributing to
It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
> I personally evangelized Redis within organizations with the understanding that it would always be open source, because why wouldn't it be? And I reckon that big open source users like MediaWiki also never envisioned that Redis would cease to be open source some day.
A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
> It got a healthy boost from participating in the open source community, and then one day, it suddenly left said community in the dust, which is why we have to fork.
Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
But I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
> That's true, but it's an unfortunate accident. In my mind the core problem is that OSI chose to take an existing term/concept (source code being "open" which previously just meant the code was publicly available) and conflating it with a new, much more specific definition relating to copyright license terms.
> And then because the term "open source" already had previous usage in the industry, OSI couldn't get a trademark, which means discussions of "misuse" and "dilution" are purely matters of opinion which are very prone to holy wars. If they had just chosen an actually new/novel term which could be trademarked (e.g. "sourceware" was one alternative floated at the time), I suspect a lot of confusion could have been avoided.
As far as I can tell, the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998, so while it does sort of sound like a generic term, I don't think they were conflating much with any existing term in widespread use. The OSI themselves[1] also seem to suggest that they believe they were responsible for making the phrase ineligible for trademark:
> Ironically, we were partly a victim of our own success in bringing the “open source” concept into the mainstream.
> It reduces some of the benefits for the contributor, but it's still a mutually beneficial relationship that (imo) benefits the contributor more than the maintainer. Most third-party contributions are features/fixes specifically needed by the contributor, and having them merged upstream typically makes life much easier for the contributor, despite the possible risk of future relicensing due to the CLA. From the contributors' point of view, that's still generally better than alternatives such as either maintaining a private fork forever, or re-implementing the software in-house from scratch.
Personally, I only contribute to projects with CLAs when I have pretty much no other choice, due to constraints outside of my control. Example: I have begrudgingly made contributions to Qt because I have no control over the upstream that KDE uses.
To be fair, I guess this does technically still count as a mutually beneficial relationship, but to me, it feels a lot more like a toxic one. But yes, that's true.
> A lot of people made this assumption, but at the end of the day, in retrospect this was akin to assuming that ZIRP would remain the status quo forever. And that's understandable, given how the industry skews young and that means a majority of folks have worked their entire career in this low-interest-rate, massive-tech-valuation bubble. And even for older engineers, it's easy to get lost in the bubble when most of your coworkers are younger and have 100% internalized those market conditions as being "normal".
> So then when the bubble deflates a little bit, people start vocally blaming Redis and Hashicorp and RedHat and Elastic and MongoDB and every other previously-open-source company that gets added to this ever-growing list. That's human nature I suppose; when enough people make the same bad assumption, they're going to blame the external symptoms and not blame their own bad assumption.
Well, from my perspective, a perfectly-reasonable, common assumption became an unreasonable without much warning.
As much as people have misgivings about how Red Hat has handled RHEL, they still proved for a very long time that it is possible to run a sustainable business even when the primary thing you do is work on open source projects. They are not alone: there are others. Off the top of my head, Collabora, Ltd. is often right alongside Red Hat. I think all of the misgivings people have with Red Hat are also after the IBM acquisition, so it's hard to be sure exactly what went wrong there.
What's happening today feels very different, though. In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
And I won't say that people shouldn't take caution and mind the risk. They are! I think a lot of people are more skeptical of business models than ever. Even on the consumer end, the mantra of "If you're not paying for the product, then you are the product" has entered the mainstream thanks to Facebook, and many are skeptical of startups like Discord as well for similar reasons.
But even then, I feel deeply that companies should take responsibility when the expectations are misaligned. If you have a CLA on your project with the explicit intent to be able to relicense the project later, please communicate this very clearly to your users and contributors. Prior to recently, a very good justification for a CLA was actually just legal book-keeping: it killed many birds with one stone, like allowing a contribution to be used in a dual-licensed product with a commercial license, additional assurance that the person who is contributing the code has the legal right to contribute it, and allowing for good-faith relicensing when it would be helpful (e.g. transitioning from GPLv2 to GPLv2+ or something like that.) I didn't expect CLAs to be used the way they are used today, and needless to say I'm pretty disappointed.
So sure. Users should beware. But, I think that doesn't absolve companies from not setting proper expectations. We should expect companies to not do things that will leave everyone feeling bamboozled. Just as arguably the people should've known better, companies like Redis, Inc. should've known better, too.
> Changing the license doesn't leave the community in the dust though. I mean, "we" don't "have" to fork, unless "we" are cloud providers, right? I find it curious that many of the loudest voices in these threads aren't actually code contributors to the software being discussed. (I'm not referring to your comments, to be clear; I found your writing quite insightful and nuanced, even though I disagree with some of it.)
In some cases, I am legitimately not permitted to use or run SSPL software. To be clear though, it's not like I disagree: I feel like SSPL is a trash fire that, if brought from the metaphorical realm into the physical, could be seen from space. It is less a copyright license to me and more of an extended middle finger.
In other cases, I choose open source for practical reasons. For example, if I am using Linux, many distributions will flat-out not package software that is not open source. This is both for ideological and practical reasons. Working with non-open-source software in an otherwise-fully-open-source project feels like dealing with toxic waste. And it's not entirely unreasonable, as it can be surprising. If I install the Redis package one day and it's open source, then the package updates in a system upgrade and it's SSPL, that would be a rather huge problem! So this clearly can't work, and we have to very clearly distinguish what software is safe to use and what software might be quite unsafe to use.
Even if it is technically possible for me to use SSPL software, I would greatly prefer to not do so anyways. If I wanted to contribute upstream to a project I use, I'd greatly prefer it to be one that doesn't use a CLA. Valkey doesn't use a CLA. Therefore, if I use Valkey, I don't have to sign a CLA to contribute upstream.
> And meanwhile I don't think it is a coincidence that a number of the Valkey contributors work for cloud providers.
Definitely, but actually, I think this sort of model is exactly what has always worked best for open source: all of the cloud providers contributing to it get to benefit equally from it. To me this is what Linux kernel development also looks like, along with many other successful projects.
Is it a bit sad that Redis, Inc. and the folks who made Redis what it is today will ultimately lose out if Valkey winds up dominating the mindshare in the long run? Absolutely, it's a terrible end result. But the way I see it, it feels like it's either that, or the rest of the world loses out on having an open source Redis-compatible database. I don't think Redis, Inc. really needs to be rewarded infinitely forever for the work that they did, even as much as I value it, so this temporary situation, as unfortunate as it may be, seems like a good tradeoff for the longer haul.
I think the story of Redis and many other such projects will wind up being a cautionary tale, and we're just now finding out to whom it will be to. Though, even if I don't like it, it's looking more and more likely that the cautionary tale is to us, the users.
You've made a lot of great points above, more than I can reply to, so please excuse my cherry-picking of just a few in my response here.
> the term "open source" was not in any kind of widespread use prior to the explicit open source movement that began in 1998
There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.
> a perfectly-reasonable, common assumption became an unreasonable without much warning
In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
> In a post-CLA world, a lot of companies are banking on the rugpull. They are starting businesses operating in ways they know is not sustainable, securing enormous investments, and knowing full well that when the time is right they will change the rules, which is legal because they reserved the right to do so.
Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
> ZIRP led to all sorts of unsustainable businesses...The company needs to recapture some of that value to remain in operation.
Absolutely 100% agree with all of this. VC money got real silly for a minute there, like actually investing dollars on the basis of github stars, but now the party's over and it's just about hangover time. A similar thing happens when you inject a bunch of temporarily abundant food into a closed ecosystem. You get a big spike in population growth followed by a really bad time.
> There's actually a lot of contrary evidence, see https://dieter.plaetinck.be/posts/open-source-undefined-part... for a great deep-dive. That author's findings line up with my own vague recollection of the occasional use of the terms "open" vs "closed" being used intuitively and generically to describe codebases, in programming-related discussions on bulletin board systems.
Thanks for the link. I'm a bit blown away. I believed the OSI story, because many major open source figures had endorsed or been a direct part of the OSI, so I didn't think there was any reason to doubt the veracity of what they were saying, and I never saw any direct contradictions, personally. However, the evidence is pretty damning. The OSI did not coin the term open source. Wow.
I guess it's more tangential since, either way, for better or worse, they won. But, I guess it is time to stop repeating that falsehood.
> In my view it's been more of a slow process. The license changes for infrastructure projects have been brewing for a while, in response to the lack of a revenue share mechanism from cloud providers. The original Redis kerfuffle about Commons Clause started in 2018; MongoDB switching to SSPL was also later in 2018; Sentry switched to BSL in 2019; etc. Basically a slow but consistent movement of a few infrastructure companies per year, every single year for quite some time now.
That's fair. I think from my perspective, it feels like it's been rapid because it's only been a few years since it really kicked off, whereas architectural decisions to depend on a database or cache lasts a long time... I'm pretty sure software I've written 10+ years ago at companies using Redis is still in production.
> Maybe I'm naive, but I really don't think any of these well-known companies strategically planned an evil rug-pull years in advance. Rather, ZIRP led to all sorts of unsustainable businesses getting massive amounts of funding. Yes, this includes a lot of open source infrastructure software companies, but also a lot of other non-open-source businesses as well.
> Once fundraising became more difficult, everyone starts struggling to figure out how to achieve a profitable business model. For the open source infra companies, a licensing change is a somewhat natural option to consider, for software products that happen to be generating a lot of value for third parties but not for its primary creators. The company needs to recapture some of that value to remain in operation. That seems perfectly reasonable, and from users' standpoint it should be preferable to alternatives like the company going out of business.
> I haven't seen many new open source businesses in the past couple years, and for good reason. Personally as an independent infra software developer, I don't think I will ever start a new substantial open source project again, and I very much hope that Fair Source (or something with similar intentions) is successful as a more sustainable model for new infrastructure products moving forwards.
It's possible that nobody ever really planned it. I honestly don't believe Hashicorp or Redis, Inc. ever planned it. That said, every company that executed one of these re-licensing efforts does have something in common: they all reserved the right to do so from the beginning. I'm not sure if they did so with the intent to ever actually use it, but I'm sure it had to be a consideration. Otherwise, why bother with a CLA over something more lightweight like a DCO? (Admittedly, I already answered that to some degree. Though, there are alternatives. My understanding is that the Apache Software Foundation CLA allows you to retain copyright ownership while still achieving most of the other functions of a CLA.)
Ultimately, I agree with you 100% regarding ZIRP. Even I, someone with relatively little finance and economics knowledge, can see pretty clearly how there is a direct cause and effect relationship here.
I'm honestly very glad that there are less open source businesses popping up. As I have said, I have no problems using "unfree" software or paying for software. If "fair source" is the answer that makes everyone happy it is not a problem with me. Though, I really hope people consider not using the SSPL.
I think more companies that really do want to do OSI-approved open source but are afraid of cloud providers should consider AGPL though. It is riskier, but right now it's toxic waste to all of them that I know of, and it will still make it very easy for Linux distributions to package and distribute your software. But if they choose closed-source or fair-source first to avoid the potential to mislead people, it's pretty hard to fault them.
A cynical view is that it's not just 2-3 providers, its any competition to their cloud-hosting business. See for example the recent wordpress drama, which concerns a small competitor.
SSPL and related licenses are ambiguous and scary enough to ward off anyone potentially competing with the copyright owner, and I doubt that's seen as a downside.
This is a really good example of why software with a license that is basically "this could hurt you but, like, trust me bro" isn't worth building with/extending/learning. It feels a LOT like a landmine waiting to detonate.
Even if I'm doing completely non commercial work I never ever ever will want to productize in any way I'd rather build my skills and familiarity with something portable (and I don't want to have to remember when I can and can't safely use each part of my stack). Anything else is just asking for a future nightmare.
The oracle and wordpress stuff recently are devastating. Can you imagine having to grind your entire company to a halt looking for anything that uses anything that uses anything that uses redis/java/whatever?
I'm an engineer. I can't justify a fixed amount of upside for an unbounded downside if I ever get on some stranger's bad side for whatever reason.
This feature could actually be the overwhelming value of acquiring the copyright. When trillion dollar companies go to war with each other this kind of thing is a fantastic weapon in the arsenal.
No one is expected to use any of the code licensed in this way commercially. You enter a contract with the vendor, tell them what you need, and negotiate a price. At that point, it doesn't really matter what the copyright license says.
So the entire license is just a bad faith trap? I could see it being used that way, potentially, but I don't believe that's actually Confluent's, MongoDB's, Elastic's, Hashicorp's, or Redis Labs' intent. In fact they've all explicitly stated the opposite. Are they all lying?
I don't think it's in bad faith. A lot of people still believe that they have to pay one of AdaCore/Baylibre/Embecosm/Red Hat/SUSE/Wind River if you want to use GCC commercially, to cover GPL-related risk.
