Red Hat strikes a crushing blow against RHEL downstreams

Red Hat has decided to stop making the source code of RHEL available to the public. From now on it will only be available to customers — who can't legally share it. A superficially modest blog post from a senior Hatter announces that going forward, the company will only publish the source code of its CentOS Stream product to …

[Flocke Kroes]

GPL violation

Although Red Hat only need to supply source code to direct recipients of their binaries they are required to supply that source code with a GPL license - not GPL with restrictions. By tacking extra restrictions onto the license Red Hat are violating the GPL and lose their license to distribute GPL code for which they do not own the copyright or have some extra license from the copyright holders to distribute with a more restrictive licence.

Red Hat should expect letters from lawyers reminding them of their obligations.

[TrevorH]

Re: GPL violation

Hello Debian!

[andrewj]

Re: GPL violation

Agree. The TL;DR is "get stuffed Redhat".

[Orv]

Re: GPL violation

I like Debian but I really miss the central monitoring capabilities of Red Hat Satellite Server. Being able to see at a glance which of my servers are up to date is pretty important. I've searched high and low and still haven't found anything that does this for Debian or Ubuntu.

[bdeluca]

Re: GPL violation

ubuntu has this if you pay

[Nate Amsden]

Re: GPL violation

I think mostly true however to stay true to the spirit of the license if a customer wanted to redistribute the source they got from Red Hat they'd have to strip it of any trademark type stuff first, if that is done then really nothing Red Hat/IBM can do(provided the underlying license for the source package is open source).

[brotherelf]

Re: GPL violation

Yes. (Which was exactly how CentOS operated way back when, and which is why CentOS releases trailed the RHEL counterparts by months – not only did you need a working build farm, but you also needed to at least take a cursory glance at many, and replace some, packages.)

[mark l 2]

Re: GPL violation

The question comes from who is going to pay for those lawyers? IBM have very deep pockets and an in house legal team, so it would take someone with a lot of money and a vested interested to try and sue them for breach of the GPL. So from the existing RHEL compatible distros I only see Oracle as having deep enough pockets to try and take IBM to court over it.

[John Savard]

Re: GPL violation

When the wording of the GPL is clear, plain, and obvious, and the violation of the contract is clear and direct, even the very limited amount of legal counsel the FSF can afford from donations should suffice.

[Missing Semicolon]

Re: GPL violation

This is American law. If you have lots of money, you argue black is white until the other side settles.

[Plest]

Re: GPL violation

Ever heard of the phrase "pro bono"?

When something is so clear cut you cannot lose, then the kudos alone is all the payment you need becuase the great PR alone will generate so much business. Lawyers are business people who know how to argue and any smart businessness person knows when they're on to a winner!

[Wzrd1]

Re: GPL violation

The problem is, when dealing with Corporate America, such cases can get continued so often and for so long, before the case even gets in front of a judge to be heard, a decade or more can pass.

That's one hell of a lot of pro bono billable hours to sacrifice.

But, never fear, the Hat and Big Blue will continue to get their free alpha and beta testing done by Fedora and CentOS users.

[Anonymous Coward]

Re: GPL violation

AmazonLinux is Fedora-based. Maybe AWS would take it up. Could gain some public opinion favour, something Amazon sometimes needs.

[captain veg]

Re: recipients of their binaries

What if I obtain the source, via whatever means (e.g. a legit free dev account) and compile the binaries myself? Given the right compiler (er, gcc probably) they will be indistinguishable from "the real thing".

-A.

[Grogan]

Re: recipients of their binaries

To that, all anybody could say is "good for you". You're allowed to compile source code.

If you distributed them they'd object to your use of trademarks and logos but if you take out their branding, you'd be within your rights. (This is what downstream distros do)

I don't think they could successfully bind you to that NDA if you defied it. They'd have to sue you, and that's different. Defending yourself is not the same as bringing suit against a big, deep pocketed company.

Then again, all it takes is a Republican judge. Justice is quite crooked in the U.S. IBM will undoubtedly have more practice sucking political dick.

[xylifyx]

Re: recipients of their binaries

You dont need to distribute the source, do some analysis and cherry pick the patches from CentOS stream that is equivalent. It might be possible to automate it.

[Soruk]

Re: recipients of their binaries

Have something that automatically sucks down all CentOS Stream source packages, and with a developer account grab the RHEL sources, but instead of building them, use them to compare patches with Stream ones. Hopefully if an RPM build version tag matches between Stream and RHEL the patch set is identical so use those version tags to choose which Stream source packages to pick up.

[Doctor Syntax]

Re: recipients of their binaries

"They'd have to sue you, and that's different. Defending yourself is not the same as bringing suit against a big, deep pocketed company."

To which the response might be cease and desist letters from various copyright owners for being in breach of the licence for the software they're distributing.

[Wzrd1]

Re: recipients of their binaries

I've gotten cease and desist letters. As they were without merit, I filed them away and ignored them.

Cease and desist have no real power, they're only a warning that you might bring litigation and you really don't need them to do so.

If litigation is filed, IBM can then have their attorneys get continuances for a decade or more before the case even sees the inside of the courtroom. By then, there might not even be an IBM around.

[Yet Another Anonymous coward]

Re: recipients of their binaries

>Cease and desist have no real power,

Before we can qualify you as a supplier for $BIG CONTRACT can you confirm there is no outstanding legal issues ?

ps you aren't allowed to explain it's a check box on the form.

Lying on the form means we get your first born and can kill your dog

[TheWeetabix]

Re: recipients of their binaries

.... what?

[Yet Another Anonymous coward]

Re: recipients of their binaries

I'm saying that irrelevant legal letters can still cost you time and money if you end up having to get a lawyer to write to a customer's lawyer to say that there is no real legal threat.

It gets worse if the customer is a government and therefore cannot be logically argued with.

Or somebody is trying to get out of a deal and you didn't disclose an "outstanding legal threat"

[Lucasjkr]

Re: recipients of their binaries

The issue would be that they would simply cancel your account so that you could receive and redistribute future versions. That’s the whackamole the article alluded to.

[John Savard]

Re: GPL violation

Precisely. This point was missing from the article. Red Hat will indeed not be in compliance with the GPL when they implement this policy.

If they want a free UNIX-like operating system that they can turn into a proprietary product, they will have to do what Apple did to make OS X. So long Red Hat Linux, hello Red Hat BSD.

[andro]

Re: GPL violation

Yeah, they are burning their actual customers. Companies who can self support and want free Linux have many options. For RedHat to stay in the game, they need to have a free option too. The developer licenses are too encumbered to be used how we need. I work for a large organisation that has a site license for RHEL. I used to run Centos on my home PC servers where I keep my skills up to date, and for some stuff I run on VPS on the public internet. I also used them for convenience even where our RHEL site license had me covered. They still got paid. I moved them to Alma when Centos died, and I have no interest in stream. I am not the only one with no interest in stream too - if the centos-devel mailing list archives are still available you can look at the size of the monthy tarballs and you can see just from that when they lost the community. They jump from consistently 100Kb - 2Mb compressed until December 2021 then not one month since has reached 100Kb in content since.

With that move a lot of people moved to alternate free clones, a lot moved to other distros. Now with containers being a more popular hosting solution, cloud native, Azure Linux, RedHat have missed the boat creating their own cloud which they could have charged for while funding a Free OS.

Personally I have decided to invest the time in learning the Debian / Ubuntu ecosystem. Thats 25 years of experience in their platform moving away. And I suspect there are many. Now its Ubuntu LTS in WSL on Windows on my workstation, Ubuntu in VMs, and while my Alma boxes are still switch on, if RedHat don't change course they will not be replaced with RedHat ecosystem products.

And here is the clincher, I am a decision maker in places where they still pay for RHEL. I was happy to spend my employers money on their support, even though we rarely need it, but now I think the path points to Debian, Arch, or another commercially supported OS in a container platform, and I am saying so when decisions are being made about the RedHat license.

[hoola]

Re: GPL violation

Red Hat is a huge corporation making money selling and supporting their version of Linux.

To me the choice is very simple, it you do not want all the bits that come with an enterprise subscription for RHEL, use a completely free version. The arguments on ElReg are often around how many free versions of Linux there are available.

In this case Red Hat has made a commercial decision that to use RHEL you will need to buy a subscription. For all the good sides of Linux and Open Source it is also one of the risks. As you say, it should be a relatively simple process to move away.

[Anonymous Coward]

Re: GPL violation

It's pretty sneaky.

Under the GPL, Red Hat doesn't have to give you the sources unless you get their binaries.

You don't get the Red Hat binaries unless you agree to their terms, which includes not giving out sources. Those terms *override* the GPL.

There is no GPL violation.

If you distribute the sources (which includes non-GPL code) you violate the Red Hat agreement. Red Hat can take legal action and/or refuse to sell you binaries.

If you think IBM won't take legal action, I refer you to "IBM vs SCO". IBM probably has more lawyers than the Reg has readers. There is not a hope in hell that FSF can out-lawyer IBM.

[unimaginative]

Re: GPL violation

You do not get it.

Red Hat's customers may have agreed not to redistrubute it, but the copyright holders have not. Red Hat only has a licence to distrubute source or binary subject to the GPL. If they "override" the GPL then RHEL is pirated software

[Adibudeen]

Re: GPL violation

And the copyright holders include a lot of people and companies. IBM/Red Hat should be expelled from the Linux Foundation and held accountable.

[Dan 55]

Re: GPL violation

They aren't overriding the GPL, because the GPL stipulates you should be able to ask for and receive the source code to the software if you own the software in the first place. We're all used to going to a website and downloading the source code whether or not we own the software because that's the easiest thing for the developer to do but that current practice is beyond what the GPL offers.

No licence for the software means no ownership of the software. No ownership means RH don't need to offer you the source code either.

So RH become another dead-end leech in the FOSS ecosystem. Hopefully though this will be the incentive the rest of the ecosystem needs to finally put systemd and pulseaudio in the bin.

[Doctor Syntax]

Re: GPL violation

"No ownership means RH don't need to offer you the source code either."

No they don't - not unless they also provide you with the binaries and providing binaries happens to be their main business.

When they do that they are obliged to provide the source of those binaries to any recipient who asks for it. They are obliged to provide it by the licence which is carries. They are obliged to provide it under the same licence. That licence specifies that with limited exceptions any additional restrictive conditions may be removed by the recipient.

This applies to any code derived from code originally distributed under the GPL. Changes to the code do not change the licence but they do make the binaries a derived work and it is the changed code with RH modifications which the customers receive .

[Dan 55]

Re: GPL violation

I don't think we're disageeeing.

Now what happens if Alma or Rocky Linux never get a RHEL licence because RH refuses to licence it to them? They don't get access to RHEL's source code and can't make a derivative of RHEL.

[FIA]

Re: GPL violation

Isn't the point that the GPL stipulates 'without restrictions', which would seem to contradict T&Cs from Red Hat that say you may not distribute the source?

If you're a RH customer and are invested in their ecosystem, you probably don't want to lose access to that as it would incur a significant business cost.

That sounds like a restriction?

Section 10 of the GPL 3 says....

10. Automatic Licensing of Downstream Recipients.

Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.

An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

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, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

[Dan 55]

Re: GPL violation

Even the GPL says that you can sell software but only make the source available to purchasers.

Someone might want to freely redistribute that source to the public after they've obtained a licence from RH, but then RH might decide to terminate their licence.

There's certainly not enough legal certainty there to make a reliably updated derivative of RHEL.

[Michael Wojcik]

Re: GPL violation

There's certainly not enough legal certainty there to make a reliably updated derivative of RHEL.

This is the important point.

There's a whole lotta armchair lawyering going on in this forum, with people confidently declaring that RH cannot do X and Y. I suspect most actual lawyers would be much more cautious. Licenses, including the GPL, are complex,¹ subject to interpretation, and perhaps more importantly subject to law – which in the US (as a common-law jurisdiction) means statute, precedent, and non-codified principles like the rule against perpetuities.²

The fact is it doesn't matter what you or I think the GPL forbids, because the GPL has no power in itself. What matters is whether any of this gets tested in court, and what the court decides, and what remedies it applies if it decides against Red Hat.

¹And, no, what some of you claim is the "plain and simple" language of the GPL does not help. In a legal context, terms are generally interpreted not with their common-sense or popular meanings, but as terms of art, and in common-law jurisdictions such as the US, in the context of legal precedent. There's no such thing as "plain and simple language" in a case like this.

²Not saying good ol' perpetuities applies here in any way; it's just an example of a non-codified common-law principle.

[Orv]

Re: GPL violation

They're not a dead-end leech as long as they're contributing patches upstream.

The point of RHEL is not that it has things that aren't available upstream, it's that you can rely on one particular stable set of libraries. That means commercial software developers can sanely support their software without worrying that a sudden upgrade from libflorp-2.25 to libflorp-3.0 will break things for half their customers. It provides a stable ABI, something that's normally missing from Linux.

[bombastic bob]

Re: GPL violation

Hopefully though this will be the incentive the rest of the ecosystem needs to finally put systemd and pulseaudio in the bin.

And, gnome 3/4/5 while we're at it!

(Cinnamon and Mate are definitely superior desktops to gnome > 2)

[I like your thinking on this - well played!]

[Doctor Syntax]

Re: GPL violation

Under the GPL, Red Hat doesn't have to give you the sources unless you get their binaries.

True

You don't get the Red Hat binaries unless you agree to their terms, which includes not giving out sources.

If you receive the binary GPL specifically gives you right to receive the source of the binary as it exists, which would include any mods made by whoever supplied the binary, not just the source as received prior to those mods being made.

If you have the source GPL also gives you rights from the original authors who placed the code under GPL to redistribute the code. It also specifically gives you the right to remove all restrictive clauses which may have been added with some limited exceptions and I can't, at least at first sight, see how these new restrictions fall within those exceptions.

Those terms *override* the GPL.

The code that RH started with was already covered by the GPL which invalidates such added terms. It allows RH to make a charge. It doesn't allow them to impose NDA terms. It does allow the recipients to remove such NDA terms.

The grey area here is that some of the code which is included would have been contributed by RH before they came up with this idea. I don't see how they could use that to try to impose terms retrospectively having already contributed under GPL. It may well impinge on projects to willingness to accept code from RH contributors in the future. At its worst it could require Linux distros taking something analogous to the de-AT&Ting of BSD sources but I can't see that being likely.

[AVee]

Re: GPL violation

I'm not a lawyer and stuff, but I don't think the GPL will invalidate a contact between Redhat and it's customers. If they signed for that they will be barred from distributing that code. It will mean that Redhat violated the terms under which they got the code thus losing the right to distribute anything in the first place. The customer is not a party in that and will still be bound by their contact.

The GPL v3 addresses that, explicitly starting that anyone who receives the software may remove any added restrictions, but that has not been tested in court as far as I know, and you could argue that the contact is separate from the license terms. More importantly, there's loads of stuff that it's not GPL v3, most notably the kernel.

I think it will be up to code authors to deal with this. But I fully expect there will be plenty that are looking into that right now.

[Grogan]

Re: GPL violation

You're looking at it somewhat backwards. A contract between you the customer, and a company can't invalidate a license they are bound by. YOU did not bind them to this license and those rights are not actually yours to waive in this case.

Also, a company can't make you sign your rights away in the first place. They can't make you agree to illegal terms. "You signed it, and it invalidates your human rights. You agreed that I get to eat your first born child". Right? Of course not.

[Doctor Syntax]

Re: GPL violation

"there's loads of stuff that it's not GPL v3, most notably the kernel."

The kernel is still GP - GPL2. Updating it to 3 would have involved tracing and contacting all the existing contributors or their heirs and getting agreement of all of them.

[FIA]

Re: GPL violation

...which would seem to be covered by Section 6:

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

[bombastic bob]

Re: GPL violation

You may not impose any further restrictions on the recipients' exercise of the rights granted herein

This is the part that i was thinking might be their Achilles' heel.

[ibmalone]

Re: GPL violation

By coincidence, the same reason RedHat can't impose additional terms on GPL2-ed code!

[xylifyx]

Re: GPL violation

What they should do is cherry pick the equivalent patches from CentOS stream which is not contaminated.

That you will still be able to with a Redhat license.

[Anonymous Coward]

This will harm Red Hat a lot for zero benefit

None of this will stop someone from creating equivalent backported patches using the relevant SRPMs as “inspiration” in a manner which doesn’t technically breach the agreement. You can bet a Prominent North American Evil Linux Vendor will continue to distribute LTS patches for their Unbreakable Linux, with free community distributions sourcing free patches from them instead. When Red Hat stopped supplying individual kernel patches, Oracle very quickly spawned a project to separate the monolithic sources back out into individual patches, documenting the changes made in each patch set.

Meanwhile, we can see Google and others reliably contributing to the Debian project, figuring that it would be cheaper to encourage the production of stable, well-tested distros directly with the community, instead of outsourcing LTS and support to Canonical or SUSE. If Red Hat causes people to start considering alternatives, they will lose market share and revenue fast. Features like SELinux support have been cleaned up extremely well over the past few releases, and developers like Kees Cook finally got Debian on track with the same kinds of proactive security already implemented in RHEL. Combining this with support for reproducible builds, lower RAM usage and better architecture support means there’s a lot of perks for those who don’t need to comply with FIPS and other stupid USG regulations to make the move already. There is even professional support and paid LTS available for (old)stable releases these days.

[Wzrd1]

Re: GPL violation

Courts aren't wars, where the more people you bring in, the better.

One or two lawyers is more than enough to bring litigation. Where corporations win is by attrition, continuing the case over and over for a decade or more.

And IBM has been around for a long, long time. I've fired M3 grease guns and M2 .50 BMG machine guns made by IBM for WWII.

A little trivia, I also fired an M2 made by the Singer Sewing Machine Company.

[Yet Another Anonymous coward]

Re: GPL violation

>I've fired M3 grease guns and M2 .50 BMG machine guns made by IBM

Back when boardroom fights meant something

[FIA]

Re: GPL violation

A little trivia, I also fired an M2 made by the Singer Sewing Machine Company.

I like to think that somewhere part of that gun is now doing sterling work as a beer garden table in a nice village pub.

[Anonymous Coward]

Re: GPL violation

Fortunately it isn't.

Those Singer guns are INCREDIBLY valuable today, it's in somebody's collection and will continue to be a wonderfully made and fully functional gun for many years to come.

[Max Pyat]

Re: GPL violation

Per the GPL, RedHat doesn't get to distribute the binaries in the first place unless source is provided to the recipient, and access to that source cannot encumber the recipient from onward distribution of that source (so long as that onward distribution is also GPL compliant).

If they aren't honouring the GPL, then they cannot ship the software. It's not about the recipient giving up rights, it's about the licensing restrictions imposed via the GPL by the authors/copyright holders

[bombastic bob]

Re: GPL violation

It's pretty sneaky.

I agree with that part. Some "bright bulb" l[aw]yer must've cleverly thought up a new loophole, and now they wanna test it.

It is no doubt that this move was prepared for, and the surprise 'attack' leaves the other distros wondering what just happened.

The only way to counter a surprize attack like this is to do the unexpected, perhaps even deceiving IBM/RH into doing something that puts them at a disadvantage.

Not sure what that is, though. They have a head start. Might take a while.

[Anonymous Coward]

Re: GPL violation

The issue is they're not specificaly saying you can't distribute things, but that *if* you exercise your GPL rights, you are no longer entitled to any services from Red Hat, including further updates, support etc - i.e. if you pay to license RHEL, if you want to keep getting the benefits of that license you can't exercise GPL rights.

Now it's a lot more arguable if that is a further restriction or not - they're not preventing you exercising the rights (in the sense of they won't sue you if you do and aren't saying "you can't" or "you agree not to"), just that you agree if you do that they will effectively terminate your agreement for future bits.

[Displacement Activity]

Re: GPL violation... well, no

By tacking extra restrictions onto the license Red Hat are violating the GPL

They're not doing that. If I legitimately owned, say, a shiny pebble, and gave it to you, and we entered into a contract which prevented you from giving anyone else that shiny pebble, your options would be pretty limited if you did want to give it away.

There no magic inscription that you can etch on to it that over-rides that contract. Unless, of course, it is magic.

[Michael Strorm]

Re: GPL violation... well, no

That's a misleading analogy; we're not talking about a physical object like a pebble that was most likely obtained with no conditions attached- we're talking about licensed software.

That means the original "owner's" permission to use and redistribute that software was already subject to *their* acceptance of certain terms and conditions- in this case, the GPL. Whether or not their attempts to impose further conditions on subsequent owners- or work around the original conditions and rights granted- is legal is open to question, but the situation is not the same regardless.

[bombastic bob]

Re: GPL violation

So aside from open source stuff (which must have source made available if it is modified) what "Secret Suce" are they offering that is worth the license cost?

RHEL could fix all of this right now by publishing everything that is NOT proprietary in any way.

At that point, CentOS-derived distros could "sync up" the published source, and do compatibility tests/edits with the rest.

Jut a thought. then it's back to the way CentOS *USED* to be, but with a different distro name. Rocky, maybe?

[tvleavitt]

Re: GPL violation

I agree. The existence of a loophole in the GPL of this magnitude is inconceivable.

[CGBS]

Fedora Dependency

I've never understood how people so easily gloss over Fedora's dependency on Red Hat and always boost the, "they are dependent on us!" narrative. When you're funding and resources come from a single place, and a large part of your human developers also come from and get paid by that same single place, you are dependent. Anything else smacks of naivety and/or adhering to a set of talking points handed down from corporate. 5-6 years ago, this chicken and egg dependency debate still might have been more of an academic argument or sniping between distro fans in a forum flame war, but boundaries once thought fixed sure are suddenly moving in an ever more restrictive manner.

[Anonymous Coward]

Fedora would be fine without Red Hat

If Red Hat stopped funding Fedora then others would provide funding and guidance. Some of the most prolific packagers for the project now work for Amazon, just something to keep in mind,

[CoolKoon]

Re: Fedora Dependency

The reason people gloss over Fedora's dependency more easily is because it's an upstream distro meaning that it's not gonna be installed on servers en masse the way CentOS was (and Alma/Rocky Linux will be) ever. And this makes the whole project much less critical in terms of general infrastructure too.

[alain williams]

I am surprised that IBM took this long

to find a way of effectively making Red Hat closed source.

One result is that I shall move servers to Debian both mine and those of my customers - some of whom have done things like: Red Hat for production machines and Rocky/something for development and standby machines.

It is tempting to say "just grab the source, it is GPL" but IBM is a law firm that happens to sell computers so even if I am in the right they will make it very expensive for me to do so ... much the same as a patent troll does "pay $40k for a license or risk $100k legal costs".

Shame: Red Hat was nice while it lasted.

[TVU]

Re: I am surprised that IBM took this long

" I am surprised that IBM took this long...to find a way of effectively making Red Hat closed source"

Indeed, and it is a very nasty thing to do so I hope that this new policy gets challenged in the courts.

While there is the synchronisation loophole that Liam pointed when a major release has taken place, I suspect this move will also result in a shift way from Red Hat and towards other distributions, e.g. SUSE Linux Enterprise Server and others.

[AdamWill]

Re: I am surprised that IBM took this long

"I suspect this move will also result in a shift way from Red Hat and towards other distributions, e.g. SUSE Linux Enterprise Server and others."

Where are the SLES source RPMs?

[Edward Ashford]

Re: I am surprised that IBM took this long

All in the repo, we just don't tend to pull them as they are huge.

[Anonymous Coward]

Re: I am surprised that IBM took this long

https://sources.suse.com/

[coredump]

Re: I am surprised that IBM took this long

I don't think Red Hat has been "nice" for many many years. Perhaps not since RHEL came out and "Red Hat Linux" went away.

[yoganmahew]

Re: I am surprised that IBM took this long

Do you smell that? That IBM smell. Nothing in the world smells like that. It smells like 'closed'...

[Orv]

Re: I am surprised that IBM took this long

How are you centrally managing patches on your Debian servers? I like Debian but it's hard to give up the management features of Satellite Server.

[HighTension]

Re: I am surprised that IBM took this long

Have a look at Foreman, it's the upstream for Satellite. With Katello it can manage deb and rpm based products.

Follow the instructions to start installing it on Rocky/Alma and to get Puppet and Katello integration use this installer command line:

foreman-installer --scenario katello --enable-foreman-plugin-puppetdb --foreman-proxy-puppet true --foreman-proxy-puppetca true --enable-foreman-plugin-puppet --enable-foreman-proxy --enable-foreman-compute-ovirt --enable-foreman-compute-libvirt --enable-foreman-plugin-remote-execution --enable-foreman-cli-puppet --enable-puppet --puppet-server true --puppet-server-environment-class-cache-enabled true

Create products for your deb-based distros and work from there. You can use Puppet, Ansible, Salt or Chef plugins to manage your servers. With Puppet you can use Chocolately to manage Windows packages too.

[thondwe]

Re: I am surprised that IBM took this long

IBM quite used to running closed Ecosystems which have trapped corporates in the past - the dreaded Legacy lock in - so cutting off the Red Hat clones closes an escape door?

Yes you can jump to a.n.other Linux provided you can port your Applications, get Enterprise support for your hardware, etc - but the choice has been drastically reduced?

[Mick Russom]

Re: I am surprised that IBM took this long

"Shame: Red Hat was nice while it lasted."

red hat was nice until systemd. after systemd and the infection of lennart poettering linux has been quite a mess.

[Doctor Syntax]

From the GPL ( https://www.gnu.org/licenses/gpl-3.0.html ):

"If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term."

"Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License."

AFAICS that means that the only code on which RH can impose these new conditions is code entirely created by RH or a 3rd party which does not derive from GPL code. All other code receives GPL terms from upstream.

[TrevorH]

Also "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. You must make sure that they, too, receive or can get the source code".

[Doctor Syntax]

I wonder what effect this will have on projects receiving contributions from RH or even individual contributions RH employees.

[Orv]

Probably not much. Most of what goes into RedHat is already pushed upstream. Their big value-add is backporting patches to older versions to maintain binary compatibility.

[the spectacularly refined chap]

From the GPL ( https://www.gnu.org/licenses/gpl-3.0.html ):

"If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term."

That was my understanding, but look at what it is stated to mean - as opposed to the presumed intent:

“The Program” refers to any copyrightable work licensed under this License.

The subscription agreement with Red Hat is not under the term of the GPL, indeed it is given before and as prerequisite to getting the licensed material, ergo it can't be construed as part of "The Program". External restrictions are not covered by that clause.

Sure, it's not in the spirit of the GPL but it looks to me as if they have a prima facie case. It's one of the risks of producing a licence so long and complex in the first place: that you may consider the FSF "one of the good guys" doesn't change that peril.

[Doctor Syntax]

RH are distributing binaries derived from GPLed code. Their use of the code is subject to the conditions of GPL which include permission form the original authors of that code, not some intermediary such as RH, to remove such restrictive conditions. Some of that code will have originated with RH themselves but before these conditions were imposed. It seems likely that this new tack will make it hard for them to get more code into the kernel or other GPLed projects.

[that one in the corner]

> The subscription agreement with Red Hat is not under the term of the GPL

Which means that RH customers can not pass on a copy of the subscription agreement (but who would want a copy of it?).

Meanwhile, the rest of the GPLed code can be shared, as described above.

[the spectacularly refined chap]

Which means that RH customers can not pass on a copy of the subscription agreement (but who would want a copy of it?).

Meanwhile, the rest of the GPLed code can be shared, as described above.

But you are subject to a contract under which you have agreed not to distribute the code. As shown above, the GPL does not appear to prevent side agreements, only additional restrictions within the program itself or its components. You can guarantee IBM lawyers will have looked at this very closely before they proceeded.

I'm not saying I like it - it's very much against the spirit of the GPL which tries hard to prevent that kind of restriction, but the crux of the issue is what the licence says, rather than the broader intentions or what you want it to say. I was surprised when the article author stated it appeared to be permissible, but looking at it I agree with him.

[Roland6]

Am I looking at the right agreement?

“ Content is governed by the license that accompanies it. By using or downloading any Content, you agree to the applicable license. ”

Source: https://www.redhat.com/en/about/terms-use

But then I note the documents are quite old.

Eg. https://www.redhat.com/licenses/OSA_v2_20171211.pdf Is dated 2017.

[Henry Wertz 1]

Not bound

"But you are subject to a contract under which you have agreed not to distribute the code. As shown above, the GPL does not appear to prevent side agreements, only additional restrictions within the program itself or its components. You can guarantee IBM lawyers will have looked at this very closely before they proceeded."

Except you aren't subject to a contract saying you have agreed not to distribute the code, because the license for the actual (GPLv3) software specifically has a clause saying if those you got it from try to apply contract or licensing clauses restricting the right to redistribute the source code, those clauses are invalid.

[the spectacularly refined chap]

Re: Not bound

If that forms part of the license for the software. GPL says nothing about side agreeements, including side agreements I insist you take up before I give you the code and/or the binaries. I'd like to see the additional terms provision tested in court, it sounds like a land grab that would be thrown out, but it's an irrelevance: it isn't what IBM/RH are depending on here. Essentially there are two distinct contracts here - the subscription agreeement and the software licence. The licence effectively states that additional terms may not be added to the licence: it is silent on all other matters. The subscription agreement does not form part of the licence and thus its conditions stand.

To simplify take it there is one author we will call A. Whenever and however you receive a copy of the software you get a licence from A saying you can do X, Y and Z. Then there is another party we will call RH. You make an agreement with RH that you will not do X. Now you have two separate agreements, there is your agreement with A and your agreement with RH. You are contractually bound by both: the only way you can conform to both is to forget X and use Y and Z only, regardless of what A says. Try to refer to what A says in your agreement with RH and you'll be laughed out of court - A has no standing in the agreement you reached separately with RH.

[Lucasjkr]

Problem

The problem is, even if you can download and distribute the source with trademarks stripped out, they can simply refuse to let you have access to updated binaries when they’re released, which leaves them with no obligation to provide source code to you either.

[katrinab]

If the sell Linux, Gnome, or any other GPL software with anything other than a GPL license, they are selling pirated software.

[Liam Proven]

[Author here]

> If the sell Linux, Gnome, or any other GPL software

1.

Red Hat does not sell software at all.

Red Hat sells support contracts. With the contract, you get some software.

If you violate the terms of the contract, RH is able to terminate your contract and keep your money.

2.

No Linux distro is 100% GPL.

There is GPL 1, GPL 2, GPL 3, AGPL, MIT, BSD, etc. etc.

This is not about selling software and it is not about any version of the GPL.

[nematoad]

"... the only code on which RH can impose these new conditions is code entirely created by RH"

Does that include systemd?

If so that could be the spur to get distros to dump that POS.

Win/Win.

[ExampleOne]

Doesn’t this mean Red Hat are potentially getting sued for GPL violation by Oracle? I mean, Oracle contribute to the Linux kernel so should have standing?

[Doctor Syntax]

Oracle has a distro based on RHEL but I suppose the two have a financial understanding which covers this and, presumably this term will be imposed on Oracle's Linux customers. However RH have been kernel contributors. As I pointed out in another comment GPL ensures that those receiving GPLed source code get their permissions from upstream. What happens when RH themselves are the upstream for a particular snatch of source?

[TrevorH]

Well, who knows how that is now. At one point when OEL started up, it was found that there were typos in their SRPMs that had come directly from the CentOS version of the SRPM so it was obvious where they came from.

[demon driver]

"Oracle has a distro based on RHEL but I suppose the two have a financial understanding which covers this" – and Oracle will welcome Red Hat's getting rid of the freeloader competition just as well.

[Doctor Syntax]

Birds of a feather...

[Liam Proven]

[Author here]

> I suppose the two have a financial understanding which covers this

You do?! I don't. I have never heard of any such thing.

Do you have any evidence of any kind for this?

My suspicion is that Oracle Unbreakable Linux was an attempt to collapse RH's share price for a possible hostile acquisition.

That attempt failed, but OUL generates a revenue stream for Oracle -- and the rumours are that internally Oracle is heavily Linux-based, and barely uses Solaris. So, having its own distro has proved advantageous, worth the cost, and became at least partially self-funding and possibly actually profitable, so it continues.

[spuck]

Cross-licensing agreement?

I could see it possible that Oracle and RedHat (or rather, IBM) might have a cross-licensing agreement in place where they both agree to allow use of copywritten code or IP and not sue each other for the same.

IBM's war chest of patents might be a valuable bargaining chip for such an arrangement, but I agree that I don't see any reason why RedHat would benefit from Oracle having their own derivative distribution.

[ChoHag]

Nothing about the GPL requires anyone to put the source code changes they make in a publicly accessible location, only that they cannot distribute binaries compiled from those changes without also giving the recipients of those binaries the potential to access the changes. RedHat are well within their rights to withhold the GPL-covered code they've written until their customers ask for it, when they have no choice but to provide it one way or another and they can't stop their customers doing with it whatever they like, except that they'll be restricted by the GPL as RedHat were.

[Anonymous Coward]

you're making an assumption

You're making an assumption that all of the binaries RH deistribute are only based on their own code. By the way, it isn't.

[ExampleOne]

The potential problem is not the with-holding the code, it's terminating subscription agreements for of end users who exercise their GPL rights. This is basically exactly the same legal argument advanced by GRSec, and it was called out as GPL violation then. Why is it not being called out the same now? Or were all the claims then FUD?

Truthfully until this particular model is legislated, we won't know if it breaches the GPL. If it IS legislated, and it DOES breach the GPL, RH and IBM are in a massive world of pain, as anyone who contributed anything to any GPL component of RHEL would have standing to sue. Including Oracle and Microsoft. Essentially, this is potentially a massive gift to those opposed to Linux.

[containerizer]

What is there to sue for ? The kernel source is freely available from the community at kernel.org, always has been, always will be.

The GPL (v2) requires that the person who provides a binary based on a "derived work" of a GPL-licensed software must also provide the corresponding source code.

[Doctor Syntax]

The same rules apply to any other GPL2 or 3 code that makes up a distro. They could make private changes to any BSD licenced components; I'm not sure how much of that exists in RH. And, of course, they can't take any GPLed code and convert it to BSD.

[Liam Proven]

[Author here]

> requires that the person who provides a binary [...] must also provide the corresponding source code.

You omit the crucial defining specification: *to whom* it must provide that source.

[Anonymous Coward]

And ANYONE they provide that source to can then freely redistribute it, any purported "contract" stating otherwise is automatically invalid.

[Paul Crawford]

Such a shame they did not pull systemd from the world's other distros while closing the door

[karlkarl]

> And under the terms of their contracts with the Hat, that means that they can't publish it

This is allowed by the GPL. However the worst Red Hat can do is terminate their contract with the one who published it. They can't i.e sue them.

What this probably means though is that downstream projects are going to have to create bots to sign up to the free RHEL developer accounts for access. Which has a knock on of:

1) People like me who hates being tied to a server and simply mirror the entire repo for offline backup. RH will probably see me as a risk and will put download restrictions on me.

2) RH will simply terminate the free developer access programme.

Commercially: I can't see why companies would jump through these hoops. There are loads of companies who offer equal Linux support; just look around rather than sticking to that 90's style inertia (as charming and nostalgic as it is).

Community: Do people *really* want these guys dictating the direction of Linux via Systemd, Wayland, NetworkManager, etc, etc?

[CoolKoon]

"RH will simply terminate the free developer access programme" - I think that that'd be the last straw. If developers will have to pay a lot to be able to develop for RHEL then they're not gonna do it, simple as that.

"I can't see why companies would jump through these hoops." - One major reason I can see is Pacemaker. And the other lies in the fact that they have all their customers still running their production systems on legacy CentOS (6 and 7) installations.

[Anonymous Coward]

Welcome to IBMHEL.

It was only going to be a question of when, not if, the old Big Blue started squeezing revenue from anywhere it could find.

[wayneinuk]

Ouch, Ubuntu here we come ….. So glad we held back jumping from C7 into the unknown!

[keithpeter]

Springdale Linux

Springdale Linux formerly PUIAS Linux does a rebuild of RHEL. Springdale is mainly for internal use at Princeton and the IAS, but the University IT staff who work on it chuck the binaries over the wall and have been doing for some decades.

https://springdale.math.ias.edu/

They have their thinking caps on...

https://groups.google.com/g/springdale-users/c/53hFsR7oLEQ

So three times the rug has been pulled part way through a planned support period without warning or time to adjust budgets. CERN, FermiLab and various University project staff will be most amused I'm sure.

Icon: for those who have been made redundant and for those having to make guesses...

[Alan J. Wylie]

The Software Freedom Conservancy's response

A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model by Bradley M. Kuhn

[Alistair]

Re: The Software Freedom Conservancy's response

The Software Freedom Conservancy's response

Met once, long time ago. Still one of the smartest people in the room, just about anywhere, that article is an awesome read.

[Liam Proven]

Re: The Software Freedom Conservancy's response

[Author here]

> The Software Freedom Conservancy's response

Thanks for this.

Mr Kuhn wrote to me, thanked me for the article, praised it and sent me this response, in fact. That was most gratifying and I thank him for it.

[Anonymous Coward]

It's easy for end users to say "jump to Debian/Ubuntu/whatever". It's entirely different for commercial organizations to jump ship. In some cases, 3rd party vendors only support their products on specific releases of RHEL. Heck, I have seen one RHEL7-based product that doesn't even support RHEL8 yet. These are EXPENSIVE products and they may never support non-RHEL installations. And they may not even work even if you could install them. And sometimes there are no viable alternatives.

Welcome to the real world :(

[thames]

So sort of like the mainframe was at one time? How very IBM. How's IB-Hat's mainframe business doing these days by the way?

[CoolKoon]

Not just whole systems. Infiniband, RAID and FC cards are rather typical examples too and they're indispensable for academia and bigger companies alike.

[Doctor Syntax]

"Welcome to the real world"

I'm sure the vendors will want new customers. But if that part of the real world that isn't dependent on these applications moves away from RH or becomes unwilling to move to it the supply of potential new customers will dry up unless they elect to port to other platforms. And what does such a port entail? Possibly no more than a recompile and test. Does RHEL really include show-stopping differences?

And never give a customer cause to review the market. Some of those customers were likely running on CentOS previously, now on Rocky or Alma rather than RHEL. They will now be reviewing their own situations which might in turn lead them to review the application software market as well.

[Mikel]

Around ans around

>These are EXPENSIVE products and they may never support non-RHEL installations. And they may not even work even if you could install them. And sometimes there are no viable alternatives.

The point of UNIX and hence Linux is to provide a set of tools that can be rebuilt on any platform so that the platform vendor cannot take hostage your business processes and data, and inevitably destroy them when they go under. So congrats on reimplementing that hazard using the tool designed to prevent it.

[Paul Crawford]

These are EXPENSIVE products and they may never support non-RHEL installations.

If you are paying a lot for some special software then paying for RHEL is going to be part of that, so this aspect is not changing anything.

What it changes is folks using the 'free' versions that are aimed to be RHEL compatible, for them jumping to another vendor is easer and makes sense. What this is likely to mean for RedHat/IBM is the community moves away from that version, the Fedora up-stream version is no longer that attractive (why bug-fix a commercial product for free when they are screwing the free community?) and more Linux admins folks will be experienced in the alternatives such as Ubuntu or SUSE and guess what? If they need paid support it ain't IBM getting that deal!

[Doctor Syntax]

It may well be that some of those customers were running it on CentOS and its successors rather then RHEL. They now have the choice of paying more the RHEL, looking around to see if there are other options or talking to their suppliers about ports to other distros.

There will also be those running production on RHEL but test, training, development, backup or whatever on CentOS and successors. They also will probably want to move those extra systems away from the RH world.

Between that and the existence of users on the other distros as a potential market must surely be prompting vendors of what are currently RHEL-only applications to review their own positions.

[Ian Mason]

Part of the real world is that the customers for 'expensive package' may decide that the whole RHEL farce has gone on long enough. One "big enough that they could easily account for 20% of expensive package's revenue" commercial organization that I've done work for use RHEL in production and Centos in test/development and so on. It could decide that RHEL is too expensive to use for everything, especially given that the expensive support from Red Hat/IBM that they pay for is considered a crock of shit by all there. If they say to the vendor of 'expensive product' "support our linux platform of choice or we walk" I bet that vendor will find a way to get the RHELisms out of that software in quite short order.

[Crypto Monad]

> These are EXPENSIVE products and they may never support non-RHEL installations

Somebody running an "EXPENSIVE" product probably won't object to paying a small amount extra to IBM for an RHEL licence.

But if the upshot is to start pushing the mainstream users into other distros, and then the vendors start supporting some of those distros too, it could be an own-goal for RedHat, with a smaller and less technically-savvy customer base. We'll see.

[Richard 12]

Those suppliers want customers

They chose to only support RHEL because only supporting one distro reduces costs.

If their customers demand a different distro, they will support a different distro - and after a while, they'll drop support for RHEL.

[Liam Proven]

[Author here]

> It's entirely different for commercial organizations to jump ship

You are entirely correct and I am sure that this formed part of RH's risk analysis.

Personally, IMHO, this consideration would form part of a competent organisation's due diligence.

Most, of course, fail at that.

[thames]

Not very developer friendly

I have a few minor open source projects in several languages which I distribute via the usual avenues for such things. Before I release a new version I run an extensive automated test suit run on roughly a dozen different distros (including BSD) on x86 and ARM.

One of these test platforms has up until now been a Red Hat derivative. At first it was Centos, and later AlmaLinux.

The point of testing on Centos or AlmaLinux was to look for problems that people using RHEL may have and fix them before release. If AlmaLinux have to stop doing updates and get out of sync with RHEL then there's no point to running tests on it anymore. Fedora isn't a substitute since it is not the same thing as the current RHEL version.

I'm not going to either sign up for a RHEL license or a RHEL developers' license. All signing a developer agreement would do is give Red Hat greater ability to sue me for some incomprehensible reason in a foreign court. Why would I want to do that?

If AlmaLinux can't work around the current problems then I'll simply drop testing on RHEL derivatives. I don't imagine that Red Hat / IBM will even notice, but over time more developers may come to the same conclusion that I have and Red Hat may find that their platform gradually becomes the less reliable one on which to run actual applications.

For now though I'll wait to see what AlmaLinux can come up with.

[that one in the corner]

What about any non-GPL components?

Are there parts of RHEL that are *not* covered by the GPL and without which a fully RHEL compatible version is not possible?

They need not be major parts, in the grand scheme of things, but if there any little bits which may really be restricted by RH's actions that would be enough to prevent any rebuilds from being 100% bug-compatible with RHEL. A point which RH would be sure to emphasise.

If such a situation exists, *we* may all know that those components are irrelevant to 99.999% of Users, but even a few differences would be enough for RH sales & marketing to leverage into full-blown FUD ("you are unique, you are one of the 0.001%" would probably work on most CEOs).

All they have to do is set the perceptions about remixes they don't like, not the reality.

[Happy_Jack]

Re: What about any non-GPL components?

That's not how the GPL works. It's designed deliberately to be invasive. If the GPL applies to any part of the software it applies to all of it.

[Doctor Syntax]

Re: What about any non-GPL components?

It applies to any code derived from GPLed code. It doesn't apply to code with other licences. There will be nothing to stop Red Hat adding free-standing components which do not derive from GPLed code in future. They have now unmoored themselves from the rest of the Linux world and would start to drift away from it if they added such components. How badly that affects their attractiveness to the rest of the Linux economy remains to be seen.

[Liam Proven]

Re: What about any non-GPL components?

[Author here]

> If the GPL applies to any part of the software it applies to all of it.

This is an egregious over-simplification.

Points you fail to address:

1. Your term "the software" is appallingly woolly and does not define what you mean. Bundling 1 component with another does not make them part of the same piece of software. A Linux distro is not "a piece of software." It is about 20,000-60,000 pieces of software, distributed together but entirely separate.

2. No distro is 100% GPL.

3. No distro is 100% GPL 2 or GPL 3, and cannot be.

4. Other licences apply as well. This is not about any or all versions of the GPL alone.

5. It is hard even for the GPL to define what "a piece of software" means, so for example some distros bundle ZFS (under the Sun CDDL) but others will not.

To quote Dr Ben Goldacre:

"I think you'll find it's a little more complicated than that."

[FrogsAndChips]

Re: What about any non-GPL components?

s/little/bit

[Doctor Syntax]

Re: What about any non-GPL components?

Some parts of the distro may be based on BSD or other licences. RH could make their own modifications of these. However the kernel is GPL and so are the GNU-based utilities around it and they make up the core of any distro.

[Bebu]

Re: What about any non-GPL components?

RHEL6 had a rebuild of the Chromum browser after Google dropped RHEL6 support for their Chrome.

I could never find the SRPM for the chromium package or even a patch set.

Sun/Oracle java was also packaged until Larry changed the licensing.

Illumos (OpenSolaris) is looking good to me :) but the BSDs and Debian derived distros are real options.

What would be ironic is that we all end up running a Microsoft Linux distro.

[mrusc]

Re: What about any non-GPL components?

This is an important question, as most of the discussions regarding this change to RHEL center around the GPL license question. Although the kernel and most core system libraries are GPL, there are a significant number of key packages that are not under GPL/LGPL/AGPL license, and without which, you could not have a complete "clone" of RHEL.

e.g., in CentOS 7, there are ~7800 binary packages in the core OS.

- Approximately 68% of the packages are under GPL/LGPL/AGPL licenses,

- Approximately 30% are under permissive licenses (BSD, MIT, Apache, openssl, public domain, etc),

- The rest are under "weak" copyleft (most of the weak copyleft require distribution of source only if modified)

This leaves a significant number of packages that do not require source distribution, even when modified. It would be very challenging to have a reliable, compatible distro without these non-GPL components, several of which have relatively frequent patches (openssl) and/or interface with kernel or system APIs.

Examples of some key packages not under GPL/LGPL/AGPL include openssl, openssh, bind, zip/bzip, netsnmp, boost, libvirt, ftp, curl, python, perl, nss, ...

[CowHorseFrog]

Strike another victory for American leadership, where they appear to make a short term grab for money and actually destroy their future.

Heres another perfect example, invest, send factories for everything and anything in a country run by human rights abuses and dictators with nuclear weapons, just for a few dollars... and today we have China. China would be nothing if it wasnt for leadership and their unendless quest for a quick buck.

[Mister Goldiloxx]

Every time you said "Red Hat" I mentally corrected to "IBM" and then it all made sense.

[David 132]

And what everyone here is missing is that Red Hat as a brand is now 30 years old. This is IBM we’re talking about, and as multiple lawsuits have shown over the last few years, they take Logan’s Run as their HR template. No wonder Red Hat is being terminated.

[Plest]

Thsi is a f**king shakedown, nothing more!

So basically the game is, try to cut off the source code, make people sweat for a while, make a big PR fuss and then relent BUT ask each of the downstreams to pass back up some tiny percentage of their revenue streams, say 1%-2% ( charities and volunteer groups exempt of course for good PR! ) which given the huge amount of down stream work relient on RHEL means a shit load of upstream revenue from various quarters.

[Herby]

No good people, not good!

I don't know what the final result will be, but this first salvo doesn't look good. I have never liked the Debian packing scheme, or its updater. I note that Fedora/RHEL/Rocky is a much, much more polished interface.

Oh, well.

[Doctor Syntax]

Re: No good people, not good!

"I have never liked the Debian packing scheme, or its updater"

Why on Earth not? It Just Works.

[Orv]

Re: No good people, not good!

I like it for one-offs but it's hard to manage a whole fleet of Debian servers and keep them in sync with each other and up to date. The packaging system isn't very deterministic and sort of squishes its way from release to release, with hand-intervention needed to configure things and fix dependency problems. There also don't seem to be good central management tools that I can find. Everyone says "use puppet" but puppet won't show me which systems are out of date and why.

[Anonymous Coward]

Re: No good people, not good!

There's still SUSE, the #2 enterprise Linux vendor after Red Hat who has gone the reverse way by bringing the community distro openSUSE Leap in line with its enterprise offering (SUSE Enterprise Linux or SEL).

SEL (and thereby openSUSE) also have wide ranging ISV support (most commercial software than supports RHEL also supports SEL).

And it has YAST ;)

[penfoold]

Re: No good people, not good!

SUSE's enterprise Linux offering is called SUSE Linux Enterprise (not SUSE Enterprise Linux - SEL) with their server product SUSE Linux Enterprise Server, or SLES for short.

[Liam Proven]

Re: No good people, not good!

[Author here]

> I have never liked the Debian packing scheme, or its updater.

That is a statement of personal preference and as such is perfectly fair and reasonable.

No problem. You do you.

> I note that Fedora/RHEL/Rocky is a much, much more polished interface.

This purports to be a statement of objective fact. In my extensive personal experience over more than 25 years, I know it not to be the case. In fact I personally find the reverse to be true. In terms of corporate/enterprise distros, I personally would rank them as...

1. Most polished and complete: Debian/Ubuntu

2. Intermediate: not bad, some major issues -- [open]SUSE

3. Weakest, multiple major flaws in all released versions: Red Hat/Fedora.

As such that means that you are attempting to present your opinion as objective truth, which it is not. As such, I call BS.

[Lennart Sorensen]

Re: No good people, not good!

Well the Debian package format has always been far better than the mess that is rpm, and Debian's updater certainly has reliably done in place upgrades far var longer than Red Hat has ever managed to do that. That was the main reason I moved to Debian from Red Hat about 25 years ago now. Yum and dnf and whatever else RedHat has added since hasn't done anything to fix that rpm is just not a well designed package format, and the source packages are even worse.

[Anonymous Coward]

Re: No good people, not good!

> Debian's updater certainly has reliably done in place upgrades far var longer than Red Hat has ever managed to do that.

Spot on.

I dunno if it's still the case, but I believe the standard party line from Red Hat on major version upgrades (e.g RHEL 6 to 7) was "back up your stuff and re-install".

Whereas I've upgraded several single-digit version Debians up to today's 11.7 over the years. Sometimes it took a while, but I can't recall a time when it went sideways.

To be somewhat fair, I've read there are recipes for in-place upgrades of RHEL and its rebuild distributions, but I've not personally tried them.

And after Red Hat's trust-shattering actions around CentOS Stream when EL8 was *already released*, I don't expect I will.

[Roland6]

“ who can't legally share it.”

It would have been useful for the author to expand on this.The confidentiality clause in the Red Hat enterprise agreement explicitly excludes materials carrying open source licences.

[bazza]

Re: “ who can't legally share it.”

I was wondering if that was the actual situation. RH must surely know that any attempt to prevent customers in receipt of source code RH don't actually own and covered by GPLx would end with an ugly failure.

Makes one wonder how much of the source in a RHEL is RH wholly owned code.

This development reminds me a little of the approach GR Security took. They (he?) basically took the approach of refusing to be a supplier of future versions, if a customer of a current version published the souce code for it. There was much criticism, though AFAIK no actual court rulings against the practise. The thing that was unclear was how were customers of GR Security supposed to meet their GPL obligations should one of their own customers demand and publish the source code. Perhaps they simply relied on a request for source code from their customers being a very rare occurence.

Regardless, RH's move is certainly a disappointment. For those who are clinging on to the idea that Linux is somehow going to successfully avoid being absorbed (for all practical purposes) by big business, this is just another reminder of how things are slowly sliding away from them. That RH's business model (or Cannonical's) can work should come as no surprise; the proprietary operating system vendors did jolly well out of support fees; there is market demand for support.

Time to move to FreeBSD?

[Doctor Syntax]

Re: “ who can't legally share it.”

"For those who are clinging on to the idea that Linux is somehow going to successfully avoid being absorbed (for all practical purposes) by big business, this is just another reminder of how things are slowly sliding away from them."

See the posts by Ian Mason & thames above.

What could happen is that the Linux market slips away from RHEL.

Any business using RHEL in production & several CentOS/Rocky/Alma instances elsewhere is going to be reviewing its situation next week: is it cheaper to buy all the extra RHEL licenses they need once those work-alikes are unavailable or to move. As part of that they'll be talking to any application vendor who currently only supports RHEL and who consequently will also be reviewing their situation.

Also, expect Suse and Canonical to start pitching to application vendors PDQ.

[Anonymous Coward]

Re: “ who can't legally share it.”

It's always a good time to move to FreeBSD, Red Hat's latest shenanigans notwithstanding.

[spicysomtam]

RHEL is history who cares?

I don't know anyone who uses RHEL anymore; everyone else now uses Debian, Ubuntu, Alpine, Arch, etc. Only aws uses a spin off called Amazon Linux 2 and that is based on Centos.

[abend0c4]

Re: RHEL is history who cares?

Red Hat has been growing at a little under 20% a year and had revenue of around $5.6bn in 2021. You clearly don't move in the same circles as their customers.

If they were insignificant, this wouldn't matter, but it's a crucial test of Open Source.

[containerizer]

Re: RHEL is history who cares?

"show me you don't know anyone who uses Linux in a serious production environment without telling me you don't know anyone who uses Linux in a serious production environment"

[navarac]

Canonical

I'm sure that if Ubuntu was not based on Debian, Canonical would be eager to try the same thing with Ubuntu.

[xylifyx]

Re: Canonical

They would be dead the minute they even suggested it.

[Gizepi64]

Denial of Access

I believe the Linux Kernel as still published by Linus Torvalds and his merry band of dev's is GPL and thus if downstream corporate interests are to turning into greedy, selfish corporations, the newer versions of the Kernel should be denied to them here forth. Let's see how they like being "disabled" following much work.

[Ian Mason]

Mr. Proven

I do hope that "going forward" in the first sentence, second paragraph was meant to be in quotes. If not, next time you consider writing "going forward" in place of "in the future" I want you to imagine your former chief sub Teresa Teras standing behind your left shoulder, arms crossed, tapping her toes, head on one side, eyebrow raised, with that "I could eat you for breakfast sonny" look of hers in her eyes. That should be enough to persuade you back onto the right track.

[Liam Proven]

Re: Mr. Proven

[Author here]

:-D An excellent point, but the phrase was carefully chosen because RH itself is being ambiguous about the timeline and has not published dates, even when asked.

It appears from subsequent announcements that in fact the limitation of source code publication on Git slightly *preceded* the announcement. I suspect RH was testing the downstreams to see if they would notice, and at first, none did.

But I will readily concede that I could have handled this ambiguity better.

[sweh]

Maybe this will be sorted, eventually.

This isn't the first time this sort of "You get our binaries and GPL but if you exercise your GPL rights you lose further access to our binaries" issue.

The first one I can recall was sveasoft, who were early in creating an alternate software for the Linksys WRT54G based on Linksys GPL'd releases. They tried this sort of them and were condemned. Sveasoft died, and other alternatives like DD-WRT, OpenWRT etc thrived instead.

Later we had Grsecurity doing the same thing; Bruce Perens was sued for claiming this broke the GPL, but a judge threw it out ( https://www.theregister.com/2017/12/22/grsecurity_defamation_perens_dismissed/ )

In both cases no decision was actually made on whether restrictions like this broke the GPL license.

Now RedHat/IBM are doing this; I wonder if this is now high profile enough to get proper legal attention. Unfortunately any case could take years to resolve :-(

[Richard 12]

Re: Maybe this will be sorted, eventually.

Unlikely.

The cost of litigation is likely much higher than the cost of transitioning to another distro.

So many will weigh up the one-time cost of transitioning against the ongoing cost of the additional licences.

[nijam]

Re: Maybe this will be sorted, eventually.

> In both cases no decision was actually made on whether restrictions like this broke the GPL license.

No, because the offenders knew it did break the licence trerms and they (or their backers) were desperate to avoid it coming to trial.

[Anonymous Coward]

Re: Maybe this will be sorted, eventually.

GR Security were doing something different, and a lot more nuanced than a simple dumb refusal to distribute GPL code on request. If you bought a compiled kernel (based on their patch set) from them, you could ask for and would receive the source code. If you published that source code yourself, that too was perfectly fine. So far, so very straight up/down with GPL2.

But, subsequently, they'd decline to sell you a compiled newer version of the kernel with their patch set.

This was the novel bit. That too is perfectly fine with GPL2 (which has absolutely nothing to say about your rights to receive follow on versions); not even the supreme court can compel someone to sell something when there's a whole bunch of laws saying that they don't have to if they don't want to.

GR are certaintly not the only company that refuses to make code derived from GPL2-licensed source freely and widely available on a public repo, and no one has to. Common practice does not make it compulsory.

There have been court cases concerning dumb refusals, which have gone the right way. RH are definitely not going to go that way. RH are perfectly at liberty to include proprietary, RH-owned code in their Linux distro, and they don't have to distribute source code for those programs to anyone - not even customers. They're perfectly at liberty to use GNU-licensed tools for producing such software. I see this resulting in a gradual withdrawl of available source code, and eventually there will too much missing to be able to usefully recreate RHEL. We might not like the end result, but at the end of the day if that's what they do, that's what they do. As ever, the market will speak. If today's operators are happy to pay the support bill, then that's what they'll do.

It's basically the same model followed by Google with Android; there's AOSP, but the bit you really need is boot loaders, drivers, and the Play Services binaries to make an "Android". Of course, Google have come under a lot of criticism in the EU for leveraging their control of Play Services, but they've not actually relinquished control or opened that up in anyway.

[trevorde]

Simple solution

Just use Windows

[bombastic bob]

Re: Simple solution

Just use Windows

HA HA HA HA HA... oh were you serious?

(I should laugh even HARDER if you were!)

But yeah, nice trollin'. We all can use a good laugh now and then.

(my apology for any mishap involving coffee, cats, and keyboards)

[Kurgan]

Debian is the way

I already use Debian (since forever) so I just don't care at all. Maybe now someone else will see why Centos was a bad choice for servers.

If you want (can afford to) to pay through your nose, go on with RH if you like it so much. Otherwise, go with Debian.

Oh, and don't forget who made us all become slaves to that pile of junk that is systemd.

[Anonymous Coward]

Re: Debian is the way

>> If you want (can afford to) to pay through your nose, go on with RH if you like it so much. Otherwise, go with Debian.

Good idea, who cares that the software businesses care is not supported on Debian, only on enterprise distros like RHEL, SEL and if you're lucky, Ubuntu.

There's a reason why (classic) CentOS was widely used, and why instantly after its death alternatives spung up. Because the RH ecosystem actually matters.

>> Oh, and don't forget who made us all become slaves to that pile of junk that is systemd.

Right, of course it's better go with a community distro which has its own track record of massive fork ups and a crude understanding what "stable package" means. There's a reason why few of the big ISVs touch Debian or its often toxic and overly activist community.

Thankfully Debian isn't the only alternative to RHEL, assuming it's a situation where Debian is actually an alternative.

[Binraider]

Dear all, you all had adequate warning of what crap IBM were going to try and pull when they announced the intention to buy RH.

If you weren't planning to move distro then, then you sure as hell should be now.

I do get why RHEL can be useful in certain situations, for example I have hardware that have RHEL driver packages that "just work", and even with source code seem to be beyond anyone else getting working on other distributions. But, in the grand scheme, the solution there was to retire that hardware with the dependency.

From the standpoint of GPL violations; the sources for open source components are available, so from that perspective I think IBM are within their rights to point people to those. If you don't like it, as above, plan to move already.

[Anonymous Coward]

Freeloaders crying...

Red Hat should have done this years ago!!

Freeloaders always will complain and mention that they are betraying OSS/GPL terms, but Red Hat invested a lot and as it is not a non profitable company, needs to make money out of that investment! Since the announcement of CentOS Stream I saw various freeloaders complaining they would move away from Red Hat, so why they keep using Alma or Rocky? Both these companies, such as Oracle, also are getting money from Red Hat's investment without paying Red Hat nothing at all. The same freeloaders mentioned OpenSuse or other distributions, so go for it! Don't use nothing related to Red Hat Linux anymore... I am certain that the ones complaining don't work for free, as the engineers from Red Hat, but they want things from free as long as it doesn't involve their paychecks

[keithpeter]

Re: Freeloaders crying...

Red Hat should have done this years ago!!

@Anon

How many years ago?

(Some here may guess why I'm asking)

[rcxb]

Re: Freeloaders crying...

Red Hat invested a lot and as it is not a non profitable company, needs to make money out of that investment!

Red Hat earns $3,400,000,000 per year, and maintains profit margins around 85%. They are not struggling to keep the lights on.

https://www.zippia.com/red-hat-careers-9680/revenue/

https://www.netcials.com/financial-gross-profit-margin-usa/1087423-RED-HAT-INC/

[samzebra]

RedHat... er... IBMHat is the new Oracle...

[Anonymous Coward]

Red Hat and rpmfusion?

This relationship isn't mentioned anywhere in Liam's article, or in Bradley Kuhn's analysis, or in any of the comments.

Now.....I thought that RH has ALWAYS had a policy of not shipping items which do not meet the RH licencing requirements.

As a result, my computers are currently running Fedora 38 plus some packages from rpmfusion. This is because some applications will not run without rpmfusion packages.

What I'm wondering is this:

(1) Are typical RHEL or Rocky or Alma users in the same sort of position vis-a-vis items "which do not meet the RH licencing requirements"?

(2) And how does a typical RHEL or Rocky or Alma user test some alternative distribution (say Ubuntu or SUSE)?

[ibmalone]

Re: Red Hat and rpmfusion?

Exactly, what I'm wondering is what happens to efforts like EPEL. RedHat have gradually shifted responsibility for providing packages we actually need to EPEL. (Site license, running RHEL, need EPEL packages because RedHat can't be bothered building them any more, who's the "freeloader" there?)

[RickRuby]

Go sh*t in your hat, Red Hat.

[TrevorH]

Never heard of "when you're in a hole ..."

...then stop digging. Or, double down on what you just said and go on a "you're all picking on us" rant: https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes

[luis river]

...Redhat yesterday, tomorrow: Redhell...Please NO MORE INDUSTRY LOCK-IN ON AMERICAN LAND

[WWWillem]

CentOS toast ??

Been a multi year RHEL and CentOS user. Since 1997 I've also been a decent size contributor to Linux in general and therefore CentOS.

But what IBM is doing now makes me cringe. Could I revoke my open-source licensing from IBM?

WWWillem

[Biggvs Richardvs]

I think RedHat is shooting themselves in the foot. Too many alternatives out there to let whatever goodwill they have around their product slip away.

Maybe some really mission critical applications may be "stuck" with them, but anything that falls under Google's "good enough most of the time" philosophy don't have to put up with their bs and eventually won't.

[DustFox]

Oracle answers

https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/