> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.<p>> Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.<p>That's quite the workaround, the rocky team has proven it's willing to get hacky if needed.
It sounds like they have two different mechanisms they can pull from currently, which will get them to parity with RHEL releases.<p>Red Hat would need to shift a few knobs and probably offend quite a few people running UBI images at least (including a zillion folks in the OpenShift community who rely on them) to cut off this current approach to getting the sources.<p>I wonder if Red Hat is willing to play this game of whack a mole? And IMO, was it worth it?
The solution here is forking and accepting that IBM just doesn't want to share. The whole value of the Red Hat eco system is lots of people using the down stream variants. Actual direct licensees of Red Hat are not where most of the action is.<p>The value creation is actually distributed across the ecosystem. People encounter issues, report them, and fixes are distributed. If you break that cycle and get IBM out of the loop, the process just continues elsewhere. The vast majority of that ecosystem does not pay IBM a single dollar and probably never will.<p>IBM is a company that is in slow decline, so the remaining Red Hat employees are facing an extended period of that company just squeezing harder and harder until nothing remains. It's death by a thousand cuts. But the bottom line is that a lot of people doing the hard work of committing actual code on behalf of the ecosystem that are currently employed there will be facing endless rounds layoffs, reorganizations, restructurings, etc. If there isn't an employee exodus happening there already, that might soon start to happen. The only question is where those people will end up.<p>A well funded foundation maintaining the fork of the distribution formerly known as Red Hat could be a nice destination for such people. Between Amazon, Oracle, and the countless users of Rocky, Alma, Centos, Fedora, etc. there should be plenty of brain power, motivation, and money to make that happen. They need a stable foundation. They don't need IBM to be part of that.<p>Don't play IBM's game on their terms. Just cut them loose. They get to do whatever they want downstream, not upstream. And they get to contribute all their fixes under GPL. That's not optional. This foundation would be free to use these fixes as they need to. Comparability with IBM's downstream distribution should not be a goal for this foundation. And if IBM wants to pretend they can do it all by themselves, they are more than welcome to try.<p>My prediction is that if the big supporters of this ecosystem join forces and do this, IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat.
When I was at IBM and RedHat did the "CentOS"-move, IBM-execs was actually pretty pissed off. It was bad optics and RedHat did it on their own, while IBM got "the blame". This is probably more of the same stuff. They think they can get away with being asshats and people will just blame IBM.<p>We see you, RedHat. You are NOT on the right path.
I originally had a strong anti-RedHat response to this change. When I thought about it and heard RH's response their sharp change makes sense.<p>They sell RHEL. It's from what I gather their main source of income. Revenue from this funds things like SystemD, a lot of work in Gnome, many many things that RHEL customers and other users of Linux and desktop Linux benefit from. Of course many contributions to open source/GNU tools come from folks in no way affiliated or paid by RH and RH does use these packages but RH also provides a lot of value.<p>So it stands to reason, to me at least, that to allow anyone to reskin/respin/or basically just ship a RHEL clone without RH branding that is "100% bug/binary compatible with RHEL" just without the license cost is giving away something you work on for free. No rational business would allow this.<p>CentOS, Fedora are free. RHEL is not. Makes sense.
Are the RHEL SRPMS watermarked for individual Customers in any way? It seems like Redhat has no mechanism to stop a torrent of the SRPMS showing-up. Attribution would be exceedingly difficult. Since distribution of FLOSS-licensed source isn’t copyright infringement it’s not like they could DMCA it away.<p>Arguably the specfiles are able to be copyrighted. I wonder what the license is like for those.
I was poking around the Rocky Linux website, and wondering where to download the latest source code for Rocky 9.2? Let's say IBM decides not to burn up the ecosystem, will Oracle / Alma start using the source that Rocky exfiltrates?<p>Related question, as a Red Hat subscriber can I still distribute Red Hat ISO and source code? It seems like I should be able to distribute ISO images and source after obtaining them.. but not repackage it? I don't plan to impose any restrictions on the people I distribute to.
Free.<p>That word does not appear at all in TFA.<p>In the IBM/RH blog post it references[1] the word appears once, disparagingly, in the gratis sense.<p>I appreciate the beer / speech distinction can get tiring to explain repeatedly, but it feels like the move to distance themselves from the deeper implications & obligations of <i>free</i> is, shall we say, very carefully calculated.<p>[1] <a href="https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes" rel="nofollow noreferrer">https://www.redhat.com/en/blog/red-hats-commitment-open-sour...</a>
If RedHad don't like what Centos (of old) does, then why do they still insist on mooching off of GPL software? If they don't accept the terms of GPL, good news! They don't have to use it!<p>Surely such hard working and deserving guys could write their own software and sell it honestly without needing to debase themselves by stealing from filthy hippies.
There’s one thing I don’t understand. They keep saying GPL this, GPL that.<p>Meanwhile there has been this huge push to use permissive licenses for like two decades now, because GPL bad (you don’t have to go far, just look at any discussion around licensing here on HN).<p>There’s nothing in .spec files that says they have the same license as the software they cover. Fedora contributions are required to come with a MIT-like license.<p>So you have quite a small core of software under GPL — the kernel, glibc, coreutils, gcc, binutils, make… and not even the darling of security advisories, OpenSSL. Thanks to incessant corporate PR against GPL, the GPL-based software base is shrinking slowly but steadily. That Rust-based coreutils replacement? MIT.
Friendly reminder that not all open source licenses are as reassuring as the gpl is.<p>Keep that in mind next time you make an open source contribution (and maybe sign off copyright) to a repository that is not protected by the gpl license.
So long "Upstream First" principle<p><a href="https://github.com/RedHatOfficial/open-source-participation-guidelines">https://github.com/RedHatOfficial/open-source-participation-...</a>
> "Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs."<p>Oh no! How dare they make <i>us</i> do the work?<p>It feels tiring to hear these arguments that they must be provided with everything bundled neatly with no questions asked and no contributions to the actual upstreams.
> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.<p>They have phrased this very carefully but there is a caveat here.
UBI is using a small subset of RHEL packages.
They say "possible to obtain Red Hat sources" and that's true, but you cannot - afaik - obtain all RHEL sources this way.<p>This is not too important as they are using a different way to obtain the RHEL sources now.<p><a href="https://access.redhat.com/articles/4238681" rel="nofollow noreferrer">https://access.redhat.com/articles/4238681</a>
> Moreover, Red Hat’s Terms of Service (TOS) and End User License Agreements (EULA) impose conditions that attempt to hinder legitimate customers from exercising their rights as guaranteed by the GPL.<p>Does someone have more details on this?
It's sad to see a post like this get so much hate in the comments section. We all benefit greatly from an organization maintaining a stable Linux ecosystem and the idea that somehow redhat isn't entitled to give back to Linux as much as they have benefited from OSS goes to show just how much coolaid HN has been drinking as of late.<p>These corporate concerns are not some law of nature and it's up to us to support people when they are willing to fight for end consumers, something that modern redhat has all together abandoned
May I remind everyone that these weird steps that the open source community is doing are not the result of Redhat per se but are a result of IBM that wants his investment back.
On another topic, we can finally see the motivation behind those SRPMs.<p>The whole purpose of a SRPM is to take some upstream source code and repackage it into a different archive blob which has to be downloaded in its entirety and unpacked in order to determine whether any of the code is patched, or pure upstream.<p>If, instead of a SRPM, you have some small, declarative text file which gives upstream URLs, SHA256 digests and build config steps, then that tiny declarative text file is all that someone needs from you to clone that package in their own distro, exactly
The amount of material needed to repro your whole distro goes something like from gigabytes to megabytes.<p>I mean, think about it. There is such a little declarative piece there in the process: the RPM spec file. Now, normally we think about building binaries from sources. But under RPM, you "build" source packages too! It's an obfuscation step intended to make people dependent on your way of handling sources.
What exactly prevents Red Hat from adding one or more proprietary components, like a RHEL bootloader, or network manager and simply refusing to share the code for those components?<p>If Red Hat doesn't back down, I don't see anyway around Rocky, Oracle and Alma doing a fork.
Watch IBM and RH publish changes to these features Rocky Linux will use to obtain the source, and effectively remove the "open source" part of it and violate the GPL.
>Every user of Rocky Linux is valued and their contributions matter.<p>That's very wrong. It's not Linux, it's GNU/Linux. [0]<p>[0] <a href="https://www.gnu.org/gnu/linux-and-gnu.html" rel="nofollow noreferrer">https://www.gnu.org/gnu/linux-and-gnu.html</a>