> Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.
That's quite the workaround, the rocky team has proven it's willing to get hacky if needed.
Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here".
Sure, they can make it more difficult by making them static, but it seems doable.
The blog post is vague on this topic and I'm not sure if you can really get all sources that way. I have my doubts but I've never tried:
Red Hat would need to shift a few knobs and probably offend quite a few people running UBI images at least (including a zillion folks in the OpenShift community who rely on them) to cut off this current approach to getting the sources.
I wonder if Red Hat is willing to play this game of whack a mole? And IMO, was it worth it?
I suspect they're playing with unintended consequences now.
One of the nice "features" of buying CentOS, is that it meant CentOS was never going to compete - there was a clear line between community and professional, and CentOS were never going to sell you professional services.
Pushing everyone to non-RH builds has removed that line, and there's a strong chance that non-RH builds selling professional services, is going to have a higher opportunity-cost than publishing CentOS did.
And even now, technically RESF is the one producing the distro and it's also not selling professional services. Who produces the distro has no effect on who sells the services.
Could you clarify what you mean by opportunity cost here? Who faces this cost and why?
1) having something to show their customers who has the actual expertise
2) making it clear that the Red Hat of today is significantly more open than the Red Hat of 2014 when neither CentOS Stream nor UBI existed and CentOS releases were months late despite the SRPMs being on ftp.redhat.com
3) making it obvious that they are respecting the GPL, and that no one gives a flying f**k about "free as in freedom" because all the uprising was always about either the free beer or the clicks/likes.
Indeed - Red Hat is making it obvious that IBM (like most large companies) views open source as free beer - or rather free labor.
It's great when they get other people's labor for free, as long as they don't have to give away any of their own.
I feel like returning to that apparent Schelling Point could quite easily be an improvement over the Red Queen's Race that I worry is developing here.
Honestly this from this post Rocky conflicts with the "RHEL is closed source/proprietary/paywalled" narrative that people are trying to push. If RHEL was truly any of those things Rocky wouldn't have been able to continue on, but they were able to quickly find a solution, though to me it seems a bit hacky. If Rocky is pulling packages from the supposedly untested, beta of RHEL CentOS Stream, and UBI and some EC2 instance, why would I use that over something that was build cohesively in one place like Stream?
[1] https://podcast.asknoahshow.com/343 about 20 min in
The value creation is actually distributed across the ecosystem. People encounter issues, report them, and fixes are distributed. If you break that cycle and get IBM out of the loop, the process just continues elsewhere. The vast majority of that ecosystem does not pay IBM a single dollar and probably never will.
IBM is a company that is in slow decline, so the remaining Red Hat employees are facing an extended period of that company just squeezing harder and harder until nothing remains. It's death by a thousand cuts. But the bottom line is that a lot of people doing the hard work of committing actual code on behalf of the ecosystem that are currently employed there will be facing endless rounds layoffs, reorganizations, restructurings, etc. If there isn't an employee exodus happening there already, that might soon start to happen. The only question is where those people will end up.
A well funded foundation maintaining the fork of the distribution formerly known as Red Hat could be a nice destination for such people. Between Amazon, Oracle, and the countless users of Rocky, Alma, Centos, Fedora, etc. there should be plenty of brain power, motivation, and money to make that happen. They need a stable foundation. They don't need IBM to be part of that.
Don't play IBM's game on their terms. Just cut them loose. They get to do whatever they want downstream, not upstream. And they get to contribute all their fixes under GPL. That's not optional. This foundation would be free to use these fixes as they need to. Comparability with IBM's downstream distribution should not be a goal for this foundation. And if IBM wants to pretend they can do it all by themselves, they are more than welcome to try.
My prediction is that if the big supporters of this ecosystem join forces and do this, IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat.
You could have said that if they switched to using CentOS Stream, and that would even have been my favorite outcome as a Red Hat employee.
However, Rocky Linux is neither a sibling nor a fork of RHEL. It's a debranded clone that by definition cannot even have a single bugfix that isn't in RHEL. For Oracle it's okay because it's peanut money in order to annoy Red Hat, so they can afford this; for Amazon or Facebook it's no good and that's why they forked upstream at the Fedora or CentOS Stream level.
As long as Rocky Linux stays a RHEL rebuild built by a third party like the CentOS of 2010 (except backed by corporate money rather than a guy in Nebraska), Red Hat is already putting millions into "the foundation". That's what they pay for the thousand people that develop Rocky Linux, ahem RHEL. Without them, there can be no Rocky Linux at all. So, as long as Rocky's money making side keeps undermining Red Hat's money making side, game theory predicts no other outcome than death for both RHEL and Rocky.
_EDIT_: if you downvote, I'd be very glad to learn where I'm wrong
Rocky is doing something no different than what RH is doing, and if this is problematic for RH's hopes of sucking in a few $B, that's more a problem with RH's business model than it is Rocky's. They have made $Bs selling support for free software, some large part of which they didn't author, and now they want to squeeze the entire ecosystem for more.
I have zero sympathy for RH and fully support Rocky's approach here. This is a problem of RH's own creation and trying to deflect the blame onto Rocky is absurd.
Ideally, Rocky's money making side could come to some sort of agreement to share revenue with RHEL's money making side, so that in turn RHEL's software making side doesn't mind sharing code with Rocky's (lack of) software making side.
I think the abundant corporate sponsoring of Rocky Linux proves that AWS, Google, Facebook etc. are happy to pay for access to RedHat's work. They just do not agree to the way that the licensing scales (both costs and hassle).
Not necessarily. They could easily have an optional repository for "bugfixes that aren't in RHEL". Those who want bug-for-bug compatibility with RHEL for some reason could simply not enable that repository.
clang dropped to third place after Apple and Google decided to refocus on other languages, it is yet to recover from it.
FOSS is great as mantra, it turns out many people can only spend so many hours, if putting food on the table matters as existencial question.
what do you mean by this?
We see you, RedHat. You are NOT on the right path.
They sell RHEL. It's from what I gather their main source of income. Revenue from this funds things like SystemD, a lot of work in Gnome, many many things that RHEL customers and other users of Linux and desktop Linux benefit from. Of course many contributions to open source/GNU tools come from folks in no way affiliated or paid by RH and RH does use these packages but RH also provides a lot of value.
So it stands to reason, to me at least, that to allow anyone to reskin/respin/or basically just ship a RHEL clone without RH branding that is "100% bug/binary compatible with RHEL" just without the license cost is giving away something you work on for free. No rational business would allow this.
CentOS, Fedora are free. RHEL is not. Makes sense.
They've just dialled the "greed" knob a bit higher, that's all.
Exactly what the triggering incident was this time they've been very careful not to officially say (which is likely a better option than the optics of getting into a finger pointing war with a smaller target), and I suspect we won't be able to fully judge their motivations unless/until the details leak and/or are inferred by people close enough to the situation to guess correctly.
Nowadays one could probably lean on staff to manage issues and arbitrage that go-it-alone mindset over paying the RH subscription. Now that loop-hole is closed.
Arguably the specfiles are able to be copyrighted. I wonder what the license is like for those.
Highly unlikely. File hashing can be used to easily check for this.
RH can't actually do what their trying to do, but that's less important than the fact that they want to. I can't see voluntarily having anything to do with them now. I see no value in any product or service they might offer that is worth knowingly working with someone who has exposed such a lack of integrity.
Related question, as a Red Hat subscriber can I still distribute Red Hat ISO and source code? It seems like I should be able to distribute ISO images and source after obtaining them.. but not repackage it? I don't plan to impose any restrictions on the people I distribute to.
The value proposition for RHEL is ostensibly support (and a "throat to choke", for whatever that's actually worth). Red Hat's gamble is that no "legitimate" Red Hat subscriber would risk their support entitlement (and the ability to contract with Red Hat for support in the future) by exercising their rights under the GPL.
It's a clever hack. It runs counter to ideals of Free software (and I find it personally repugnant) but it's clever.
That word does not appear at all in TFA.
In the IBM/RH blog post it references[1] the word appears once, disparagingly, in the gratis sense.
I appreciate the beer / speech distinction can get tiring to explain repeatedly, but it feels like the move to distance themselves from the deeper implications & obligations of free is, shall we say, very carefully calculated.
[1] https://www.redhat.com/en/blog/red-hats-commitment-open-sour...
Though I suspect we'll both end up less wrong by filing our theories under 'guesswork' and seeing what the actual state of play is six months from now.
Surely such hard working and deserving guys could write their own software and sell it honestly without needing to debase themselves by stealing from filthy hippies.
Meanwhile there has been this huge push to use permissive licenses for like two decades now, because GPL bad (you don’t have to go far, just look at any discussion around licensing here on HN).
There’s nothing in .spec files that says they have the same license as the software they cover. Fedora contributions are required to come with a MIT-like license.
So you have quite a small core of software under GPL — the kernel, glibc, coreutils, gcc, binutils, make… and not even the darling of security advisories, OpenSSL. Thanks to incessant corporate PR against GPL, the GPL-based software base is shrinking slowly but steadily. That Rust-based coreutils replacement? MIT.
I don't really know how this might or might not work. My gut says that since the .spec is meaningless without the sources, it's a Modification of the work and thus the spec, patches, and the resulting SRPM is definitely a Derived Work. But every time anything quasi-legal is being brought up here or anywhere else, it gets drowned in the arguments over what the meaning of the word "is" is, so I don't know how you can twist it, legally.
But then, the elephant in the room is that IBM may decide to give away only the GPLed SRPMs, and say a big fuck you to anything more permissive. People rallying against copyleft have made quite an impact, and the GPLed landscape is shrinking.
Keep that in mind next time you make an open source contribution (and maybe sign off copyright) to a repository that is not protected by the gpl license.
https://github.com/RedHatOfficial/open-source-participation-...
"Previously, we obtained the source code for Rocky Linux exclusively from the CentOS Git repository as they recommended. However, this repository no longer hosts all of the versions corresponding to RHEL. Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs."
Why would you need RHEL SRPMS if the upstream packages contained all the patches and why refer to them as "pristine upstream packages" in the first place?
Oh no! How dare they make us do the work?
It feels tiring to hear these arguments that they must be provided with everything bundled neatly with no questions asked and no contributions to the actual upstreams.
We already _do_ a lot of work. This is _more_ work.
This is the rebuilders' burden, and always has been. It should be their engineers doing that work, just as with other open-source project. If you want to rebuild TensorFlow or React, slap on your own branding, maybe sell support or consulting for it or enable others[1] to do so, do you think those teams will go out of their way to repackage stuff for your convenience? That's above and beyond common open-source practice. Expecting Red Hat to continue going above and beyond forever just seems awfully entitled.
[1] "Team members don't do X but sponsors do" deserves its own thread.
Complaining about change; and describing the steps that are being taken is far from saying they "must be provided with everything bundled neatly with no questions asked"
They have phrased this very carefully but there is a caveat here. UBI is using a small subset of RHEL packages. They say "possible to obtain Red Hat sources" and that's true, but you cannot - afaik - obtain all RHEL sources this way.
This is not too important as they are using a different way to obtain the RHEL sources now.
Could it decide to stop sharing source for non-copyleft packages next?
Does someone have more details on this?
tl;dr - GPLv2 requires no restriction on free/paid recipients of binaries to also freely redistribute source code. Red Hat EULA says your subscription will be canceled if you redistribute the source code. Is that a restriction?
A couple OSS laywers I spoke to said no. Common sense says it feels an awful lot like intimidation to effectively keep their product proprietary (what Fortune 500 company would like to have their Red Hat servers all go dead because some employee downloaded sources and uploaded them somewhere?)
> (what Fortune 500 company would like to have their Red Hat servers all go dead because some employee downloaded sources and uploaded them somewhere?)
What does this mean? Are you implying that RHEL has some sort of kill switch per customer embedded in it's source code that someone could exploit? I am not following this train of thought at all.
These corporate concerns are not some law of nature and it's up to us to support people when they are willing to fight for end consumers, something that modern redhat has all together abandoned
So it's not enough to employ more than 1000 people working on upstream/Fedora/CentOS Stream, have a strict upstream first policy for features that go into RHEL and their other products, donate to a bunch of foundations and sponsor conferences, maintain the main repository of firmware updates for Linux, be consistently in the top three contributors to Linux, open source pretty much all the closed source code that they get from acquisitions, distribute source also when not required by the license, give away two distributions for free, and possibly more things I don't remember?
Good to know, at least they tried.
If you know the history, if you know the license, then you know the philosophy that you're taking from. I don't think they're evil, but the people who did the early work getting this started did so with one level of expectation, and this is a different one. You get no love, Red Hat.
Not when you stepped in the open source and GPL arena, no. There are some pretty heavy expectations considering most of us grew up in a world where every distro was freely available everywhere, including the original Red Hat before they went the RHEL route. That's the entire reason CentOS came to be. And here we are again.
I say we... I use Arch Linux and gave up on this over a decade ago.
Further: https://forums.rockylinux.org/t/has-red-hat-just-killed-rock...
It's also what a lot of people expected would happen when IBM bought RedHat and the whole centos-stream debarcle happened and i suspect a lot of what were seeing is that IBM/RedHat(can we start calling them big purple now) is not seeing the growth to RHEL sales they were expecting from those changes/decisions, or might even seeing a decline in greenfield deployments of RHEL.
The whole purpose of a SRPM is to take some upstream source code and repackage it into a different archive blob which has to be downloaded in its entirety and unpacked in order to determine whether any of the code is patched, or pure upstream.
If, instead of a SRPM, you have some small, declarative text file which gives upstream URLs, SHA256 digests and build config steps, then that tiny declarative text file is all that someone needs from you to clone that package in their own distro, exactly The amount of material needed to repro your whole distro goes something like from gigabytes to megabytes.
I mean, think about it. There is such a little declarative piece there in the process: the RPM spec file. Now, normally we think about building binaries from sources. But under RPM, you "build" source packages too! It's an obfuscation step intended to make people dependent on your way of handling sources.
SRPMs can be used offline. The GPL requires the complete corresponding sources so you have to include the upstream sources anyway together with the binary RPMs; might as well bundle them in one file so you can share the metadata format between sources and binaries built from them.
What you mention ("upstream URLs, SHA256 hashes" plus the content of the spec file) is exactly what you find on git.centos.org.
Besides the main design of RPMs dates back to 1990. I suspect there was no conspiracy to hide SRPMs from Rocky Linux back then.
Or any connectivity at all! Back then, it was not unusual for Linux distributions (which came in CDs) to have both one or more "binaries" CDs and one or more "sources" CDs. One distribution which kept that tradition is Debian: you can download at https://cdimage.debian.org/debian-cd/current/source/iso-dvd/ a complete set of 19 DVDs containing the source code for all packages, and at https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd... metadata to create a complete set of 21 DVDs containing all the binary packages for the x86-64 architecture.
That plus a stack of patches is what FreeBSD ports and other ports-like systems use instead.
(I'm afraid "ports-like" is intentionally vague because accurately enumerating the members of that category would involve substantial effort and I'd probably still get it wrong)
Other open source competitors like SUSE and Canonical have much smaller revenues, so Red Hat could be seen as having a bit more influence over Linux's overall direction (they employ a ton of devs, they have a ton of resources). Case in point, the systemd controversy.
There's also a historic argument that one cannot trust FOSS in the hands of any corporation, but we start getting into more philosophical and nearly-religious debate at that point.
I'm not particularly fond of this latest move but I'm unconvinced they've fallen off the line yet.
Even with this decision in place I believe that Red Hat will still be by far a net positive to have around for open source overall.
They could change my mind about that, certainly, but they'd have to make a substantially more egregious move to do so.
If Red Hat doesn't back down, I don't see anyway around Rocky, Oracle and Alma doing a fork.
Why wouldn't they be able to do that? Sure, they can't patch the kernel or any of the existing stuff, but what would prevent them from writing a Grub replacement or a Red Hat shell? It has to be free of GPL code, but the operating system as a whole isn't what's under the GPL, it's the individual components, some of which aren't GPL, but BSD, MIT, ISC or some other licens.
It's not working out that great for the old giants, right? I mean Canonical and SuSE.
That's very wrong. It's not Linux, it's GNU/Linux. [0]
