Defying Red Hat, Rocky Linux and AlmaLinux Vow to Continue RHEL-Compatible Updates (arstechnica.com) 143
Reactions continue to Red Hat's announcement that they'd start limiting access to Red Hat Enterprise Linux sources, reports Ars Technica:
Rocky Linux, launched by CentOS co-founder Greg Kurtzer as a replacement RHEL-compatible distro, announced Thursday that it believes Red Hat's moves "violate the spirit and purpose of open source." Using a few different methods (Universal Base Image containers, pay-per-use public cloud instances), Rocky Linux intends to maintain what it considers legitimate access to RHEL code under the GNU General Public License (GPL) and make the code public as soon as it exists.
"These methods are possible because of the power of GPL," explains Rocky Linux's blog post. "No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights. Our legal advisors have reassured us that we have the right to obtain the source to any binaries we receive, ensuring that we can continue advancing Rocky Linux in line with our original intentions.... [O]ur unwavering dedication and commitment to open source and the Enterprise Linux community remain steadfast."
"In the unfortunate event that Red Hat decides to ramp up efforts to negatively impact the community, Rocky Linux will persist to continue serving the best interests of the entire open source community. As a reminder, we welcome everyone to contribute to our efforts. You can learn more about how you can join us and all of the various ways to contribute on our wiki."
Ars Technica notes that AlmaLinux is "also working to keep providing RHEL-compatible updates and downstream rebuilds." "The process is more labor intensive as we require gathering data and patches from several sources, comparing them, testing them, and then building them for release," wrote Jack Aboutboul, community manager for AlmaLinux, in a blog post. "But rest assured, updates will continue flowing just as they have been."
The Software Freedom Conservancy's Bradley M. Kuhn weighed in last week with a comprehensive overview of RHEL's business model and its tricky relationship with GPL compliance. Red Hat's business model "skirts" GPL violation but had only twice previously violated the GPL in newsworthy ways, Kuhn wrote. Withholding Complete Corresponding Source (CCS) from the open web doesn't violate the GPL itself, but by doing so, Red Hat makes it more difficult for anyone to verify the company's GPL compliance.
Kuhn expressed sadness that "this long road has led the FOSS community to such a disappointing place."
Red Hat argued that they "do not find value in a RHEL rebuild." Rocky Linux dismissed this view as "narrow-minded," and RHEL-derived AlmaLinux even responded with specific examples, also noting its contributions to the RHEL and CentOS communities. AlmaLinux's community manager wrote "When executed properly, downstream rebuilds provide tremendous value and are a tremendous asset to upstream projects."
And ITWire shares one more reaction: German open source vendor SUSE says it will not be making any changes to its policies on source code access, emphasising "that the freedom to access, modify, and distribute software should remain open to all".
"These methods are possible because of the power of GPL," explains Rocky Linux's blog post. "No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights. Our legal advisors have reassured us that we have the right to obtain the source to any binaries we receive, ensuring that we can continue advancing Rocky Linux in line with our original intentions.... [O]ur unwavering dedication and commitment to open source and the Enterprise Linux community remain steadfast."
"In the unfortunate event that Red Hat decides to ramp up efforts to negatively impact the community, Rocky Linux will persist to continue serving the best interests of the entire open source community. As a reminder, we welcome everyone to contribute to our efforts. You can learn more about how you can join us and all of the various ways to contribute on our wiki."
Ars Technica notes that AlmaLinux is "also working to keep providing RHEL-compatible updates and downstream rebuilds." "The process is more labor intensive as we require gathering data and patches from several sources, comparing them, testing them, and then building them for release," wrote Jack Aboutboul, community manager for AlmaLinux, in a blog post. "But rest assured, updates will continue flowing just as they have been."
The Software Freedom Conservancy's Bradley M. Kuhn weighed in last week with a comprehensive overview of RHEL's business model and its tricky relationship with GPL compliance. Red Hat's business model "skirts" GPL violation but had only twice previously violated the GPL in newsworthy ways, Kuhn wrote. Withholding Complete Corresponding Source (CCS) from the open web doesn't violate the GPL itself, but by doing so, Red Hat makes it more difficult for anyone to verify the company's GPL compliance.
Kuhn expressed sadness that "this long road has led the FOSS community to such a disappointing place."
Red Hat argued that they "do not find value in a RHEL rebuild." Rocky Linux dismissed this view as "narrow-minded," and RHEL-derived AlmaLinux even responded with specific examples, also noting its contributions to the RHEL and CentOS communities. AlmaLinux's community manager wrote "When executed properly, downstream rebuilds provide tremendous value and are a tremendous asset to upstream projects."
And ITWire shares one more reaction: German open source vendor SUSE says it will not be making any changes to its policies on source code access, emphasising "that the freedom to access, modify, and distribute software should remain open to all".
Redhat's moves are toxic (Score:5, Interesting)
And the Linux community should stop considering RHEL a legitimate distribution -- the curtailing of public access to the sources calls for an Industry-wide boycott of RHEL.
Re: Redhat's moves are toxic (Score:3)
Re: (Score:2)
Re: Redhat's moves are toxic (Score:5, Interesting)
Re: Redhat's moves are toxic (Score:4, Informative)
Re: Redhat's moves are toxic (Score:4, Informative)
>"Yes snaps are annoying and bloated"
And the concept of being forced to use ANY container for a software program in your distro, rather than also being supplied a native package, is even more annoying and bloated.
Re: (Score:3, Informative)
when Ubuntu forced snaps on us, we switched to Debian.
Ubuntu did not force snaps on you.
I find them odious and the idea of having to avoid them irritating and so I also switched (to Devuan) but the fact remains that you can in fact install Ubuntu without snap (somewhat of a PITA) or you can remove snap after install (trivial) and install the missing pieces from official PPAs.
What Ubuntu did was wave snap under your nose. The smell drove me away too, but I was not forced to use snap, nor were you.
Why are snaps bad? (Score:3)
Could you (or someone) give a simple explanation of what is bad about this? I searched online and found some old and seemingly out-of-date posts where people had complaints that just didn't seem to add up. Like, they complained about some really obscure technical edge cases that don't apply to most users (and certainly not to me) or they complained about really generic things like them taking up more memory or being slower to load, or having more bugs.
Well, I got loads of memory. We all do these days, i
Re: (Score:3)
To this day, Snap (and flatpak) have a security model that strives for some good stuff, however it makes interop between applications somewhat trickier. For example, if you want browser integration between chromium and keeppassxc, you can't use snap/flatpak. That is one example, but when I last tried to make a go of it with the strategy, several of these hiccups would crop up. I think trying to do screen sharing from a browser in a flatpak under wayland also screwed up, owing to overly segregated pipewire
Re: Why are snaps bad? (Score:2)
Re: (Score:2)
Re: (Score:2)
some really obscure technical edge cases that don't apply to most users (and certainly not to me) or they complained about really generic things like them taking up more memory or being slower to load, or having more bugs.
You must not be a programmer, or if you are, must not have ever had to validate input. Writing input validation is all about edge cases, because as a programmer you have to worry about all data coming your way. Just because an edge case doesn't apply to you, it doesn't mean it doesn't apply to anybody else. Oh, and they complained about it having more bugs? Oh no!
Well, I got loads of memory. We all do these days, it's cheap. My OS uses up a tiny sliver of my memory and I have plenty left over for everything I want to do (including running heavy games like Star Citizen), so why should I care if these things are more memory-heavy than the alternatives? There is plenty to spare!
Besides considering that some systems do not have loads of memory, it's precisely because of bad developers that we need gobs and gobs of memo
Re: (Score:2)
>"Ubuntu did not force snaps on you."
Actually, they kinda did...
It is true you don't HAVE to use snaps or the snap system in Ubuntu. But they don't supply key software packages in any other format. So you then have to rely on third-parties (outside the distro) for a proper native package.
So that is, in essence, forcing snaps on people.
Re: (Score:2)
Plus, they've doubled down on it saying that from 24.04, even the core OS will be packaged as snaps.
My own use case is a turnkey system on an air-gapped network. We manually maintain a set of APT repositories on that network. But unless I'm mistaken, you can't just stand up your own snap repository the same way. We probably will end up going to Debian.
Re: (Score:2)
We have to balance the fact that Debian is easier and better in a lot of ways, with the fact that one of the major software components in our product is only officially supported on RHEL and Ubuntu. Our need for support from that vendor has been small enough that we should be OK.
Re: Redhat's moves are toxic (Score:2)
claiming they dont force it then saying remove after it is installed by default. you're hilarious pal. pry your cranium out of your egress
Re: (Score:3)
Well, they did force snaps.
Default install, you have snaps. Ubuntu forbade Flatpak in spins, so further mandating snaps.
If you start ditching all the snap content and have to backfill from other sources, how much are you really running 'ubuntu' at that point? Note that ubuntu strives to push harder and harder on superseding apt with snap. There was a post at one point pontificating about the future when even the kernel would be managed by the 'snap' infrastructure instead of a .deb. Which points to another
Re: (Score:3)
Ubuntu is the windows of the Linux world.
Re: Redhat's moves are toxic (Score:4, Insightful)
Only in small/ bespoke installations.
RHEL type installations dominate when at scale.
And frankly, after using both since their inceptions and before, I'd much rather use RHEL-type any day.
Re: Redhat's moves are toxic (Score:4, Insightful)
Agreed, and this is why Red Hat's move leaves me discomfited. They already make good money. Will shutting out the clones make them any more money? I do not think so.
And listening to some very good and fair interviews with Matt McGraw and another employee defending the move didn't leave me feeling any better about the whole debacle.
And it's not the specifics of the action that bother me (shutting off the git repo). It's the attitude both employees expressed that bothered me. It's a bit hard to put into words. Obviously pushing debranded spec files and patches to github cost Red Hat real money and I don't mind that they've shut that down. Previous to RH acquiring the CentOS team and starting this git repository, CentOS had to download Red Hat SRPMS and extract all the brand stuff and create a new SRPM. Why not just go back to that system? It's no skin off RH's back. If Alma and Rocky want to do that work, let them, just like CentOS did originally. Obviously RH doing all the debranding work was a nice touch for a while, but obviously unsustainable from RH's pov. It really bothers me that RH wants to use seat agreements to stop this particular practice and lock people out of the SRPMs.
I was also very put off by McGraw's insistence that downstream rebuilders offer nothing of value to the community at large. That's clearly false or they wouldn't exist in the first place. There's quite obviously a segment of the market that RH is not serving, and probably does not want to serve. Clearly if someone is willing to pay Rocky for maintenance support, there''s a market there that RH could go after if they wanted to. Rocky *is* offering the community and the market value. To prevent Rocky or Alma from filling that space just looks bad, regardless of whether or not they are profiting on RH's hard work---never mind that RH is profiting off a lot of people's hard work, even if they do a ton of open source development work. This decision is just business I get it. But I've always thought of RH as a different sort of company that tolerated the things that open source allows.
Finally I'm left wondering what the whole point of CentOS stream really is. Before CentOS stream, Fedora was the community project and the ultimate feeder of RHEL. Fedora clearly benefited the entire community and continues to do so, while also benefiting RH. CentOS Stream, on the other hand, seeks to be a community also, but to what end? To just feed the black hole of RHEL? Why would I want to participate in the CentOS Stream community and contribute to development? I just don't get it. Sure anyone could build some kind of slow-moving EL-like distribution out of CentOS Stream, but I'm not sure there's a benefit to it. Seems like RH was hoping for some free development contributions to RHEL through Stream. I dunno.
Re: (Score:3)
>"Finally I'm left wondering what the whole point of CentOS stream really is"
To trick people into thinking they are using something stable, when, in fact, they are using a beta-test system?
>"Fedora was the community project and the ultimate feeder of RHEL."
Fedora is more like an alpha, and Stream is more like a beta, now. At least, that is the way I look at it.
Re: (Score:2)
Oh I agree. I just am asking what is the point of having a CentOS Stream "community?" Other than free beta testing for RH? If I am going to beta test and help make it better and more bug free, I want the fruits of that to be available to Alma and Rocky and anyone else, not go into some EULA-limited black hole.
Re: Redhat's moves are toxic (Score:4, Interesting)
The sentiment is easy enough to put to words, in fact, a singular word: entitlement
This is a huge problem with companies that are heavily software in general. Actually it's a problem with companies dealing extensively in any sort of intellectual property. They account any use of their work without them being paid as a market opportunity. They frequently assume that the use of their work is fixed, and pricing is just a matter of whatever they feel like. If you cut off the possibility of running a clone, then naturally they will pay full price for RH proper once the cheap option is off the table.
Now there are moderating voices that know better, but ultimately the behavior of the company as a whole is a compromise between those varying viewpoints.
This applies to overestimates of impact of piracy on music, movies, and software, to clones, even to a company's own pricing structure where they end up pissed at the customers daring to purchase the minimum tier and how those customers don't really deserve what they get.
Re: (Score:2)
Ubuntu tried it https://www.gnu.org/philosophy... [gnu.org]
They cannot "win" this (Score:5, Insightful)
>"Withholding Complete Corresponding Source (CCS) from the open web doesn't violate the GPL itself"
Withholding it from posting to the web does not. But withholding it from people you distribute binaries DOES. And they can NOT put restrictions on what those people who leak it or receive it do with it (like an RHEL customer just forwarding it to Alma/Rocky). That is clearly in the GPL.
RedHat can cancel the leakers' accounts and service, except they will not be able to determine who leaked it. If they try to contaminate the sources with fingerprinting to find out, that move might be considered a violation of the GPL. And regardless, all it takes is source release leaks from two different customers, compare the two sources to identify any watermark/fingerprint, and strip it out.
>"Red Hat argued that they "do not find value in a RHEL rebuild."
They KNOW that isn't true. What built their dominance in the enterprise space was CentOS. Without millions of people who used it bringing mindshare and talent and demand to their ecosystem, they would be mostly obscure. If they were successful in eliminating all RHEL clones (which they won't be), long-term prospects will dry up completely.
>"German open source vendor SUSE says it will not be making any changes to its policies on source code access, emphasizing "that the freedom to access, modify, and distribute software should remain open to all".
That is easy for them to say because they have nowhere near the marketshare of RHEL, And there are no foundation-based clones of THEIR enterprise Linux. But, yeah, it is nice to know.
Re: They cannot "win" this (Score:4, Interesting)
Re: (Score:3)
>"Is anyone shocked this happened after IBM bought them?"
Not after IBM bought them, but after they canceled CentOS.
>"We switched right after that happened."
There is nothing to switch to that does what RHEL/CentOS/Alma/Rocky does: rock solid/stable, 10 year updates, well-known, and wide third-party vendor hardware/software support. The closest is SuSE ES, but that has its own issues, is small in comparison, and is pretty unknown in the US.
I still think this hair-brained scheme will fail and have no i
Re: (Score:2)
I suppose I'm curious about SUSE ES issues. I've not been a huge fan of some of their technical projects, but I could easily look past that as their availability (via LEAP) is much more friendly and less dramatic.
Re: (Score:2)
True. But that is now. What about later?
That is one huge advantage of CentOS being killed and the gauntlet moving to the Foundations of Alma and Rocky. There are now non-profit, third-parties with a totally different mission and goal. And that keeps the commercial entity in check in several ways. Compliance with the GPL, free access for those who want it, and continued support of the ecosystem.
Re: (Score:2)
Alma did form as a non-profit org, Rocky *technically* isn't a non-profit org. However, CentOS was a non-profit org and see how well that worked?
Ultimately if you want a non-profit foundation as a fundamental of your distribution, you really probably should stick with Debian. Fundamentally with RHEL a very commercial mindset is calling the shots including trying to tank the non-profits.
Again, the *only* reason there's a non-profit at all is because RHEL made it difficult otherwise. If SUSE were popular *
Re: They cannot "win" this (Score:5, Interesting)
>"Ultimately if you want a non-profit foundation as a fundamental of your distribution, you really probably should stick with Debian"
Agreed. So we need to work to create an EL version of Debian, with updates for 10 years and something support companies can then hitch their wagons onto. And then hope that the large players like HP and Dell will get on board with official support of that. Ironically, a big nasty player like Oracle, or even Amazon, could make that happen in short order. If either demanded hardware support for the proposed "Debian EL", it would certainly happen.
Then RedHat would be TOTALLY screwed.
Re: (Score:3)
On the other hand, Debian tracks dependencies well enough to be able to upgrade to the next major version without blowing everything away and starting over, so it may not need to be 10 years.
Re: (Score:2)
>"On the other hand, Debian tracks dependencies well enough to be able to upgrade to the next major version without blowing everything away and starting over, so it may not need to be 10 years."
There is nothing magical about the "10 years" of updates. In a way, it is kinda arbitrary. But it has evolved into a workable standard amount of time. Understand that many businesses depend on stability, especially on appliance-like-systems, that "upgrading" is extremely time-consuming and complex (and thus, ex
Re: (Score:3)
If you can actually just roll from the last point release of the last stable version into the first release of the next (and you can with Debian or Ubuntu), it looks a hell of a lot more like an update than an "upgrade".
3rd party apps mysteriously breaking is not actually likely given that the system libraries have versioning built in to the dynamic linking.
But if you REALLY do need it, Ubuntu does offer paid extended support to increase the lifetime of an LTS version from 5 to 10 years.
Re: (Score:2)
"Understand that many businesses depend on stability, especially on appliance-like-systems, that "upgrading" is extremely time-consuming and complex (and thus, expensive). "
I have multiple systems now (which I p2v'd years ago) which have been cleanly upgraded from debian 2.0, 2.2 and debian 3.0 all the way up through debian 8. The 2.0 -> 8.0 VM is still running the same custom apache based app I wrote almost, shit... 10+ years ago, whatever it was. This common redhat/windows problem simply doesn't exist
Re: (Score:2)
3rd party apps mysteriously breaking is not actually likely given that the system libraries have versioning built in to the dynamic linking.
Ahh, the nice world of well maintained versioned C based system libraries.
Contrasted with almost every other ecosystem where neither backwards nor forwards compatibility is really a major concern...
Unfortunately, more and more effort is going towards that latter mindset and away from the former. Even in the land of C, you are at the mercy of the discipline of each project to actually avail themselves of the versioning well.
Re: (Score:2)
Re: They cannot "win" this (Score:4, Insightful)
>"Debian?"
1) Does not have 10 years of updates.
2) Not supported by major hardware vendors like HP and Dell
3) Has no certification program (people or software)
4) Is not a target for many large commercial software systems
There are valid reasons for the existence of so-called "enterprise linuxes", and, unfortunately, Debian doesn't currently meet them. Ubuntu is much closer, but not there either. Plus I wouldn't trust Canonical any more than IBM/RedHat.
Re: (Score:2)
Now correct me if I'm wrong, because I'm not a huge RHEL user, but does RHEL have 10 years of support?
I know the RHEL 8 release says it has 10 years of support, but a closer look reveals that 8.0 has about 4 years of support, ditto RHEL 8.1, RHEL 8.2, etc - mixed in with a few releases that have a brief window.
I know RH tries to backport some fixes, but for other software, it includes newer versions in the next minor release.
Which means that EOL fo
Re: (Score:2)
>"Now correct me if I'm wrong, because I'm not a huge RHEL user, but does RHEL have 10 years of support?"
Yes
>" I know the RHEL 8 release says it has 10 years of support, but a closer look reveals that 8.0 has about 4 years of support, ditto RHEL 8.1, RHEL 8.2, etc - mixed in with a few releases that have a brief window. I know RH tries to backport some fixes, but for other software, it includes newer versions in the next minor release. "
They are guaranteed to be compatible, so point updates are still
Re: (Score:2)
Seems they check all your boxes.
Re: They cannot "win" this (Score:3)
oh come on, a version upgrade of redhat is a trainwreck into a minefield, long solved by distros run by people with brains. shun and avoid the redhat for serious enterprise use
Re: (Score:2)
That's part of the market appeal to RedHat - you don't have to 'upgrade' it. Whatever release you use is a perpetual release, always supported and no further considerations are needed.
Re:They cannot "win" this (Score:4, Interesting)
Agree about the technical likelihood of fingering out any hypothetical fingerprinting scheme, however I don't think the GPL forbids fingerprinting any more than it mandates continued access to new versions of the software.
I also agree about them underestimating EL clones. Back in the day, 2003, Red Hat was 'the' de-facto distribution. Their "business will be forking to a restricted model, with the free becoming basically a beta testground" announcement as much as anything else set the groundwork for Ubuntu to be able to find a receptive market. RedHat pissed away a lot of mindshare that has impacted them to this day. It was barely salvaged by people getting comfy with CentOS situation (at the onset, there was uncertainty how true to the 'real' RHEL it would be, or that it was on secure enough ground, or how well it would keep up).
And there are no foundation-based clones of THEIR enterprise Linux
Keep in mind the only reason there are foundation-based clones of RHEL is because RHEL tries so hard *not* to have free access. SuSE LEAP means a third-party cloning is not really needed, so it doesn't happen. SuSE took their lumps back in the day by starting with a RHEL-like model without first building up mindshare, so they understand better than RHEL how important that free access is to mindshare. There are also no Ubuntu "clones" (there are rebuilds that apply a somewhat distinct vision, but no one obsessed with a 1:1 clone, because the original is fine.
Honestly, SUSE deserves a lot more attention. They have comparable lifecycle, but with the distinction that they offer 6 month overlap for 'service packs', whereas RHEL overlap is 0 seconds. They have longer lifecycles than Ubuntu, and frankly more technical backing than Ubuntu, based on my experience.
Re: (Score:2)
>"Agree about the technical likelihood of fingering out any hypothetical fingerprinting scheme, however I don't think the GPL forbids fingerprinting any more than it mandates continued access to new versions of the software."
I am no legal expert on GPL, that is for sure. But I thought that users of GPL are required to supply EXACT COPIES of the source that was used to compile the binaries being distributed. Corrupting them with watermarks/fingerprinting would violate that requirement. Since the spec f
Re: (Score:2)
Re: (Score:2)
Is that even manageable?
Wow, that would be the "nuclear option" if ever I saw one. It could not be simple, nor cheap, and would make support really difficult on RedHat.
Re: (Score:2)
IBM probably already has a few hundred patents on a secret canonical source, plus customer id to embed into source with steganography, and corresponding binary output. Bonus points for a method to do so in a way so as to allow the transform to happen without recompilation.
It would seem insane to bother to do that, but if there's any one company on the planet I'd see doing something so painful, it's IBM.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
all certifications would have to be done for each customer individually.
Not if the source differed in only steganography of whitespace and comments, producing the same binaries as output of the build. Same exact binary output, same exact thing being certified.
Re: (Score:2)
No. You need the sources the binary was produced from or the certification is invalid. The rules are really strict in these cases. The second problem is that you cannot do "steganography" on comments and whitespace beyond kindergarden level.
Re: (Score:2)
If your hypothetical src.rpm steganography solution is sufficiently advanced, you may be able to demonstrate identical binary output without a recompile, and the certification only cares about the binary output.
It becomes a game of whether your steganography strategy can be easily overcome without manual human attention or not. There's obviously different opinions on whether you can pull that off, but I personally think you *could* make it so painful as to require human attention on a per-package basis.
Or
Re: (Score:2)
In kindergarden, sure. In actual reality you certify the binary produced by a specific compiler version on a specific reference platform and from a specific source code. One of the reasons this is so expensive and hard to do. Anything you change in the sources could trigger, for example, a compiler bug that the original sources did not trigger and hence changing even one bit in the sources makes the whole certification invalid and you need to redo it. Yes, that is somewhat insane. But it is how it works for
Re: (Score:2)
I think the technical likelihood of getting a solution going is low, but if the original source is included, but with some extra fingerprint included in hard to find ways, the original source is still supplied.
Even if manual inspection of multiple differently fingerprinted src.rpms makes it obvious which part is intended to be the fingerprint (e.g. some %patch file disguised as a real patch that is just a fingerprint), the manual labor they might inflict on a clone could make the job just too much for the v
Re: (Score:2)
>"Even if manual inspection of multiple differently fingerprinted src.rpms makes it obvious which part is intended to be the fingerprint (e.g. some %patch file disguised as a real patch that is just a fingerprint), the manual labor they might inflict on a clone could make the job just too much for the volume of packages involved."
None of it has to be manual. That is easily automated. Two SRPM files into the utility, one de-identified SRPM comes out. It only has to be done once, from two inputs, for ea
Re: (Score:2)
You assume that an easy to identify "fingerprint" pattern can be discerned, that the injection of said fingerprint would be done in a highly predictable manner. It can be very hard to programmatically suss out a shifting fingerprinting strategy. It's sort of like generating a captcha, easy to generate, potentially very hard to work backwards from the result for software, even as a human may find it trivial.
Re: (Score:2)
Source files are all text. It is just a diff of two files, one by one. But I admit, a creative entity could make it very complex if they chose, like space or case changes other comments or changes in numerous files within each of the sources. But I still think that would violate the GPL, because they are not supplying the IDENTICAL source files used to create the binaries. So they would be limited to only additional files (which are not needed and can be discarded).
But I still can't mentally work my way
Re: (Score:2)
I see there are some but-hurt no-honor, no-integrity "moderators" active again. How pathetic. Go read the moderation guidelines.
Re: (Score:2)
Agree about the technical likelihood of fingering out any hypothetical fingerprinting scheme, however I don't think the GPL forbids fingerprinting any more than it mandates continued access to new versions of the software.
Actually it does practically, unless you build the binaries for each customer from the fingerprinted sources for that customer. Because you need to deliver the sources you build the binaries from, not some other ones. Sure, you _might_ get away with putting the variations in comments and maybe a claim as to this being non-functional parts could be upheld in court. Or not. But fingerprints in comments, whitespace, formatting, etc. are _very_ easy to strip out.
Re: (Score:3)
What built their dominance in the enterprise space was CentOS
I would say their dominance was built by RHL, the free distro that existed before RHEL and was basically renamed to Fedora.
Re: (Score:3)
True, but RHL wasn't really renamed to Fedora, wasn't so straightforward.
At the same time, they made clear there would be *zero* commercial support correlated with Fedora. With RHL, you had some comfort knowing that you had a common base with "business" level stuff. Hell, I paid for RHL back in the day.
As they wouldn't need to even try for professional support, it was going to lean hard into bleeding edge. Even between the 'major' releases, things could change dramatically in arbitrary ways. Applying nor
Re: (Score:2)
RedHat can cancel the leakers' accounts and service, except they will not be able to determine who leaked it.
A court might interpret adverse consequences for exercising the rights granted under the GPL to constitute additional restrictions, which the GPL forbids.
Re: (Score:2)
RedHat's lawyers take the stance that necessarily refers to additional restrictions on the source code that was accompanied by the license. They are not placing restrictions on *that source code*, they have a separate customer relationship that they are terminating which terminates access to future software.
I suspect the courts would side with "the license can't possibly apply to other people's software, or to software that does not yet even exist, or to force business relationships apart from having to del
Re: (Score:2)
They won't mind losing a few subscriber and no legitimate business with multiple deployments will risk having their account shut down.
Remember,
Re: (Score:2)
To be further clear, the only value RHEL/CentOS ever provided was NOT related to their software engineering (per se) - regardless of any community contributions of their engineering teams.
It was because the releases are extremely static and have a large degree of momentum. Had Debian had any degree of corporate release backing, it would have been easily preferable when those inroads were made 20-odd years ago.
Re: (Score:2)
I know/agree.
That is why what we need is a "Debian EL" with 10 year update cycle and some big players to force HP/Dell/etc to officially support it on their hardware/middleware. Wouldn't take long for it to be a target of commercial software porting and third-party support to spring up.
Re: (Score:2)
All we really need is kernel hardware support at this point, honestly. That, and a lawyer-approved "supported" stamp. Debian has very rarely needed anything like "support" in my experience, though naturally we'd want issues to continue to be fixed...
Most distros get their fixes from Ubuntu fire testing things first, anyway, these days...
Re: (Score:2)
They can't give you source with a license that says you can redistribute it and then contradict that with another license.
They do not do that. They let you redistribute the code; but if you do then your contract with RedHat becomes void so you stop getting updates & support. This assumes that RedHat find out that you have redistributed code.
Re: (Score:2)
>"..that would be illegal because they distributed sources they had a legal right to distribute. They can't give you source with a license that says you can redistribute it and then contradict that with another license. If the two licenses contradict one another then the conflicting parts of one of them are void, and they lack the legal right to ignore the license on the part they don't hold the copyright to. Redhat would be either violating or invalidating their own contract if they did that."
They can j
Didn't link to one key reaction... (Score:5, Interesting)
Red Hat's reaction (to the reaction):
https://www.redhat.com/en/blog... [redhat.com]
When this first happened, some argued it wasn't intended as anything other than a logistics change, that while inconvenient for EL clones, it just was incidental. That post make abundantly clear that they are specifically out to get rid of EL clones:
The generally accepted position that these free rebuilds are just funnels churning out RHEL experts and turning into sales just isn’t reality.
They run the risk of greatly underestimating network effects. They already suffer enough for a lot of free users having gone Ubuntu over the years (Ubuntu owes their success in large part due to the original "EL vs. Fedora Core" debacle back in the day). Their relevance is largely propped up by shops that found ability to continue without change from clones.
Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.
And there we have it, they do not find value (for themselves) and want people to stop it, and are trying to find ways to kill the clones, the end.
Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere
Funnily enough, only RHEL has this 'problem' and it's only a problem for RHEL itself. They whine despite being a massively profitable business concern all while the clones keep flowing. RHEL is obsessed with the concept that "free clone users" represent market that would otherwise be giving RH money and just how much *more* money they could be getting.
So ultimately, the clones have identified two channels of continuing, but I think they are at high risk:
-One is the RH container image. Already they have a huge challenge, they only have a partial selection available, the packages that RH deemed "relevant to containers" but held back on everything else. Notably, no kernel.
-Another is cloud instances. I'm not about to spend money to evaluate the situation here. From their description, I'm guessing RHEL decided that RHN subscription management as it stands today is too much friction for a cloud workflow to handle, and thus a cloud instance of RHEL gets a nice plain DNF access to binary and source. Challenge may include something like above, where they again limit package selection to the "cloud relevant subset" (which one might think should be everything, but they may make judgement calls about the relative likelihood of certain tasks in that and cut it off). Or perhaps they rework their cloud hosting strategy to have RHN reasonably accommodate a cloud hosting scenario, and start requiring subscriptions through the cloud infrastructure before even allowing an ssh in, or having a 'base' packages and requiring rhn registration before opening things up.
I still wonder long term about even the strategies working as-is. 1:1 would mean knowing the contents of the installation isos, which aren't relevant to any of the channels cited to acquire RH content. I could easily see, for example, anaconda just not being anywhere to be found in either channel.
Finally, if RHEL is hell-bent on this "act closed source like when it comes to the commercial phase", then a quick license audit of an EL clone shows that as much as half of the packages are not copyleft. So they could remove a huge chunk of src.rpms from the 'non-rhn' paths and make it impossible to clone without rhn content.
Re: (Score:3)
It's why the AWS Linux 2023 abandoned RHEL as the upstream source for their next release, and switched to Fedora.
Re: (Score:2)
I would presume that sort of move would be out of impatience for new features. I would have guessed CentOS stream as the upstream if obnoxious upstream source package availability were the only concern. If being just impossibly pissed off with all things RedHat, then I would have guessed Debian testing as the selected target.
Re: (Score:3)
>" That post make abundantly clear that they are specifically out to get rid of EL clones"
Oh, there is no question of that. It was the logical next step after discontinuing CentOS, if their intent wasn't just to not help the free EL space but to actually try to destroy it.
>"So ultimately, the clones have identified two channels of continuing [...]"
There is a third, which I outlined in my earlier posting. Just collect the sources from RHEL accounts of third-parties who leak them. GPL clearly allows
Re: (Score:2)
"as much as half of the packages are not copyleft. So they could remove a huge chunk of src.rpms from the 'non-rhn' paths and make it impossible to clone without rhn content."
That gives me hope that some upstream projects will start seeing the value of Free Software, and switch to GPL.
Re: (Score:2)
A licensing change in many cases is just impractical. Projects without copyright assignment would need to identify all copyright holders and get them all to agree.
A lot of the upstream projects don't really care about copyleft principles. A lot of it is "resume-ware" in a sense, they only care to make sure they get credit. In fact, a lot of corporate backed projects *insist* on a BSD-style license, to make it easier to commercialize for their own use.
Re: (Score:2)
Just collect the sources from RHEL accounts of third-parties who leak them. GPL clearly allows it, and RHEL can't stop it and will have no effective legal recourse against the leakers or the receivers.
The distributions shied away from that because:
1) That would require that someone explicitly goes against the user terms
2) If RH can, somehow, figure out who the "donors" are, they may cut off those off from rhn, making it an inherently risky supply chain
I suspect most of such packages are for things that are not needed
It's at least enough to break 1:1 clone, at which point it's enough drift so as to miss their goals. However, it may be the case that the only thing that *really* needs to be perfectly 1:1 is the kernel, owing to the number of third-party packages that are
Re: (Score:2)
>"But for example, libuuid is a fairly common utility library that is not copyleft. Perhaps more significantly, python is not copyleft."
Again, very good observation. Not sure how to address those cases. Again, through other means, they could provide equivalent updates for those cases (not as easily, for sure). BUT what happens when it is time to, say, develop Alma 10? You need a starting point, not just an update. Hmm.
Re: (Score:2)
I don't know enough of the details, but if a load of EL is not copyleft, and was left out of subsequent flows to the clones, then couldn't those clones just grab those elements from Fedora? Or else maybe grab them from source and package them up from scratch?
I see the support problem - that is, maintaining LTS whilst taking a faster-moving distro as the source for it - but I wonder if the Rocky folks really care all that much? So long as the main elements of the OS work and stay working together, then do we
Re: (Score:2)
I don't know enough of the details, but if a load of EL is not copyleft, and was left out of subsequent flows to the clones, then couldn't those clones just grab those elements from Fedora? Or else maybe grab them from source and package them up from scratch?
Yes, but then it's no longer a 1:1 clone, which is the whole goal. Otherwise, CentOS Stream 9 is close enough to RHEL9 by those standards. However, it may ultimately drive a determination that, in fact, the kernel needs to be 1:1, *maybe* a few other parts, but everything else is 'close enough' by most standards. In fact, I'd say in practice the transition to Fedora-like SIGs away from cloning RHEL add-ons when RHEL first took control of CentOS demonstrated the community was largely fine with a lot of co
Re: (Score:2)
...They whine despite being a massively profitable business concern...
Do you know for a fact that they're (still) "massively profitable"? I kind of doubt they'd have sold out to IBM if that were the case. They were certainly the first profitable linux-based success story, and we all cheered them for that. And, need I add, we all benefited from their ability to pay Linux developers. Since those heady early days, when clones were tolerated, the rug has been largely pulled out from under their business model. Amazon is running a massive cloud based, essentially, on a RedHa
Re: (Score:2)
Well, I can't say for certain *now*, but the last year with unambiguous results (pre-IBM), 2019, they had $433 million profit on $3.4 billion revenue. 2019 was well well into the cloud provider era, and RH financial results over time were just getting better and better, not declining, during the rise of the cloud providers:
https://www.statista.com/stati... [statista.com].
As to why sell to IBM? Well, IBM gave them 34 billion reasons. RHAT had about a $24 billion valuation and IBM offered $10 billion over market rate, so s
When IBM bought Red Hat it became FOSS-hostile. (Score:3)
This outcome was predictable. The community response should not be to make Red Had more accessible because that's giving aid and comfort to a now established enemy of FOSS.
The ethical response is not to make "IBM Hat" easier to obtain, but to use the power of the community to aggressively deter adoption and use of Red Hat Linux.
You cannot effectively protest a corporate decision by enabling more use of what is now a hostile OS. We will see if the Linux community gives Red Hat the SCO treatment it deserves or if convenience trumps principle.
Re: (Score:3)
>"The ethical response is not to make "IBM Hat" easier to obtain, but to use the power of the community to aggressively deter adoption and use of Red Hat Linux."
There is no current path for that. Unless the Debian community creates an EL version of their own distro, with 10-year updates and gets someone like Oracle or Amazon to bully HP/Dell/etc to also support it on their hardware. That, I could really get behind at this point. Other companies will spring up to support and target something like "Debi
Mistaken assumption that this will convert to sale (Score:4, Interesting)
RHEL has this myopically mistaken assumption that Centos and their ilk are "stealing sales" — this is 1800's mercantilism at its finest.
The reality is these are not sales they'd get. If they truly succeeded in their effort, I'd be shocked if it gained them even ONE new sale.
People using these distros will just go elsewhere if they are forced to do so.
I prefer RHEL style, but if forced, I'd suck it up and use ubuntu. It isn't as good IMHO, but it's "good enough".
Really all I want is the tooling, not binary compatibility. So maybe if we just got some of the more enterprise type things in RHEL into something else "rhel-like" then that's sufficient enough.
I don't want to spark a holy war, so I will resist giving examples.
"Red Hat's idiotic mess" (Score:4, Insightful)
"First demonize it, then do it yourself - Red Hat's idiotic mess", under that title Germany's arguably most renowned IT news publisher Heise released a commentary a few days ago that's as clearly worded as it is insightful. Translated with your translator of trust (mine would be deepl) it should be a fairly easy read, although it uses a good amount of hard-to-translate, sometimes untranslatable, figures of speech:
https://www.heise.de/meinung/K... [heise.de]
Specifically, the text finds very clear words on Red Hat's reaction to the goings-on on their blog.
Everyone here has utterly missed the point (Score:5, Interesting)
Re: Everyone here has utterly missed the point (Score:2)
Oracle and Red Hat could have a deal we don't know of. And shutting down 'freeloader' downstream distros would then be in the commercial interest of both of them.
Re:Everyone here has utterly missed the point (Score:4, Insightful)
It absolutely does make it ethical. This is not Oracle (no matter how much you despise them) exploiting a loophole. This is Oracle exploiting a fundamental feature of the licensing scheme which Red Hat selected when choosing to use an almost immeasurable quantity of others' work as a basis for its product. That Red Hat chose to enhance those others' work is praiseworthy, but it had no obligation to do so then, and cannot create an obligation for others to do so now.
So are thousands of other people who contributed to Linux and FOSS, rather than demand that their particular business model be awarded a profit. The GPL allows you to make a profit by providing service and support. The GPL does not allow you to make a profit by channeling your changes to the code into similar but not identical code on timelines of your own choosing.
If you distributed GPL-licensed code or derivatives of it, you're obligated to distribute the source code for that particular code to anyone who received it from you and makes the request. If you penalize people for exercising that right, even in an allegedly separate contract, you've still creating "further restrictions on the recipients' exercise of the rights granted [in the GPL v2]."
Re: (Score:2)
I don't think so. One I have personally heard RedHat middle-management bitch about 'freeloaders' when referring to CentOS. When making big public statements, sure they'll imply commercial reselling is the sore spot, as that isn't a very sympathetic "victim" of their policies.
Oracle Linux meanwhile, I almost never encounter in the real world. Either customers don't want to pay RHEL prices, so they go Alma/Rocky or they want support, in which case they recognize exactly what Oracle is doing and are rightfu
Re: (Score:2)
Excellent points, and very well put. thank you.
I had not realized that the free entitlements RH provides came with such caveats. Very discouraging indeed.
Re: (Score:2)
"If actual RHEL and base repositories were just easy to access, the clones wouldn't exist and public opinion wouldn't give a rat's ass about whether Oracle can pull of OEL or not."
Yes, this exactly.
Let's not forget why CentOS was created in the first place: because IBM started making it impossible to download RedHat ISOs (and prebuilt packages) for installation without an existing license.
They need to go back to a "RedHat is a linux distro" approach of things, and provide a free-tier, no support, no registr
Re: (Score:2)
I thought so too until I listened to an interview with an employee working on RHEL. He never once mentioned Oracle but several times specifically singled out Rocky Linux and the Rocky founder. He also singled out Alma Linux to a lesser extent. Seemed pretty clear to me that these two downstream clones are the primary targets. He seemed especially incensed that the company behind Rocky Linux would have the gall to sell support contracts, at best making money off of RH's hard work, or at worst stealing pr
How many of toil us keep the GPL alive? (Score:2, Insightful)
Seeing this story unfold, and all of the comments, I have to ask: how many of us actually contribute to the FLOSS world? (Note the "L", non-copyleft BSD/MIT licenses don't count)
I know I have these ideals, but have sold out to the proprietary side for bread & games.
Its quite a big company, and at there is now a lot of this whining going on. While we don't ship anything running on linux, all our internal infastructure is de-facto "for free" (same as natural resources are free: the only price is the cost
Playing with fire... (Score:4, Interesting)
It doesn't take much more than one copyright holder taking action for a violation, and Red Hat could lose all rights to that work under the GPL, forever. See GPLv2, section 4 and GPLv3, section 8.
Re: (Score:3)
If anyone is expecting RMS et. al. to be against RedHat on this topic regarding RHEL, then RMS et. al.
Re: (Score:2)
Has RMS, et al made open acknowledgements of this same practice by AdaCore? I can find no reference to Stallman ever making comment.
I"ve personally never heard of AdaCore previously.
Re: (Score:2)
RMS & Robert Dewar co-designed the software architecture of GNAT as tapping into GIMPLE & RTL of GCC over a period of decades with RMS overseeing the addition of a few GIMPLE features into GCC specifically to support only Ada features in GNAT that are absent in C and in C++. RMS gave FSF blessing of the licensing bifu
Re: (Score:2)
While I find their moves to be highly frustrating and dubious, I won't accuse RHEL of 'just rebuilding the communities stuff". They do honestly pay a large large chunk of open source developers working those upstream. Ansible Tower is 'just' AWX, but the couple of guys that actually do most of AWX? Red Hat employees. The handful of people doing Ceph? RedHat employees. Systemd was only the choice of RedHat because RedHat had Poeterring as an employee.
In fact, when Poeterring left, you see on github a few
Re: (Score:2)