When I was working for the US government we had to obey rules against shipping "freeware," which RHEL wasn't because we payed for it. But it was cheaper and easier to do most of our development on CentOS systems and because the software was the same we weren't worried about compatibility issues.

> we had to obey rules against shipping "freeware"

I am in the USA but this is new to me.. can you say more or better, links? regarding science applications, specifically...

I’ve worked at orgs where the problem with freeware wasn’t the lack of cost, but the lack of support/indemnity/assurance and the lack of a contract to establish a legal framework for the dependency.

ok- so if I understand those terms, roughly(?):

support --> contact system for humans to reach other humans with bugs or questions

indemnity --> a legal statement by the vendor that the client is not responsible for long term liability for patents or legal challenges

assurance --> a legal statement that the vendor will take responsibility if the product is not what it appears to be, or is missing parts that are required to fit a purpose

establish a legal framework --> define the copyrights and governing law for rights, responsibilities and disputes between the vendor, their suppliers, the customer and their agents

Spot on. The kind of features that accountable execs care a lot about. The engineer’s conception of companies like IBM and SAP and Oracle is that they sell terrible clunky software, but a substantial part of the value comes in the CYA that the above brings. The users are rarely the real customer.

For a concrete example, have a look at SQLite. SQLite is Public Domain, but it's used virtually everywhere, from phones to airplanes (https://www.sqlite.org/famous.html).

Not all companies are going to trust that something is actually public domain. So, you can get a "Warranty of Title" for SQLite. See https://sqlite.org/copyright.html

And those companies might not be satisfied with "community support". So, you can get paid support for SQLite. See https://sqlite.org/prosupport.html

This was when I was at a FFRDC doing work for the DoD, the rules might be different elsewhere but I wouldn't be surprised if they were the same either.

As soon as you use something like SAP or Oracle the number of offically _supported_ distributions quickly decreases. As example SAP HANA: RHEL and SLES or for example Oracle Database: RHEL, OEL (based on RHEL AFAIK) and again SLES.

So it is not only a question if it would theoretically/technically fail on another platform.

I don’t imagine SAP certification would extend to a community-supported fork of RHEL even if it was a 1:1 clone.

Many businesses will use the Forks for their dev environment.

Which is silly because Red Hat will literally give you free RHEL for non-prod if you pay for RHEL in prod.

https://developers.redhat.com/articles/2022/05/10/access-rhe...

I think the replies to you missed the main point: standing on the shoulders of giants. RH has a LOT of resources and being a fork of it means you get all that person power for free.