Keeping Open Source Open
rockylinux.org
rockylinux.org
> 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".
Agreed - Rocky Linux probably has other options, but these seem like decent ones.
> Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here".
It does seem like Red Hat wants to subvert the GPL, but I'm not sure who would be suing them for doing so.
Once you get lawyers involved, you lose a lot of goodwill. At that point, who can tell RH apart from Oracle?
RH is still leading and sponsoring a lot of Linux development — that's the goodwill part. But maaaann, for quite a while RHEL has not been a very welcoming and inviting distro (unless you're the one checking the boxes on the corporate procurement form).
Customers may want to pay for training and consultancy, managed hosting, hardware, feature development, hand holding, insurance, productizing, etc. This is the business that RedHat is in, but so are MontaVista, AWS, vmware, Google, to name a few sponsors of Rocky. If everyone agrees to upstream a fair amount of their revenue, there should be plenty for RedHat to contribute into various projects.
Sure will be a bit of hassle to negotiate a fair price. But so far, these companies appear happy with the quote they pay Rocky, whereas the RedHat deal (per seat/per core/per instance/whatever) clearly is not. If RedHat had been more open to that kind of a deal with CentOS (8), there would probably never have been a Rocky Linux.
So yes, there is always the free loaders issue, but mostly people and businesses are open to sponsoring organizations that have a lot of goodwill.
I for one am perfectly happy paying some. Appreciating that RedHat is not a charity, while also doing great work for the community I bought the distro and merchandise for years. Even when they changed course to target enterprises and I became less their target audience I kept supporting them for being a major contributor.
I feel bad that other distros try to profit from the free beer (and its implied enterprise quality), but restricting access to what is essentially a commons in order to force other through your front door takes away all of the goodwill.
Now we're talking. :D
To me, the optimal outcome would have been a foundation overseeing the creation of a CentOS Stream derivative. Something that, in a unicorn-and-rainbows world, even Red Hat could join as mentioned elsewhere in the thread. Sharing the work and then competing on the services. However, based on this very blog post I have doubt that this is the idea of the money-making arm of the rebuilders.
And what avenues of negotiating a better outcome did they try before opting for the nuclear tactics?
Making millions on DB software only withhold RedHat the pocket change they absolutely deserve is absolutely pathetic. Even with the helpful support and hand holding of then co-workers, I found that Oracle's unbreakable linux is a close to useless rip off, littered with subtle gotchas, pitfalls and please-insert-yet-another-license-key-here.
Installing, tuning and maintaining an OS professionally on enterprise hardware to run enterprise software is the bread and butter of RedHat. I never understood why they insisted pushing their own mediocre engineers instead, and did not want to pony up the (relatively) modest cost of reselling the license.
> I have doubts something has changed at Oracle.
I guess so. It still mystifies me why they haven't gone out of business wearing the emperors cloths.
I've never heard of Oracle Linux needing a license key anywhere before. Can you provide a link to somewhere that talks more about that?
https://lwn.net/Articles/578768/ for the history (up until 9 years ago).
They decided their new course was 'compatible enough' with the GPL and this is one of those area where you start to feel the pain that's the difference between 'compatible enough' and actually compatible with the GPL and the ideas behind it.
Hopefully in your case - given what was being said about the options - the rebuilders will end up settling on the public cloud instance approach. If that happens, with a bit of luck you can go back to your UBI related advocacy once the rubble stops bouncing.
Hopefully.
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:
Do you need screen, udhcpd to do so? Nope, but you get httpd, etc. It is just a choice they made to make it easy to host your application in a RHEL container on top of OpenShift running on RHEL (fully supportable stack)
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.
(to be clear: I don't consider this a problem. But I do consider that for RH, this may be an unintended side-effect.)
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.
Rocky is absolutely a separate entity, both legally and in practice. In fact, the project and foundation board bylaws limit undue influence in a number of ways including maximum number of board seats per employer. We try to show our values both in our words and actions.
https://news.ycombinator.com/item?id=36417968 https://sam.gov/opp/2e0365ce1e3c4c179b50fb15573d68e4/view
Read this post from Carl who works on CentOS and Streams: https://old.reddit.com/r/redhat/comments/14jq5i7/red_hats_co...
Redhat are the parasites, not Centos.
If Redhat don't agree to the deal that the gpl makes, they are free not to use any gpl code.
Trying to paywall gpl software is simply theft, and it's an incredible expression of the art, when something is free, and yet you still manage to steal it.
No, it's not, and I've seen your comments elsewhere. I don't think you even know what the "free" in "free software" means.
You are COMPLETELY allowed to SELL free software. "Actually, we encourage people who redistribute free software to charge as much as they wish or can." See: https://www.gnu.org/philosophy/selling.en.html
Red Hat is still distributing full corresponding source code to anyone they distribute a binary to. That is what the GPL class of licenses require, and that is what they are doing.
You are free to get the software elsewhere. You don't have to get it from Red Hat. And if Red Hat wants to charge you for it, you can take it or leave it.
It's always been a fact that RH can't actually prevent a Centos-alike from reproducing the binaries from the same source, since RH are obligated to make the source available to anyone they hand a binary to. So you are right, they are still doing that. Congratulations on something that was never contested.
The problem is simply that they are trying, and HAVE at least issued statements asserting policies that they don't actually have the right to make. For instance they said that users can not legally redistribute the source they have access to, because it has RH trademarks in it. Well, fortunately that doesn't actually fly. The GPL isn't nullified by just including your cooyrighted or trademarked logo into the package. If anything, it just creates a derivative work and you just gave away all rights to your logo. Presumably they were'nt that stupid and carefully only do that to software they wholly wrote themselves, or things that are MIT and not GPL.
So just like RedHat and IBM?
That's one of the benefits of open source. It helps small guys to get started and make it big. Once they become big, they can contribute back.
Red Hat has benefited from previous contributors, but then added a ton of open source work of their own.
RH are open source contributors; Rocky Linux are mere users.
https://old.reddit.com/r/redhat/comments/14jq5i7/red_hats_co...
(Which is only what I, an ignoramus, would expect - if the project aims for "bug-for-bug compatibility", then it doesn't really gain much value from fixing bugs, while a fork would.)
If you think his evaluation of Alma/Rocky contributions is incorrect or incomplete, I'd be interested in hearing your POV as a Rocky engineer.
Looking at their GH profile https://github.com/rocky-linux seems to show some public repos with code in them?
https://old.reddit.com/r/redhat/comments/14jq5i7/red_hats_co...
Those Rocky Linux repos are either not code (website, wiki, etc.), and a few are tools for repackaging/rebranding an existing Linux distro's source code bug-for-bug - an activity which, by definition, does not and cannot offer anything more than the original code already did.
It seems that Rocky Linux have contributed code as open source, just not directly to RHEL.
not migrate2rocky, or almalinux-deploy. But if you look closely, they are mostly 'infrastructure' tooling to sync sources or deal with build nodes.
Alma at least addresses this: https://almalinux.org/blog/our-value-is-our-values/
Rocky?
Second, the sole direct beneficiary of this hypothesis, IBM, apparently thinks it isn't true, and from what little comments they have released appears to have come to this conclusion after quite a bit of analysis.
Third, from my position of ignorance, I think IBM is probably correct. Why? Because the free burger in your analogy isn't Alma/Rocky, it's Fedora. A user who runs Fedora on workstations or small production servers is very likely to consider RHEL when choosing an enterprise distribution for large deployments, because they are already familiar with the ecosystem but they want stronger stability guarantees than Fedora Server. But a user who is running Alma/Rocky has much less reason to move to RHEL: they gain nothing but the license hassle.
(I'm not a heavy user of RHish distros, mind, I only ever anticipate using Rocky if somebody else already decided to deploy a particular project on it so you probably shouldn't put significant energy into whether -I- notice, but there seems to be a perception issue here that's sufficiently widespread that you might get a decent ROI in terms of community growth from doing something about it and I'm pretty much always in favour of community growth whether I anticipate being one of the happy users of the project or not)
Contributing starts from day one https://old.reddit.com/r/redhat/comments/14jq5i7/red_hats_co...
You can't all of a sudden expect you to have gained respect and trust, just because you are part of something 'big'.
I'd appreciate a small community more when they reach out, to grow them, than for a big one to lend them a hand with the basics.
What more should they do?
Also note, Red Hat pays engineers for the extended support, the compliance https://access.redhat.com/articles/2918071, etc that customers expect from RH. Engineers contribute both upstream (first) and backport those changes to older releases.
They're paid to work on FOSS projects. Gnome isn't a RedHat project. Nor is the kernel. And they're IBM projects even less.
And most of those projects started without RedHat and RedHat stepped on them to become what it is first. Plus, there are thousands of essential projects they don't have anything to do with, still in the distro.
Because Red Hat wants to work with the community, it doesn't just start projects and slap a CLA on top of it.
https://redhatofficial.github.io/ is only a small part of what Red Hat has contributed to.
What is Redhat demanding for free? They spend more than anyone else on developers for all of the Linux stack.
Their whole business started and grew on FOSS stuff people wrote for free...
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.
"Communities we contribute to
Red Hat is a proud contributor to all aspects of the software stack, from the operating system and developer toolchain to middleware, desktop, and cloud. We financially support a number of open source organizations who help us create and maintain better open source software. We also contribute to a wide range of standardization efforts that help define future, interoperable technologies."
If RedHat were exaggerating, then those named communities would have called RedHat out by now.
As did some of the other beloved giants over 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
Just like users who're choose to run Debian Stable want Debian Stable, not the somewhat stabilised rebuild of a snapshot of Debian Testing that underlies Ubuntu.
(I'm not endorsing any specific set of preferences here and my own are sufficiently complicated they don't really fit in a comment about what sets of preferences -do- exist)
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.
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
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.
> Rocky Linux is a community enterprise Operating System designed to be 100% bug-for-bug compatible with Enterprise Linux. [1]
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.
Count the contributors to Rocky and RHEL. Then tell me how they can be "doing the same thing".
RH didn’t write all of linux, but they’re trying to put a price on it like they have.
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?
Apple nowadays mainly focus on Swift, and C++ support only needs to be good enough for Metal Shading Language (a C++14 dialect), IO and DriverKit needs, and compiling LLVM (currently requires ISO C++17).
Likewise, on Google's side, those that went on to work on Carbon are no longer contributing to clang.
All the other compiler vendors that have clang forks, seem more interested into LLVM improvements than ISO C++ compliance, thus now clang lags behind GCC and VC++ in ISO C++ capabilities.
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.
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.
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.
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.
I'd also like to ask, what damage do you see this change in behavior doing to free software ecosystem ?
Is literally the only thing that would make people happy is to give away RHEL for free for people to run their production servers on?
What changes have they made to RHEL that isn't available?
I believe that would be actuall evidence of gpl non compliance, not this dismisive current interpretation that people have.
I don't think that most people who commented have a subscription.
I think this is what I mean, yes.
The rhel trees are synced from the centos trees. If centos git trees couldnt build, rhel couldnt build. Afaics the only time this seems to be in conflict is for important and critical cve's , which are built on a rhel specific branch. After package release these branches are merged with centos, and the local rhel branches deleted and business continues as normal.
This is an attempt not to break embargo agreements with researchers who ask for it.
Despite every attempt by Red Hat employees to call out CentOS Stream as being "Red Hat sources", it is not. If they wish to participate in the open source ecosystem, they can't coerce customers (paid or not) into a particular (very proprietary) usage pattern with their software. No matter how many tens/hundreds/thousands of employees they hire to code for open source projects.
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.
If the rpm package is the binary they're distributing, than that's also the source they have to distribute.
The gpl isn't literally about the community, upstream, downstream. The gpl is simply - if you give me a binary, you have to also give me (or ensure I have access to) the source for that binary. The source to a similar binary doesn't cut it.
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?
They are going upstream because of a zero day patch that RedHat have, and is also upstreamed. Hence why they are going upstream, to get the upstreamed patch that CentOS has not merged yet. So your entire argument appears to be that RedHat are doing upstream first.
The additional hassle Rocky are having is that since Stream is ahead of RHEL divining whether the third step was taken and if so with what, if any, backporting tweaks required, is rather trickier so to recreate the end result of all such third steps to get an identical (bar debranding) set of SRPMs to the ones used by RHEL your best approach has become to source the various bits of information you need to do that from multiple places.
Also I -suspect- the 'pristine upstream packages' thing is referring to the fact that most package formats, rpm definitely included, prefer to have an untouched copy of the upstream sources plus a stack of patches in their source packages and combine them during package build for both clarity and debuggability reasons.
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.
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"
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.
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?)
Legally speaking, the contract vs copyright issue is the only ground Red Hat has to stand on here.
* I do not consider myself to be one of those people
> (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.
I have been in the "GPL arena" for almost 30 years (1996). When I started using free software I didn't even have Internet access at home and had to visit relatives one hour away to download it and send emails. I used SRPMs from a Red Hat Linux CD to study source code because it was not very handy to download it with a 33.6k modem.
"Distributing free software is an opportunity to raise funds for development". Paying salaries is a way to fund developers. Ergo, distributing free software is an opportunity to raise funds to pay the salaries of free software developers.
It's like when they bought CentOS - some people started making plans, fearing they would discontinue it. Others went "call me back when it happens". Then it happened.
Further: https://forums.rockylinux.org/t/has-red-hat-just-killed-rock...
It's just so stupid people are gonna have to jump silly hoops to get the source code.
[0] https://www.redhat.com/en/about/open-source-program-office/c...
lolwut?
I can guarantee you that video and my short chapter on AWX in my book have earned Red Hat many, many multiples of that through companies adopting an AAP subscription.
I also literally built the AWX Operator that Red Hat is still maintaining to this day: https://github.com/ansible/awx-operator/graphs/contributors
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]