OpenELA's first code drop

Posted Nov 4, 2023 15:54 UTC (Sat) by jzb (editor, #7867)
In reply to: OpenELA's first code drop by rsidd
Parent article: OpenELA's first code drop

I'm not sure I agree that cloning Red Hat without saying "Red Hat" is unethical* or that Red Hat would even mind**.

Red Hat publishes code to CentOS Stream that roughly corresponds with RHEL, and invites people and organizations to work with that. It has taken steps to stop "bug for bug" compatible clones, or at least make that work harder. If that means OpenELA and any downstreams are touting "Enterprise Linux" code without direct claims of 1:1 compatibility with specific RHEL releases, that kind of seems like a win for Red Hat.

It means there's doubt around whether a OpenELA-derived release is actually "compatible" with the RHEL release. So if people are shopping for RHEL, and not just an "enterprise Linux" release, that makes it more likely they'll go to Red Hat. If you actually "need" RHEL, maybe you'll actually buy a subscription instead of using a clone. And if all you want/need is something that kind of looks like RHEL and you're happy to forego all the certifications and such -- take your chances with one of the OpenELA distros.

* As long as they're not stripping any copyright notices or things like that.
** I am a former Red Hat employee, but don't take anything I say as past or current official Red Hat stance on anything. Whether Red Hat as a company minds the omission of the words "Red Hat" is just speculation on my part.

OpenELA's first code drop

Posted Nov 6, 2023 20:40 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (4 responses)

It was always my understanding that what Red Hat really wanted to stop was people buying a one-seat support contract, running CentOS (pre-Stream, nowadays Rocky or something) on a few hundred workstations, and then, whenever a workstation has a problem, you first reimage it with CentOS, and if it still doesn't work, you reimage it with your "one" copy of RHEL and ask for support. Then you reimage it back with CentOS and reapply the fix (which will probably still work, because CentOS was at the time more or less equivalent to RHEL).

Obviously, this is abusive of Red Hat's subscription, and they are well within their rights to prohibit it. The only real question, to my mind, is exactly what means they can or should use to enforce that prohibition, and exactly how it ought to be worded (technically, the customer only ever installs RHEL on one workstation at a time, so you can't just prohibit multiple installations...). I imagine there are probably other permutations of "install CentOS, buy RHEL support, and use the one for the other," but the above is probably the most tricky to outright ban. I imagine that CentOS might have been internally seen as an attractive nuisance for this sort of client misbehavior, and so they got rid of it.

(In case it's not obvious: A few hundred workstations will have problems at a higher rate than a single workstation. You are asking Red Hat to do more work, and refusing to pay for it, so that's abusive.)

OpenELA's first code drop

Posted Nov 7, 2023 3:26 UTC (Tue) by calumapplepie (guest, #143655) [Link] (3 responses)

That sounds like a lot of work. If you're willing to go to the effort of occasional re-imaging, then there's a decent chance you're also willing to go to the effort of just fixing broken things yourself.

To my knowledge, most Red Hat customers never use the support at all; they just paid for Red Hat so that they'd have the OS which their proprietary software vendor said was supported. If you can get a bug-for-bug identical OS without paying Red Hat at all, then why wouldn't you?

OpenELA's first code drop

Posted Nov 7, 2023 10:14 UTC (Tue) by zuki (subscriber, #41808) [Link] (1 responses)

> To my knowledge, most Red Hat customers never use the support at all; they just paid for Red Hat so that they'd have the OS which their proprietary software vendor said was supported.

80% of the value⁽¹⁾ of the service provided by Red Hat is timely updates with few regressions. So even if the customer never opens a ticket or makes a support call, they are using the support provided. If there never is a major bug worthy of a opening a ticket, then that's Red Hat QA working as expected.

Testing of RHEL packages with various proprietary (or not) software vendor's third party stuff is also part of the work done by Red Hat. And fixing regressions — if an update breaks 3rd party stuff, it will be fixed/reverted/redone. That is part of the "support" too.

⁽¹⁾ number made up ;)

OpenELA's first code drop

Posted Nov 9, 2023 3:18 UTC (Thu) by sionescu (subscriber, #59410) [Link]

It's common for vendors in certain "high-security" environments to only certify their software on a specific version (service pack) of RedHat. Their customers will necessarily buy RedHat licences, install the exact service pack stated in the vendor's docs, then explicitly block updates because they don't want to pay for an update to the software, and the current version will stop working if the host is updated to another service pack.

OpenELA's first code drop

Posted Nov 7, 2023 10:40 UTC (Tue) by farnz (subscriber, #17727) [Link]

Re-imaging is trivial - it's literally "click the button, reboot the system and wait". The only hard part in the whole thing is being careful with your licensing, so that you've not got more copies of anything in use than you're paying for - but you're doing that anyway, because your proprietary software terms allow for audits, and have huge fees included if you fail an audit; e.g. one package I've encountered had a "list price" of over $100,000/month per user in a month, but you could easily negotiate down to under $10,000/year per concurrent user. Fail audit, and you would be expected to pay list price for that month; so, having had 10 concurrent users, and 30 engineers using it in a month, you'd go from under $100,000 in a year to $3,000,000 for the month in which you were audited and found to have more concurrent users than you'd paid for.

In this sort of situation, you've already built tooling and processes to guarantee that you comply with the licensing rules, because of the cost of failing to do so, but you'd still like to cut out the $9,000/year "overhead" you pay for RHEL with Standard Support for 30 engineers using RHEL workstations with the expensive proprietary software. Doing so by reimaging with real RHEL (bearing in mind that in the environment I saw this in, workstations are reimaged daily to stop engineers saving work locally instead of on the NetApp) whenever a bug needs reporting is cheap, especially since your bug-for-bug rebuild of RHEL is unlikely to have many bugs. And most of the cost is "fluffy" cost, in terms of engineers not doing their work but waiting to use the "real" RHEL system to reproduce a bug to be reported to the tool vendor or to RHEL support.