Red Hat Is Not Linux (2000)
web.archive.org
web.archive.org
Red Hat has always been open source. They have followed the letter of the license and still do. Not only that, they make big money! And they have employed and still do employ many top tier open source developers who contribute open source code to a variety of projects. The money they make makes all of open source better!
Their business model probably isn't for you, non-enterprisey do-it-yourself HN reader. But that's ok. There's absolutely no reason for you to be bitter or resentful about that because you have many other choices of Linux distribution available to you. All of which has been improved in some way by Red Hat.
I actually wish more open source projects followed the Red Hat model. Corporations making big money using open source would actually be paying the developers of those open source projects! That would be amazing!
I agree with you, Red Hat are a huge contributor to open source. Their business model lets them make money and then they use that money to contribute to projects in the wild. To me, it’s a win win.
I can understand why people would be upset with the changes. I don’t understand why they would be angry though.
The choice of down stream repackage distros has always been at RH’s convenience. This has always been clear since the day CentOS was a thing, and Rocky/Alma after it. Their product model depended on the whims of another product.
Now combine that with its new business leaders that promise explicitly to pare back efforts that don't help or even hurt the bottom line.
Would that make you happy with them? Sure, they aren't under an obligation to drive FOSS, but there is an obvious and notable change in direction here.
What notable change has their been to their contributions has their been? Please point to some reduction or drop in quality.
Without a concrete talking point, the statement is so empty that I could say the same about any distro, for example Ubuntu or Suse which also have commercial components to their businesses
"There was a time, not too long ago, that Red Hat found value in the work done by rebuilders like CentOS. We pushed our SRPMs out to git.centos.org in a neat package that made them easy to rebuild; we even de-branded it for them. More recently, we have determined that there isn’t value in having a downstream rebuilder."
These comments are explicitly about a focus on doing the things that directly drive revenue. Their actions correlate with their stated direction.
We can debate whether the direction is right or wrong for them (I'm explictly not making a judgment here), but the direction and intent are clear.
Whether they are effectively maintaining components for another distro is besides the point.
That does not make their direction or intent clear with regards to open source contributions
Do you think they will keep advancing spice as much as before now that they've deprecated it in their products?
More wood into fewer arrows means just what it sounds like it means.
Red Hat itself was mostly fine. I've competed against them and fought against their FUD. They're an enterprise software vendor no different from Oracle in this regard. But besides the sales and marketing knife fights necessitating unsavory tactics (everyone's does it), it was a mostly ethical decent business.
That said, as an old OS/2 fan and former IT executive that had to deal with large strategic outsourcing deals: IBM is not a trustworthy vendor, and plays old school dirty tactics in almost every large customer: from attempting to get people fired for questioning IBM, to near bribery. For this reason, I never want to do business with them or Red Hat unless I absolutely must.
Amen. IBM doesn't believe their customers are "developers" or "sysadmins"; they believe their customers are C-levels who will always come back. They miss the point that C-levels rotate out as previous devs and sysops rise up. That's how they lost the mainframe market, and the desktop market, and now the minicomputer market that they clawed back with RHEL. The cloud they already lost.
Or straight up bribery. An IBM exec in Poland pleaded guilty to bribing an government official to get a contract in 2012.
My guess is IBM and some RedHat people decided to be greedier than than they should and by shutting down access to the RH repositories somehow they think they can squeeze as many companies as possible to pay for Linux.
Terrible how good things are ruined by greed.
I disagree. I think the mistake was bringing CentOS in house: legitimising a free version of their own cash cow.
It is virtually Rule No. 1 of business: don't compete with yourself. If you are selling something expensive, don't later start to offer an unrestricted free version too.
I'm thinking a sudden change of view because of internal politics rather than an organic change as part of some master plan.
In 2019 the Scientific Linux developers announced they would stop development and collaborate on CentOS instead.
At that point Red Hat had captured the RHEL-clone world, leaving them in a position to destroy it.
I remember trying out PUIAS for a short time back when CentOS was having a lot of community issues.
I personally used CentOS for systems that I knew had a long lifetime ahead of them and for their use a distribution that could be "supported" for a number of years was the way to go. But since upgrading from CentOS 7 to CentOS 8 was such a PITA, I started slowly migrating to Ubuntu LTS which makes version upgrades painless.
I think they did. Place I worked had explicit direction to replace RHEL with CentOS to cut licensing costs. Most big companies would pay when they are force to pay and no free alternatives available that'd do the job. They won't pay just because it is nice thing to do.
Oracle then forked the distribution, and their presence far outweighs CentOS.
For those who would argue against this assertion, run the command "wsl.exe -l -o" inside a Microsoft Windows command prompt.
You will not find CentOS there, and you will not find Red Hat, but the coverage of Oracle Linux is quite thorough.
Red Hat has a long history of antagonism of their partners and users, and they have paid dearly for it.
> Red Hat made linux mainstream.
1. In the English-speaking world, mainly meaning North America.
For instance, SUSE is just as old, and brought Linux to the mainstream in Mitteleuropa. Not just in "DACH" (the German speaking world: Deutschland, Austria, Confœderatio Helvetica), but also for instance it was the first Czech-language distro. I worked for SUSE in Prague for 4 years, and it is still big in that part of the world.
Conectiva brought it to LatAm. TurboLinux to Japan. Etc., etc.
2. FSVO "mainstream" -- Red Hat Linux (note, not RHEL) was not really very useful as a desktop OS. I ran it, I used it, but trying to install something as complex as a desktop using raw RPM with no dependency management was nightmarish. That's where Mandrake came from: Red Hat refused to bundle KDE because Qt wasn't 100% GPL, so Mandrake ported KDE to RHL and bundled them.
Caldera was even earlier, and OpenLinux 1.0 with KDE was the first desktop distro I tried that was polished enough to make my primary OS for a while.
RHL was mainly a server OS, and as such, not very mainstream for most people.
I think that's what gp is saying: in the "enterprise" space, Solaris and HP-UX and Irix were kings. RedHat moved into that space by providing businesses the same model of support, while ALSO having a desktop version/free version for people to learn on.
RedHat THINKS they're still doing that with Fedora/CentOS Stream, but everyone disagrees.
They are doing that with the free developer licencing.
But it didn't, not back then. In the 1990s, and for most of the company's first decade in business, it offered a free distribution and made most of its money from selling merchandise. Which is to say, not very much money at all.
It's only around 2003 but its management hit upon the idea of having a premium enterprise distribution, and making the only way to obtain it being to buy commercial support for it. That was a stroke of genius, and over the last 20 years, it's made the company very rich indeed — in stark contrast to its first decade.
> while ALSO having a desktop version/free version for people to learn on.
Again, that split only came after about a decade in business. For its first 10 years or so, there was only the free version.
Also, more to the point, back when Solaris and HP UX were big, Red Hat was still very small and mainly in the business of selling T-shirts and mouse mats.
It's a bit of a generalisation, but to an extent, it was Microsoft Windows which put commercial UNIX out of business, followed by Apple macOS which showed that UNIX on the desktop could be as good or better than Windows.
Windows established a marketplace of COTS high-end x86 kit with decent graphics capabilities and capable storage subsystems. Apple successfully piggybacked on that to make desirable easy to use RISC UNIX workstations for consumers, using their own processors but otherwise pretty much off the shelf PC industry parts.
And those things put together are what created a marketplace in which Linux could thrive and compete effectively.
When Linux was first invented, a high end PC had a crappy VGA card on the ISA bus, and many of them didn't even have mice, sound or networking as standard. I was there. It was grim.
MacOS wasn't UNIX based until the big MacOS X rewrite which was around 1999, if I remember right. It felt very much like it was a reaction to Linux, especially with them making a big deal about how it was an Official UNIX(TM), not so subtly reminding us that Linux was not.
What really killed Unix on workstations was NT, and it killed it when the first sgi NT workstations shipped.
In the server space, Linux began to replace Solaris once you could run Oracle on Linux. That was the end of every other Unix.
In addition major new chrome (Cocoa, OS X Finder, etc.) Mac OS X originally included a version of the older Mac OS APIs (Carbon) as well as a Mac OS 9 virtual environment (Classic) for running older non-Carbon apps. It was really a chimera that included pretty complete Mac OS 9 ABI support as well as a Mac-flavored version of NeXTSTEP.
It's a bit of a shame that Apple keeps abandoning its backward compatibility layers (I hope Rosetta2 will be different) but I guess that's what emulators are for.
> What really killed Unix on workstations was NT, and it killed it when the first sgi NT workstations shipped.
'Cos it sure as anything wasn't Windows 9x that persuaded businesses that Windows was a legitimate OS.
Their enterprise support started around RH6, which was in 1999 and grew from there. It eventually morphed into RHEL because of the enterprise success, but didn't start with it.
And RedHat had previously already displaced Digital Unix for all the webservers by the end of 2001.
That's Switzerland (or if you're particularly pedantic: the Swiss Confederation) for those not brushed up on their Latin and Latin graphemes.
https://en.wikipedia.org/wiki/Geographical_distribution_of_G...
TBH I didn't even consider that anyone might not know where Helvetia was, but you're right, I should have mentioned that.
https://ecommercegermany.com/blog/the-complete-guide-to-unde...
But a lot of people don't know it, and as the terms are in 3 languages, its meaning is not obvious.
In another thread today, there are a lot of people upset and angry that they could not work out that a story about how an AI image generator can't create an image of a single banana, called the "AI lone banana problem" or something, did not say clearly that the problem was that an chatbot can't draw just one banana. And the story was really long at nearly 3000 words, which apparently is a 10-15 minute read and also apparently ain't nobody got time for that.
The HN commentariat does not always pick up on messages I would consider very obvious indeed... :-/
(And I didn't in the least find it pretentious)
I only learned the term a few years ago, while working at SUSE, and it fits a need I wasn't aware I had.
"The German-speaking world" is awfully long and yet remains imprecise:
* Are we talking about countries where there are some German speaking people? No -- that's probably every country.
* Are we referring to countries where there's a resident German-speaking minority? No. The USA has the Amish who speak "Pennsylvania Dutch" (among other minorities there among whom old folks speak Germanic languages) and that isn't Dutch at all but a Low Germanic dialect -- or a family of them.
Then there are the Volga Germans: https://en.wikipedia.org/wiki/Volga_Germans -- hundreds of thousands of German speakers around the former USSR.
* Are we talking about countries where German is the majority language then, like Anglosphere in English? The Teutonosphere?
* Oh, but hang on, then shouldn't the term be in German?
* Ah, but hang on, I do know a little German, and German speakers love coining new words by ramming existing words together, so it's probably been invented a dozen times. The Deutchsprachigewelt or something.
* Uhoh... maybe there is such a word but non-German speakers don't know it because they don't understand it, or they can't say it?
* And anyway, whose German then? Hochdeutsch or Schweitscherduutsch or Bayerisch or Swabish?
So I looked, and there is, and it's short and easy, and it cuts through the difficulty of two of the countries having different forms of German and the third having a really weird form of German but anyway it's not the standard language it's just one of four...
It's in German and English and Latin! Cool!
It is very much an open question whether they comply with the GPL by imposing additional restrictions on a license which states that you may not add restrictions.
From the GPL: "For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received."
The operative word being recipients.
Redhat may be the devil incarnate now that they apparently are a part of IBM... Though as far as this distribution change I don't see the problem.
To me this seems like a pretty clear cut case of adding restrictions to GPL code and risking getting those licenses taken away. It will be interesting to see if they face any real repercussions though.
That would be a restriction, in your example, but that is not what Red Hat is doing.
> Why is that OK but losing a very expensive support contract not? Does it get better if it's a month to month support contract?
Because in your first example, they are applying a restriction to copies of the software you have already received. That would be against the GPL, but that is NOT what Red Hat is doing.
Red Hat, if they were to terminate their support contract with you, does not affect any of the free software you have already received. You are still free to do with it as you like because there are no restrictions. But, Red Hat might not give you any _more_ software, and they don't have to because the transaction covered by the GPL for the software they already distributed to you was completely fulfilled.
Personally, I am doggone tired of people continually misrepresenting this point. Red Hat is simply __not__ violating the GPL.
>Red Hat is simply __not__ violating the GPL.
a particularly interesting thought to unpack. Because while this event isn't a violation, the 'jury is out' on whether or not Red Hat's entire business model is compatible with the GPL in the first place. One thing that we do know is that Red Hat has displayed willingness to violate the GPL in the past.
https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
>the pattern of “commoditizing your complement”, an alternative to vertical integration, where companies seek to secure a chokepoint or quasi-monopoly in products composed of many necessary & sufficient layers by dominating one layer while fostering so much competition in another layer above or below its layer that no competing monopolist can emerge, prices are driven down to marginal costs elsewhere in the stack, total price drops & increases demand, and the majority of the consumer surplus of the final product can be diverted to the quasi-monopolist.
What red hat is doing is commodotizing their complement, it's nothing more than that. One big example is that I would rather be using an OpenRC init system, but because redhat throws their weight around I need to use a systemd-based distro at work, to work on embedded systems (can't use ~~chroots~~ systemd-nspawn unless the host is also running systemd).
By throwing all this shit out for free they're able to destroy any sort of organic competition that might arise. Honestly I wouldn't even be mad, except a big chunk of it enterprise-ey shit and introduce major security issues just from how they're architected.
There's good and bad, but the problem is they make it very hard to just take the good and leave the bad. They bundle things together, like the decision to make Gnome depend on systemd, or the way networkd can't really be seperated from systemd, or renaming gummiboot to systemd-boot.
They also don't do a good job of disclosing what open source projects they have de-facto control over, and you're likely to find a lot of redhat employees in key positions in projects you didn't realize had anything to do with redhat.
That's literally the GPL.
> if you are a paying customer you get terminated if you share the code
And that's shit, but also the problem with tethering yourself to a single vendor. They don't have to do business with you.
There are plenty of other RPM enterprise vendors, switch to SUSE.
I have to question that.
Nearly all of my worst experiences when using Linux have involved software that they or their developers have, to the best of my knowledge, been significantly involved with creating.
I'm thinking of software like systemd, PulseAudio, NetworkManager, GNOME 3, and Wayland, for example.
I've wasted far too much of my time dealing with unnecessary, silly, and inexcusable problems involving such software.
What makes it even worse is that despite me trying to avoid their ecosystem, their software has unfortunately still made it into other major distros, including Debian.
After a few painful years though, the bugs got fixed in the "right" places, and that's part of why Pipewire (also developed by Red Hat) was able to come along and replace it so quickly.
And thankfully Pipewire addresses a lot of the actually legitimate issues with PulseAudio
However, whenever I started searching for solutions to the various problems I was encountering, I pretty much always found numerous other bug reports, mailing list threads, blog posts, Stack Overflow questions, forum posts, and so on, from other people running into the same troubles, along with other problems that I thankfully hadn't been experiencing.
It was clear to me that I wasn't alone.
Which is what this site and petition is about, at my first glance anyhow.
The Redhat that this last week has been on an anti-neckbeard crusade saying 'we aren't the distro for your type' to those of us who got them in the market is what is disappointing. It's like you help your friend become part of your larger friends group and then they ghost you when they don't need you anymore and are 'too cool' for you. So yeah, fuck off Redhat. They can do whatever they want, but they won't be getting any good will, and the petty anarchist in me will take advantage of any situations that come up to do ill upon them if it has a low personal cost.
Publicly stating you will “do ill upon” a multinational corporation sounds a lot like a threat, and we don’t do that here.
Now we have just fscking Linux, no apps, and RH is even closing it down. There you have your reasons. Open source my ass - that you can't even redistribute; it's just a big scam.
Update: fortunately there's still Mac OS.
Go download the source for Darwin.. https://github.com/apple/darwin-xnu
Compile it. Install it on your MacBook. Tell us how well MacOS boots that kernel.
So I resent them. It's the resentment of personal loss, not some grand philosophical stance.
Less than six months later, Redhat announced that the were going to discontinue RedHat Linux and start releasing their new RedHat Enteprise Linux. This left me rather angry and embarrassed. It was definitely a turning point in my understanding of FOSS. It also made me a lifelong Debian/Debian derivative user.
I've supported RHEL professionally, even getting RHCEs in it. RedHat has also contributed a lot to the open source community. But I've certainly never forgot that first pivot, so I'm not surprised with their recent decisions regarding RHEL's source code.
But I am a solid supporter of the "pay for RHEL or use Debian" philosophy. If you need promises about the future, pay for RHEL or use a project that doesn't have commercial motives. Debian is great and I wish more companies would standardize on it and support it.
I'm not such a fan of the middle road of hoping that vendors will continue supplying things of value for free. It's especially ironic that an insurance vendor got burned by placing a bet on a free operating system with no assurances whatsoever. The RHEL subscription is insurance.
Edit: I guess people don’t like Ubuntu that much
Ubuntu did a lot to popularize Linux and make the Linux desktop experience more usable. It struggled for a long time to figure out how to monetize that, though. They seem to be profitable now[1] claiming a growth in revenue to $205.4m and operating profit of $44m with a headcount of 858 (up from 705 the prior year).
The "Ubuntu Pro" move this year (which also raised many hackles, briefly) will probably pad the coffers a bit more.
[1] https://find-and-update.company-information.service.gov.uk/c... (See "Group of companies' accounts" through December 2022. The PDF link is atrocious.)
In this climate, that is a solid philosophy
I wish there were legal consequences when companies lied about future prices of things or durations of support.
Notes and presentations from various HEPiX conferences around 2003/2004 will reveal the reaction to academic licence fees for RHEL, and the birth of Scientific Linux as an EL rebuild.
Remember these were/are publicly funded projects with budget time-lines.
At the turn of the century the only ones paying for this linux thing we were all dedicating our lives to proliferating. Around this time solaris was teasing going open source and freebsd was on parity with linux. We had options then and we have options now. Redhat eventually relented, but here we are again. We've come a long way, now we're leaders and decision makers at our respective organizations. I've since abandoned redhat, I invite you to do the same.
GPL Version 3: "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License" (emphasis added)
Of course, there are good reasons to believe this violates the spirit of the GPL, but that's beside the point.
You get source to RHEL 8.5. You rebuild it (carefully removing Red Hat marks/logos to avoid being snagged for abusing the trademarks), and Red Hat says "ok, you're done. Go ahead and distribute that all you like, but we're cutting you off."
Your rights are intact, but your subscription and access are severed.
I've said this elsewhere: I don't think you or anybody really wants a GPL that can be used to force a business to continue its relationship with someone it doesn't want to do business with.
What's to stop a company from claiming that their subscription was really terminated for redistributing code and not because they failed to pay their bill or maybe because they were abusive to Red Hat support folks?
For that matter, what's to stop Red Hat or another company from removing that from their agreement but continuing to cancel subscriptions (or just refusing to renew) without stating cause?
People who think that this GPL provision is going to force Red Hat to just open the floodgates again and continue pushing out exact RHEL release code are likely very, very mistaken.
If Red Hat has decided to stick a spoke in the clones' wheels, it can simply release only GPL'ed code and stop releasing any non-GPL'ed code that doesn't require it. The current scenario with the code Red Hat releases to Stream is infinitely better in every way except if all you want to do is rebuild the "bug-for-bug" clones or consume them.
As far as I'm concerned it more than meets Red Hat's minimum requirements to comply with the GPL and as a participant in open source. Unlike scores of open core companies, all of Red Hat's features and innovations are being released - the sole thing being held back is exact clones of its product.
Note that this particular requirement got a fair amount of attention in 2011 when Red Hat changed its kernel source releases and stopped breaking out patches. (Here: https://lwn.net/Articles/430098/)
In some ways I think of the GPL(s) like the Bill of Rights. Great document, great ideas behind it - falls flat in some respects today due to age and ambiguity.
I'm fine with generic kernel builds and that's what I usually use, but I don't think tweaking your kernel is as painful or manual today as the greybeards here remember.
Back then, we went into "make menuconfig", and meticulously reviewed every single configuration option, carefully tuning them to our bespoke hardware; it only took a few hours. Try doing that nowadays; there's simply way too many configuration options (each new device driver adds a couple, and even the kernel core has grown to hundreds of them). So yeah, I'd say fully tweaking your kernel is a more painful process today than in the past.
(The same for packages; back then, we could open "dselect" and page through all the available packages in a single evening; nowadays, there's too many of them.)
Even back in the Gentoo days, when we measured the differences, they were underwhelming.
They’re not following each dependency, building it, then testing it, debugging etc…
That’s not a judgement on them. I wouldn’t want to do that either. I just meant to say that they “feel” different to me, even if the end result is the same.
Well, I've got something to tell these 127 people from 2000 about SCO who have an issue with RedHat about some impending doom in 2003 [1] ;-)
[1] https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes
Their heel turn happened after a management change. The whole debacle was stranger-than-fiction (at least at the time). The whole "we're SCO now, and we're evil" was just bonkers.
The lesson that people should've taken from that, though, is that any company is just one management change away from major changes.
My understanding is that Red Hat Enterprise Linux can be thought of as Fedora + stability + patches, and that the patches themselves should be released downstream as part of the GPL.
What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. This has made it more difficult for "repackagers" like CentOS, Rocky and Alma to keep their disros up to date.
Assuming I have the above correct (and I may not), my suspicion is that Red Hat is looking at cloud providers who also have been repackaging, for example, Amazon Web Services' Amazon Linux has historically been RHEL repackaged and bundled with some aws tools. I'm not aware of AWS distributing their changes either. From this perspective, it looks like the AWS benefits from the stability + patches without paying RedHat for their development. (I'm also not aware of whether aws distributes the Amazon Linux sources and if so those are done in a way that is useful for the community... I'll do some further research on my own. edit: It looks like the Amazon Linux sources are here: https://github.com/amazonlinux/linux)
From what I've read, what's actually making people grumpy is that signing in to download the sources, and later giving these sources to anyone else, could risk losing your RHEL account.
If I download everything and advertise a rebuild based on those sources? I'd expect that my subscription will be going away soon. There's probably a line somewhere in between where Red Hat would take notice and care.
But I would wager a good bottle of Scotch[1] that line is much closer to "everything" than a maintainer grabbing Red Hat's changes to their work via a sign-in to the no-cost account and incorporating those changes or something like that.
[1] Say, Auchentoshan Three Wood or something good but not like 30-year-old Speyside. I'm not made of money...
Because if they distribute a copy to an individual, RHEL account access banned or not, distribution of binaries puts them on the hook for providing sources. Unless there's no way to buy a single copy as a random stranger, this all seems incredibly impractical to enforce.
In any case: Red Hat giving you a copy of RHEL only entitles you to source for that version and not future (or past) versions.
So if you somehow receive RHEL 8.5.1 from Red Hat on media independent of a subscription, you have the right to receive the sources for GPL'ed software present in that release.
Not RHEL 8.5, not RHEL 8.5.2, etc. And, technically, you only have the right to source to GPL'ed software, so they don't have to give you source for Apache HTTPD or other permissively licensed software in RHEL.
An interesting wrinkle that I haven't seen addressed yet is whether Red Hat has to find a way to convey source to you after the subscription if you had access to download source during the subscription but didn't exercise it. It was there, you just didn't take it. If you want it later, do they have to ship you a DVD or something? I have no idea.
> the patches themselves should be released downstream as part of the GPL.
The GPL only says you must provide the source to your customers. Not to anyone else. It does not compel you to offer them the world, gratis, no, not if you don't want.
The situation is actually (c) - IBM RedHat is distributing the patches (and sources) as required by the GPL, but only to people who pay for their license. Re-distributing said patches or sources automatically invalidates your license, so if you exercise your GPL rights to re-distribute the GPL code you bought from IBM, you immediately lose both your support contract with them and any access to any future patches.
This has meant that many companies and projects who were historically using CentOS for free have found that they either have to pay IBM to move to RHEL, or to switch to another distro. Projects like Rocky and Alma which were trying to replace CentOS are now on rather shaky grounds (though they are trying to find additional ways of surviving).
Also, folks are realizing that Red Hat's subscription agreement allows it to terminate the subscription (and access to future source code) if someone redistributes code (including GPL'ed code) in a way that Red Hat doesn't like.
People who misunderstand the GPL are accusing Red Hat of violating it by not widely distributing RHEL source to everyone.
People who sort-of understand the GPL (or willfully misrepresent it) are accusing Red Hat of violating the GPL by "restricting" the ability to redistribute sources. IMO it is not, because customers have all their rights to the code they receive under the subscription prior to termination - they simply are blocked from later releases.
Red Hat has basically acknowledged that it "sees no value" in a free RHEL clone, and is under no obligation to make it easy for clones to exist - so it's not going to anymore. It prefers you use Stream or pay for RHEL or do something else.
I've been writing about this a lot on my blog, starting here: https://dissociatedpress.net/2023/06/24/red-hat-and-the-clon...
(Disclaimer: I'm a former employee of Red Hat, so I am potentially biased one way or another.)
Ultimately, the issue is RedHat thinks people should be using centOS stream if they don't need enterprise support and a significant part of the community just want RHEL but free.
> What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal.
My understanding is a bit different:
Red Hat submits patches upstream and also back-ports those patches into existing RHEL releases that have long-term support.
The upstream patches are still as open as ever, nothing has changed.
The back-ports into existing RHEL releases are what Red Hat is trying to make harder for people to consume outside of a Red Hat subscription (the free developer subscription and the paid support contracts).
I'm not making a judgement either way in this comment, just trying to help clarify my understanding.
That’s an interesting detail. Thanks!
[1]Has Rakuten made a Rocky-er road for Red Hat?
https://www.mobileeurope.co.uk/has-rakuten-made-a-rocky-er-r...
I've always been a user of the Debian and Arch worlds. The RHEL/Fedora/etc world has been this "other" part of Linux that I frankly haven't touched much, and haven't yet found a reason to.
One thing I'm not totally clear on is what specifically Red Hat offers that people pay for, i.e. what are the details of the "+ stability + patches" of what GP mentioned. Are there paid applications as well? Is paid support a large part of the business model? And so on and so on. I'm still just a little mystified by the RHEL business model, and every time I hear someone talk about it, it's literally vague one-word answers such as "stability," "patches," "support," "enterprise stuff," etc. Even the RHEL FAQ offers essentially just that.
I'm still not quite informed enough to be able to confidently lean one way or the other, but I have to say that I can't shake the feeling that RHEL's business model ultimately relies on exploiting their customers' desire to change their systems as little as possible, even if it means the customers eschew more modern systems that make obsolete the need for the kind of products and services RHEL provides. Or to put it another way, RHEL enables their customers to live with "the devil they know," and not adopt more modern best practices. Which isn't necessarily a bad thing, I get it, but also if that is indeed the case, it seems like a rickety foundation upon the already rickety foundation of trying to sell open source software that easily be unseated by, say, the nix model of doing things.
I don't know, I could be dead wrong, but starting from what I've seen most other tech companies do and mixing it with a dash of "the idea of paying for Linux seems insane to me"...in lieu of better information, I can't dismiss the above out of hand.
Very, very generally, updates tend to play better with or expect that the software it's working with is also updated; and so, while yes it can be stable to stick with a particular version for 10+ years, the value of that stability drops as time goes on, as the software/OS in question has more and more trouble operating in the context of/with other/newer software, and so 5+ years into that 10+ year timespan, that stability you're supposedly paying for doesn't feel very stable at all -- and that doesn't even begin to touch what happens once those 10+ years run out and you need to get with the times.
Which is all to say: this is why rolling releases exist. Better to get used to surfing the wave all the time, rather than sitting on the beach for years and then having to swim an Olympic race after you're out of shape. I'm mixing metaphors here but you get the idea.
What's more, obviously riding the wave can be a little tiring, and thus more and more best practices are borne out of that problem -- which is why I mentioned nix in my last comment. I'm not even a nix user, have never done more than read about it, lest one think that I'm yet another nix zealot on HN, but I do think that it or something like it is a very very good solution to the pains that can be had by constantly staying up to date. I for one will always be more interested in that kind of route, rather than agreeing to the golden handcuffs of long-term support. While not in a RHEL-like setting, I've been bitten by the "I just want this old thing to keep going and never change" problem too many times before.
Like, I was listening to the most recent episode of Linux Unplugged, and they had a member of the RHEL team on, and when asked about the value proposition of RHEL, he said something to the effect of that it's not just the software, but being able to offer the specific versions with the specific patches in particular combinations of other software with whatever patches. And I couldn't help but think -- isn't he basically just describing nix? Nix's whole thing is to super easily enable declaring specific versions of software in specific combinations, and to be able to recall it with a config file -- Matthew Croughan's talk at SCALE this year was essentially...that, and doing it super easily. And perhaps if we aren't keeping so much old software alive, it wouldn't all need so many patches to allow all the various combinations required.
I don't know. It all seems like a very heavy-handed, people-y solution to a problem that we've mostly solved, and perhaps even eliminated the conditions for to exist in the first place.
Anyways, this is all mostly hypothetical pontification, and I'm sure that those who actually work with RHEL on a daily basis could poke tons of holes in my point of view. Would love that actually, as like I said I feel very much like an outsider looking in. But it just seems like a goal that is fundamentally flawed.
For those enterprises, the value of the stability RHEL provides goes UP as time goes on, because the longer you wait, the more risky and costly it is to migrate to the new version/solution/etc.
The final product includes support; nobody is asking for that. There is no expectation for dedicated engineer time or solving their support cases. Nor is there any expectation of certifications or any other value-adds that RH provides.
Afaik the cloners demand the access to sources and patches to what is being shipped, which is their right. They are GPL, and not Redhat's for most part.
Just about everyone. The final product is RHEL in this context.
> which is their right
No, as per the GPL they only have to provide sources to paying customers.
If they were providing binaries only to paying customers, that would be right.
But they aren't. Anyone, who spins up RHEL VM in the cloud, uses UBI image or downloads it from the developer account has the same right.
In all cases, RH cannot prevent anyone, who obtained the sources, from distributing them further; not even threatening with contract termination. That would be "further restrictions", which GPL explicitly forbids.
Sorry, but yes there is. The final product includes the outcome of all that. Especially the minor and z-stream releases are the culmination of all the work of customers reporting bugs and Red Hat applying that dedicated engineer time and solved support cases to the next release.
There are many companies (including the one I work for) who treat clones as equivalent to RHEL. So, yes, it effectively conveys many of the certifications and system requirements to receive support from other companies. The clones have been promising "bug-for-bug" compatibility for a reason, and that reason is (in part) to ride the certification coat-tails.
If these things were not true, there'd be none of this drama. Rocky and Alma could easily base Linux distros off Stream and do additional testing and add or modify features to be more interesting. The code is there. The product is not.
Aren't these supposed to go into Stream?
> So, yes, it effectively conveys many of the certifications and system requirements to receive support from other companies. The clones have been promising "bug-for-bug" compatibility for a reason, and that reason is (in part) to ride the certification coat-tails.
Yet, it is not the same as certifications. Certifications apply only to the original RHEL; clones are in the gray zone: it should work, but if there are problems and you need to use them, you better have it on RHEL.
> If these things were not true, there'd be none of this drama.
The drama is there, because RH/IBM thought, they could squeeze those customers, that use both CentOS and RHEL (usually CentOS for dev or staging and RHEL for production); they wanted it all.
I can understand if those companies file support cases that originated in CentOS and RH things, that they abuse their support contract. That's not OK. But RH has it's own skeletons in closet, too.
The clones themselves are a collateral damage there.
Basically - there's never been a bug-for-bug compatible RHEL clone that shipped quickly until Red Hat made it possible to do.
Stream isn't a product, it's a project. And it should be a project. If Rocky or somebody else wants to add value and make it a product, they can do the work to do so. Rocky/CIQ, in particular, has made all kinds of noise about how Rocky is the "stable foundation you can build on and rely on for years to come."
Well... Red Hat has decided to stop making it super-easy. It's a bummer that this hits users who were never potential revenue sources for Red Hat/RHEL, but I can just hear investors asking "why the ever-loving ** are you making it so easy for others to clone your biggest product?"
[1] https://dissociatedpress.net/2023/07/03/red-hat-and-the-clon...
It is telling that no one in the meeting could actually answer that: "We still face formidable competition, and we do not believe our moat will hold for more than 12-18 months before whatever replaces us in the market emerges and begins rapidly eroding market share, resulting in dwindling profits and share prices. By allowing an unofficial free-tier -- a clone, as you say -- of our enterprise product, we keep developers from rapidly switching to Debian and it's derivatives. Once that happens, the hosting and enterprise data center markets will collapse irretrievably leaving us with only legacy customers who will leave, one server age-out at a time."
An elegant weapon for a more civilized age.
That was so disappointing.
Waiting to see which of the two alternatives shakes out.
Dangerously past EOL on some servers, I just don't have to motivation to rebuild.
There are not just 2 and never were.
Oracle is, you know, quite big and fairly well known.
It's also much older than either Alma or Rocky.
So is Springdale Linux, formerly PUIAS Linux:
https://springdale.math.ias.edu/
EuroLinux is also a thing for the wider world, i.e. outside North America:
https://en.euro-linux.com/eurolinux/what-is/
In Japan there is Miracle Linux:
https://distrowatch.com/table.php?distribution=miracle
In China there is Euler OS:
https://developer.huaweicloud.com/intl/en-us/euleros/index.h...
There was also Inspur K-UX:
https://en.wikipedia.org/wiki/Inspur_K-UX
Both the latter were even officially UNIX™ certified.
I am sure there are many more I don't know about.
After Red Hat, Ubuntu was the one that people would think was all of Linux.
This doesn't just happen in operating systems. I've talked to several people who seem to think AWS is literally the only way to run a server, and have it as their baseline assumption at all times.
Every install is different. There's no platform to target. No API levels or anything like that. The Linux idea of compatibility is "You can make it work, with a hammer, if you spend a half hour".
I fully believe that it would be easier to add the missing bits to Android, to make it able to replace "Real Linux" even on servers, than to get Linux to a state that was fully ready for the Year of the Linux Desktop.
I used to think it was being held back by big tech or something.... but as time goes on, I realize it's more about the fact that Steam doesn't work on my laptop and I will probably have to spend 20 minutes fixing it, and this is on Mint.
To do that they need to be commercially successful.
Now, you can argue whether the recent moves are helpful to their bottomline or not (I think this is short-sighted and in the end will hurt them), but we need to acknowledge they are not charity, and also that we all are already benefiting from their money and their work.
But sadly times change. Get it, they want to make money, but doesn't change the sadness these recent moves have caused.