Se title.

@Will Godfrey

Irony: A company whose unique sales proposition is long term stability pulls a fast one not once, not twice, but three times.

Yes and I suspect that some of their paying customers also make use of the free distributions, so unless Red Hat change their pricing structure, those customers could be facing much higher costs. At least that would provide some incentive for those customers to go shopping elsewhere.

... then how come SUSE have been doing this for years?

If Suse had enough market share that anyone cared about, you would see companies trying to clone it. That has not seemed to happen.,

"That has not seemed to happen"

It might start to happen now.

SUSE have never provided the source to allow a community build so there can't be blow back from stopping. Plus SUSE haven't said anything that people can take as an insult. If Redhat had said in 2022 "we'll keep providing the source for rhel8 but rhel9 will be the breakpoint" they'd have had less blowback. Instead they've benefited from centos et al acting as a feeder for people to adopt RHEL but pulled the rug on a lot of people who have existing installations.

I've watched and used Linux since it was released, but never Red Hat. (Mostly used the BSDs, which seem to be more of a literary tradition than the Linux tied-to-executable form.) I find it hard to understand who is inconvenienced by these moves. The closest I've read is people who are clients of (expensive) proprietary software that is only "certified" to work on specific builds of Red Hat. And all you get for that is a specific set of versions and build configurations (bugs, if you like) for software that is readily available elsewhere.

Seems to me that the complaint must be with these proprietary software providers, for the lack of faith in their product, or lack of testing against other distributions. If the software is so expensive and so singular, I expect that most of the clients do indeed spring for matching Red Hat licenses. So again, I'm missing who's actually inconvenienced here.

One problem with RHEL it's that it's license activation process adds complexity if you want use it in automated systems like CI/CD. In those cases having the possibility to throw a CentOS at them and be done with it, with the confidence that your test environment will work the same way as your production system it's a godsend. Also, having local mirror of the repository is a pain, but with CentOS it was easy.

"I find it hard to understand who is inconvenienced by these moves."

You mean apart from those building the Rocky & Alma downstream distros?

1. Companies who use RHEL in production because they need support* but who also run a downstream rebuild for training, testing and/or development boxes because they don't need support on those. Are they going to have to pay more for those secondary functions? This is the risk for RH. If the matching downstream builds aren't available those customers are going to have to reconsider whether RHEL is still the best choice for production.

2. The certifying** application vendors who certify against RHEL because its existing place in the OS market has made it a valuable market place for applications. If this makes their customers wish to look elsewhere they are going to have to do the same. The testing against a platform is expensive. Maintaining multiple versions if testing reveals that's required is expensive***.

3. The customers of the vendors of the certified products who might not have a problem per se with running RHEL but will have one if their vendor switches platforms.

* Support is what provides the customers' perceived value for money.

** In regulated application areas certification of the S/W they use is an external requirement that the customer needs to meet.

*** "Inconvenience" isn't the issue; it's the cost.

but who also run a downstream rebuild for training, testing and/or development boxes because they don't need support on those.

Worth remembering that a free RHEL Developer account gets you 16 unsupported licences (up to 128 cores across those instances), which is 16 more than Microsoft gives Windows devs. So for training or dev or even small (self-supported) production workloads, developers can use their dev account licenses.

This policy/allowance of course remains at the whims of RHEL (beware building a business on it) and testing can be difficult because you have to activate those instances with your account credentials - as Claudio4 mentioned above, for automated CI/CD pipelines or anything where you might be standing up and tearing down instances automagically, throwing CentOS or similar at it was much more straightforward from an activation standpoint. I doubt that is unfixable, but you'd need some monitoring to avoid it trying to spin up a 17th instance and falling over.

As you mention, the main appeal of RHEL is support, and certification for vendors and customers operating in regulated industries.

The last article here mentioned Red Hat required its customers to agree not to redistribute GPL source code made available to them from Red Hat. That is very naughty and not mentioned at all in this article. I will take it as proof that Red Hat knows that this requirement is legally problematic.

Liam pointed out in the article " The GPL doesn't free them from their Red Hat contracts: they can redistribute the source code if they so wish, but equally, the Hat can respond to them doing so by terminating their customer contracts, and that is 100 percent compliant with the GPL. "

It would take a court case to determine for sure whether it is 100% compliant or not. The question would be whether this is an implied instance of those additional restrictions that the GPL says should not be applied and may be removed if they are.

^ I fully agree with this and I hope that a court case does follow so that the resulting judgement gives us clarity if nothing else. Even if it is superficially an adverse one, that is still useful because it will be an indication that GPL licences, etc. need to be amended to stop future foul play.

Relicensing existing projects isn't easy. It means all the original contributors or their heirs need to be traced and agreement obtained. It's one reason the Linux kernel is still GPL2.

You are quite right.

I can see the value in Red Hat getting a revenue stream in return for their excellent work. If a customer finds the relationship problematic they can take the source code elsewhere and under those circumstances loss of Red Hat support would not be an issue. The freedoms granted by the GPL are still effectively preserved, but by a thinner margin than I am used to.

I am concerned that as Red Hat have found this opportunity others will follow without contributing patches up stream. I see it as a weak part of the GPL. I hope it is not so weak that it can be embraced, extended and exploited.

With each new release could someone buy a copy then publicly redistribute it? Red Hat would then cut them off as a customer so it would require a new volunteer for each release. I assume Red Hat would try and vet customers to avoid this but would this be a possible work around?

From the article--

"...We suspect that the company is not going to back down on this..."

It's well-nigh way past time that everyone take a very serious dose of reality medication and therapy, along with a course in "Reading Comprehension 101". This will come as a shock to a lot of people, but,

There IS NO 'COMPANY'! See this week's Comment Section of "Distrowatch" , [1]here .

[1] https://distrowatch.com/

All that work to make italics and bold, would a direct link and/or quote have been too difficult? As it is your point is lost.

That "Reading Comprehension 101" is certainly needed because it's very clear indeed in the context that the company is Red Hat. In case "Big Purple" went over your head IBM which took over Red Hat is often referred to as Big Blue and, as mixing red and blue gives purple, the resulting amalgam is commonly referred to hereabouts as Big Purple.

The GPL doesn't free them from their Red Hat contracts: they can redistribute the source code if they so wish, but equally, the Hat can respond to them doing so by terminating their customer contracts, and that is 100 percent compliant with the GPL.

Is it though? Is there a legal basis for that assertion? I'm not a lawyer but as I read it the GPL requires you not to place any restrictions on the right to further distribute the source code. (Section 6 of the GPL2, and section 10 of the GPL3). The wording seems fairly plain and unambiguous, yet this seems to be entirely what Red Hat are doing? ("That's a nice support contract.... shame if something were to happen to it....").

Can you explain how terminating their contracts should they do this isn't a restriction as defined by the GPL? The choice seems to be continue to receive support or be able to exercise your rights under the GPL. That is restrictive surely?

I assume I am wrong in this, as to take the risk of potentially invalidating a whole chunk of the licences that your business is built atop would seem like madness. This suggests they've got actual lawyers involved.

But as a simple computer programmer can someone explain what I'm missing?

Don't really have a problem with RH making money, but to do it in the face of the licences they've agreed to. That's not right.

RH have complied with the GPL by making the source code to the software available to the customer. The customer may download the source code if they want to, that's fine.

If the customer then dumps it on Github, RH may not want them as a customer. Obviously this is not expressly written into the GPL or in the RHEL software licence.

I assume I am wrong in this, as to take the risk of potentially invalidating a whole chunk of the licences that your business is built atop would seem like madness.

The licences belonging to those distros which just build the RHEL source and make it freely available or more cheaply available than RHEL? I haven't done the maths but RH seem to have worked out it's not much and they might get more custom from people with RHEL copies going to RHEL.

As Doctor Syntax says above it's going to take a court to decide whether RH hinting that they'll terminate you as a customer if you choose to exercise your license rights to publish the source code. The GPL says you can't impose extra restrictions. Does the RH contract count as an "extra restriction"?

It might even turn out that different legal systems around the world will decide to interpret this differently.

In the end this is bound to end up in court and quite likely in more than one.

I've read opinions in other places that this isn't really aimed at the freebie clones but at the commercial ones who'd business model is to take the code from RH and then sell support at less than RH sell it for.

The business relationship between publisher/licensor and customer/licensee is not written into the GPL. The GPL is not about that, it's only bothered with ensuring that the software's source code is made available to the customer/licensee. If the business relationship is over, the GPL doesn't give the customer/licensee the right to continue receiving source code from the publisher/licensor.

The GPL is bothered with more than ensuring that the software's source code is made available to the customer/licensee. It's bothered about it being made available with the right to redistribute without further restrictions.

That is written into the GPL, including an obligation not to impose such restrictions on those to whom copies of code are supplied. The question here is whether the business relationship under which RH provide GPLed code implying such a restriction on their customers.

LOL. If that were illegal; then no "third party" support organization would be able to operate. Like your corner auto repair shop. Or tire store. Or appliance repair shop... ...etc.

Once you buy something; it's yours to do with as you will. Unless it's something under copyright; which adds (or subtracts) some restrictions. You can buy a book; read it; and later sell it to someone else; without restriction. But because of copyright laws; you can't make *copies* of that book and sell them; unless the copyright owner has given permission.

Now; Linux is software; which also comes under copyright law; but the GPL explicitly allows one to make copies of software licensed under it and redistribute them however one might want. But when you do that; all those copies are *also* licensed under the GPL (one can't change an upstream license without the approval of the original copyright owner). Which is basically what Red Hat is trying to do by; in essence; when saying "if you redistribute; we'll cancel your subscription to RHEL."

"Obviously this is not expressly written into the GPL or in the RHEL software licence."

What is expressly written into the GPL is that (a) it applies to derivatives, (b) the recipient of GPL code, if redistributing it, is bound to pass on the GPL with the code and (c) is not allowed to add further restrictions if they do and (d) is entitled to remove them if they have been added.

In this both Red Hat and their customers are recipients. RH as a recipient is bound by the GPL and if it modifies the code the resulting derivative is still covered by GPL, must provide the modified code if required and should not add further restrictions.

The question is then whether these contractual terms for RHEL are an implied further restriction.

If SEL is RHEL (source only available to customers), OpenSUSE Leap is Fedora, and Tumbleweed is CentOS Stream... nobody ever took SUSE to court over this model.

https://www.suse.com/download/sles/

Free support for 60 days

https://www.suse.com/source-code/

Typically, the source code is distributed along with the binaries. You can also send us a written request to provide the source code for a SUSE product by addressing your written request to:

SUSE Software Solutions Germany GmbH

c/o IP & Privacy Counsel

Maxfeldstrasse 5 , 90409

Nuremberg, Germany

If the customer then dumps it on Github, RH may not want them as a customer. Obviously this is not expressly written into the GPL or in the RHEL software licence.

Yes, it is, and the wording to me seems 'Obvious':

section 6 of the GPL 2:

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.

or section 10 of the GPL 3:

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.

So, again, I ask... how can RH do this and not have invalidated their licence to huge chunks of their distribution? Therefore making their distribution of those sections illegal? (One of these being Linux).

Yes, they can restrict their customers via contract, but I don't understand how they've not invalidated their licence to the software in doing so.

That is the bit I would like explaining.

You say the GPL doesn't forbid what they're doing, but it really seems it does??

Much of Linux (particularly the kernel) is distributed under the GPL; not GPL V2 or GPL V3.

GPL V1 - the original GPL - in 3 (b) states:

b) accompany it with a written offer, valid for at least three

years, to give any third party free (except for a nominal charge

for the cost of distribution) a complete machine-readable copy of the

corresponding source code, to be distributed under the terms of

Paragraphs 1 and 2 above; or,

"Any third party" would seem to me to include exactly that: "Any"; whether an actual customer or not.

If the customer then dumps it on Github, RH may not want them as a customer.

That may well be true, but there seem to be at least 2 possible problems with it:

1) There is certainly a case to argue in court that by deliberately punishing customers who choose to freely publish GPL code, RH are violating the terms of the GPL licence. IANAL, and it is quite possible RH might win, but I am sure it will be an arguable case and that some lawyer or activist body will choose to take it on.

2) In practice, how would RH find out which customer made the source code available? The source code either is, or is not, the source code from which the software the customer received has been built. If RH have watermarked the code in some way then it is not the source code from which the software was built. And the GPL allows the receiver to remove any watermarks they can find (or make any other changes they want to the code, for that matter) before deciding to publish the code.

While I can imagine that what RH seem to be planning to do could be done, I don't think it is sustainable in the real world unless almost all their customers agree.

The problem here is that the GPL states that it's the definitive license of the work licensed under it; and that no additional terms can be imposed.

It also says that source code redistribution cannot be denied. Not binary; SOURCE.

Red Hat's business model is selling *support* for it's distribution. Which is perfectly legal under the GPL. It's not software. So not bound by GPL license terms. However; Red Hat's attempt to restrict *source* redistribution of the components licensed under the GPL within it's packaging via *contract* terms would seem to obviously add an additional "term" to the licensing the software is distributed under. Which isn't allowed by the GPL.

I've never had any issue with Red Hat's business model. It's very similar to a warranty; after all; which often can be extended for an additional length of time via additional payment; until the product reaches "End of Life". But the software in it's *distribution* is like a book who's author(s) (the copyright holders) have previously granted copying rights. That's what the GPL does.

The authors of the GPL (Free Software Foundation?) need to weigh in on this in an official stance. The question here isn't about the "cost" of the software. It's the freedom to use it as one sees fit. Red Hat doesn't "own" it in the traditional sense. So how can they add restrictions on how it can be used or disseminated? The *worst* they're allowed to do is not honor requests for support from those who didn't obtain it from them.

They've managed to remove the raison d'etre of the rebuild/clones.

I, for one, am not going to bother learning Red Hat specific stuff on a rebuild because there is now zero prospect of using Red Hat in production. My efforts will be focussed on debian and derivatives.

I know that some software vendors insist on a particular OS, but we can now say "no, that's not going in our network" - they can either lose a sale or agree to installing it on another OS.

I've been running a combination of debian/derivatives and Red Hat/derivatives for many years... strangely it's consistently been the debian ones which are far easier to maintain (especially when it comes to updating to latest releases)

"it's consistently been the debian ones which are far easier to maintain"

You're apt to find that.

I can't imagine RedHat going to lose too much business as they have fingers in many pies, Ansible to name one, but you certainly make a good point. Is it worth making an effort to learn the guts of RHEL if fewer companies are likely to bother with it? Probably far better to stick at learning the higher levels of being a Linux jack-of-all-trades and avoid bothering to know anything more than a few of core functions of RHEL.

This is just another 'cake and eat it' pigeons coming home to roost moment. I think RedHat have a point about the direction of open source, but not in their stance.

When Liam says making it easy for competitors to copy work isn't what FOSS was ever about, what you really mean is it's never been what *Linux* is about.

Whilst using BSD source comes with some moral pressure to contribute back to the ecosystem it is not and never was necessary. It's never an issue to get hold of the source.

What the large Linux providers actually want is :

To make money from the software they produce

To do so on the backs of other people's work, some of which was provided for free under the expectation people would not make money off their work directly or indirectly

For other people not to be able to make money off the providers' work, despite the fact they have already done the same thing

As a sub point, when they manage to commercialise some of it, for the large cloud providers not to break their selling model

To still have other people carry on to provide them free labour

I can see this may attract a large amount of criticism and down votes, but consider that Red Hat and others, despite their code contributions, have driven and continue to drive Linux in a direction beneficial to them, not to the Unix community as a whole, or arguably even the Linux community as a whole.

There is nothing, except a huge amount of cost and effort, from stopping Red Hat slowly moving away from the GPL. That is what BSD did with their AT&T encumbered versions.

I don't doubt that Red Hat contribute a large amount of code and are on balance a major benefit to the Linux community. However, someone taking the benefit of another's work for commercial gain when that wasn't expected is the same thing whether it's Red Hat taking other Linux contributions and considerably enhancing it, or another party taking Red Hat's work and making few changes.

Just because you're working hard on it doesn't mean you're in the right.

Now, I do think RedHat have a point about funding. Too many open source products are inadequately funded, and if this continues they disappear.

However, RedHat and many others have no high ground here as can be seen with historic issues such as OpenSSL's Heartbleed. They're all relying on poorly funded and sometimes inadequately tested projects, and hoping they're sufficient to build their projects upon.