Oracle: Keep Linux Open and Free—We Can’t Afford Not To
Anyone who uses Oracle Cloud is either directly or indirectly using Oracle Linux. Oracle Cloud is 2% of the cloud market, so it's small compared to the big three (AWS ~32%, Azure ~23%, GCP ~10% according to this report) but 2% of a very big market ($237 billion total estimated for 2023) is still a significant user base.
From my own work, most of the Oracle Cloud adoption I see appears to be driven by favourable prices for Exadata Cloud as compared to purchasing on-prem Exadata hardware. Oracle Linux is also baked into Exadata "Cloud-at-Customer", which has essentially the same cloud control plane but the hardware and all data lives on-prem at the customer's site. That seems fairly popular with customers who want Exadata performance but can't allow their data to leave their premises for security reasons.
Non-southerners beware, flour that grows well at higher latitudes is "harder", i.e. has more gluten, while wheat from the south is "softer" / less gluten. You may need a softer flour to make really great southern-style biscuits, and that can be tough to come by outside the south.
I hate that companies can rug pull things their customers have enjoyed, and come to rely on for such a long time.
Yeah, that's probably part of why I feel so strongly about this. I relied on CentOS in my dev/test pipeline for years, so I'm effectively one of the individuals that was rug-pulled. Will Red Hat now try to squeeze us for license revenue again, at a time when sales are tight and cost controls are even tighter? Will I need to rework my dev/test pipeline to use AlmaLinux or RockyLinux, and maybe rework it again if Red Hat's restrictions end up making those not a 1-for-1 replacement for RHEL testing? The uncertainty is unwelcome.
But if they had restricted it in the first place and no one ever built things on top of it in the first place - I am not 100% convinced that is as morally wrong.
Possibly not, though I have to wonder whether Red Hat would still enjoy their current market position if they hadn't been allowing this to begin with. That others could easily build on top of what they built is part of what made RHEL probably the dominate enterprise Linux distro on the market today. It's the one I see installed most often at customer sites at any rate.
I'm not sure this maps 1-to-1, but it feels like Red Hat might end up enshittifying their own OS in an effort to extract more revenue from it. Doing so could easily backfire on them. Any restrictions they add to generate more revenue also add friction for third-party developers looking to interoperate with the OS. Some of them may choose to stop directly supporting RHEL as a result. Too much of a pain, let some RHEL customer take care of that. But most Red Hat customers are paying for RHEL because they don't want to do those sorts of things. They want to install the OS, install the software they need, and get on with whatever their core business happens to be. Over time, this could corrode the value of RHEL itself.
You (and seemingly everyone else) seems to be ignoring the fact that the source package is not just GPLed software. Not all packages are under GPL but even the ones that are consist of the GPL application code and the spec file used to build the source. This spec file (and related package files not from the original application) don’t need to be under the same license as I do not think it counts as derivative work - it is not linked into the final binary at all.
I downloaded a GPL'd source RPM (glibc) out of curiosity and extracted it, and there's not much licensing information to be gleaned there. The only license I could find in the package is the GPL itself. Aside from the source code, the package contains a whole bunch of .patch files, the spec file, and a few other scripts. With no copyright header on the script files and no other license files, it's not clear what license they're held under. I would expect the GPL as well, based on that, but who know. As for derived works, let's see what the GPL has to say about those (I know there are other licenses, but I'll stick to this one for now):
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
So whether a spec file can be held under a separate license from the GPL depends on whether it "can be reasonably considered (an) independent and separate work." Does the spec file have value in isolation? To me it would seem like it wouldn't, it can only provide useful functionality when combined with the GPL'd source code. To my mind that would make any packaging specifics derivative work under the terms of the license. Also, the spec file is not distributed "as (a) separate work", you download it with the GPL'd source code as an atomic unit. That to me would be another point in favour of considering the spec file a derived work.
Not a lawyer so I don’t really know how these interplay, but to me it seems that they have some grounds to do what they did. Even if I disagree with their actions are the right move for them to make.
I'm not lawyer either of course, and I regret not saying as much in the original post. Whether Red Hat can legally do what they're doing... no one can actually say with certainty. We'll only find opinions of varying degrees of quality, but we won't have any certainty on the subject unless and until there's a court case that sets a precedent. Personally though, I am 100% convinced that what they're doing is morally wrong, no matter what the letter of the law says.
On one side, you have Red Hat, a long time champion of open source software, that has poured billions of dollars into open source development, and which has 1000s of employees who not only on ‘company’ time but in their own time manage, develop, contribute, and create open source code. They have funded countless successful and unsuccessful projects that we all use.
As far as I'm concerned, this is simply not relevant to the issue at hand. Yes, Red Hat has made many, many contributions to open source over the years. That is beyond question, and I thank them for it. It does nothing to excuse their current behavior though. All of those contributions were freely made under the GPL. Red Hat cannot retroactively say "well, we've made enough contributions that we think these shouldn't be free any more, please pay us money." Under the GPL there is literally no threshold where that is allowed.
Red Hat knows this of course, so instead they're putting the source behind a click-through license agreement. In order to access their source trees you now have to agree to their license, which states that you're not allowed to redistribute what you've been given. Of course the GPL also has language specifically designed to prevent such attempts. There's a "further restrictions" clause that allows those receiving GPL source code to remove any further restrictions that weren't in the GPL originally. That would allow Red Hat's customer to legally redistribute that source code, as was always intended under the GPL.
But Red Hat lawyers know this too! They know that their customers have the legal right to strip off the extra restrictions imposed by that click-through license wrapper. So how then do they enforce this restriction? With threats and coercion. "Forgo your GPL rights, or we'll stop supporting the software we sold you / deny you any further access." What amount of past open source contributions make it OK for Red Hat to threaten their customers in an effort to prevent them from exercising their rights under the GPL? I say there is no amount of past contribution that makes Red Hat's current behavior acceptable, just like there's no amount of past contribution that would make it OK for them to close the source entirely.
Here’s the interesting part for me. As far as I can see, none of the users are jumping to the Rebuilder’s defence of Red Hat’s accusation that the Rebuilders provide nothing back to the community.
I'll be happy to do so. At least some of the users of downstream distros are using them so they can validate the compatibility of their code with RHEL, without having to subject themselves to Red Hat's licensing terms. Jeff Geerling is one such example. They are (or in some case were) providing direct value to Red Hat's customer, and thus indirect value to Red Hat themselves, by validating that their own contributions would work in RHEL. Red Hat's choices make their efforts harder, and call into question whether FOSS contributors should continue to make efforts that indirectly benefit Red Hat.
Personally, the company I work for has been using CentOS for many years because Red Hat wanted to place onerous licensing restrictions on any use of RHEL in the cloud, which is where most of our testing is done. To be clear, my company doesn't use RHEL internally on its own production systems, nor do we redistribute it in the products we sell. The only reason we care about testing against RHEL is because many of our customers use RHEL on their production systems. Our only motivation is to make sure that our products work correctly when they interoperate with RHEL systems at our customer sites. Are we "taking" from Red Hat by doing this? I say the opposite. Our customers benefit directly, and Red Hat benefits indirectly when such mutual customers can do more and better things with their RHEL systems.
And let me tell you, Red Hat has not been fun to work with. We're a member of their partner network, we're doing this testing so we can help our mutual customers do the things they want to do, and Red Hat has been a pain in our ass at many turns. Their awful account management makes it harder to onboard new employees and get them set up for testing on RHEL. Red Hat threw licensing curveballs at us like "oh btw cloud usage is no longer covered under the partner license, move all your testing on-prem in 30 days or pay us $texas, kthxbye!" (We scrambled and switched to CentOS in the cloud in record time instead.) They subject us to annoying, time-consuming audits. CentOS for testing is a breeze by comparison, with no need to worry about accounts or audits or subscriptions or entitlement usage.
Also SponsorBlock! Watching a video on Youtube is much nicer when you don't have to manually scrub through the interminable VPN sales pitch.
Believe me, there are certainly days when I wish I didn't have anything to do with Oracle. 🙃