AlmaLinux – Our Value Is Our Values
almalinux.org
almalinux.org
Alma had previously stated that Oracle would be an upstream source.
"In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released."
https://almalinux.org/blog/impact-of-rhel-changes/
Rocky has said that they have found "a path forward," but have not divulged it.
https://www.theregister.com/2023/06/28/rocky_linux_rhel_ripp...
"Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered... Another method... 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."
I mean, maybe, but does it matter? You only need one person with access to the code to distribute it to everyone else, and the identity of that one person doesn't have to be public, so I really don't see how Red Hat could ever hope to stop it.
> That confusion manifested as accusations about us going closed-source and about alleged GPL violations. There is CentOS Stream the binary deliverable, and CentOS Stream the source repository. The CentOS Stream gitlab source is where we build RHEL releases, in the open for all to see. To call RHEL “closed source” is categorically untrue and inaccurate. CentOS Stream moves faster than RHEL, so it might not be on HEAD, but the code is there. If you can’t find it, it’s a bug – please let us know.
[1]: https://www.redhat.com/en/blog/red-hats-commitment-open-sour...
He goes on [2]:
> Anyone is allowed to create an account, get GPL'ed code and redistribute that code as much as they want according to the license. But they don't actually want the code because as I've said over and over, its not about the code (Free as in freedom). The code is out there (as proven by the fact that none of these rebuilders stopped nor will they stop)
[2]: https://teddit.net/r/linux/comments/14l2t86/im_done_with_red...
PS: How many people do you see linking to the actual Red Hat posts? I don't see many, which is why I think many comments on these threads are not made with honest intentions. The misinformation is rampant.
> 3) So what happened?
>
> - CentOS Engineers will not be producing that git
> repo of exploded SRPMs anymore because there is
> no need for them in CentOS project.
>
> - Red Hat recommends to take RHEL sources from
> CentOS Stream repositories because that is the
> actual source from which RHEL packages are built
> by RHEL Engineers.
>
> Can you still get access to SRPMs and create
> exploded sources repo - Yes. But there is no
> practical reason for Red Hat or for CentOS
> Project to maintain such a service.
>
> There is no change in Fedora or with anything
> related to Fedora.
>
> --
> Aleksandra Fedorova,
> member of Fedora Council
> RHEL/CentOS Strem CI Engineer
IBM can go after then in court if they want but they know that Oracle has pockets just as deep as IBM to fight them off..
I bet they will reach an agreement before this ever see a court room..
Giant corps move slowly, and companies like Oracle will require official communication only, which moves even slower. I think it's too early to read anything into it.
They have a company behind them, they have values, so why ride Red Hats coattails? Start your own distro.
They could even try and make it somewhat compatible with RHEL, in the sense that famous proprietary software like EMC and Dell stuff could run on it. A lot of times it's just a matter of having the right RPMs, environments and strings in all the right places to get them to run.
https://blog.cloudlinux.com/cloudlinux-os-8-and-9-in-post-re...
> Anyone is allowed to create an account, get GPL'ed code and redistribute that code as much as they want according to the license. But they don't actually want the code because as I've said over and over, its not about the code (Free as in freedom). The code is out there (as proven by the fact that none of these rebuilders stopped nor will they stop)
[1]: https://teddit.net/r/linux/comments/14l2t86/im_done_with_red...
It's clear that all the misinformation about RHEL, misinterpretations of the GPL, et al. are not actually about those issues. There is a concerted effort to attack Red Hat.
Become familiar with the "Twenty-Five Rules of Disinformation" [2] and you will see them everywhere.
[2]: https://web.archive.org/web/20221215015113/https://pastebin....
Red Hat is the one who put it behind a wall to begin with. You reap what you sow.
When you buy RHEL, you even get the entire source code on a DVD for the exact binary distribution that you download.
Really weird for you to be grandstanding about how misinformation is bad, while spreading it yourself.
[1]: https://gitlab.com/redhat/centos-stream
Additional docs: https://docs.centos.org/en-US/stream-contrib/techinfo/builds...
> CentOS Stream will now be the sole repository for public RHEL-related source code releases.
RHEL is in there somewhere, even if a user has to pick specific commits for it.
Furthermore, for the totally-bundled source for the exact binary RHEL release (which Red Hat only is required by the GPL to give to their customers, whom they already gave a binary to):
> For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal.
[1]: https://www.redhat.com/en/blog/furthering-evolution-centos-s...
This is not true. There are Red Hat package versions that do not correspond to any commits in that repository. For example, if a package gets updated from 1.1.0 to 1.2.0 in CentOS Stream, then later a patch is released (lets say, 1.1.1, or 1.1.0-2) then that patch will never show up in this repository. In such a situation, the 1.2 version will probably get an equivalent patch eventually, but not the 1.1 version.
Others have pointed out that embargoed security patches are not pushed to CentOS Stream until the embargo ends, and often at the end of the embargo they still don't push it until several weeks later, due to RH developers forgetting to do so.
I'm not claiming. I am linking to relevant sources directly from Red Hat staff. That is an authoritative source.
> that everyone
No, not everyone, I never said that, and you misrepresenting what I said and distracting from the main issue.
But now that you've gotten to the point of having your own opinion and take: what is "the main issue" as you've mentioned here?
Which, of course, is untrue since Red Hat has stated several times, in the links I've posted above, that Red Hat are (a) STILL providing complete corresponding source code, which one will still receive when they are distributed a binary by Red Hat, and (b) FULLY complying with the terms of GPL and other FLOSS licenses.
These are the two issues that people are misrepresenting, by saying either that Red Hat is (a) locking-down or otherwise disallowing access to complete corresponding source for binary recipients, which is untrue, or (b) that Red Hat is not complying with the FLOSS licenses their software are used under, which is also not true.
The next issue that is raised, one that was mentioned by the Software Freedom Conservancy [1], is that Red Hat is somehow extorting their customers by either making them choose between exercising their GPL rights, or continuing to receive support.
[1]: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
Red Hat is free to terminate support with any of their customers--that is not a GPL issue. The transaction the GPL covers is: Red Hat gives (or sells) the user a binary, the user can request the complete corresponding source code (not need to be immediately provided with), and once requested then Red Hat must provide that code. That is the end of the transaction. The GPL does not cover any additional period, or force Red Hat to continue business with a particular user.
What exactly is the spirit of copyleft? I see this said a number of times, but it doesn't appear to be fully articulated.
Personally I consider GPL an _implementation_ of copyleft rather than copyleft itself.
> Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.
> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.
The problem is that, as a downstream customer of that software, RH threatens to terminate my business contract with them if I exercise my own freedom to redistribute that software. It's completely in bad faith.
> With free software, users don't have to pay the distribution fee in order to use the software. They can copy the program from a friend who has a copy, or with the help of a friend who has network access. Or several users can join together, split the price of one CD-ROM, then each in turn can install the software. A high CD-ROM price is not a major obstacle when the software is free.
And so all these arguments, once all the misinformation is expelled, eventually boil down to this "it's in bad faith" schtick. Well, what is the faith of Rocky Linux when they are purveying a bug-for-bug clone of RHEL, selling support contracts on top of that, and directly competing with Red Hat's business?
Trick question, because "faith" doesn't matter. It's all legal, and these are businesses. They are making business decisions. If one thinks that some corporation--any corporation--owes "faith" or loyalty to their customers, then I got a bridge to sell you.
You're free to hate Red Hat--no one is forcing anyone to _like_ them--but I hope you have some substance somewhere within, and can articulate why.
If you don't think it is well past time to start forcing ethical behaviour on corporations... I don't know what to say to you.
I notice a certain country is fast tracking them to have human rights, like civic voting, but nothing at all about joining in responsible stewardship for our world.
In short, I've heard of people being generally annoyed by the change, which may be fair. I haven't heard too many people seriously trying to make the claim that what Red Hat is doing is illegal.
I guess the there is money that can be extracted from customers for formal business agreements, because the companies that themselves have contractual relationships with their own customers, care about having paperwork intact; similarly with insurance or compliance contracts. At the same time, this is a squeeze play against at least two downstream distros, Alma and Rocky.
So the attack is not complete, nor all in one place. I am interested to hear if this is accurate, from others with more skin in the game.
RHEL isn’t a project. It’s a product. All the actual work is still happening + being released (albeit less conveniently & not as timely). If Red Hat comes up with a fantastic new feature in RHEL the source will still be released - but it’s up to others to reassemble it. That’s hardly a concerted attack on open source. It’s a jab at copycats.
So in the RedHat so-called "copycat" case, the immediate downstream fill an important role in getting to the fourth+ layer.. there are more informal, unexpected, temporary or otherwise oddball cases than anyone can imagine. So in a growing and evolving network, the full, paid product from the original brand name source is aided and abetted by these immediate downstream distros. Thats not the same as simply counterfeit on black markets. Neither is it low effort, since these two distros Alma and Rocky, show long-term commitment and good skill levels. Those are valuable growth themselves.
What this squeezeplay on the copycats does is remove growth at the edges for lots of people, and consolidate revenue in the center, at RedHat. This is common knowledge among MBAs, and they do it all the time.
Not really, RedHat started this. They're in the enshittening phase now. Management has run out of ideas for real growth, so they are instead squeezing the customer base.
Distros for a lot of corps are sticky. People just want their RPMs/scripts/etc to work, and not have to pay Red Hat.
Hopefully this changes more with time to a more best-man-wins system, as there are a lot of really good distros out there already.
They also spent hundreds of thousands of dollars shipping free install CDs to people all over the world and piggy-backing off of the Debian community's progress. All so they could (almost two decades later) put small dent into Red Hat's enterprise entrenchment.
You would need to offer a significantly better product than RHEL, if you hoped to unseat them.
That in turn begat the very hot breath of MSFT upon Ubuntu-Canonical, which shows in the boot signing keys for Ubuntu, the MSFT-private partition type in the disk installer, and the WSL. MSFT influences can be seen in the push for always-on snap with libc and unattended-upgrades phone home and the like.
That has absolutely nothing to do with enterprise entrenchment.
I wasn't aware of this. So it's looks like RH/IBM argument that they don't contribute back is bullsh*t.
tl;dr: there are some contributions, mostly not to RHEL but to the surrounding ecosystem (including RHEL's upstream), so it apparently doesn't count.
That 5 years is the longest gap so far.
Some genuine questions:
1. If Bob doesn't currently have a RedHat subscription, does he have a way to obtain RHEL source code, legally, continuously, without the help of a current subscriber, and for free?
2. If Bob has a RedHat subscription, and has access to RHEL source code through the customer portal, is he free to continuously re-publish the source code else where? (in other words, facing no legal threat, and won't be cut off the subscription)
3. RH's staff mentioned "GPL'ed code", so it sort of implies the possibility that some other code are not GPL'ed, and might be subject to less favorable terms regarding redistribution. So, are all the code authored by RH and re-distributed by Rocky/Alma licensed with GPL? Or in other words, are there code whose re-distributability changes with the new policy of RedHat?
This was all at least 5 years ago, maybe 10, so take with a grain of salt.
I'm sure if I really learned the system it would be fine, but I've got two decades of the Red Hat Way engrained in me. It would be hard to change.
This doesn't make any sense. I've been using OpenSUSE for a decade and there's no package that can be installed via Yast (the GUI) but not via zypper (the CLI).
>There were also something different about their RPMs, where even though it was RPM based you couldn't use centos/fedora RPMs.
Obviously. They're different distros with different package names and library paths. "RPM" is just a file format.
This is absolutely not obvious to a person coming from EL/Fedora (which is the context we are discussing here). Things that are "obvious" to an existing user are not necessarily obvious to new users.
Also I'm not sure what "new" or "existing" users have to do with it. I've never used RHEL so I'm technically a new RHEL user, but I don't have the misconception that distro packages are interchangeable.
I didn't know what the differences were. I learn by doing. Everybody has to install and try a distro for the first time at some point. Unless you are arguing that you were born with innate knowledge of Suse, then at some point you didn't know either.
> Also I'm not sure what "new" or "existing" users have to do with it. I've never used RHEL so I'm technically a new RHEL user, but I don't have the misconception that distro packages are interchangeable.
I would argue that you actually have the misconception, so this is ironically pretty good evidence that "new" or "existing" users does matter.
In the RHEL ecosystem, packages can often be installed on any other (non-Suse) RPM distro, as long as the dependencies are met. For example, Fedora packages can be put on RHEL or CentOS or Alma or Rocky or Amazon Linux or Oracle Linux or Scientific Linux etc. I have some packages built for EL9 that are installed on my Fedora machine right now. Putting on a different distro you run a risk of having broken dependencies, but things are largely the same.
The same is also true for Debian, Ubuntu, and many other .deb distros. This is far more common in the linux ecosystem than not. Suse seems to me to be the odd-one-out here.
No, it's absurd to assume that you can transplant distro packages, not that you can't. And I don't really care to argue with you about this. Your incorrect assumptions are your problem, not mine.
>I would argue that you actually have the misconception, so this is ironically pretty good evidence that "new" or "existing" users does matter.
Wrong. Once again I remind you that you're the one who made the incorrect assumption and got burned by it, so your attempt at deflecting is laughable.
>In the RHEL ecosystem, packages can often be installed on any other (non-Suse) RPM distro, as long as the dependencies are met.
"As long as the dependencies are met" is doing some pretty heavy lifting there, isn't it? And why do you think your attempt to install those RHEL RPMs on SUSE failed?
>For example, Fedora packages can be put on RHEL or CentOS or Alma or Rocky or Amazon Linux or Oracle Linux or Scientific Linux etc.
First of all, four of the distros in that list are intentionally the same distro (RHEL, Alma, Rocky, Oracle), so it is expected that their assumptions and dependencies line up to allow you to install packages built for one on the other.
Second of all, it is absolutely not true that packages from CentOS (assuming we're referring to Stream) and Fedora can always be installed on RHEL or vice versa. The whole point of them being upstream of RHEL is that they can have newer dependencies. Hypothetically Fedora can switch the libfoo package to v3 with a different soname while RHEL still has it as v2, so any package that depends on the v3 soname cannot be installed on a v2 OS or vice versa.
Also, unlike all those distros which are either upstream or downstream of RHEL, SLES is not. So once again I ask, what did you think the difference between RHEL and SLES was? It sounds like you just assumed that SLES is upstream or downstream of RHEL, and made not even a cursory documentation search, nor talked to the SLES reps apparently, to relieve yourself of that assumption.
>I have some packages built for EL9 that are installed on my Fedora machine right now. Putting on a different distro you run a risk of having broken dependencies, but things are largely the same.
"The packages work as long as you ignore all the things that make them not work."
>The same is also true for Debian, Ubuntu, and many other .deb distros. This is far more common in the linux ecosystem than not.
Debian and Ubuntu will have exactly the same problem as the Fedora and RHEL example. Actually worse, because Ubuntu isn't a strict downstream of Debian but a random snapshot of Debian while it's between releases. The packages in Ubuntu can end up not corresponding to any Debian stable nor unstable.
And again, the scenario of taking RPMs from RHEL and trying to put them onto SLES is equivalent to taking RPMs from RHEL and trying to put them onto Debian. If the latter sounds absurd to you, why did you think the former made sense?
>Suse seems to me to be the odd-one-out here.
No, you just have very bad ideas about how Linux works and are weirdly stubborn about correcting them.
This thread brought me back to when I was first messing with Linux distros, I used some insane program called something like 'alien' to try to install .deb packages into Fedore Core, with no idea how wrong minded that whole enterprise was
I'm not going to engage anymore because I'm starting to get irritated by that, and my goal of commenting on HN is to broaden horizons and satisfy curiosity, not to engage in unproductive Internet arguments.
If my criticisms of suse hit a sore point with you, then I apologize. My intent was not to criticize suse. I'm sure it's a fine distro. My intent was to share my experience of moving from RHEL to Suse, as others were discussing changing from RHEL to possibly Suse. If you do that, you will probably have to modify your RPM specs because they won't (or at least didn't back when I tried) work on Suse without changes. Since many RHEL users use it to run their own apps in production, and all their RPM writing experience is RHEL, it's relevant to consider.
This is something that is explicitly warned against by the Debian developers - https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...
I have little faith that RHEL will change, especially after that blog post from the vice-president calling AlmaLinux and Rocky Linux "freeloaders" and that they bring no value to RHEL. They are the reason RHEL is as big as it is today and they're actively fighting against what made them big.
Also, there is nothing wrong with making people pay for free software. That is explicitly in the philosophy of free software and the GNU Project.
> Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.
> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.
macOS has Macbooks. Windows has surface, Samsung.
Linux has ???
That's a new startup idea, right there.
Consumer hardware is hard to pull off, to start with. Then there are tons of components requiring closed-source drivers that don't play well with Linux; you can spend a lot of money to rewrite them, or you can build piles of weak hacks that will crash your OS every few hours. You need deep pockets to get OEMs to pay attention to your needs, rather than the needs of giant manufacturers hungry for their production lines. Managing prices on small runs is extremely hard, so your 1.0 is going to be prohibitively expensive, which means it won't sell, which means you won't have the money to fix all the problems
But since you are looking for consumer devices running Linux, I recommend you check out Android, which is running on nearly 3/4 of mobile devices globally.
Famously, the Raspberry Pi.