I am not a lawyer, nor a Red Hat employee, so:

Lawyers who have looked at this license and the GPL have consistently concluded that the GPL doesn't actually require Red Hat to *continue* a commercial relationship with a customer who chooses to redistribute the software, provided that they don't take any further action to stop them from doing so.

I think it's not an interesting question, though.

Even if you thought that discontinuing a customer's contract could be construed as retaliatory, and you wanted to make that case *in court*, you'd have to find someone who was a customer of Red Hats, and who distributed only GPL code, and whose contract was terminated. Otherwise, Red Hat could rest their entire case on section 1.4 of the subscriber agreement, which says that "This Agreement... is not intended to limit your rights to software code under the terms of an open source license," and that they had terminated the contract based on the redistribution of non-GPL software. About 2/3 of the software in RHEL is MIT, or BSD, or Apache licensed, and the RPM specs are all MIT licensed.

Honestly, I don't think Red Hat cares if anyone re-publishes their software. They publish it to the public, themselves, via the CentOS Stream git repos. They aren't trying to stop redistribution of the code.

I think what they're trying to stop is the use of their *trademarks*. Rebuild distributions very explicitly make the claim that their product is not only derived from Red Hat's, but is exactly identical. They are, in a literal sense, marketing it as a product *from* Red Hat which they are re-selling. That's trademark infringement. And if you are at all familiar with the FSF, you will know that they are actually quite firmly on the side of trademarks as a legitimate trade right. When a company establishes its reputation and goodwill in the market, it is their exclusive right to use that reputation and goodwill to sell their services. If someone else uses that company's name to sell their own services, that's an infringement. If you want to sell your product on the market, you need to do so without using Red Hat's name to make those sales. You need to make the case that *you* will support the product. If people pay for your product, it must be because they trust *you*, and not some upstream vendor, to support it.

I think the entire history of the free-as-in-speech vs free-as-in-beer clarification is proof that we wanted to ensure the right to improve software if you didn't like its limitations, not the right to give away software if you didn't like its price.

Jon didn't say anything about RHEL being "re-licensed." That bit of confusion came from either the person who submitted the article, or from the Slashdot editor.

The nature of recent changes is frequently overstated, as it is here. RHEL has not been "re-licensed."

At any given time, there are something like 15 actively maintained released of RHEL -- as many as 5 releases in the same major release. Red Hat has historically published the packages from just one of those 5 releases via a fragile process. (They'd take the src.rpm that results from a package build, unpack it in a git repo, remove the primary source, de-brand and commit the rest, and push the result to a public source -- basically git as a complicated FTP.)

Now that Stream is a thing, it serves the purpose of publishing RHEL source code. It's not de-branded like the old process, but it provides a means of publishing one branch of RHEL. And for the purposes of building a downstream distribution and collaboration, it's a *much* better process.

But, while Red Hat's process for publishing code has changed, the licensing and subscription terms haven't.

https://fosstodon.org/@bookwar...

No one is under an obligation to sell you services at a loss, friend.

This sense of entitlement seems to be coming up a lot lately. Where does it come from?

I see Red Hat employees make a statement generally similar fairly often, but they are talking about "helpdesk" style support, and right now I am talking about a much broader enterprise support relationship.

The first important clarification is that The CentOS Project is described as being "community-driven," but the CentOS Project is broader than merely CentOS Stream. The project includes the Special Interest Groups that extend CentOS Stream and build new variants or projects on top of Stream.

The second important clarification is that RHEL does not have "proprietary special sauce added". RHEL (the software) is nothing more than periodic snapshots of CentOS Stream that receive continued support in the form of fixes for critical bugs and security issues.

RHEL is better understood as a support program. I don't mean helpdesk style "support-me-when-something-breaks" support. Support isn't something that exists only during incidents, support is a relationship. It's periodic meetings with your account manager and engineers. It's discussing your roadmap and your pain points regularly, and getting direction from them. It's the opportunity to tell Red Hat what your needs and priorities are, and helping them make decisions about where to allocate their engineers time to address the real needs of their customers. It's setting the direction for the company that builds the system that sits underneath your technical operations. That kind of support is what makes RHEL a valuable offering.

Because there is no special sauce added after the fact, CentOS Stream has to conform to the policies for RHEL updates. It is the major-version stable branch for RHEL.

To understand that concept better, consider: https://medium.com/@gordon.mes...

It's important to note when discussing Steven Vaughan-Nichols writing that he works with Cathey Communications, which is a firm that provides PR services to CIQ, the company behind Rocky Linux.

https://twitter.com/GordonMess...

That's important because it tends to explain why, when he writes about Alma, he emphasizes that they've "moving away from 1:1 compatibility", but when he writes about CIQ developments that are forks of Red Hat products, they're a "Rocky-friendly" fork.

The way he frames the development of forks tends toward praise in CIQ's case, and FUD in Alma's case.

We used to refer to this sort of thing as AstroTurfing. It looks like grassroots support, but it's manufactured.

It also tends to explain why, in this article, Steven uncritically quotes people trolling in Red Hat's GitLab merge requests, extending more legitimacy to their toxic behavior than he does to the actual developers.

Sorry to hear that. I've never had a problem upgrading Fedora releases from one to the next, personally.

It can't. Flatpak is tightly coupled with user sessions. It only supports desktop applications.

For anything not desktop applications, you'd use containers.

I think it's fantastic that Amazon has chosen to base their cloud optimized OS on Fedora. As the foundation of one of the most successful Enterprise operating systems available today, Fedora seems like a natural choice for other LTS software distributions.

At the same time, Amazon Linux is an LTS with a two year release cadence and a five year life cycle. The biggest difference between that and CentOS Stream is the cadence (where Stream's cadence is 3 years.) I wonder if bringing in new major features slightly more frequently will prove to be worth the effort of maintaining an entire distribution, or if Amazon will eventually choose to shift to a schedule that allows them to base Amazon Linux on CentOS Stream instead... Especially since building a system on CentOS Stream would provide the added benefit of binary compatibility with RHEL.

You make it sound like he chose to relocate there. He didn't. He was heading to Latin America from Hong Kong when US authorities cancelled his passport, which stranded him in Russia. He has been unable to leave since, because he doesn't have a valid passport.

From a certain point of view, that's probably not possible at all. Based on source code provenance reviews, Red Hat is the largest organization contributing development to many of the components in the GNU/Linux stack, all the way from low-level stuff like the kernel, libc, and the compilers, up to user-facing stuff like GNOME. And that's pretty fundamentally why Red Hat is the corporate standard, because those customers want support from the people actually involved in the development of the features that they need, and with the experience needed to fix bugs up and down the stack.

The idea that you can have a distribution that doesn't involved Red Hat is an illusion.

No, and mostly because I think the idea of "testing" by human users to be antiquated. By far, most testing is automated, and it happens before release. The problem with interactive testing by humans is that it's really not a very high quality signal. Humans are bad at fully testing complex code paths, so lots of operations go untested if they're done by humans. And worse, humans are reluctant to do tests for the sake of testing. So if the purpose of a distribution is to test the software, you're going to find that not many people want to use it. Humans don't want to be lab rats, they want reliable products.

As far as I know, all (or a reasonable approximation thereof) of the individual components that Red Hat releases under the RHEL umbrella are released in Fedora first, but that's not "for testing". It's because Red Hat has a long history of releasing Free Software, and of acquiring non-Free Software in order to re-license it and continue its development as Free Software. The thing that Red Hat sells is support contracts for that software, and re-branding applications under RHEL is a superficial aspect of the process of selling support contracts.

It is not, officially, a beta or gamma. And as a Fedora maintainer, I think I'm pretty well informed.