Any thoughts on this release from RHEL?
This article seems to suggest it could affect Rocky, Alma, etc.
Posting this for visibility to hopefully get non-hype insight from the community:
Red Hat and IBM doing Red Hat and IBM things. Life finds a way. And the Rocky Linux team is amazing.
5 Likes
The gpl has a clause that forbids restricting the redistribution of the gpl code, else you lose your own gpl license.
Iâm waiting for a lawyer to point that out.
21 Likes
I just wanted to mention that this was actually an internal Red Hat initiative and not an IBM initiative. Internal Red Hatters have mentioned it was primarily a result of internal efforts to remove duplication of work (and thus relieving engineering resources) which is consistent with other recent moves from Red Hat (e.g. the eventual dropping of LibreOffice from RHEL). There appears to be a relatively large movement toward refocusing engineering efforts on more substantive linux and open source ecosystem contributions as opposed to the more consumer facing ones.
Also, there have been concerns voiced by the community regarding where Fedora fits into all of this.
TL;DR it doesnât fit in this
https://lists.fedoraproject.org/archives/list/[email protected]/message/XM6BNUHKI3EKTDEXAAVE3JBPCG3BPUJC/
https://lists.fedoraproject.org/archives/list/[email protected]/message/CUFOHQNML45N54SG5RCKQLHEYYXXUAO5/
Those responses also touch on some of the quirks of how CentOS Stream and RHEL are developed.
Based on my reading of the AlmaLinux statement, what Red Hat is doing doesnât violate GPL as the sources are still available and can still be distributed but that the Red Hat Developer subscription license might allow them to terminate your developer subscription which gives you access to the source. Iâm sure AlmaLinux is probably going to seek some clarification about this.
The GPLv2 allows redistribution, but it doesnât forbid restrictions. Many companies have taken out patents that apply to GPLâd code (say: lame, ffmpeg, VP9, etc.) and are able to prevent redistribution that way.
The GPL requirement only applies to those who received binaries in the first place. For RHEL, thatâs only paying customers and they said âsource code will remain available via the Red Hat Customer Portalâ so it seems theyâre covered there.
RH distribute CentOS Stream freely, but that git repo is remaining, so no issue there. Yes, a paying RHEL customer could redistribute a dump of the source code if they wanted to, but that would really only be useful to help match the Stream git repo to the released RHEL versions.
Developers donât want just the minimum the GPL requires⌠i.e. a static dump of source code that can be built into the current binaries. They want all the metadata indicating such and such was patched for CVE whatever, or this was changed to enable building the program on this newer compiler or architecture, etc.
2 Likes
The Software Freedom Conservancy released an analysis of this announcement:
TL;DR It doesnât violate the GPL explicitly but definitely in spirit and creates a bit of a black box for finding GPL violations because customers of RHEL wonât want to report GPL violations because it could jeopardize their license agreement/business relationship.
They note that Red Hat has been guilty of violations in the past and generally speaking refuses to admit wrongdoing but still acquiesce to SFC demands when a violation is found. GPLv3 has a further restrictions clause but customers are going to be wary of making a stink about it to preserve their relationship with Red Hat.
It also makes a note about the interesting checks and balances that downstream RHEL clones create as a result.
Iâm not sure that the characterization of this being the culmination of a 10-year master plan is accurateâŚhaving been in a large corporation and recognizing that most of these organizations arenât as monolithic in their design and decision making as theyâre represented in media. Itâs more likely an emergent property of individuals in the company (i.e. sales and engineering) motivated by self interest instead of some coherent vision of someone at the top.
3 Likes
You beat me to it. This is the analysis lines up with my expectations.
While patents may be an exception, in general it DOES for further restrictions. It just doesnât forbid redhat from then cutting off your access.
Tho gpl v3 makes that crappiness a more explicit gpl violation.
And I forgot that RedHat declined to escalate beyond asking for royalties when this came up previously. Annoying, I get why Jeff Geerling is mad.
5 Likes
Itâs a bit of a mixed bag, in my opinion.
This specific decision largely seems to be based on individual engineering efforts to trim fat after the deprecation of CentOS. From an engineering perspective, why should I, as an engineer, have to maintain legacy workflows for something that doesnât âexistâ anymore? If the engineering teams are anything like my engineering team, we had enough on our plates to warrant trimming off legacy workflows just so we could get home to our families in a timely manner. When I was in similar positions, albeit in a different industry, I didnât always take into account the impact on downstream because taking them into account would tie my hand or dilute what my boss said was my priority.
I want to be clear that these kinds of decisions in corporations donât always come from a place of malice or even avarice. Sometimes it does and sometimes it doesnât. It is almost always some amount self-interest, though.
Itâs one of those positions where the value of downstream isnât valued enough to account for it in business decisions. (Aside: Iâm not saying itâs not valuable just that it isnât valued from a self-interest perspective)
From a community perspective, whatâs missing is a codified feedback loop from the downstreams of RHEL that makes their value more tangible. Red Hatâs position on RHEL clones appears to be largely âItâs cool that you exist but weâre not going to make business decisions based on your existenceâ. Which, from their perspective, I understand. The only real codified feedback loop that the downstreams have is purely a punitive one ⌠GPL violations. Red Hat has, it appears, found a way to skirt them. Itâs like when a kid finds out that they can pad their underwear with wads of cash to keep from feeling a spanking.
The other non-punitive feedback loops that could exist in the form of upstream contributions or even a relatively large monetary relationship appear to be purely social in nature. From an outsiderâs perspective, making a clearer community workflow that feeds back into the Red Hatâs business could probably help. This could be in the form of creating tooling to make conversion from AlmaLinux/Rocky â RHEL simpler so that there were metrics to point to that would make it easier from Red Hat to them into consideration for business decisions.
Thereâs also codifying the relationship of the downstream contributions to upstream RHEL. The unfortunate problem with community contributions is that nothing really stops Red Hat from just hiring community contributors thus negating any bit of independence of that feedback loop.
Another option might be a monetary relationship where someone pays Red Hat to maintain the legacy workflow. This is a possibility but it would likely have to be a sizable sum for it to even be considered.
Or the community could create a canary red hat subscriber that does the distribution of source and then sings when its subscription is terminated as a GPL violation and argued in court as a âfurther restrictionâ.
Or, you know, Red Hat could just tell their engineering teams to suck it up and keep doing the extra work and eat whatever opportunity cost they think they have by maintaining it. In order to make this more manageable from a Red Hat perspective, Iâd probably ask the community to automate the process of SRPM extraction to the public Git somehow.
I donât particularly like any of these options. All of them are a bit lop-sided in terms of the power dynamic. The only real option we have right now as a community is to raise a stink that impacts their bottom line somewhere so that they take downstream into consideration when making business decisions. How effective this is varies so much that itâs hard to argue its faithfulness (see the recent reddit blackout for reference).
Iâm interested in how this plays out in the long term.
Scarlet Hat is pulling an Oracle more and more frequently. If they wanted to go proprietary, then they shouldâve develop a new OS and then deal with that. They are enough of a behemoth to hold onto hardware vendors. AIX is still a thing, a proprietary RHEL'OS would be profitable.
But they are just using the GPL as a marketing gimmick. Their service contract prohibits people from doing what the GPL permits. They are in their legal right to terminate service contracts for people who exercise their right to redistribute the source code (and do other stuff, like make as many copies of the software as they want), but this goes against the spirit of the GPL.
I wouldnât have been as disgusted by Big Hatâs move if it were FreeBSD going proprietary, because the MIT license permits that and nothing prevents them from doing so. And itâs absolutely hilarious that a company that uses such a restrictive license (the GPL) is way more closed, secretive and vicious against the general open source community than the FreeBSD Project, which uses a way more permissive license and which has a way more open development model.
People in the industry should always be very wary of working with companies that put a restrictive service agreement that goes against what the software license actually says. To some extent, it is better to use community projects, like Debian, Gentoo, NixOS and the *BSDs. You donât get the support if something goes wrong, but:
- If you are a small player, you probably canât afford the RHEL support anyway.
- If you are a big player, itâs probably cheaper to have a developer (or more) quickly find the bug, fix it, have the patch run locally, then send the fix upstream.
I think a business model built around supporting existing projects and quickly giving a fix to currently very critical issues to someone could be a viable alternative to actually having a grip on the whole software stack. Think of it like a âDebian support groupâ or something like that. Find a bug or security vulnerability thatâs critical to you, pay this group to quickly fix it, then they will send the fixes upstream.
The reason for paying someone to do it quicker than the upstream depends on your threat model or business need. Having something now is an opportunity cost well spent, rather than being vulnerable or having your business halted because of a bug.
3 Likes
Thanks for the heads up rebasing infrastructure from Rocky to Debian 12 is gonna be fun
Might not be necessary.
1 Like
too late already. I dont do well with stuff like this and its not want to use rhel based stuff on principle
4 Likes
I hope that turns out to be the case, but yeah I donât personally have much downside to just going with debian here either.
2 Likes
Without going into license wars it pretty much always seems to end up at (oversimplied) that GPL âpeopleâ appears to think theyâre more entitled than others. Red Hat have poured a lot of âfreeâ man-hours into Linux and its community, you can argue about their overall influence and intentions but if you look at it broadly thatâs the end story. If they donât want to do that anymore thatâs their decision to make, theyâve already contributed a lot and you should be grateful for that especially if you (likely) have benefited from their work for free. Itâs up to you whether you want to use their contributed code or not as itâs open source and if people wants to go in another direction only time will tell.
Edit: My point is, be grateful of their work instead of turning it into anger and hatred.
2 Likes
Not gonna happen
Tons of other people have done exactly what you described not just red hat and they arent being colossal douche nozzals about it
1 Like
I think this is a money grab, aimed at Oracle who has grafted on their open source software for the past 15 years, and now with their hardware platforms, virtualized platforms, and cloud platforms exclusively based on Oracle Linux (for which they get money from customers in the form of support contracts) that is /was derived straight from them sources, it may be the final nail to force them to negotiate a proper âfeeâ⌠We will see âŚ
What happened prior to this is that Oracle was already struggling to suggest adopting oel9 ⌠and yes, it is a big enough pie to warrant cutting off everyone else⌠weâre talking hundreds of thousands, possibly millions of systems deployed âŚ
1 Like
Official Response for those still watching
TL;DR
Red Hat is still committed to open source but that doesnât mean that they are required to support downstream rebuilders of RHEL. Distributions that are downstream of RHEL that do more than just repackaging they will continue to work with because they provide value (they explicitly mention those that build RHEL for other architectures).
They also go on to say that they have always been an âupstream firstâ kind of open source company as evidenced by all of their contributions to the wider ecosystem. Rebuilders of RHEL that just remove their branding and replace it with their own arenât valuable to them and they arenât obligated to support their workflows.
They also wanted to clarify position of CentOS Stream. Itâs the place where all of the source code lives that is going RHEL and if there is ever a time where that isnât the case, that is a bug and needs to be reported. CentOS Stream is the place for downstreams of RHEL to contribute back to the project because that is where RH engineers contribute and that is all out in the open.
END
Honestly, this is probably the most pragmatic response and while people are probably still going to be angry, itâs honestly about what Iâd expect.
Also, the decision was all Red Hat from what Iâve heard from internal RHers. Itâs not the demand of IBM.
2 Likes
May we have a TLDR? I really dont kive in enterprise space but I find the drama a tad bit curious.
Wow. Thatâs a huge F.U. to Rocky, Alma, and all other RHEL derivatives:
âMore recently, we have determined that there isnât value in having a downstream rebuilder.â
âUltimately, we do not find value in a RHEL rebuildâ
âSimply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere.â
2 Likes