Keeping Open Source Open
rockylinux.org> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.
> 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.
The public cloud route is pretty elegant. Red Hat is restricting source code to subscribers only, so Rocky contributors will just subscribe for an hour at a time when they need to download source code. There’s no way for Red Hat to stop this without terminating all public cloud licensing everywhere.
I'm not a lawyer, but that's definitely not their only recourse here.
Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here".
> I'm not a lawyer, but that's definitely not their only recourse 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.
>Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here".
Once you get lawyers involved, you lose a lot of goodwill. At that point, who can tell RH apart from Oracle?
Indeed, who can?
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).
What could be done to improve it (while keeping in mind that Red Hat needs $$$ to continue development)?
Okay, let's start with the software itself being free. That is, no-one pays for distribution or use, creation is sponsored voluntarily (contributions, donations) but this is not sustainable.
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.
So two free distros are not enough, got it.
Call me a hippie, but wouldn't it be great if Rocky got its way with free as in libre, while RedHat got its way with NOT free as in beer?
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.
> Call me a hippie, but wouldn't it be great if Rocky got its way with free as in libre, while RedHat got its way with NOT free as in beer?
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.
They seem to have been able to fund development before. So what changed? Just the new corporate overlord that wants a return on their investment?
Quoting Reddit: "The problem of rebuilders has been around forever. Things heated up a couple of months ago when we detected what we think was a continued bad-faith action from one of the rebuilders, not on the code/engineering side but on the commercial/money making side of their house. That's as far as I'll go publicly. After that it was just a matter of discussion on what to do about it, so we landed on the announcements I made last week."
Post-IBM RH always falls back on this: we took a free operating system and made billions from selling it to others, and now we're extra-mad that somebody else is doing the same.
Why the fixation with "post-IBM"? Ever heard of PNAELV?
https://lwn.net/Articles/578768/ for the history (up until 9 years ago).
Curious to learn who the bad faith actor was. Oracle? Rocky Linux? Alma? VMware? All of the above?
And what avenues of negotiating a better outcome did they try before opting for the nuclear tactics?
I don't have a view in which rebuild they saw bad-faith action from; but I have doubts something has changed at Oracle.
Disclaimer: I'm an ex-oracle employee.
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.
> Oracle's unbreakable linux is a close to useless rip off, littered with subtle gotchas, pitfalls and please-insert-yet-another-license-key-here.
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?
Their business model allowed for greater ease to actually download and run unregistered/unlicensed copies, but higher costs with per-core licensing and clauses which required (i.e.) the per-core licensed OS plus the per-core licensed database if you wanted to use the latter. It was both easier to run for free and way more expensive to run in legal compliance.
That quote is someone complaining that others are making money of "their" work, not that Red Had isn't making enough money to fund development.
Honestly the UBI images seem like the best option. They publish those, they have to publish the source for them.
Sure, they can make it more difficult by making them static, but it seems doable.
The UBI images only contain a small subset of all RHEL packages.
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:
They are images tailored towards runtime use. They do not come with server components. For example, you can't get/download udhcpd in a UBI image.
This is a very weird situaiton. As far as I know the whole Red Hat distribution is still open source. Now they put themselves in a position to refrain from publishing their open source changes. If those changes do not flow up or down stream, how are they going to keep calling themselves open source? (They don't call themsegpes free software as far as I can tell)
UBI images are to host applications.
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)
I wonder if Red Hat will provides sources for the rpms in the containers (or actually installed) and nothing else.
Breaking rpm in cloud and container instances seems like a losing strategy.
Yeah, instead of just upsetting the downstream 'rebuilders', you start upsetting enterprise customers too.
The use of UBI to gather sources is maddening to me. It actively inhibits opportunities we have to get the UBI package set expanded, something I'm working on for my industry. Their use of UBI for this purpose is getting in the way of enabling officially provided and unencumbered containerized RHEL for public consumption.
It sucks this hampers your goal of getting the UBI package set expanded but that's not because of the rebuilders using it as a loophole, it's because of the course IBM/RedHat set.
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.
The entire situation smells like an iterated prisoner's dilemma that's going to end up locked in an eternal defect/defect cycle with assorted odd and unintended collateral damage on the margins.
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.
It sounds like they have two different mechanisms they can pull from currently, which will get them to parity with RHEL releases.
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?
> 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.
That wasn't relevant in buying CentOS, plenty of people were selling personal services for CentOS. IBM itself was doing it, and perhaps Kyndryl is still doing the same for the newfangled RHEL rebuilds.
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.
"technically" is a really thin veneer though. The founder of Rocky is also the CEO of CIQ. That's not exactly six degrees of Kevin Bacon.
(to be clear: I don't consider this a problem. But I do consider that for RH, this may be an unintended side-effect.)
> 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.
Could you clarify what you mean by opportunity cost here? Who faces this cost and why?
IBM faces this cost. Before they created this fracture in the EL community there wasn't all this interest and support behind centos alternatives. People just used centos for free or rhel for support. now you could potentially use EL with support from another vendor without IBM seeing a dime.
My guess is that they will be content with:
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.
> making it obvious ...that no one gives a flying f*k about "free as in freedom" because all the uprising was always about either the free beer
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.
Per this link: https://www.redhat.com/en/about/open-source-program-office/c...
"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.
I've seen plenty of posts on Twitter, Medium, on the Fedora mailing list, and elsewhere by individual contributors and industry veterans (some of whom had storied careers at Red Hat) who are not happy with Red Hat's decision.
Lots of free beer in Linux exist because Red-Hat and IBM made it happen in first place.
As did some of the other beloved giants over here.
If "they" was Red Hat then I might agree with you. But "they" is now IBM, which has lawyers like a gas station bathroom has bacteria.
Interesting how you seem to know more about the relationship between Red Hat and IBM than the people who actually work at Red Hat and IBM.
It's cute how many people think the uproar is about whiny freeloaders or clickbait influencers.
No it's mostly from people with a commercial interest. I can't take Rocky seriously when they are selling support for a thing they don't make, but demand it's readily provided for free and no hassle.
>when they are selling support for a thing they don't make, but demand it's readily provided for free and no hassle
So just like RedHat and IBM?
What are you talking about?
What is Redhat demanding for free? They spend more than anyone else on developers for all of the Linux stack.
>What is Redhat demanding for free
Their whole business started and grew on FOSS stuff people wrote for free...
Just like Canonical asks for Ubuntu, and SUSE for SLE/Leap they make. Rocky/CIQ are not 'making' RHEL, ...
IBM/RHEL doesn't make most of RHEL either. It's repackaged FOSS projects. Some they contribute to themselves as well, but most not.
You paint a very weird picture of the engineers they pay to work on Gnome, the kernel, or the hundreds of other libraries used.
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.
>You paint a very weird picture of the engineers they pay to work on Gnome, the kernel, or the hundreds of other libraries used.
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.
> Gnome isn't a RedHat project. Nor is the kernel.
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.
You avoid answering: "What more should they (Red Hat) do?"
Don't be a dick to Centos - and anybody picking that torch.
There was time today's big distros were small and they mostly took from community, packaged it and sold support for it. Rocky is small now so needs to take more from community. If it becomes big later it can also contribute back.
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.
But that's the thing, Rocky simply can't grow in that way, because they're not trying to do their own thing, they just aim for bug-for-bug compatibility. They are not pushing out new code and helping advance the ecosystem.
But that's a large part of the appeal. "Binary compatible with RHEL" sells Rocky, not "another Linux".
Regardless of the reasons, Rocky Linux does not contribute a single line of useful code to the world.
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.
The majority of value comes from noncommercial activity with commercial interest. More songs sell after people hear it for free on the radio. More people buy a package only after the free samples. More license seats sell, but only after 100x more seats were free. Contribution to FOSS is not just the (SS) code, but the act of making/keeping it genuinely Free and Open. I don't care about McDonalds or Burger King when someone's going around with free hamburgers handouts - but if I'd been eating free Burger King burgers all along, it's a pretty clear choice where I'll go to buy my business burgers on the VC's dime. "Mere users" know very well, with less confirmation bias or sunk-cost rationale, what makes a good product. I trusted Red Hat more when they supported CentOS - these recent actions are clearly user-hostile and eschew the main value of FOSS being its network effects.
First, you are making a completely unrelated argument. "Rocky helps sell RHEL": assuming it to be true, that is not a contribution to the open source world. It does not bring new software into the world. It is only a marketing help to IBM's balance sheet, and it helps only insofar as the open source world benefits from IBM making money from RHEL.
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.
Out of curiosity, what makes you say that Rocky Linux have never contributed a single line of code to the world?
Looking at their GH profile https://github.com/rocky-linux seems to show some public repos with code in them?
I'm trusting Carl George's words here:
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.
If I'm reading that reddit comment correctly it referred to contributions to RHEL not contributions to open source, which if I'm reading it correctly was what your original comment stated.
It seems that Rocky Linux have contributed code as open source, just not directly to RHEL.
... or related upstream.
not migrate2rocky, or almalinux-deploy. But if you look closely, they are mostly 'infrastructure' tooling to sync sources or deal with build nodes.
Note: I am not talking about 'individual contribs' but those representing the projects.
Alma at least addresses this: https://almalinux.org/blog/our-value-is-our-values/
Rocky?
Rocky routing around Redhat's attempt to hack the GPL is itself a useful contribution to the world.
TIL Nothing I write is useful.
Carl George, a principal SWE at Red Hat, claimed to have found exactly one code contribution from the Rocky Linux or Alma projects back to RHEL - a two-line bugfix in a .spec post script.
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.
Yes, I am aware of Carl and his biases.
Except, we are?
Then it may be worth asking yourselves "how do we get this fact publicised more widely?" since I don't recall reading about Rocky's contributions either.
(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)
> If it becomes big later it can also contribute back.
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.
According to Rocky Linux devs they aren't: https://forums.rockylinux.org/t/vague-accusations-about-shad...
Developers? What do they develop? If they have upstream contributions great, but if they are just adjustments to their build pipeline they are not developing... That is tweaking.
Read this post from Carl who works on CentOS and Streams: https://old.reddit.com/r/redhat/comments/14jq5i7/red_hats_co...
Does it matter if Rocky and CIQ are separate organisations? Would your or anyone elses opinion be different if the flow went client -> paid support -> Rocky rather than client -> paid support -> CIQ -> donation -> Rocky?
That's one guy saying he doesn't know what's up. I have no doubt he doesn't get paid. What counts though, is this:
I'm one of the board members who replied on the forum thread. Rocky has never sold support or any other product. We make an OS for the community, that's it. The link to the support providers page simply is that, a list of other third party providers who offer paid support services.
So why is Rocky Linux as the 'project?' trying to indicate they still go to space: https://mastodon.social/@rockylinux@fosstodon.org/1106244765..., referring to the 3 person seat, 2 year premium support 'they' sold to NASA?
https://news.ycombinator.com/item?id=36417968 https://sam.gov/opp/2e0365ce1e3c4c179b50fb15573d68e4/view
So a "founding partner" is now a third party provider? Frame it as you may, but there is in fact commercial interest here. Even if Rocky were a separate entity, it depends on the sponsors selling support.
Open source projects with sponsors and partners are pretty commonplace. Naturally, projects depend on having some support from others. You can frame that as a "commercial interest" but I maintain that is an inaccurate description of our sponsor and partner relationships.
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.
I think you misread the post. He's clearly saying that he doesn't understand how the conclusion was drawn that there was anything shady going on. Willing to bet that the RESF builds rocky linux and CIQ does all the "shady" business dealings, which is out of their control.
They demand that Redhat pay for what they take in the only coin that the original producer ever asked for.
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.
> Trying to paywall gpl software is simply theft
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.
Yes, and anybody who buys RedHat product, even for a few minutes on a shared cloud provider, is entitled to the source code, and is also entitled to redistribute the source code as they see fit. Which is what Rocky is doing.
Which is both brilliant and surprising that RH didn't see it coming
I'm still not convinced that 'hiding the source code' was the final end game to this.
I never said you can't sell free software. You have picked the wrong argument to try to make thinking I conflate the frees.
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.
You recognize a clickbait influencer when you see it.
What's the term for those paid actors placed in audiences to cheer for patently terrible things? Found one.
"Free software contributor of 25 years"?
RedHat themselves are a free software contributor of 25 years. So the point still stands.
I was a hobbyist contributor for 10 years before joining Red Hat and still do occasional contributions to random projects I use.
What's the term from name-calling when facing some argument one doesn't like?
Could they not just leave these alternate channels a few weeks or months behind the current release that only the subscribers have access to? That would keep them as the most current, up-to-date source over Rocky Linux.
"Approximately the same lag as you used to get with CentOS" would seem pretty fair to me - I'm aware people grumbled about it and understandably so, but it was still a relatively stable and relatively co-operative situation.
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.
Here's a thought, maybe Red Hat was being honest when they said that they were not under an obligation to make it easy for rebuilders, and that's it? Maybe they weren't out to immediately kill the clones because they know that they can't? We have actually heard very little communication from Red Hat most of it has been speculation from people on what they might or could do, but as you point out there are ways around the changes Red Hat made.
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?
They are actually under exactly that obligation. It's very explicit in the gpl not only what the terms are, but what their intent is, precisely so that no one can ever claim any other possible interpretation.
But according to Red Hat in the interview linked below all of RHEL is built from CentOS Stream, is having the source code available in CentOS Stream Gitlab not adhering to GPL ?
Nope. Centos Steam is merely upstream of RHEL. GPL stipulates that when you give someone else a binary, you also give them the source to that binary, not something similar.
Isn't that the whole issue here? Customers and people with Developer licenses can get the exact RHEL binaries "behind the paywall". And even then if something is upstream does that not mean that the same code flows down stream?
No. CentOS stream is irrelevant here. RHEL customers cannot meaningfully distribute the sources of RHEL. This has been the issue since the beginning, it's just that RH has tightened the knobs progressively over the years.
RHEL source according to Red Hat is CentOS Stream. If the source of RHEL is CentOS Stream then how is it irrelevant? Red Hat cannot deprive you of your right to sources and to redistribute them under the GPL. But Red Hat can also determine who they want to do business with.
centos stream is not the source of rhel binaries. it's upstream of rhel.
Mike McGrath has been very explicit about this in his comments on the Ask Noah Show podcast episode[1] and a number of responses in the r/Linux subreddit.
[1] https://podcast.asknoahshow.com/343 about 20 min in
All I heard in that segment was Red Hat stopped taking extra steps to debrand and push packages from RHEL, and now clones will have to build their software from CentOS Stream. I did not hear anything about additional actions that Red Hat will take or plans to take. Did I miss something?
The users in question don't want a clone of CentOS Stream, though, they want a replacement for classic CentOS.
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)
If they don’t care, then why make it more difficult?
Because it is extra effort on Red Hat's part that corporate backed projects can compensate for if they choose to ?
There is no extra effort here. The binary comes from the source. You don't have immaculate conception for RHEL. RHEL uses the source, and use to provide a link to the said source. Now they don't. And nobody is even asking RH to post sources publicly. People will happily take that burden off of them. They don't have to post the source, they can let their customers do so, but they forbid their customers. So this argument fails.
RHEL source according to Red Hat is CentOS Stream. CentOS Stream is publicly available. Red Hat cannot deprive you of your right to sources and to redistribute them under the GPL. But Red Hat can also determine who they want to do business with.
That interpretation of GPL is the main reason for this post. You have not stated anything new here. Your argument started with something about effort and fell back to their legal line. All your posts in this thread are of a defensive/shilling nature. It has stopped being productive.
The solution here is forking and accepting that IBM just doesn't want to share. The whole value of the Red Hat eco system is lots of people using the down stream variants. Actual direct licensees of Red Hat are not where most of the action is.
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.
> 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
And without the GPL and all the code that came with it, there would be no RH. Rocky is making use of the same legal protection that RH is. Yes, RH spends more on development but they are doing so using the tools and existing codebase given to them, for free, by others.
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.
> Rocky is doing something no different than what RH is doing
Count the contributors to Rocky and RHEL. Then tell me how they can be "doing the same thing".
Taking open source code, some large part of which wasn’t authored by them, and bundling it for others? Same thing, with one notable difference: one of them is trying to extort everyone into paying for code they themselves got, in part or in whole, for free.
RH didn’t write all of linux, but they’re trying to put a price on it like they have.
That makes a lot of sense.
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).
> It's a debranded clone that by definition cannot even have a single bugfix that isn't in RHEL.
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.
That repo would undercut the entire purpose of Rocky, which in their wiki state
> Rocky Linux is a community enterprise Operating System designed to be 100% bug-for-bug compatible with Enterprise Linux. [1]
At that point, why wouldn't the user just be using centos stream?
Lets see how it goes, Red-Hat is a major contributor to anything GNOME, X Windows/Wayland, GCC, Linux kernel.
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.
>clang dropped to third place after Apple and Google decided to refocus on other languages, it is yet to recover from it.
what do you mean by this?
https://en.cppreference.com/w/cpp/compiler_support/20
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.
When I was at IBM and RedHat did the "CentOS"-move, IBM-execs was actually pretty pissed off. It was bad optics and RedHat did it on their own, while IBM got "the blame". This is probably more of the same stuff. They think they can get away with being asshats and people will just blame IBM.
We see you, RedHat. You are NOT on the right path.
I originally had a strong anti-RedHat response to this change. When I thought about it and heard RH's response their sharp change makes sense.
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.
How did they survive and thrive for 25+ years then? Rebuilders have always existed.
They've just dialled the "greed" knob a bit higher, that's all.
Historically they've generally politely ignored community rebuilders and got a trifle enervated by commercial rebuilders - they changed how they handled distributing kernel code (to a fully patched tree rather than a pristine tree and a stack of patches I -think- from memory) in response to Oracle doing a commercial rebuild.
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.
I don't know for sure but if I had to guess early Linux some 25-years ago didn't have the prevalence of polish it has now at least on the desktop. In the server space it was probably solid. That being said businesses back then were likely leery of running a RH clone with just some Linux staff -- better to pay RH for support.
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.
They sell software though that is mostly licensed under the GPL which has certain requirements regardless of if you give it a way free , support down stream projects financially or make an entire public company around it. I’m not sure if red hat can really stop rebuilds beyond ensuring all their trademarks are removed any more than Debian could suddenly stop ubuntu from using that as their starting point OS. RHEL is not free but as I understand it you are getting support from redhat, potentially some legal protections for another SCO type lawsuit, but you are not paying for Linux. I can’t license red hat Linux and get a non GPL license from red ha can I?
Have any law suits from say the FSF or others been filed against Redhat for this action?
Are the RHEL SRPMS watermarked for individual Customers in any way? It seems like Redhat has no mechanism to stop a torrent of the SRPMS showing-up. Attribution would be exceedingly difficult. Since distribution of FLOSS-licensed source isn’t copyright infringement it’s not like they could DMCA it away.
Arguably the specfiles are able to be copyrighted. I wonder what the license is like for those.
> Are the RHEL SRPMS watermarked for individual Customers in any way?
Highly unlikely. File hashing can be used to easily check for this.
Not no mention, source is text. Plain diff shows any differences. There is a lot of text, and so a lot of haystack to make small changes, but no way to hide them at all, and no way to break the product if the diffs are undiffed or further diffed to obscure the origin.
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.
I was poking around the Rocky Linux website, and wondering where to download the latest source code for Rocky 9.2? Let's say IBM decides not to burn up the ecosystem, will Oracle / Alma start using the source that Rocky exfiltrates?
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.
Red Hat can't stop you from exercising your rights under the GPL to redistribute the code. You also can't compel them to do business with you. They've structured their support agreements such that if you do exercise your rights under the GPL they will stop supporting you (and decline to offer you future subscriptions).
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.
To be clear, it's not yet known for certain if the chilling effect of a terminated contract violates the "no further restrictions" clause of the GPL or not. Evidently IBM's lawyers think it doesn't. But it would be good to test it in court first.
GRSecurity started down this road. IBM though has deeper pockets
More importantly, IBM has the best of the best in terms of lawyers. The likelihood of them ever losing a case is basically nil. They sustained and won a proxy war with Microsoft, when Microsoft was the richest company on the planet.
It's not grsecurity's idea, it started on the 90s when Spender was in kindergarten or so. It's always been the way free software companies made money.
Much like GPLv3 was written to counter tivoization, I’d love a GPLv4 to kill what RedHat is doing before they do irreparable the entire free software ecosystem.
In this case, is the change you imagine GPLv4 would say "you cant prevent anyone, at any point from downloading the source code from a project you create" because that is super slippery slope?
I'd also like to ask, what damage do you see this change in behavior doing to free software ecosystem ?
It seems pretty mad. Apparently Redhat doing all of their work as GPL'ed OpenSource and upstreaming everything so that everyone benefits, and anyone can take the software and build their own, sell it, etc, isn't good enough.
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?
Part of the open source social contract is downstreaming too. You can't just take, promise to give back, and then hoard what you've built.
There is no hording though.
What changes have they made to RHEL that isn't available?
downstreaming ? How is the open source social contract anymore than making source code available?
That's what I mean. Not putting up a EULA dam. They don't have to build CentOS or assist anyone, but they can't block the code from flowing downhill.
According to Red Hat the source of RHEL is publicly available on CentOS Stream Gitlab, without a EULA.
It's the upstream source, not the source used to build RHEL. RHEL is downstream of CentOS stream. Much like linux kernel's source is available, it does not help you much.
According to Red Hat it is. If you don't believe them you can get a Developer subscription to get a RHEL ISO to compare with a CentOS Stream ISO. I imagine a lot of people, myself included, would be interested in the analysis of that.
So you do that analysis. Two downstream distros of RHEL have said that they cannot continue to offer RHEL rebuilds/updates without substantial changes. That means that it is not possible to use CentOS stream alone to build RHEL packages. You are free to do all the analysis in the world.
However, it is "exactly" that code, isnt it.. thats been my understanding.
It may incidentally be in some cases, but isn't guaranteed to be. Things don't necessarily flow back up from RHEL to CentOS stream, and even if they do in a general sense, it may not be sufficient to build the exact same tag that RHEL uses. Someone else mentioned that they were not able to build RHEL packages from CentOS stream.
Do you have an example of this, since the project I work on definitely has its code synced to gitlab..
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.
Pushing things back to CentOS stream is not a requirement of GPL. GPL's role ends once RHEL customers get the source. Do you mean evidence of CentOS stream not being enough ? The post talks about it. Rocky needs to collate sources from several places now to create 1:1 RHEL rebuilds.
> Do you mean evidence of CentOS stream not being enough ?
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.
The damage is corporations could now determine whether they classify downstream use of open source code as "valuable" or "not valuable", and determine (according to their own rubrics) whether to effectively end the open source gravy train in their own ecosystem, or be a member of the open source community and share alike.
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.
So Red Hat is saying that CentOS Stream is how RHEL is built, you are saying it is not. Can you show the difference in packages from CentOS Stream and RHEL? Rocky says they pull packages from CentOS Stream, and with their project goal remaining 1:1 binary compatibility then that must be the case.
So far I have talked to two individual developers who have not been able to reproduce a RHEL 9.2 build only using what's available in Stream.
Free.
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...
Could equally be a move to minimise how much of the discussion that springs up around this blog post gets derailed and eaten alive by arguments and/or misunderstandings around said distinction.
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.
This makes me feel very uncomfortable.
If RedHad don't like what Centos (of old) does, then why do they still insist on mooching off of GPL software? If they don't accept the terms of GPL, good news! They don't have to use it!
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.
There’s one thing I don’t understand. They keep saying GPL this, GPL that.
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.
No, it's the other way around: GPL requires that all pieces required to compile the binary (the exact binary that triggers requirement for distributing source) needs to come along. IIUC if they distribute source as SRPMs, the .spec needs to be included and without limitations (legal or technical) that would prevent user from rebuilding the original software.
Well, nothing prevents you from rebuilding the upstream tarball, or tarball with RH's patches applied even, using upstream's instructions. Doesn't have to be the identical RPM package, does it?
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.
Perhaps I'm missing something, but doesn't it have to be the source for an identical rpm package.
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.
Is an RPM spec file even copyrightable? It's pretty much the definition of tabular data akin to a simple recipe or a phonebook, neither of which are subject to copyright under US law as I understand things. I'm also not convinced that a spec file would satisfy the "threshold of originality" to make it copyrightable.
Friendly reminder that not all open source licenses are as reassuring as the gpl is.
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.
So long "Upstream First" principle
https://github.com/RedHatOfficial/open-source-participation-...
This is not at all in conflict with the upstream first, if so please tell me how you see it being in conflict.
The blog post says:
"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?
I believe that currently RH send a patch to the upstream project, then apply/backport it to CentOS Stream, then if they consider it appropriate apply/backport that to RHEL, and it's the first step there being their first step that's the 'upstream first' part.
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.
That's not "upstream first".
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.
> "Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs."
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.
Yeah, that's not what any of us are saying.
We already _do_ a lot of work. This is _more_ work.
So who should be doing that work? On whose payroll? Should Red Hat engineers be spending their time de-branding and wrapping things up neatly for rebuilders to use? Note that every minute they spend on that is a minute they're not spending on adding features, fixing bugs, or backporting fixes to the last ten years' worth of releases. You know, the things they're actually obligated to do by their contracts with customers. Why should they continue letting free work for non-contractual partners - who seem increasingly inclined to be competitors - displace or delay that?
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.
Note that they're actually doing more work now (checking for contractual entitlements, playing whack-a-mole with rebuilders, trying to reassure ecosystem partners, etc etc) than they did before.
I'm not sure that's true at all. Having done a bit of packaging myself, I'm well aware that it's hard, tedious, frustrating work. Doing it twice, once for their own users and again for the benefit of those whose only practical effect is to fragment the ecosystem, is a substantial burden.
> playing whack-a-mole with rebuilders Are they playing whack-a-mole? Or was this one change that people are arguing (and Red Hat's lawyers seem to think) is within their rights under the GPL ? It will be whack-a-mole if Red Hat tries to stop supporting VPS instances or stop updating UBI, both of a 1% chance of going away.
More work that has little effect on the actual upstream ecosystem beyond giving out something for free that 20k people at Red Hat are literally paid for. Ubuntu is not a clone of Debian, they extend it, tweak it, provide the code back to the community. What is the specific parts of the work that Rocky does that benefits the open-source community? What improvements has the community benefited from through your "work"?
They arent asking to be handed everything - they've simply explained how the process has changed now.
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"
> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.
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.
Another similar question I have is around license requirements for various packages. How many of the packages in RHEL are actually GPL/copyleft, where RH must share sources?
Could it decide to stop sharing source for non-copyleft packages next?
> Moreover, Red Hat’s Terms of Service (TOS) and End User License Agreements (EULA) impose conditions that attempt to hinder legitimate customers from exercising their rights as guaranteed by the GPL.
Does someone have more details on this?
I wrote this a couple days ago, sums it up: https://www.jeffgeerling.com/blog/2023/gplv2-red-hat-and-you
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?)
I am amazed that multiple OSS lawyers gave you the same answer and you still don't believe them.
> (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.
Losing access to Redhat services won't immediately bring down your servers, but if you are unable to install security updates or new software without switching to a different distro they might be as good as dead.
But they do make all of that source code available under CentOS Stream. GPL does not require an SLA for providing source code of all bugfixes and security patches free of charge in under 24h. Just embargoing security patches for 1-2 weeks from Stream would be a good enough move for RH to signal to enterprise customers that Rocky/Alma are not a drop-in gratis replacement for RHEL in production systems.
The GPL requires all source code be available including the scripts and glue code required to build the binary alongside the source. You can't pull a Stream and offer "most" of the source, but not the source required to rebuild the latest stable release. That's counter to the spirit and the letter of GPLv2.
Legally speaking, the contract vs copyright issue is the only ground Red Hat has to stand on here.
The last time I recall a company doing the 'we will follow our GPL obligations and give you - specifically you, the recipients of the binaries from us - the source but if you exercise your right to redistribute don't expect to be able to renew your contract' thing I believe the eventual conclusion amongst the people who seriously knew what they were talking about* was 'this is obnoxious but legal.'
* I do not consider myself to be one of those people
I think what RH did is ethically questionable but is a great development for the use of GPL in the enterprise (for releasing SW under GPL that would otherwise remain closed-source): there is now a path for respecting GPL freedoms (in a slightly round-about way) without necessarily making the product gratis.
It's sad to see a post like this get so much hate in the comments section. We all benefit greatly from an organization maintaining a stable Linux ecosystem and the idea that somehow redhat isn't entitled to give back to Linux as much as they have benefited from OSS goes to show just how much coolaid HN has been drinking as of late.
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
> somehow redhat isn't entitled to give back to Linux
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.
No. No it isn't.
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.
> So it's not enough ...
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.
Give me a break.
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.
So you should be well aware of community expectations. And so should Red Hat.
Community expectations aren't necessarily correct and probably won't help paying the salary of thousands of engineers.
Sorry, but the people who started this in no way were prioritizing anyone's salary. They had a vision of freedom, and THAT VISION -- more than "someone trying to do a company" -- is what got the best parts of this software going. One company that can't make the numbers work ain't my problem.
And you're wrong. https://www.gnu.org/philosophy/selling.en.html
"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.
I said prioritizing, I didn't say anything like "didn't consider at all"
I didn't say they were correct. I said be aware of them.
It would make sense if they started out building a proprietary os (for which, btw, the count of people you mentioned is not enough, Microsoft employs vastly more people). If they contribute to open source projects and then cry for compensation, it makes no sense. They can expect compensation for services sure, but not for their open source contribution code. Those are the rules they are playing by. Not to mention that there’s vastly many more contributors who aren’t getting compensated.
They established all that when they had other priorities. Clearly they've changed their mind about a thing or two, so you can expect a lot of that to wash away, slowly.
Ok, call me back when it does.
Obviously by then it will be too late to do anything about it.
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.
It's been 9 years. A few tempests in a teapot later you still have RHEL rebuilds (according to TFA nothing is changing in that respect), they are more timely than CentOS ever was before the acquisition, and you also got Fedora ELN CentOS Stream as a pathway towards contributing to RHEL. So yeah, I rest my case: call me back when it happens.
Bill Cosby was a real funny dude—and also a serial rapist.
Can you explain what you think Rocky are giving back to the community?
CentOS? A usable downstream distribution?
Further: https://forums.rockylinux.org/t/has-red-hat-just-killed-rock...
And why does it matter, anyway? The GPL exists for a reason and RedHat knew what they were getting themselves into.
It's just so stupid people are gonna have to jump silly hoops to get the source code.
Really? Some images, bug reports, and internal build tools. What new software or features have Rocky contributed to the community they can't keep talking about? I side with RH here because I personally, every day, use a lot of software they've made available. That takes time, effort, and money. Heck, you personally benefit immensely from an acquisition they subsequently open sourced. When Rocky has something that's anywhere near this [0] let me know.
[0] https://www.redhat.com/en/about/open-source-program-office/c...
> Heck, you personally benefit immensely from an acquisition they subsequently open sourced.
lolwut?
Are you saying you don't have any material on AWX?
That video has earned me a grand total of $500. And most of that earning happened a couple years ago. I have never run AWX for any of my own projects (or deployed it for any clients), so I have not materially benefitted from it in that way either.
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
Sorry about that. I should have tried to keep the conversation level higher instead of playing with the time zone difference.
What Rocky is giving the community is a check on Red Hat's ability to charge nearly anything they want to for RHEL. That is worth quite a bit.
May I remind everyone that these weird steps that the open source community is doing are not the result of Redhat per se but are a result of IBM that wants his investment back.
They are the same entity now that's kind of what happens when a company gets merged into another company.
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.
On another topic, we can finally see the motivation behind those SRPMs.
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.
What an idiocy.
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 the SRPM was designed 30 years ago when people didn't have always online high speed connectivity.
> when people didn't have always online high speed connectivity
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.
And so, if all you did was put the original tarballs on a CD-ROM or floppies in a simple form, with your patches and build steps on the side, you'd just be a middle man helping some people make their own distro.
> If, instead of a SRPM, you have some small, declarative text file which gives upstream URLs, SHA256 digests and build config steps
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)
I really hope sanity breaks out at Red Hat.
What is RHEL compatibility so important and why is it always such a hot topic?
Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you) in bringing open source to the table against enterprise proprietary vendors.
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.
> Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you)
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.
Not RHEL compatibility, because that's what Stream also has, the bug-for-bug similar behaviour is wanted when you have RHEL servers but test on Centos without having to bother with licenses or terms.
If you have RHEL in production, you are already allowed to install it on test servers without restrictions. Or so I'm told.
What exactly prevents Red Hat from adding one or more proprietary components, like a RHEL bootloader, or network manager and simply refusing to share the code for those components?
If Red Hat doesn't back down, I don't see anyway around Rocky, Oracle and Alma doing a fork.
They can't easily do that without really risking to break the gpl. Btw, Rocky, Oracle and Alma cannot fork; their entire value proposition is being RH-compatible. What could happen is a new giant trying to displace RH as the reference Linux platform, poaching significant amounts of devs from RH. That would require years and billions of dollars though.
> They can't easily do that without really risking to break the gpl.
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.
Red hat does a lot of work in kernel, subsystems, and libraries, where linking is necessary. They can, more or less, happily ignore the legal landscape as long as they stay open, because those licenses are interoperable; the minute they started closing things, they would have to pay a lot of attention not to break gpl constraints.
The whole point of selling RHEL is everything is coming from community and open source and they are making money only for support. If they start closing even a bit of software, they will loose customers to other enterprises like Microsoft
> What could happen is a new giant trying to displace RH as the reference Linux platform, poaching significant amounts of devs from RH. That would require years and billions of dollars though.
It's not working out that great for the old giants, right? I mean Canonical and SuSE.
Next: Add --accept-redhat-eula flag
I'm not a copyright expert, but I'm pretty sure that'd run afoul of the "you may not impose any further restrictions" clause of GPL. Being able to modify and redistribute the source is the whole point.
I see. So even RH blocked access to their srpm repository by any way, it's not about GPL. Finally RH needs to block providing binary by EULA but it will be annoying for evaluation and container.
Watch IBM and RH publish changes to these features Rocky Linux will use to obtain the source, and effectively remove the "open source" part of it and violate the GPL.
>Every user of Rocky Linux is valued and their contributions matter.
That's very wrong. It's not Linux, it's GNU/Linux. [0]