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

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 (guest, #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.