Red Hat cutting back RHEL source availability [LWN.net]

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 15:23 UTC (Wed) by GhePeU (subscriber, #56133) [Link] (114 responses)

To be honest I'm only surprised it took this long.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 15:37 UTC (Wed) by Bickelball (guest, #143671) [Link] (90 responses)

I feel like the actions of Rocky and Alma pushed Red Hat to try and defend their business. I saw an article that called Rocky and Alma parasites and feel like that was pretty accurate. Clipped text from article below:

...
Overgrazing the commons
I’m sure the history of technology parasites predates open source, but that’s when my career started, so I’ll begin there. Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusion of these two RHEL clones’ success would be to eliminate their host, leading to their own demise, which is why one person in the Linux space called them the “dirtbags” of open source.
...
Complete article here:
https://www.infoworld.com/article/3697733/chatgpt-s-paras...

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:08 UTC (Wed) by MarcB (subscriber, #101804) [Link] (29 responses)

This criticism is somewhat dishonest. It is not that Red Hat is providing some particularly sophisticated solution no one else could have come up with. It is also not about commons at all.

What RedHat actually provides is the - sometimes exclusively - supported environment for 3rd party software. They can do this, because they are in a uniquely strong position and have established connections to many suppliers of such software. Competitors can't really do this, because it is a chicken-egg-problem. Larger vendors will not even talk to you, if you are too small.

Red Hat invested a lot of time and money to achieve their position, but it should be clear that this is not about fairness, and that no one besides Red hat will benefit from this. This does not mean, that what Red Hat is doing is intrinsically unfair - but it might become at some point.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:34 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

Yes
And those 3rd party are supported on redhat -not on some clones like centos.

So if you care about being supported, you pay and use redhat
If you are not, then you could as well use anything else: suse, Debian, gentoo, whatever

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 4:34 UTC (Thu) by mbar (guest, #73813) [Link]

> not on some clones like centos
You just wrote that Debian testing is a clone of Debian stable.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:49 UTC (Wed) by jzb (editor, #7867) [Link] (21 responses)

"It is not that Red Hat is providing some particularly sophisticated solution no one else could have come up with."

This seriously undervalues what Red Hat does overall with RHEL. Red Hat didn't start out in a "uniquely strong" postion, they fought to get there. Providing a "supported environment for 3rd party software" is a lot more complex and sophisticated than people give Red Hat credit for -- Red Hat has to do a ton of development work upstream to land features that customers want across multiple upstreams.

Then they work with partners to do testing and certification. And then they support an operating system for a decade plus, including upstreams that go EOL like Python 2.7.

Red Hat makes open source consumable and boring for businesses. It's a lot of chopping wood and carrying water that competitors have tried very very hard to avoid, in a variety of ways. (Credit where due, I think SUSE tries to emulate this to a large degree, they've just been less successful at scaling it.)

Just because Alma and Rocky and others can quickly recompile the source code to RHEL should in no way delude people to think they can easily step in and do all the development that happens up to that point. People seem to handwave away all the work that leads up to that source code in the first place. Sophisticated isn't really the metric here: it's the ability to deliver an open source platform that's consumable by business at scale for a decade. Repeatedly.

But people have seriously devalued that because they can get the bits for free without thinking too much about all the work that went into the source that makes the bits available.

There's a related discussion about how relevant RHEL is now given that the world is moving away from a model of staying on an OS for 10 years. But that doesn't decrease the complexity of providing that or make it any more honest to handwave away what RHEL represents as not "particularly sophisticated."

Disclaimer: I'm a former Red Hat employee (and even more former SUSE/Novell employee...)

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:35 UTC (Wed) by pizza (subscriber, #46) [Link]

> Just because Alma and Rocky and others can quickly recompile the source code to RHEL should in no way delude people to think they can easily step in and do all the development that happens up to that point. People seem to handwave away all the work that leads up to that source code in the first place. Sophisticated isn't really the metric here: it's the ability to deliver an open source platform that's consumable by business at scale for a decade. Repeatedly.

Yeah. It's all very cargo-cult-ish.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:59 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (18 responses)

10 year-plus
This is so damageable to the world

This kind of offer helps the damaged mindset from the 90ise that you can, sanely, let an environment live forever

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:03 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (12 responses)

> 10 year-plus This is so damageable to the world

Yet I guess you complain about planned obsolescence and lack of firmware update when it's about phones, TVs or NAS enclosures...

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:09 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (11 responses)

Hardware is not software

In which sane world do you run a ten-year old libssl ?
In which sane world do you use a ten-year old screen ?

I have différent answer for those questions

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:17 UTC (Wed) by pgarciaq (subscriber, #153687) [Link] (5 responses)

In which sane world do you run a ten-year old libssl? In which sane world do you use a ten-year old screen?

In essentially any enterprise environment, actually.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:21 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (4 responses)

Those same environnement that closes for two month after a cyberattack ?
I don't know, I've work for many compagnies and never met such choices with succesful outcome: it was always a failure

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 18:54 UTC (Thu) by clump (subscriber, #27801) [Link] (2 responses)

Distributions like RHEL and Debian may ship older versions of software. When security issues arise, maintainers may backport fixes or upgrade to newer versions.

More information for RHEL can be found here: https://access.redhat.com/security/updates/backporting

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 19:19 UTC (Thu) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

Yes, yes, that's a nice story

On the other hand, let's have this other nice story
You have rhel 6, supported up to 2020, released in 2010 with openssl 1.0.0

TLS 1.2 has been added to openssl 1.0.1 in 2012

Question: in 2020, on my fully supported rhel 6 server, do I:
- use TLS 1.1, because that's all I can get and I am insecure
- use TLS 1.2, because redhat backported the whole TLS 1.2 implementation

Answer:
None
openssl was upgraded from 1.0.0 to 1.0.1 somewhen

So you started with a specific version, and upgraded to another
Basically, you could've just upgraded to the next release ..
Yes, I know that this "is just a library"

Yet if you have a very sensitive system, upgrading just that library means running the full qualification procedure

Anyway
From my personnal experience in compagnies, 10-years support is very great because people can just fire some stuff and move on
Said stuff will rot in place, never to be touch in many years, but that is not my problem so I do not care
And then you come, consider said system, consider that everybody who worked with that thing left years ago
And you cry alone in the dark

3-years support is far better from a security perspective, because it is a reason to keep taking care of stuff: manager will give you time, security teams will prioritize etc
And when systems are kept sane all the time, as when you clean your house, so job is simple and easy
Whereas when you leave the dirt for year, good luck cleaning the mess ...

Security is nothing but psychology.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 20:37 UTC (Thu) by clump (subscriber, #27801) [Link]

OpenSSL is a good example of what we're talking about. The answer to your question is to update the package and TLS version. See: https://access.redhat.com/articles/1462223

Ten+ year security doesn't make software less secure, quite the opposite. You can still upgrade to a new version of RHEL every two or three years. My experience is that organizations don't care as much about operating system versions as they do about the versions of the applications and languages they're running. In those cases, they're often providing their own OpenSSL or Java or Python.You might upgrade the OS every couple of years, but you're constantly upgrading your applications.

Too many of my customers *only* care about their applications. They don't think much about the underlying operating system. That's among my customers that self-manage. Many of my customers are running toward cloud services as fast as possible.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 13:40 UTC (Fri) by Freecoffee (guest, #165758) [Link]

From the security perspective new is not always better, and the work RHEL does is epic at this point.

There was a time in computing when everything could be free/semi free and open but all that leads to now is lack of viability and longevity of the work.

If anyone has not noticed the billion hours of coding in flash sites that evaporated from the internet.

I have worked in development for companies and the honest truth is no one can afford to direct resources to perfection and recreating the wheel.
Yes ivey grows over entire areas of apps and buisness processes and in a perfect world there would be maintenance but that is not any company I have ever worked for.

On a side note the cloud is great until you need to have stable costs. It does not give an operation a lot of leverage in negotiation when you are dependant on the cloud for your buisness infrastructure. No asset model what could go wrong.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:33 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

Lack of updates is a huge part of how you get planned obsolescence.

I have a Synology NAS from 2013 that got its last *major* update last year, and it's not even cloud enabled. Meanwhile other companies that actually expose your data on the internet might sell you an old model that they don't plan to update anymore in 2025.

Well, Synology is doing the same kind of work as Red Hat.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 4:07 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I just retired by 10-year-old Synology today actually. Alas, with WFH, doing `rclone` over VPN to the cloud was a losing proposition and Golang has yet to support the MIPS32 processor it used, so my remote backups have been out-of-date for quite a while. It had a good run, but the hardware choices never got adopted by the New Languages :/ .

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 0:05 UTC (Thu) by butlerm (subscriber, #13312) [Link] (2 responses)

The entire business model of a company like Red Hat requires making critical and necessary updates to versions of dependencies long since abandoned by their original developers. In other words no one using RHEL is running an unpatched, unsecured ten year old libssl or anything like it, they are using a generally ABI compatible version maintained by Red Hat with security fixes and necessary upgrades, and often more than one such version.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 7:06 UTC (Fri) by taladar (subscriber, #68407) [Link] (1 responses)

So really, when you think about it, they are running bleeding edge software versions that got limited testing, patched by people who know less about it than the original developer. But because said developer chose not to modify the version number people think their system is somehow "stable".

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 16:14 UTC (Fri) by jzb (editor, #7867) [Link]

"So really, when you think about it, they are running bleeding edge software versions that got limited testing, patched by people who know less about it than the original developer."

Really, when I think about it, I am aware of the amount of testing that goes into RHEL and feel fairly confident that if what I need is a long-term stable operating system it's going to meet my needs.

The original developer / project, in many cases, hasn't done nearly the amount of testing against what they've released vs. what ends up in RHEL. Calling it "bleeding edge" is silly. The reason many people want and pay for RHEL is because they know that there's additional testing vs. the vanilla upstream.

I would grant you that the original developer has more context for the original software. Whether they know more than the person patching it, overall, is not guaranteed. Whether they're better at security or fixing security issues is definitely up for debate.

You seem to be simultaneously arguing that you really want to run RHEL, and that it has little value, which is mystifying to me.

Red Hat cutting back RHEL source availability

Posted Jun 24, 2023 15:13 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (4 responses)

> 10 year-plus
> This is so damageable to the world
> This kind of offer helps the damaged mindset from the 90ise that you can, sanely, let an environment live forever

Yeah for sure... Quite frankly, read what you wrote, all of this makes zero sense. You're taking the example of people that do not apply any single update to judge a model where a vendor makes the effort of providing updates so that responsible customers can maintain their software up to date.

For sure some people like those making a living of selling hardware might prefer to see landfills full of obsolete cars because the software that runs on the central computer isn't supported anymore, make a business of desoldering components from obsoleted smartphones, or doubling the price of energy delivered to a vulnerable neighbor country while they're running maintenance operations to replace the hardware in power plants due to the new requirements of a major software upgrade. But there are also a lot of people who want to keep safe software running fine on existing hardware without changing prerequisites every 3 years nor facing regressions due to forced major upgrades.

You seem to be ignoring an important fact, which is that a linux distro is primarily a redistribution of a collection of opensource software, and that a lot of them are done as side jobs, and not in a professional manner, meaning that forward compatibility is not the most common thing. As such performing a distro upgrade almost guarantees a number of regressions or breakages that are sometimes OK on your laptop but not at all in many environments. Distro vendors providing 10 years support go through that effort mainly to protect their customers from this.

Red Hat cutting back RHEL source availability

Posted Jun 24, 2023 15:40 UTC (Sat) by ju3Ceemi (subscriber, #102464) [Link] (3 responses)

Excuse me .. what ?

I am sitting on a i5-2400, released in 2011, running Debian 12 (released in 2023)
Do you really believe people have to change hardware every time they update the software ?

That is .. that is crazy

Also, when you pay a RHEL subscription for a server (at least 350$/y without support nor any stuff), you probably have some kind of business behind this
People with hobbies for their free time do not pay that money for the elusive right to use old hardware ..

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 8:13 UTC (Sun) by wtarreau (subscriber, #51152) [Link] (2 responses)

The 'E' of RHEL stands for "Enterprise". Nobody cares about your i5-2400 released in 2011 in this context, as it's not supposed to run this distro. And yes, most enterprise users will renew their hardware after a few years to save on energy costs. The fact that your 4-core 95W i5-2400 from 2011 is half as powerful as a 8-core 7W Core i3-N300 from 2023 is probably not a problem for you, but it's an enterprise's responsibility to divide power usage per performance unit by 27 like this over the years. Thus in practice a server will be installed with a distro and will run it until it gets decommissioned 3-8 years later. And that's also in this context that for such users the effort made by package maintainers to provide non-breaking updates that fix bugs and security issues is valued, because these customers basically don't have to think about the software anymore. On your PC or laptop you can devote time adjusting/fixing packages after an upgrade if you want. When you deal with 1000 servers you don't want to discover breakage every morning anymore.

I, too, used to find CentOS interesting for end users. It's just that lots of consultants install this at their customers' as a way to save money by not buying the original, hence avoiding to pay for the development effort done upfront. I'm not seeing a simple solution to this, to be honest. Maybe they should make a free version of RHEL which is trivial to activate and switch to a paid mode, to try lower the barrier of adoption, and pre-fill a number of visible config files with "this is an unregistered copy, if you value it please consider supporting our effort". But the constant guerilla between RHEL and forks is only hurting their users, community and their image by making the solution look not sustainable in my opinion.

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 8:23 UTC (Sun) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

So enterprise will renew their hardware to save energy
Nothing related to RHEL

Mais tu sais, je me suis déjà occupé d'un parc de 3500 serveurs (à l'époque où j'étais ton client)
Peut-être n'avons-nous pas eu les mêmes expériences professionnelles, fréquentés les mêmes genre d'entreprise ?

Thank you for your feedback anyway

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 4:50 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

Maybe, maybe not, I can't know since you're posting under an alias. In any case if you've dealt with so many servers you certainly understand the value of not going through major upgrades for no reason and only applying the regular fixes that come with enterprise distros.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 21:22 UTC (Wed) by Wol (subscriber, #4433) [Link]

> Red Hat makes open source consumable and boring for businesses. It's a lot of chopping wood and carrying water that competitors have tried very very hard to avoid, in a variety of ways. (Credit where due, I think SUSE tries to emulate this to a large degree, they've just been less successful at scaling it.)

To put it another way, it's Red Hat that puts food on the programmers' tables.

Cheers,
Wol

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 18:19 UTC (Thu) by markhahn (subscriber, #32393) [Link] (4 responses)

debatable - rh is a flag of convenience.

but think about what the vendors are doing here: it's slimy. they should be saying "our app runs on anything compliant with a particular standard". the whole "supported on" is lazy and hostile to the customer.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 22:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

It's not so much slimy, as lazy (in the sense that all programmers are lazy). If I say "runs on anything compliant with a particular standard", then I need some way of verifying that my app really does run on anything compliant with that standard - that means that tools need to exist that check my app for cases where it assumes an implementation detail, and tools need to exist to verify compliance of your OS with the standard.

By saying "runs on Ubuntu 14.04 LTS", I've isolated down exactly what I'm promising - if I accidentally depend on an implementation detail of Ubuntu 14.04 LTS that changed in 16.04, that's fine, because I promised I'd work with 14.04 LTS only. And if Canonical update Ubuntu 14.04 LTS and break my app, I've got to catch up; so I want to work with Canonical to ensure that either this doesn't happen, or I have some notice and can fix my app before my customers get the update.

Same logic applies to RHEL, except that the RHEL support lifetimes are slightly longer than Ubuntu LTS (6 years to last release instead of 5, 12+ years from first release to end of ELS to Ubuntu's 10 years from first release to end of ESM).

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 0:48 UTC (Fri) by intelfx (guest, #130118) [Link]

> By saying "runs on Ubuntu 14.04 LTS", I've isolated down exactly what I'm promising - if I accidentally depend on an implementation detail of Ubuntu 14.04 LTS that changed in 16.04, that's fine, because I promised I'd work with 14.04 LTS only.

Well, that’s exactly what OP meant by “[being] hostile to the customer”.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 8:53 UTC (Fri) by eduperez (guest, #11232) [Link]

> they should be saying "our app runs on anything compliant with a particular standard".

History has told us, over and over again, that being "compliant" with a particular standard, means next to nothing; there are countless "anecdotes" of software compliant in theory, but incompatible in practice.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 16:31 UTC (Fri) by jzb (editor, #7867) [Link]

Have you supported any products of note against "anything compliant with a particular standard" yourself?

What the vendors are doing is not slimy, lazy, or hostile here. First of all, the idea that there even exists a "particular standard" to be compliant *with* is questionable given the number of dependencies that any given application might have. What standards would you suggest that are adequate to say that a database or streaming/messaging platform is supported?

Let's say I want to ship a product based on Apache Kafka. Please tell me which standards I can target that are available in shipping operating systems that guarantee if I target them I can also promise support.

The most reasonable way for a vendor to develop, test, and support an enterprise type application is to pick specific versions of popular operating systems and work against those. Because we're not just talking about "it compiles and runs" -- we're talking about being able to support a customer with heavy workloads and a contract with an SLA that says downtime costs you, the vendor, money.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:36 UTC (Wed) by rbtree (guest, #129790) [Link] (28 responses)

If there are any real parasites, it's Oracle Linux. A multi-billiion dollar company does nothing but take the source, rebuild into their own clone of RHEL, and then sells support for it. I feel like it was them who pushed Red Hat into doing this.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:56 UTC (Wed) by ballombe (subscriber, #9523) [Link] (14 responses)

Oracle has enough money to pay for a RHEL license for one box and get access to the source...

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:41 UTC (Wed) by acdha (guest, #165733) [Link] (13 responses)

Yes, but to do that they'd have to sign a binding legal agreement saying they wouldn't do that. The unauthorized use section of the license appears to suggest that Oracle could only do that by paying for RHEL licenses for each Oracle Linux system (emphasis mine):

(g) Unauthorized Use of Subscription Services. Any unauthorized use of the Subscription Services is a material breach of the Agreement. Unauthorized use of the Subscription Services includes: (a) only purchasing or renewing Subscription Services based on some of the total number of Units, (b) splitting or applying one Software Subscription to two or more Units, (c) providing Subscription Services (in whole or in part) to third parties, (d) using Subscription Services in connection with any redistribution of Software or (e) using Subscription Services to support or maintain any non-Red Hat Software products without purchasing Subscription Services for each such instance (collectively, “Unauthorized Subscription Services Uses”).

This might violate GPL

Posted Jun 21, 2023 20:19 UTC (Wed) by faramir (subscriber, #2327) [Link] (12 responses)

Not sure if that last part isn't violating the GPL on anything for which RedHat doesn't own copyright for the entire codebase. They could probably use the contract to cancel someone's subscription, but I would think the GPL would stop them from
forcing their (former) customer from using the source code they had already obtained. Of course, not all of the software in
RHEL is GPL'ed; but some rather important things are. The RHEL Workstation license at $179 is probably the cheapest
available. Fifty two "users" could buy a new license once a week and pay less than $10,000 a year to get full access. Even if they banned people, it would be like trying to play whack-a-mole to shut something like that down. This might cost more than hobbyists could afford, but it might be amusing to see Oracle try to do it or even better just pay for hobbyists to do it.

This might violate GPL

Posted Jun 21, 2023 21:28 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

You're missing the point. It says "Unauthorised use of SERVICES". You are paying RH for a service, which has nothing to do with copyright, GPL, source code, whatever. It basically gives Red Hat the right to say "bye bye customer, nice knowing you, we no longer wish to do business with you".

If you are relying on support services to keep your boss / shareholders / regulators happy, that's a biggy.

That's why, although I'm pushing Scarlet at work, I'm also pushing the fact that it is a source derivative of OpenQM, and the latter is a slot-in replacement. If my employer wants to pay for a licence and support they can.

Cheers,
Wol

This might violate GPL

Posted Jun 22, 2023 9:07 UTC (Thu) by leromarinvit (subscriber, #56850) [Link] (1 responses)

The way I understand the GP comment, this is not something this "customer" would care about - it would be the expected course of business. They'd just send a new "throwaway" customer to RedHat every time the last one is kicked out.

Not saying I'd condone Oracle doing this, and then turning around and selling the result for profit. I'd have much less of a problem if someone did this and gave the result away for free.

It's of course still silly, and I'll continue not using any RHEL clone myself (or RHEL itself, for that matter). But I also have a hard time believing CentOS or other clones being freely available really made much of a difference for RedHat's bottom line. In my mind, what RHEL customers are paying for is having a system that's officially supported by the vendor of whatever it is they actually want to run, not for the base OS itself. Having a free clone available, even if 100% equivalent on a purely technical level, doesn't change anything in that equation.

This might violate GPL

Posted Jun 27, 2023 7:39 UTC (Tue) by TRauMa (guest, #16483) [Link]

What Red Hat, apparently, is concerned with is organizations buying support for say 10 servers and then filing bugs and support requests for 50, which is easy to do if 40 of them run on something that is not Red Hat in branding, but bug for bug compatible. As far as I can tell it's the reason that buying Red Hat is so expensive and uneconomical for small shops - if Red Hat offered an affordable small license, many of their customers would use it to run their server farms on it. When they have to buy a somewhat big package because there's nothing small on offer, they can't gamble the system quite as much. And now Red Hat tries to strangle the bug for bug compatible versions.

This might violate GPL

Posted Jun 22, 2023 10:03 UTC (Thu) by farnz (subscriber, #17727) [Link] (8 responses)

You lose your Red Hat services if you break this contract. You still have your GPL rights to the source you have, but you're not getting updates from Red Hat any more.

And yes, there will be trickery to get round this - but Red Hat could (for example) simply refuse to sell RHEL Workstation to people it suspects of working somewhere that's not playing the game the way Red Hat want them to, using sources like LinkedIn to check your affiliation, and asking if you still work at $COMPANY before selling you a services contract.

This might violate GPL

Posted Jun 22, 2023 11:21 UTC (Thu) by matp75 (subscriber, #45699) [Link] (7 responses)

Humm, I doubt they would really "refuse to sell" as it would be illegal in most countries. Probably just making things harder is enough (like not being able to check it is same source easily so in people mind that impact supportability/compatibility)

This might violate GPL

Posted Jun 22, 2023 11:23 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

What countries make it illegal for me to refuse to sell a service to someone? The only cases I'm aware of involve refusal based on a legally protected characteristic (e.g. I can't refuse to sell to you for being a woman, or disabled, or based on skin colour).

This might violate GPL

Posted Jun 22, 2023 12:18 UTC (Thu) by skissane (subscriber, #38675) [Link] (2 responses)

> What countries make it illegal for me to refuse to sell a service to someone? The only cases I'm aware of involve refusal based on a legally protected characteristic (e.g. I can't refuse to sell to you for being a woman, or disabled, or based on skin colour).

Under Australian competition law, "it may be illegal for a business with substantial market power to refuse to supply its goods or services without a legitimate reason" https://www.accc.gov.au/business/selling-products-and-ser...

Does Red Hat have "substantial market power"? Would refusal to license their software to competitors constitute a "legitimate reason"? That's a question for the the regulator and the courts.

This might violate GPL

Posted Jun 22, 2023 13:44 UTC (Thu) by pizza (subscriber, #46) [Link]

> Would refusal to license their software to competitors constitute a "legitimate reason"?

That's not what RH is doing, has ever done, or can ever do. Because GPL and other F/OSS licenses don't let you discriminate. There is almost [1] nothing that RH ships that can't be obtained elsewhere.

Remember, we're not talking about "RH software" here, we're talking about "RH services". Absent a contract of some sort, there's nothing that entitles anyone to Red Hat services, in *any* jursidiction.

Meanwhile, "breach of contract" has routinely been upheld as a "legitimate reason" to not do (repeat) business with someone.

[1] The only exceptions are proprietary stuff that RH has acquired, but to the best of my knowledge they've always eventually released those things as F/OSS.

This might violate GPL

Posted Jun 22, 2023 16:05 UTC (Thu) by farnz (subscriber, #17727) [Link]

I would be surprised if the regulator found that RH had substantial market power, and I would also be surprised if "intends to break the terms of the contract they are agreeing to" is not a legitimate reason to refuse a sale - remember that this is just about the Red Hat services, not about the licences on the software (which you can get from Red Hat without the support services, via CentOS Stream).

Substantial market power would require the market to be one where you can't substitute Ubuntu LTS (Canonical), SLES (SuSE), nor can you substitute RHEL-compatible distros like Oracle Enterprise Linux, CentOS Stream, Rocky Linux, AlmaLinux, ClearOS, Miracle Linux. Given the sheer amount of compatible choice (OEL, CentOS etc), and two commercial alternatives that aren't hard to port to (Ubuntu and SLES), I can't see how a regulator would decide that Red Hat's commercial offerings represent substantial market power - not least because it's trivial to move to a compatible alternative from someone else.

This might violate GPL

Posted Jun 26, 2023 18:34 UTC (Mon) by matp75 (subscriber, #45699) [Link] (1 responses)

It may be illegal in France, see https://www.inc-conso.fr/content/refus-de-vente-ou-de-pre...
but looks like from this page , it is dependent if the buyer is considered a consumer and there are very few exceptional conditions.
I have seen it used between 2 business for software (just could not refuse to sell at list price) (the vendor sold it to not be sued even if the buyer attitude was very incorrect and unfair at that time)

This might violate GPL

Posted Jun 26, 2023 19:26 UTC (Mon) by farnz (subscriber, #17727) [Link]

The question would be whether a legitimate expectation that you will violate the contract you agree to when buying the service is sufficient to refuse to sell you a service covered by that contract - my understanding is that such a violation is one of the exceptional conditions, even in business to consumer sales (albeit that the permissible contract terms are very restricted in B2C sales in France).

This might violate GPL

Posted Jun 22, 2023 15:09 UTC (Thu) by Wol (subscriber, #4433) [Link]

> Humm, I doubt they would really "refuse to sell" as it would be illegal in most countries.

Would it? It would almost certainly be legal to refuse here in the UK. If a shop mis-prices an item they can refuse to sell it. What they CAN'T do is reprice it upwards at the till, but if they put a £10 tag on it instead of £100 they can withdraw it from sale. Most shops however would honour the £10, write the loss off, and rapidly go and reprice the shelf, but they are under absolutely no obligation to do so. (Repricing at the till is treated as "making a fraudulent offer", and while shops do do it, if their victim is a Trading Standards Officer, they are in for a world of hurt ...)

So if Red Hat said to a prospective customer "you've acted in bad faith (broken your contract) before, we don't want to deal with you", there is absolutely nothing the prospective customer can do about it except walk away - Red Hat could even threaten to bill them for wasting RH's time and they would be completely within their rights.

The government does not get involved with private contracts, unless the judiciary is asked to rule on a broken contract (or other such things as is a contract legal ...).

Refusing to sell is basically policed by the reputation damage such a refusal would cause. Which is quite often minor, especially for the big players ... (provided they don't do it too often).

Cheers,
Wol

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:01 UTC (Wed) by dullfire (guest, #111432) [Link] (1 responses)

While I am loath to say anything nice about Oracle, and have seen lots of things they did badly, it is ironic the above comment comes so soon after this article: https://lwn.net/Articles/934941/

Where we have quotes like:

> Something that he has heard the stable maintainers complain about a little bit is the lack of companies willing to stand up and say that their products are based on the LTS kernels and that they are willing to fund maintenance and backporting activity for those kernels. He reiterated that Oracle does use the LTS kernels; it picks up the odd-year LTS for its enterprise kernel and the company is "totally willing to fund" work on the parts of the kernel that it has experience with and knowledge about, which includes filesystems and storage, Wong said.

I have no direct knowledge one way or another how true Wongs statement is, but I would image (and hope) that there would be several people calling him out if he was making a bald faced lie. So it would seem likely there is at least some truth to it.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 21:21 UTC (Wed) by geofft (subscriber, #59789) [Link]

Yeah, much as the community hates to admit it, Oracle really is active in upstream maintenance and they really do a lot besides just compiling Red Hat's SRPMs. For kernels in particular, Oracle maintains their own distro kernels ("Unbreakable Enterprise Kernel") as well as rebuilds of Red Hat's kernels as best as they can reverse-engineer the source tree ("Red Hat Compatible Kernel"). The Oracle tree is the default one, but the Red Hat one is available for customers who are running third-party products that really need the features of a particular Red Hat kernel and not just userspace compatibility. https://blogs.oracle.com/linux/post/changing-the-default-...

Also doing a git log --author=oracle.com in your Linux kernel clone, Xorg server clone, or a few other repos will also be informative.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:22 UTC (Wed) by pebolle (guest, #35204) [Link] (5 responses)

> rbtree (guest, #129790)

Should we point you to a mirror?

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 9:17 UTC (Fri) by rbtree (guest, #129790) [Link] (4 responses)

Go ahead. I've been paying for LWN for years before your sanctions cut off my access to banking services. And I am not even Russian.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 13:42 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (3 responses)

End the aggression, pay the reparations and sanctions maybe will be lifted.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 14:53 UTC (Fri) by paulj (subscriber, #341) [Link]

Interesting precedent this, to target sanctions at citizens generally (resident or not) of countries that engage in aggressive wars abroad, and require reparations for past aggressive wars before lifting such sanctions. It would be good to apply that evenly. USAsians and UKians take note.

Anyway.. we are certain to incur the wrath of our dear editor if we continue.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 15:01 UTC (Fri) by rbtree (guest, #129790) [Link] (1 responses)

I have about as much responsibility for another country's actions as you do. My home country is much more peaceful than yours ever was if you're from any of the NATO states, so you both should probably have a good look in the mirror instead of lecturing others.

Let's stop here

Posted Jun 23, 2023 16:23 UTC (Fri) by corbet (editor, #1) [Link]

This isn't something that will be resolved to anybody's satisfaction on LWN, and is certainly off-topic; let's please stop this thread here.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:50 UTC (Wed) by jzb (editor, #7867) [Link] (1 responses)

Indeed. It's interesting that I don't see too many people interested in Oracle Linux as a CentOS Linux alternative. I think that speaks volumes.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 8:54 UTC (Thu) by leromarinvit (subscriber, #56850) [Link]

To be honest, even if they gave it away for free, I'd be vary of using it. Given their past behavior, putting yourself at the mercy of Oracle doesn't exactly seem like a winning proposition.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 14:35 UTC (Thu) by digdilem (guest, #165747) [Link]

Indeed.

The lineage is something like

Free (Fedora) -> Free (CentOS Stream) -> Commercial (RHEL) -> Free (Rocky) OR Free (Alma) OR (Free/Commercial Oracle)

I understand OEL itself is free, but you can buy support - happy to be corrected if that's wrong. Rocky also sells support through another company - neither impacts usage of the OS if you can provide your own support. RHEL is unique that you don't get to play with *anything* unless you pony up first. (Limited free subscriptions aside)

It'll interesting to see how Rocky and Alma will adjust to this change.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 15:41 UTC (Thu) by digdilem (guest, #165747) [Link]

> If there are any real parasites, it's Oracle Linux

Actually, I think Redhat is acting very similarly to how Oracle used to in the past. Since the IBM acquisition, Redhat has been acting far more commercially aggressive and I personally view both companies very similarly.

Red Hat cutting back RHEL source availability

Posted Jun 24, 2023 0:48 UTC (Sat) by timrichardson (subscriber, #72836) [Link]

You may as well call free software a cancer. That's what these arguments sound like.

Red Hat built its business on open source. It turns out not be convenient, apparently.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:17 UTC (Wed) by gtirloni (subscriber, #85631) [Link] (9 responses)

I can't even imagine what all the non-RedHat employees that contributed code used today in RHEL might be thinking.

Such a parasite that I am for submitting bug reports, helping users for free, writing docs, promoting RH products, paying for RH support, writing bug fixes and features that make their way into apps that RHEL uses... Shame on me. Red Hat truly doesn't owe anything to anyone, having created their empire with their own hands from scratch. Congrats to them; I can only repent.

I've been using Red Hat distros since the RH4 days and have contributed in many ways, but I'm downloading a Debian ISO just now to avoid being such a leech on them.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 8:19 UTC (Fri) by AdamW (subscriber, #48457) [Link] (8 responses)

I totally understand being angry at this, but - if you don't mind, and this is a genuine question - as a valuable community member, do you actually need an attempted bit-for-bit rebuild of RHEL for something? Is there anything for which CentOS Stream and/or Fedora are not doing the job?

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 2:48 UTC (Sun) by richarson (subscriber, #74226) [Link] (7 responses)

Speaking for myself: stability over a long period of time (10 years) is the most important thing, bit-fot-bit compatibility is actually not high in my priorities list.

Neither Stream (5 years) nor Fedora (13 months?) provide that.

Stream is similar to Debian and Ubuntu LTS in terms of support years but Stream is also more of a moving target than the other 2.

So at this point, migrating to another distro is starting to sound less and less like an annoyance.

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 12:31 UTC (Sun) by pizza (subscriber, #46) [Link] (6 responses)

> Speaking for myself: stability over a long period of time (10 years) is the most important thing, bit-fot-bit compatibility is actually not high in my priorities list.

...Yet neither is important enough to actually pay for. Isn't that the whole point of this entire discussion?

> So at this point, migrating to another distro is starting to sound less and less like an annoyance.

Sure, but keep in mind that you'll be trading one set of pain points for another. Not necessarily better or worse, just different.

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 18:54 UTC (Sun) by richarson (subscriber, #74226) [Link] (5 responses)

> > Speaking for myself: stability over a long period of time (10 years) is the most important thing, bit-fot-bit compatibility is actually not high in my priorities list.
> ...Yet neither is important enough to actually pay for. Isn't that the whole point of this entire discussion?

If I (or actually, my bosses) had to pay for every system we have, we'd be bankrupt. And I know we're not the only ones in that boat.
I only stated (or maybe tried and failed to state) that our choice of CentOS/Alma/Rocky was mostly based on the longer support time of those distros.
And 99.999% of the time, we don't really need RH's support (we have in-house experts) so I can't justify paying all money for licenses.

> > So at this point, migrating to another distro is starting to sound less and less like an annoyance.
> Sure, but keep in mind that you'll be trading one set of pain points for another. Not necessarily better or worse, just different.
Oh, I'm aware, but we already use Debian and Ubuntu for some systems and since we have expertise, adapting should not be a huge problem.

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 19:33 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

> If I (or actually, my bosses) had to pay for every system we have, we'd be bankrupt. And I know we're not the only ones in that boat.

So.. who do you expect to pay to keep maintaining the software you depend on?

....If you're being honest, the answer is "As long as it's someone else, I don't care."

(Personally, I don't mind folks making money off of my code. But I have a problem with folks expecting me to support them, on their schedule, for free)

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 20:36 UTC (Mon) by richarson (subscriber, #74226) [Link]

I donate money to open source projects, a lot of peaople and companies do the same.

And I don't expect support from them, stop trying to put words in my mouth please.

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 22:06 UTC (Mon) by apple4ever (guest, #164280) [Link]

> So.. who do you expect to pay to keep maintaining the software you depend on?

Someone who has reasonable prices. See jccleaver below who already described the problem.

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 20:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> If I (or actually, my bosses) had to pay for every system we have, we'd be bankrupt.

What is the value of your systems being inaccessible for a week? Is it more than the cost of licenses for your machines? RedHat also supports popular public clouds with pay-as-you-go model.

So basically, either you pay for support, which is not cheap, but neither is it too expensive; or you accept the risk and go with one of the countless free alternatives (Debian, Ubuntu, Amazon Linux, Fedora, Gentoo, ...)

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 20:44 UTC (Mon) by richarson (subscriber, #74226) [Link]

As I said on another post, we have sufficient in-house expertise as to no need supoort most of the time, so we knowingly accept the risks, or better try to mitigate them (e.g. with HA) as much as possible.

The problem is, the main free alternatives that we're using (CentOS/Alma/Rocky) now are at the real risk that RH decides to cut them off.
I don't really think that's what RH wants to do but I'm afraid that it will eventually happend.

I like RHEL-based systems, I'd like to keep using them, but it *is* too expensive for us if we have to pay for all of our servers.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:21 UTC (Wed) by pebolle (guest, #35204) [Link] (1 responses)

> Bickelball (guest, #143671)

And it would still be dishonest if we even think of you as a "parasite" or a "dirtbag".

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 20:41 UTC (Thu) by clump (subscriber, #27801) [Link]

Does somebody need a hug?

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:29 UTC (Wed) by mrmattyboy (guest, #165732) [Link] (4 responses)

I'm assuming Rocky and Alma to be purely open source not-for-profit projects in this:

Personally, I see these projects as the "hook" for people.

If I could, I'd compare to Windows or (maybe) Photoshop - licenses are there to pay for the product - fine.
However, if I were somebody starting out, didn't have much money or no ability to _pay_ for those productions, it leaves with me with options:
* Go for a free alternative (this generally means lacking in features, but free)
* Pirate the software

Most of the time (and I'd bet all of the time) these companies accept this and, to me, they see this as a benefit.

You won't find an industry leader using pirated software (else they'd expect a lawsuit coming to them)... However, you will find plenty of people that have learned and grown to love the software through any means possible (pirated or otherwise).
So they invest in the technology that is useful to them and this is where the money comes from.

So bringing this back to RedHat.. if RedHat _only_ had the paid offering and there was never a CentOS or Rocky Linux, would it be as popular in the community - if not, I'd reckon they'd be a lack of interest in it and they'd struggle to get *new* business.
Startups and companies that start to use linux would have grown up with Debian and the like and, when they grow to or are in the position to chose a paid-for corporate license for this.. who will they pick? RedHat? Or Ubuntu or another provider that provides a free distribution?

This is where I think RedHat should support these open source programs, because they get a massive following behind EPEL (sorry, I'm not too familiar with the terminology of this ecosystem) and when money starts coming out of companies that need a reliable operating system, it will be the one that they're familiar with.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 7:13 UTC (Fri) by taladar (subscriber, #68407) [Link]

There are also all those third parties which make software RedHat wants to be built for RHEL. Large companies might buy a license just to have build and test servers but if you are just an open source project you are less likely to build for RHEL if there is no free distro (both monetarily and free of the hassle of licensing nonsense) version you can use on your build and test servers.

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 18:26 UTC (Mon) by parmstrong (guest, #165812) [Link] (2 responses)

"If I could, I'd compare to Windows or (maybe) Photoshop - licenses are there to pay for the product - fine.
However, if I were somebody starting out, didn't have much money or no ability to _pay_ for those productions, it leaves with me with options:
* Go for a free alternative (this generally means lacking in features, but free)
* Pirate the software"

There is another option.

Some people may not be aware that Red Hat provides RHEL and a lot of other bits for FREE. Simply sign up at http://developers.redhat.com
Create an account with your personal email address and you have access to the Red Hat Developer for Individuals subscription that allows you to run up to 16 instances of RHEL (and other Red Hat Software) in PRODUCTION for individuals. This is designed to get individuals and startups off the ground with software they can depend on. Also, huge community and tonnes of help.

Disclaimer: I am a Red Hatter.

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 19:14 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

> Red Hat Developer for Individuals subscription that allows you to run up to 16 instances of RHEL

That's now been raised to 240 instances:

https://linuxiac.com/red-hat-boosts-free-developers-subsc...

Red Hat cutting back RHEL source availability

Posted Jun 27, 2023 0:26 UTC (Tue) by edgewood (subscriber, #1123) [Link]

That seems to be a bug rather than a deliberate change. One of the original reporters has updated his toot after hearing from several Red Hat employees: https://fosstodon.org/@omenos/110602377978605193

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:04 UTC (Wed) by Vipketsh (guest, #134480) [Link] (7 responses)

To some extent I understand RedHat's position and I think it's not so much Alma or Rocky but rather the quite rich non-paying crowd that used CentOS before.

A few years ago I was working for one of the top-5 semiconductor companies -- operations that make literally billions in profit every year. I was pretty surprised to learn that these people rolled on their own: they used CentOS, had their own support and maintenance structures and, as a user, the result was pretty terrible. I think it would be quite fair if these companies with so much money would contribute just a little to the the software that makes their business tick. Much more so than some tiny company trying hard just to make ends meet.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 19:02 UTC (Wed) by jccleaver (subscriber, #127418) [Link] (6 responses)

Many of these companies actually TRIED to find a solution for this. Anyone who's been around OSS for a while is well aware of the negatives of the free-rider problem, after all.

After the financial issues with donations that CentOS had, and then once RH took over the project, RH actively pushed away people who wanted to write checks to ensure the larger EL ecosystem remained viable. The root of this is that RH's licensing fees make no sense for companies that don't need every box to be certified AND have their own (often large) staffs of Sr. Linux Engineers on duty. All of this was made very clear when CentOS Linux was pulled away in favor of Stream only.

Something like $350/box/yr for 1000s of boxes just doesn't make sense. We need RH for escalation points, but it's not like the 1000s of boxes are doing unique workloads or require individualized support. I worked for a large company that had maybe 3 different workloads across 8 different models of Dell hardware running at any given moment, across a huge farm. That's 3x8 combos of things that could go wrong where we need to phone RH for support, and everything else we'd handle ourselves.

We're not paying $350/box/yr for that if we don't need a certified OS on each system, but we'd pay a hefty site license fee and throw in a non-profit donation to the CentOS Foundation if we could have (and if it meant we got 4h SLAs on tickets). RH sells proprietary bits, but it doesn't sell a proprietary *platform* and the RH execs seem unable to comprehend this.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 10:12 UTC (Thu) by paulj (subscriber, #341) [Link] (5 responses)

For 1 in 10^X (X >>> 1) type problems, the number of bug reports you make will indeed scale with the number of boxes you run the software on.

"It doesn't matter how many boxes I run" is only true for (near) 100% hit-rate bugs.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 11:21 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

There's room for a compromise solution from RH, though. At 100,000 systems, you need a team who can correlate errors and distinguish hardware errors from software errors, whereas with 3 boxes, I can't make that distinction easily.

Thus, while the company with 100,000 systems will see a problem that occurs once in every 1,000,000 minutes every day, and raise a ticket, whereas I'll only see it every year or so, the ticket from the company with 100,000 systems is likely to be much easier to debug than mine, since my ticket is "this is a bug - it's occurred once, and then not again after a reboot, but I'm confident from the logs that it's a software fault. I'm not sure how to reproduce or test a fix", where the 100,000 system company will be raising a ticket of the form "this is a bug - you can see in these 100 logs that it's consistent. We can reproduce daily, and thus can test fixes in about a week".

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 17:18 UTC (Thu) by hkario (subscriber, #94864) [Link] (1 responses)

If you really were running 100k boxes, I'm pretty sure you wouldn't be buying licences through the web page, but have a discussion with a sales representative about bulk orders and negotiate a specific contract.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 19:56 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

When you only need 24 licenses to cover every combination for 100k machines, discussing special treatment may be a waste of time.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 19:00 UTC (Thu) by jccleaver (subscriber, #127418) [Link] (1 responses)

> "It doesn't matter how many boxes I run" is only true for (near) 100% hit-rate bugs.

Ehh, I'd say it's true for anything you can derive a reproducer for. But in my experience at $job-=3, that often *was* the case.

Most of our problems came about under high load conditions, sometimes with specific hardware thanks to a driver bug or whatnot, or with our app or DB doing something weird after a specific kernel update but working fine before. But the first line of defense for a large environment is always going to be your own SysEng/SysAdmin team, not RedHat Support. We'd be doing the isolation work to narrow down the problem as specifically as we can before we Phone a Friend and escalate because ultimately it's our job internally to keep those systems running.

I have no idea if RHEL subscribers as a whole treat RH as frontline Linux tech support, but that certainly wasn't our need and we weren't going to pay out the ass for that purely based on cores where the underlying product is still OSS. I can't believe the CentOS folks didn't realize that, but based on the behavior of others at RedHat, I very much believe that some of the other folks there didn't.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 22:42 UTC (Thu) by farnz (subscriber, #17727) [Link]

The only place I've worked that bought RHEL expected Red Hat Support to answer questions like "why does 'ln -sr' not remove the destination file if it already exists?" and "why does 'scp root@11.5.0.1:/file file' fail with a Connection timed out error when ssh root@10.5.0.1 works?"

I have no idea how prevalent that sort of behaviour was (and that place had under 10 servers running RHEL, so not a big burden for RH - it was mostly a Windows shop), but it's something RH have to account for.

I'd also note that because RH engineers participate upstream, including in CentOS Stream, if you're reporting your issues upstream once you find them, RH engineers may well get involved with the fix, to forestall their customers making the same demand later. This has happened to me with Xorg bugs in the past, where RH engineers fixed the bug upstream, precisely because they understood my bug report, and were able to fix it.

All you'd be paying RH for is the ability to get RH engineers to prioritise your bug over all the other things they do; a support contract where instead of charging per-server, they charge based on the number of incidents you can raise might well work for your situation - you pay to get access to the RH Knowledge Base, and to raise (say) 10 incidents per year with RH support, rather than paying for 10 servers.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 1:36 UTC (Thu) by andresfreund (subscriber, #69562) [Link] (3 responses)

> I feel like the actions of Rocky and Alma pushed Red Hat to try and defend their business. I saw an article that called Rocky and Alma parasites and feel like that was pretty accurate.

Red Hat has a parasitic side itself. For postgres I've spent many months supporting old toolchains, odd kernels with performance characteristic seen nowhere else, solely caused by RHELs extremely long support cycles - which they make money off, but I don't.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 7:19 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

And the worst part about that is that all the knowledge about old systems you acquire in the process is completely useless in the future. At least if some bug only occurs on some bleeding edge distro like Gentoo you are likely to encounter similar issues and software versions on more stable distros a year or three down the line. Any time spent on ancient version support is a huge waste in terms of side-benefits like learning.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 17:01 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

RHEL gives free (as in "no cost") licenses to developers: https://developers.redhat.com/about

Red Hat cutting back RHEL source availability

Posted Jun 27, 2023 7:57 UTC (Tue) by TRauMa (guest, #16483) [Link]

Did you mean to comment this somewhere else because I fail to see the relevance here.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 17:53 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Such a comment from a LWN.net guest who doesn't pay for a subscripition is -- simply gross.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 11:01 UTC (Fri) by Wol (subscriber, #4433) [Link]

> I’m sure the history of technology parasites predates open source, but that’s when my career started, so I’ll begin there.

Edison? His (rejected) patent claiming to invent the light bulb post-dates his visit to a light bulb factory ...

Cheers,
Wol

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:14 UTC (Wed) by amacater (subscriber, #790) [Link] (19 responses)

From RHEL 2.1 to RHEL 9.x - so much for compliance with licensing conditions and supplying source from here on in.

Remember the promises given round the release of RHEL 2.1 - at which point RHEL had gained the co-operation of the independent Fedora distribution?

Rocky and Alma were doing precisely what they were able to do given access to the source.
They weren't representing themselves as RHEL. They gave their own support.

This is the Oracle Linux playbook that Red Hat complained about so much - remember Unbreakable vs. Unfakeable?

Is it now back to hardball copyright lawsuits that led to the demise of the likes of Pink Tie Linux and White Box Enterprise Linux?

For third parties developing for deployment on RHEL - maybe run, don't walk, from RHEL development - you'll now have to rely on each of your customers paying for Red Hat Enterprise Linux support and maintaining their subscription.

For instances where Red Hat is the upstream for a significant codebase: how long before they change the licensing or availability to other distributions?

I've always questioned what "support" meant in the context of an enterprise distribution - it now means access to GPL'd code?

[From someone who remembers Red Hat 9 the first time]

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:29 UTC (Wed) by pizza (subscriber, #46) [Link] (12 responses)

> For third parties developing for deployment on RHEL - maybe run, don't walk, from RHEL development - you'll now have to rely on each of your customers paying for Red Hat Enterprise Linux support and maintaining their subscription.

Um, that's no change from before; if those customers wanted "support" they always had to pay RH for it. Everyone else has been essentially freeloading on top of the fees RH's customers are paying. Especially Oracle, who was directly binting RH's hand in the process.

Meanwhile, likes of Alma/Rocky (and even Oracle) can just grab the source packages from CentOS stream and use that as the basis for their rebuilds. After all, nothing shipped in RHEL wasn't already present in CentOS stream first.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:45 UTC (Wed) by MarcB (subscriber, #101804) [Link] (4 responses)

There are two, very distinct, reasons to use Red Hat: The support you get from Red Had and the support provided by 3rd parties for their software, exclusively on RHEL - or a 100% compatible platform.

You only needed RHEL for the first, now also for the second, because 100% compatible platforms will no longer be realistic.

Apparently Red Hat believes that 3rd parties will stick with them as the only supported platform.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:52 UTC (Wed) by cesarb (subscriber, #6266) [Link] (3 responses)

> Apparently Red Hat believes that 3rd parties will stick with them as the only supported platform.

I know of at least one third party that, after the CentOS announcement, started focusing on Ubuntu LTS as the recommended platform, while before it was CentOS/RHEL.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:16 UTC (Wed) by Vipketsh (guest, #134480) [Link] (2 responses)

Unfortunately it's not always so easy because often you are not the only vendor who's tools your customers are using. They can only use a distro which is supported by all the tools they use. For example, in the semiconductor industry *everyone* will be using tools from the Big 3 tool vendors who generally support RHEL 6,7, often 8 and rarely some version of SLES. Thus, if you are not the big 3 and you want to provide some tool to this industry you have to support the aforementioned distros and trying to support anything else is meaningless.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:26 UTC (Wed) by gtirloni (subscriber, #85631) [Link] (1 responses)

Compared to all other RH customers, the semi industry must look tiny, doesn't it? Also, their RH Support costs would be a line error in their budget.

Recent moves by IBM and Red Hat hurt more small companies and individuals. You know, the ones that one day might grow to actually buy official support from Red Hat. They are shooting themselves in the foot but this is classical IBM thinking.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 8:35 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

>Compared to all other RH customers, the semi industry must look tiny, doesn't it?

It’s the same in every industry. ISVs want to limit the number of platforms they have to support, they will happily support Red Hat (RHEL), Microsoft (Windows), Google (Android) as long as those do not gouge them too much, provide some benevolent dictatorship of the platform and someone paid you can call when things go wrong.

Consider that even the multiple abuses of Microsoft, could not convince the industry to invest in anything but Windows on the desktop. It did bare Microsoft access to dominance of the (new, not established yet) mobile and server market but no one was in any hurry to rock the desktop boat.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:12 UTC (Wed) by PlaguedByPenguins (subscriber, #3577) [Link] (2 responses)

> After all, nothing shipped in RHEL wasn't already present in CentOS stream first.

That wasn't how it worked.
At least in the early days of Stream, important kernel security updates turned up in Stream weeks later than in RHEL (and Alma/Rocky). I don't know if it's still that way.
I was perfectly happy to help debug future RHEL by running Stream, but "less secure than Alma/Rocky" was a red line, so I had to give up on it.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:09 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

That's only true of embargoed issues, but even then the aim is for sources to hit stream roughly when the embargo lifts. That said stream was a huge change in how RHEL is developed and (even though I do very little of that) I am not surprised if there were some initial pains.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 16:02 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

This is not my understanding, although I'm certainly no expert. My understanding is that if RH is going to deliver a fix for a CVE, embargoed or not, that fix is delivered in binary form to RHEL customers before it is made available to anyone else, even in source code form. This is a selling point of having a RHEL subscription.

The result of this is that if the RH developers manage to get the source changes into CentOS Stream on the same day that the binaries are made available to RHEL customers, the 'clock starts ticking' for Alma/OEL/Rocky on that day. There are more complexities involved too: the RHEL package may contain *only* that CVE fix, but the CentOS Stream code may contain other non-CVE fixes that haven't yet been shipped to RHEL customers. This, also, is a selling point of having a RHEL subscription: customers often want *only* the CVE fix, and literally nothing else, even if those other things are also bug fixes, until they are ready to consume those other fixes.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:00 UTC (Wed) by amacater (subscriber, #790) [Link] (3 responses)

CentOS Stream isn't stable: at the point at which RHEL 9.x forks from it, there may be patches in Stream that are in advance of what's actually in RHEL 9.

Hence the fuss in December 2020 or thereabouts. "Freeloaders" and "parasites" isn't exactly the best phrase to describe FLOSS users - and I'm somewhat surprised at Matt Asay using that terminology.

I've seen less evidence in the last few years of Red Hat/IBM caring for the desktop and workstation users - migrating to cloud and containers, producing their own infrastructure with Podman. As someone using and supporting Red Hat systems over many years, this does feel like an abandonment of RHEL as a vibrant infrastructure supporting the commercial world - a definite change from Red Hat pre-acquisition - and an unwelcome development overall.

Each very definitely to their own - but if I were starting a project tomorrow, I'd assuredly *not* use Red Hat or a Red Hat derivative, though I might have recommended it today.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:06 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> CentOS Stream isn't stable: at the point at which RHEL 9.x forks from it, there may be patches in Stream that are in advance of what's actually in RHEL 9.

That's just patches heading into the next point release. All of this is maintained in git branches. That's how that the other rebuilders are able to accurately rebuild RHEL.

> Hence the fuss in December 2020 or thereabouts. "Freeloaders" and "parasites" isn't exactly the best phrase to describe FLOSS users - and I'm somewhat surprised at Matt Asay using that terminology.

I am assuming you haven't read Matt Asay much.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:11 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

To be fair, until now the rebuilders were using git.centos.org. They will indeed need some adaptation to their tools.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 7:32 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Matt Asay is firmly in the camp of the last corp paying him to defend its (often shady) business practices, spraying dirt on the competition. It’s a wonder he is still identified as an OSS authority by some (though it says a lot about what “open source” was really about).

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:40 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

> From RHEL 2.1 to RHEL 9.x - so much for compliance with licensing conditions and supplying source from here on in.

To my understanding, this is entirely compliant with the licensing conditions. The GPL (and pretty much every other copyleft license) does not say that you have to post all source code publicly. It says that you have to provide source alongside any binaries you distribute, to the recipient of the binary. If Red Hat only distributes RHEL binaries to customers, then they only have to distribute RHEL source to customers. Similarly, if they only distribute CentOS Stream binaries to the public, then they only have to distribute Stream source to the public.

Of course, Red Hat's customers *could* then turn around and release the RHEL source publicly. I guess they're just not terribly interested in doing that.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:01 UTC (Wed) by jccleaver (subscriber, #127418) [Link]

>Of course, Red Hat's customers *could* then turn around and release the RHEL source publicly. I guess they're just not terribly interested in doing that.

That in and of itself wouldn't be an issue. However, all signs point to RedHat terminating the license of someone redistributing its bits. Using those SRPMS to run a rebuild and then distribute the packages *you* create would be the next step, but something tells me RH plans to make binary or self-hosting rebuilds as painful as absolutely possible going forward. Kind of like what they did for their kernel patches in the SRPM once Oracle started doing its OEL thing.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:03 UTC (Wed) by jzb (editor, #7867) [Link] (2 responses)

What promises has Red Hat broken here? I'm genuinely curious. Can you point to specifics?

"They weren't representing themselves as RHEL." I believe Rocky uses the phrase "bug-for-bug compatible" with RHEL. So, technically, not saying "this is RHEL" but walking as close to that line as possible.

"For third parties developing for deployment on RHEL - maybe run, don't walk, from RHEL development - you'll now have to rely on each of your customers paying for Red Hat Enterprise Linux support and maintaining their subscription."

So here's a thought. Maybe they should be paying for RHEL support? What vendors want is a platform they can target that they can depend on. The development and maintenance of such a thing doesn't come cheap. If Debian, for instance, is good enough - great. Target Debian, tell your customers to use Debian, and they can save the RHEL subscription money for whatever.

But. If it actually has value and the complaint is "I can't get that platform for free anymore," where the platform sits under an application you're paying a vendor for, maybe you (or the vendor) need to be paying for it.

The thing that everybody is really panicking about is the loss of a free RHEL. Think about why that is. Because it does have value and they know the alternatives don't provide what they really want.

If you are using a RHEL clone in non-production situations they have no-cost subscriptions and/or the CentOS Stream model should be sufficient if what you want is a RHEL-alike that doesn't have to be "bug for bug" compatible. If you absolutely have to have "bug for bug" compatibility with RHEL, I'll say again: Then you probably ought to be paying for it.

(Disclaimer: I am a former Red Hat employee.)

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 8:00 UTC (Fri) by taladar (subscriber, #68407) [Link] (1 responses)

> If you are using a RHEL clone in non-production situations they have no-cost subscriptions

But what I want as someone who already thinks supporting the ancient versions RHEL uses is a huge pain is to avoid the additional pain of licenses, not paying for licenses, the whole license nonsense itself. I want to make some Docker build image or test server without having to worry about making a RedHat account and signing up for some free license, connecting the system to the license server,... even if RedHat thinks that is the way my use-case should be covered "for free".

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 16:02 UTC (Fri) by jzb (editor, #7867) [Link]

"But what I want"

Is irrelevant, really. I mean, you're entitled to want whatever you want, but Red Hat as a business is not obliged to make it possible. They've come a long way from the early CentOS days to try to meet the needs of people who don't match their customer profile. If signing up for a subscription and dealing with subscription processes is still too much trouble for you, then there's plenty of other Linux distros that are really good for most use cases.

But if you want or need "bug-for-bug" compatibility with RHEL -- if CentOS Stream and their Red Hat Universal Base Image aren't close enough for your needs -- either meet them where they are or don't use RHEL.

I get that Red Hat's subscription process adds friction. I use their no-cost developer subscription myself for a workstation and server. It adds a little bit of time for me to sign into their web-based system and generate images that are already subscribed. But it's necessary because I want to use RHEL for a workstation for work and my $dayjob has a software requirement that depends on either a specific version of RHEL or Ubuntu, and of the two I'd prefer to use RHEL.

There is a point where it becomes unreasonable to expect Red Hat to make available or allow "bug-for-bug" clones of their *product* with zero cost and zero friction.

The reason people want very specifically RHEL and not CentOS Stream is all the stuff outside the source code that Red Hat adds that makes, say, "RHEL 8.5" attractive but "CentOS Stream 8.5.2111" unattractive. The certifications, documentation, regression testing, and very specific compatibilities that go with RHEL 8.5 but not Stream.

If you're not a customer, you're not entitled to that. Because it's not merely about the source code at that point, it's about a whole lot of other work that is well beyond the software and that costs a ton of money beyond development.

Note: "I want to make some Docker build image...without having to worry" about an account is doable today, if Red Hat UBI has the packages you need. They do make a Docker image freely available based on RHEL that requires no relationship with Red Hat at all. See this for example: https://hub.docker.com/r/redhat/ubi8

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 23:05 UTC (Wed) by rqosa (subscriber, #24136) [Link]

> Is it now back to hardball copyright lawsuits that led to the demise of the likes of Pink Tie Linux and White Box Enterprise Linux?

Out of curiosity: did Red Hat ever threaten legal action against either one of those? If so, that's news to me.

Searching for the first one led me to this Linux.com editorial from June 2002, which mentions that "Red Hat apparently demanded that Cheapbytes not to sell the ISO images of Red Hat Linux as “Red Hat Linux.”", but that was the reason why Cheapbytes rebranded it in the first place, rather than something that happened afterwards.

(Other sources indicate that Cheapbytes got at least as far as RHL 8.0 — which was released about 4 months after that editorial, and was the next-to-last RHL release version prior to its split/rebranding into Fedora Core and RHEL — before they gave up. And by that point in time, cheap and readily available CD/DVD burners together with broadband ISPs were well on their way to ruining the business model that companies like Cheapbytes and Walnut Creek CDROM had used in the 1990s.)

As for WBEL: I used it for a while in the mid-2000s, and ISTR reading discussions back then (on its mailing lists & elsewhere) in which users complained that, as a practical matter, WBEL was one person's pet project, whereas CentOS was maintained by a larger team who were better able to keep it up to date with RHEL. For example, this LWN article from March 2005 mentions that CentOS had already put out a release based on RHEL 4, whereas WBEL hadn't. So I'd been assuming that that was the reason for its demise.

(Incidentally: as of right now, its website is still online, but it looks like its front page hasn't been updated since 2009.)

Red Hat becoming IBM

Posted Jun 22, 2023 9:14 UTC (Thu) by kragil (guest, #34373) [Link] (2 responses)

IBM is a bad company, nearly Oracle kind of bad, so RH is going in that direction fast. Seems that they have accelerated that transformation with this move. It is only downhill from here, and it was crystal clear from the start that this was going to happen. First they killed free (useful) CentOS, and now they want to kill RHEL-clones, because quarterly reports are demanding growth. You see that everywhere now. MS, Google, Amazon, Netfix etc. They all _try_ to "fight" the downturn with these "changes".
And all the IBM-employees here calling other free software projects parasites don't change these facts.

Red Hat becoming IBM

Posted Jun 22, 2023 13:04 UTC (Thu) by tau (subscriber, #79651) [Link] (1 responses)

"Growth" is the entire problem. Companies defend these sorts of actions by saying that they cannot survive unless they make money, but the truth is that the modern financial sector does not allow them to survive unless they make _exponentially increasing_ amounts of money.

Maybe this is an overly rosy picture but there was a decades-long period where companies cultivated stable lines of business and sources of revenue, and they would occasionally expand into new markets if there was a compelling business case for doing so. When they needed capital to fund this expansion they would talk to an investment bank to raise the funds. Now investment banks are behemoths that run the show and demand constant exponential growth in the name of "disruption" and "innovation". This is impossible to sustain beyond the short term of course, but by that point they've slurped up all of the short term gains and dumped the dysfunctional wreck on whatever retail investor is left holding the bag.

RH had a perfectly stable ecological niche and the business unit is being wrecked by demands that it show Silicon Valley style hypergrowth.

Red Hat becoming IBM

Posted Jun 23, 2023 11:05 UTC (Fri) by Wol (subscriber, #4433) [Link]

Driven by the fact that we're all pushed into investing our money into pension funds ...

Where the managers are rewarded for making a profit, and not punished for making a loss, so it's in their interest to ride a roller coaster. Who cares if they make a loss some years as a few shells they've sucked dry go bust. Just be glad you're starting from lower down so when you find a new victim to suck dry you can award yourself higher bonuses.

Cheers,
Wol

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:00 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (5 responses)

IIUC (I work for Red Hat but not on how sources are distributed), there is absolutely no change in practice.

CentOS Stream RPM sources are stored in GitLab therefore the whole history is available including past minor releases of RHEL. The only change is that the repositories will not be mirrored to git.centos.org.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:11 UTC (Wed) by jzb (editor, #7867) [Link] (2 responses)

That's nice to hear. I'd say that the blog post that sparked this is a bit muddy on this point.

In practice, does this mean that the RHEL clones will still be able to identify the source that makes up a RHEL release / minor release to rebuild it, or is that going to be (on purpose or simply as a byproduct) obfuscated too much to rebuild a RHEL release going forward?

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 19:45 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

There may be some issues if an embargoed issue hits very close to the release, but generally it should be okay.

The relevant bit in the (admittedly cryptic) post is "To be clear, this change does not signify any changes to the CentOS Project, CentOS Stream or source availability for CentOS Stream or CentOS SIGs". The changes for rebuilders are minimal but I can see why the author didn't want to say they are not affected.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 19:49 UTC (Wed) by jzb (editor, #7867) [Link]

Thanks for the clarification / response. Much appreciated.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 14:20 UTC (Thu) by pabs (subscriber, #43278) [Link] (1 responses)

A clarification to your comment from mroche on HN:

Some clarification is needed here.
git.centos.org (g.c.o) has been the historical canonical local for RHEL sources that have been exported out of Red Hat. On any given package you would see several branches, one for each major release and other organizational artifacts (e.g. c7, c8, c9, etc). Initially CentOS Stream 9 was exported to g.c.o as it wasn't a true upstream in the full sense of the word, but with CentOS Stream 9 that changed. c9s is developed in full on GitLab, and now c8s as well, while the final RHEL sources for those packages are still output to the c8 and c9 branches on g.c.o.
What changes here is that Red Hat will no longer be exporting the c8 and c9 content to any git platform (c7 will continue as exists until its EOL). Customers can access sources as needed via the Customer Portal and CDN repositories, but sources in git form will not be publicly available for those artifacts. Moving forward, only c8s and c9s sources will be available, and g.c.o will not see any updates for EL8 and EL9.
While most (I'd estimate at least 95%) of the platform will match in terms of NEVRA between versions available in CentOS Stream and their RHEL counterparts, there are some packages that will not due to the way they are developed.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 17:06 UTC (Thu) by andrewsh (subscriber, #71043) [Link]

Here’s even a more detailed explanation by Aleksandra Fedorova. The summary:

3) So what happened?

CentOS Engineers will not be producing that git repo of exploded SRPMs anymore because there is no need for them in CentOS project.
Red Hat recommends to take RHEL sources from CentOS Stream repositories because that is the actual source from which RHEL packages are built by RHEL Engineers.
Can you still get access to SRPMs and create exploded sources repo - Yes. But there is no practical reason for Red Hat or for CentOS Project to maintain such a service.
There is no change in Fedora or with anything related to Fedora.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:56 UTC (Wed) by xilun (guest, #50638) [Link] (9 responses)

I'm kind of disturbed by all the comments here calling projects that exercise basic Free Software freedoms "parasites".

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:14 UTC (Wed) by pebolle (guest, #35204) [Link]

> I'm kind of disturbed by all the comments here calling projects that exercise basic Free Software freedoms "parasites".

My thoughts exactly.

Calling other people "parasites" should not be done lightly. And complaining about people that do what Free Software is actually all about should not be done at all.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:37 UTC (Wed) by Bickelball (guest, #143671) [Link] (3 responses)

In a healthy open source ecosystem, competition and innovation go hand-in-hand. Red Hat, Suse, Canonical, AWS, and Microsoft all create Linux versions with associated branding and ecosystem development efforts. All utilize and contribute Linux source code, but none claim to be “fully compatible” with the others. That is like being a counterfeiter in my view.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 19:17 UTC (Wed) by camhusmj38 (subscriber, #99234) [Link] (2 responses)

If full compatibility with X is what the market demands then you have to provide it. And if you have provided it you should be able to say so so you can compete with the market leader. IBM PC/Compatible for example.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 5:43 UTC (Thu) by Bickelball (guest, #143671) [Link] (1 responses)

the market does not demand full compatibility with Red Hat - Ubuntu has more market share than Red Hat, and Suse and AWS Linux have healthy market shares - they build and share a lot of code together with Red Hat, but don't just copy Red Hat and claim bug-for-bug compatibility - and try to sell support for x% less. That is very parasitic sounding, or counterfeiting, in my view...

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 19:27 UTC (Thu) by jccleaver (subscriber, #127418) [Link]

>the market does not demand full compatibility with Red Hat - Ubuntu has more market share than Red Hat, and Suse and AWS Linux have healthy market shares

That's a weird way of looking at it. The "market" demands what it demands, and the EL-based ecosystem is large. Frankly, I'd consider the RPM and DPKG worlds to be distinct, with RH controlling Fedora and RHEL (and thus all EL derivatives).

The fact remains that near-bug-for-bug compatibility with major RHEL releases is functionally all that matters for most EL-level ISVs, users, and operators. RHEL is making these harder to create, apparently unaware of how vast this ecosystem is and how important it is for their future sales and support contracts. RHEL complaints that people will run 3000 CentOS boxes and pay for three RHEL licenses for the boxes that some vendor requires upstream support contracts for, without realizing that there's a vast market there for real-world monetization of that for people that don't actually *need* to otherwise do so the vast majority of the time.

So yes, there's market and a need for this, and RH continues to shoot itself in the foot and piss away decades of goodwill through its actions here.

A true "centos" (Community Enterprise OS) that functioned with the bulk run like Debian, with certification done by a couple of big internet companies that would be fine throwing a $1M here and there to a non-profit that paid for it would cost a lot less than the $34B that IBM paid RH for. Amazon could do this with Prime Day pocket change.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 19:30 UTC (Wed) by flussence (guest, #85566) [Link] (1 responses)

If anyone wants to get mad about the way Red Hat interprets license compliance, perhaps they should start by addressing a smaller target like, oh I dunno, various GNU projects' practice of throwing opaque code dumps over the wall. Start with Bash.

That said, I've always found this obfuscation of process Red Hat engages in to be childish and ineffective. The general perception of their brand is that they seem entirely unable to compete by *offering a better product*, so instead try to undermine others around them as if those others can't simply rebase on another distro's copies of source code. If they were serious about giving Oracle a black eye they'd be sponsoring PostgreSQL like there's no tomorrow. Or bcachefs (or tux3), or LibreOffice. That thing they keep doing to Ubuntu apparently successfully.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 19:49 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

What is obfuscated in having all SRPM sources available in git trees for the whole pipeline covering Fedora Rawhide, Fedora ELN and CentOS Stream? There is hardly any difference between c9s and RHEL9 sources except for embargoed issues whose fixes have to be developed and built internally.

In 2009 when I started at Red Hat doing a backport for RHEL entailed sending email to a private mailing list or committing to a private CVS server. These days I just open a merge request on GitLab, transparency has increased immensely.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 12:46 UTC (Thu) by gdt (subscriber, #6284) [Link] (1 responses)

Yes, it's not like Red Hat are paying to create the majority of the software they distribute.

If you are the author of a program and you get a bug report against your software running on RHEL then re-creating that bug has now become more complex. Sure there are zero-cost options, but that's still complexity (eg, annual renewal). What's worse is that Red Hat didn't ask you if they could include your software in RHEL or EPEL, which is rather 'parasitic'.

An answer for smaller software projects is to state that the supported platform is Debian and to tell users of RHEL and other commercial distribution to access the support which they are paying for. The result is a worse experience for commercial Linux users, but that's a natural result of Red Hat's changes to the ecosystem surrounding their distribution.

In the long run these changes will hurt Red Hat. People looking to deploy their "first real Unix" won't consider RHEL as the walls are too high. That in turn will make RHEL questions less able to be answered informally (which is currently the way the vast majority of RHEL issues are solved). Availability of trained people is already the major limiting factor to RHEL use, and this decision will only make that worse, limiting the size of the RHEL market.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 13:37 UTC (Thu) by pizza (subscriber, #46) [Link]

> Yes, it's not like Red Hat are paying to create the majority of the software they distribute.

Red Hat pays folks to support (and maintain) everything they ship as part of RHEL, including long after upstreams have EOL'd the specific stuff RH shipped.

RH also spends a *lot* of money to support, maintain, and even create quite a few upstream projects and general infrastructure used by many more.

> If you are the author of a program and you get a bug report against your software running on RHEL then re-creating that bug has now become more complex.

It's no different than it was a week ago. If you were already using actual RHEL, you can continue as before. If you were using a RHEL rebuild, then you continue as before.

> An answer for smaller software projects is to state that the supported platform is [something] and to tell users of RHEL and other commercial [ /ancient/LTS ] distribution to access the support which they are paying for.

This is perfectly reasonable.

However, I think it much more appropriate to tell them that you'll support their platform of choice in exchange for appropriate compensation. Honestly, this the only sustainable answer, as anything else devalues your time.

Red Hat violating GPL

Posted Jun 22, 2023 22:39 UTC (Thu) by dreadedhill (guest, #140784) [Link] (1 responses)

To my read, this is an exact violation of the GPL, as Redhat is forbidding re-distribution.

Had to go read the GPL to refresh memory. :)

Perhaps Redhat can lock down some non-GPL bits, through not without complications.

Red Hat violating GPL

Posted Jun 22, 2023 23:06 UTC (Thu) by farnz (subscriber, #17727) [Link]

Red Hat aren't forbidding redistribution - they're saying that if you redistribute the RHEL SRPMs, they reserve the right to drop you as a customer. You are still permitted to redistribute the RHEL SRPMs; the terms for the subscription services make it clear that the worst case is that you're in breach of the subscription agreement. In turn, the general terms for agreements with Red Hat make it clear that the penalty for being in breach is that RH can give you 30 days notice that they're dropping you as a customer.

And the actual licence agreement for RHEL says that you must remove RH trademarks before redistribution, but that otherwise it's permitted to redistribute.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 2:13 UTC (Fri) by pabs (subscriber, #43278) [Link]

I am reminded of Drew Devault's 2021 post "Open source means surrendering your monopoly over commercial exploitation":

https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-y...

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 19:14 UTC (Mon) by xman (guest, #46972) [Link]

Honestly, I think this is going to just play in to cloud providers' hands. Choking the "free" Red Hat world is going to make vendors and users alike flee to the distros managed by their cloud providers... ultimately weakening Red Hat's hand.