TBF if I were to start a company today i would never choose a RHEL-based distro over a Debian-based one. As a matter of fact almost all startups are already on Ubuntu... To my perspective playing corporate games with the open source community have hurt the public image of "stability" of RHEL-based distros. (Obviously Rocky and Alma have no fault on this)
I don't know. All that I read from them over and over again is that they celebrate themselves and that they made the right decisions. What I really would like to read are more detailed writings about their challenges, especially legal concerns.
I had already read that when it was published, and I think it's very vague.
> Fortunately, there are alternative methods available to obtain source code, and we would like to highlight two examples
Okay, you list two options for obtaining the source of any RHEL binaries, but which one of these do you currently use? Or can't you say anything about it due to legal reasons?
> These methods are possible because of the power of GPL. No one can prevent redistribution of GPL software.
Not every RHEL binary is GPL-licensed, though. How do you plan to obtain the source for non-GPL-licensed binaries, where there might be no legal guarantee to obtain the source?
The vagueness is not intentional, it's vague only because at the time it was written we hadn't decided on a particular source. For Rocky Linux, RHEL cloud instances are currently the primary source.
Not every RHEL binary is GPL licensed, but all the packages we distribute have an open source license permitting such redistribution. There are a few left out, for example some Red Hat proprietary artwork, tools, etc.
I often get a bit of a feel of the Monty Python "Nudge Nudge Wink Wink" sketch from talking with folks who think we're doing something legally dubious.
> For Rocky Linux, RHEL cloud instances are currently the primary source.
Okay this answers the first question thanks.
> Not every RHEL binary is GPL licensed, but all the packages we distribute have an open source license permitting such redistribution.
Regarding the second question, fair enough, you are allowed to redistribute the source code. However, there is no legal obligation for Red Hat to distribute the source code to you for non-GPL binaries. So, what happens if you cannot obtain the source code of the Red Hat binaries (non-GPL) via your RHEL cloud instance workaround? Essentially, Rocky relies on an RHEL cloud instances workaround to fetch sources that could stop working (for non-GPL) at any time. Not such a bright and shiny future, if you ask me.
We aim to be as transparent as possible. The only information that we don't share publicly is the obvious stuff (PII, sensitive infrastructure information, etc). The information regarding source access / challenges / etc is available at https://rockylinux.org/news/keeping-open-source-open/.
The RHEL sources aren't freely available. They are only provided to RHEL customers. Red Hat strongly discourages said customers from leaking the sources to Rocky, so Rocky won't say anything that might reveal where they got the sources. [1]
The GPL only requires that you provide sources to those to whom you distribute binaries, not to the general public.
[1] Red Hat can probably figure it out anyway. For example, they could slightly alter the sources and/or assets provided to each customer in a way that doesn't affect the functionality, and see which version turns up in Rocky's repository. But the leaky customer might too big for Red Hat to punish. Government maybe.
Just want to note that there is a lot of non GPL software in RHEL. e.g. Apache licensed or MIT. For which they do not have an obligation to provide the sources.
I already pointed that out multiple times to Rocky Linux staff. They have no answer to this. The whole concept of Rocky is a big bet, that Red Hat won't pull the sources of non-GPL binaries e.g. in cloud instances and other public accessable places, where Rocky is currently fetching their sources from.
If you choose not to participate in this gamble, then this distro may not be suitable for you.
> The GPL only requires that you provide sources to those to whom you distribute binaries, not to the general public.
Interesting. I looked at Wikipedia GPL page and saw this: "The GNU General Public License (GNU GPL or simply GPL) is a series of widely used free software licenses or copyleft that guarantee end users the four freedoms to run, study, share, and modify the software.[7] "
So any user of GPL covered software can share it with anyone. Right? Can any RHEL user share sources to Rocky? And to public?
I think this is an interesting question in general because GPL has also this clause
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein
So I think it could be debatable if RHELs policy represents a restriction. Overall I feel this part of GPL has not been explored all that thoroughly and I feel it raises questions beyond this RHEL case. For example FSFs GPL FAQ states:
> For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA
I don't understand how that is not conflicting here; wouldn't your client be distributing the code to be modified to you, and that should be covered by GPL? And as such the NDA would represent additional restriction?
I suppose there could be a special case where the client would ask modifications for a publicly available sources and as such would not be distributing the code themselves, but I feel that can not be considered typical or general case.
Similar interesting case would be employees receiving copies of company internal forks of GPL code. Should employees have right to redistribute the code in accordance to GPL terms without threat of getting punished?
AFAIK mere exchange of code between employer and employee is not considered "distribution" for the purpose of the GPL. They are part of the same company, working on the same project. Similar relationships exist between client and contractor, client and lawyer, etc.
> The function of the contractor in such cases is nearly identical to that of an employee; however, because the contractor is not an employee, providing a copy of software to the contractor could be considered distribution. This is one of the thornier areas of GPLv2 interpretation, and it is discussed in more detail below
> A full discussion of the tenets of international copyright law bearing upon this issue is beyond the scope of this article, but it seems likely the question would have different answers outside the U.S [...] Therefore, the triggers for copyleft obligations, based on activity outside the U.S., may have a lower threshold than in the U.S.
They can, and they do, so the community eventually gets the sources. But Red Hat has every right to terminate their paid support contract with any customer who shares.
> Wouldn’t rebuilding from the RHEL sources be the easier approach?
Yes, if you can get the sources, of course. RH tells that they'll stop doing business with you if you share the source code you get from RHEL, which is Free and/or Open Source software.
> Also Alma doesn’t mirror Stream, they pull sources from several unencumbered places including stream.
Thanks for clarification. AFAIK they target versions of Stream and ABI of RHEL, but I learnt more today.
Happily surprised to see this hit the front page! If anyone is interested, I keep track of some statistics regarding Rocky Linux usage at https://rocky-stats.tiuxo.com/auto.html
Note that those statistics are only really useful for determining relative usage of Enterprise Linux distros as it's derived from EPEL logs. I haven't gotten around to attempting to derive statistics from the Rocky Linux logs because it's an intimidating amount of data.
(It's supposed to be automatic, but it seems the GitHub CI is having an issue with one of the dependencies for the past week. Guess now's a good time to fix it, and maybe make the page look more aesthetically pleasing...)
My default Linux for stuff. Just installed it as a VM on my Proxmox box for an SFTPgo instance. I think it is the best choice today for RPM based distro.
Projects have always done this, as Red Hat has always been rather litigious and it's unwise to give them any unnecessary ground for legal complaints. The common euphemism has been "Prominent North American Enterprise Linux Vendor" since the early days of CentOS.
Back in 2007, CentOS's self-description was "CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendor's redistribution policy and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork.) CentOS is free".
Rocky Linux has /etc/redhat-release as well. Reason being that some software checks that file for version / compatibility information, and we want to avoid breaking it. (They should be checking /etc/os-release, but it is what it is.)
There's actually a (very silly) reason for not removing /etc/redhat-release. There's many applications out there that rely on that file's existence, even if it's just a symlink to the proper file. Some apps use this as a way to figure out "what kind of system" it is (e.g. is it a red hat like system?) or as a way to figure out what the system is and version it is running. It's a bit annoying, as sometimes these apps either read it or they don't, so it's inconsistent.
It gets even more weird when you consider /etc/os-release has better information (in my opinion) then the {redhat,system}-release file would ever provide. There's also the random situations where if redhat-release doesn't exist, an app may look for system-release and do some sort of parsing to figure it out (again, ignoring os-release) and may get it wrong.
That's part of why you'll find Oracle Linux, CentOS Stream, Fedora Linux, and even us with /etc/redhat-release existing as a symlink to our own. I find it to be the odd bandaid to something that shouldn't be a problem, but sometimes life just isn't straightforward.
What should have they done? Thank them and IBM for setting the landscape ablaze, and dropping a couple of napalms on top by stopping white-box SRPM distributions?
Ah yes, the Rocky Linux attitude in action. Red hat has done and continues to do absolutely nothing deserving of thanks. Not for their work on fedora, not centos stream, not the myriad of projects that they maintain, absolutely nothing.
What they have done made great waves in scientific research communities. They had an unwritten agreement starting with ScientificLinux and CentOS took its place, which allowed tons of places from CERN to universities worldwide to use a standard base for software development.
Now this base is gone, and we're still trying to find our new base. This is highly damaging.
I'm not keeping sides (Rocky vs. Alma, etc.), but it was a rugpull for us, worldwide.
I have no hard feelings with RedHat or IBM at the end of the day, but being labeled as a freeloader just because we can handle our problems ourselves without a license is a bit insulting to be honest.
I know it's said that "freeloader" is a term used for companies abusing their license terms or using loopholes by buying 10 licenses and using the KB with 10K CentOS nodes, but it didn't help at the end.
So, RedHat/IBM handled this very badly and roughly. Their perception slipped from "One of the oldest distributions we respect as a community" to "Another tech company which wants money" very fast and very abruptly.
I think it's important to point out that the "freeloader" comment was not something that Red Hat or IBM said. It's something that one or two people said internally or on mailing, as part of a larger conversation where the context isn't that clean. Muy memory is hazy but I dont' think they actually used the word "freeloader" specifically, I think that was a paraphrase in a news article or something. I'll see if I can find a link.
Mike actually talked about the term in LinkedIn, trying to clarify it, accepting that it's an internal term in the process. Citing relevant part of his answer [0]:
Finally, I wanted to say something about the term "freeloaders" I've seen many use it. This is a mostly internal term we have at Red Hat, it looks like at some point it slipped out in the public. So what does it mean? A freeloader is when a large enterprise business has 20 RHEL licenses, 150,000 community rebuild systems, and sometimes hundreds of user accounts and hundreds of kbase searches per month. It's not the enthusiasts, it's not the hackers and coders, it's not the academics, and it's not the people that use rebuilders because they can't afford it. We really try not to use the term, but when we do, it's about the large companies that can afford to pay but don't.
I see this as damage control mostly, because RedHat and IBM has the power to negotiate these problems on every level they want with their customers. Heck, Docker called us for 280 Desktop installs in a month (which is another story not related to my department, but I digress).
At the end of the day, we became labeled as freeloaders, even if it was unintentional. Also the quote above acknowledges us (researchers, enthusiasts, coders, hackers (in folklore sense)), and does nothing to address about the rugpull we had gone through.
The only thing we got after that was discontinuation of SRPMS like a slap on the face.
We thank our upstream often, in person, in social media, etc.
We sponsor the Fedora Flock conference, the only opportunity to fiscally support Fedora, and will continue to do so. Same with the CentOS Connect conference. Those checks get written directly to Red Hat, by the way.
Given you work for Red Hat, we can even say we've paid you a little! :)
We do love collaborating with our upstreams--I myself recruit folks into Fedora and CentOS whenever I can, in addition to Rocky.
It's more than words and sponsorship--I really do mean it when I say I want to empower the Enterprise Linux community, and I'm thrilled that Rocky is at a point where we're able to do so.
Fedora, perhaps, but any goodwill they might have gotten from releasing Stream was burned when they killed CentOS. You don't get thanks for making something available when it's worse than the thing it replaced.
Depends on what you are, and what you do. If you don't have the expertise, and you run non-standard hardware (IB cards, GPU farms, or semi-complex storage to begin with), having a RH subscription is a plus IMHO.
If you believe that you can handle all of that yourself (and you can do if you're willing to do), go with one of the free alternatives.
