If I understand the post correctly, RH is planning to move away from distribution of source code to non-customers and only provide CentOS Stream sources to the community:
“ CentOS Stream will now be the sole repository for public RHEL-related source code releases.”
Not too much it seams: FAQ | AlmaLinux Wiki
Yeah, I was concerned as we have moved some 150 of our 400 CentOS servers to AlmaLinux.
Looks like the process remains the same as the upstream source will still be available as is required by GPL.
Not publicly - only to their customers
I hope that EL derivatives will still be able to access the source RPMs.
The RH news says: “Red Hat customers and partners can access the RHEL sources through the customer and partner portals, in accordance with their subscription agreement.”
It looks like they want to monetise the use of EL source RPMs.
But what does this mean for users of Alma and all the other clones?
To date, these rebuilds have been free, but that could change now if they don’t use CentOS Stream as the source!?
Right. Since they make the source available to customers I wonder if that satisfies the GPL’s requirement. Or is it the case that SRPMs are not part of the GPL since it’s a package format?
Here is an official response: AlmaLinux OS - Forever-Free Enterprise-Grade Operating System
So will alma cook up a hack to get the source regardless or are we going to fork? Or end the project?
If the project and development can continue I will leave my server on alma, otherwise would have to look at debian/ubuntu.
Oracle is silent on this… they are not affected? They probably have a deal to pay for the source?
We moved to Alma-8.x from CentOS7 and were having a long term plan to stay on Alma, given the fact that Alma was planning to remain Downstream to RHEL.
This RH announcement is a mighty blow to the industry.
We are expecting some more regular updates from Alma on this… the official response ( AlmaLinux OS - Forever-Free Enterprise-Grade Operating System is still very basic and does not provide a lot of answers still.
Would request to set a cadence of updates please.
I second that. Although it really looks like RH made sure not a lot of progress would be possible in this front, it is important to keep talking to the community.
We are on the verge of moving from CentOS 7 to Alma 8 and 9, and now our decision is kinda on standby, waiting to see what’s going to happen there.
My understanding that is to get RHEL binaries you need a subscription, which then gives access to sources, but only through the Red Hat portal which requires agreeing to the terms.
Red Hat does distribute the UBI containers free, and without a subscription so anyone who does ‘docker run -it --rm registry.access.redhat.com/ubi9/ubi /bin/bash’ is a customer of Red Hat and entitled to the sources of the UBI binaries? Or have I misunderstood.
The UBI images have dnf/yum so extra packages can be installed, again without having a Red Hat subscription. Is this a way around the problem of getting sources?
I don’t think the problem is getting the sources, but doing that in a way that it is legal to build them and redistribute. AFAIU the new scheme does not allows that.
As per - AlmaLinux OS - Forever-Free Enterprise-Grade Operating System, as it stands today, “the Red Hat 8 are not getting published on git.centos.org like they were supposed to be.” - i.e. Alma users are already missing on critical CVE fixes which are otherwise available on RHEL 8.
The above site states that “In the short term, we will be working with other members of the RHEL ecosystem to ensure that we continue to deliver security updates with the speed and stability that we have become known for” - It doesn’t tell how it will be done and the timeframe.
Just wrote an email to benny Vasquez [benny@almalinux.org] to get more updates.
The UBI sources are provided along with the binaries, e.g. you can download the source of gcc like this:
# dnf download --enablerepo=ubi-9-baseos-source --source gcc
However, UBI contains only a tiny subset of RHEL, e.g. no kernel package.
Yes. The interesting part here is: What constitutes “distribution”? If UBI comes with RHEL repo definitions and you dnf install packages which are not in UBI, did RH distribute them to you (in which case they need to provide the source under the GPL), and under what terms?
E.g. for rpmfusion repo definitions, RH lawyers seem to fear that shipping the repo definitions may already constitute (extended) distribution of contents, and that’s why they “don’t let us do it” in Fedora.
That point is mute if UBI images come with UI repo definitions only, of course.
Apologies in advance, lengthy post coming up, full of assumptions. Perhaps all of this has been discussed already; in that case, apologies (again).
After reading the news (and admittedly panicking a little) I immediately started to investigate how to get Debian up and running with SELinux, particularly for Podman, K3s, K8s. Turned out that the refpolicy wasn’t up to spec compared to the fedora-selinux + container-selinux packages.
Mentioning my panic in various places after reading various news sources, I was sent this link by Daniel J Walsh (SELinux and Containers (podman, buildah etc) engineer at Red Hat) which got me thinking…
If I understand the various Red Hatters commenting on the whole affair correctly (and I may very well be wrong and may have missed key issues), their stance is:
(0. They want to combat other outfits from profiting from their work and investment into the product. Which they worded in a way that dare I say was a tad hostile and one-dimensional.
The reason CentOS Stream is not suitable for production is not so much about code quality as it as about packaging and delivery. The claim is that anything in Stream has already passed all the testing and other stringent requirements, it is the rolling release element that makes it unsuitable for production.
Due to the delay in RHEL patches making it to downstream distributions, they argue that no downstream distribution is truly ‘bug-for-bug’ compatible with RHEL.
They take the view that downstream distributions give nothing back.
My proverbial 2 cents:
When looking at true community supported distributions (i.e. Almalinux, Rocky Linux) it is more complicated I reckon. When small startups and businesses who do not have thousands of dollars to spend on subscriptions use a community distro, that is fair – pay when you can, but not necessarily from day 1. When large companies run hundreds of servers and thousands of containers are using a community distribution, it’s not quite the same. Surely, there should be some way for them to contribute (in a measurable way) in that case, either financially or developmentally.
Having thoroughly ignored CentOS Stream when it was announced and switching to Almalinux when first possible, I was unaware of that. That does open up some perspective and opportunities, I would think.
Fair point, but not as relevant for small, obscure organisations using a community distribution at small scale.
A bit of a one-sided viewpoint, I believe. There must be plenty of users submitting bug reports as well as providing upstream assistance. Even though some outfits are seeking monetary gain (which is indeed unfortunate for RH), there is also the whole community ecosystem to consider. A large part of it now very unhappy and likely to jump ship, with a lot of potentially hazardous consequences for both RH and the FOSS community at large.
The ‘solution’ some Red Hatters seem to be pointing at is to change the nature of distributions based on RHEL. Rather than being a (delayed) downstream edition, they suggest syncing up with day 1 of a CentOS Stream release. (at which point it should be in sync with RHEL).
Teams could then test and package updates in a more production friendly way than the CentOS Stream default way. This would result in a mostly compatible RHEL derivative, albeit with half the life-cycle, which for many users would be ‘good enough’ (i.e. a container host for web hosting, LAN services and other basic things). They’d at least have a solid foundation to build an infrastructure with. This would, of course, increase the workload for teams such as Almalinux and Rocky Linux considerably.
They say that the updates and patches in Stream have already gone through rigorous testing and thus are of high quality, the problem not being one of content, but of packaging and delivery. If I understand all that correctly, it would be akin to Ubuntu LTS being a derivative of Debian Testing. If adopted, this would also open up opportunities for potential feature updates being pushed from the derivative to either Stream or Fedora.
While that isn’t what many people and organisations would want to consider (larger ones in particular), it would be a long-term path forward for smaller outfits.
Would it not be worth discussing if it were feasible to make an Almalinux CE next to regular Almalinux? Provided enough volunteers and funding could be obtained, of course. Supporting AlmaLinux 8 and 9 for as long as feasible, while offering an AlmaLinux CE on the side for future migration, testing and early adoption for smaller and more nimble outfits, I mean.
Possibly of interest, from the Rocky Linux blog:
Official update: AlmaLinux OS - Forever-Free Enterprise-Grade Operating System
This whole situation feels to me like some suit at IBM losing his mind over imagined lost revenue with no idea at all of how the FOSS community functions. Welcome to the world of IBM 
I have read some reactions for Red Hat’s article in some days.
According to SFC’s analysis, RHEL’s subscription contract and enterprise agreement restrict rights and exercise of it granted by GNU GPL.
“Unfortunately the way we understand it today, Red Hat’s user interface
agreements indicate that re-publishing sources acquired through the
customer portal would be a violation of those agreements.”
Are almalinux communities concerns same issues to shown by SFC?