I mean, RHEL clearly does not care about the GPL. Couldn’t the same argument be made then about RHEL and their attempts to undercut all the devs who put in free time to make Linux?
And “mostly sponsored” is just another way of saying sponsored. Just because you sponsor something does not mean you own it. It does not really give you many rights as I understand. Because you are a sponsor, not an investor.
You make the argument for GCC but that is a piece of GNU which I feel furthers my point. Cool, RHEL put some money into an already free and open piece of software… that makes them exempt from violating the GPL?
Fair enough, IANAL so I guess I let emotion get the best of me. That said as of v3 of the GPL: “ You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License.”
I guess I am curious what the legal reasoning is behind them skirting it is.
A separate train of thought, but also, GCC was released 36 years ago. RHEL only 23. So GCC was fine without for 13 years. My bet is they would be fine without another 13, too.
Can you eloborate on the minimally vs fully. In my book you are either compliant or you are not. Or is this a case of spirit vs letter? If so, I would love to know the spirit part.
This is a case of 100% violating the spirit, and perhaps also violating the letter.
The GPL requires that the distributor place no restriction on redistribution of the sources or binaries by their clients. The subscription agreement, however, is terminated if you exercise this right, despite Red Hat not being allowed to restrict the exercise of this right. This is on the very edge of legality and may be found illegal - they're shifting the consequence somewhere else to say that it's not redistribution that's restricted, but that if you redistribute then they restrict everything else.
> The subscription agreement, however, is terminated if you exercise this right, despite Red Hat not being allowed to restrict the exercise of this right.
This one. Though they can add any restrictions (like asking money for the sources, which GPL is fine with).
No, you cannot add any restriction to asking for sources nor to redistribution.
You can only ask in exchange for sources for the cost of physically distributing the source, nothing more, and in that case you must offer it to anyone asking at all, even if they do not have the binary. Otherwise, you have to distribute it for free on the same medium as the binary itself.
You can not either add any restriction to the act of distributing the program or it's sources. The GPLv2 says for example "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.". The question is whether or not terminating the subscription is a restriction, which it totally is to any reasonable reading by a layperson, and may be as well in front of a judge.
viscerally I would like to support what you say, but it makes little sense with a broader interpretation of "costs" .. IANAL but there might be some "reasonable" added there, and markets work with some bit of extra in places. It seems like a market negotiation is OK.
The value of the code has to exist in really different economies.. London to Algiers so to speak. So there has to be some room for different kinds of deals IMHO
> The GPL requires that the distributor place no restriction on redistribution of the sources or binaries by their clients. ... The subscription agreement, however, is terminated if you exercise this right, despite Red Hat not being allowed to restrict the exercise of this right.
Again -- you've said this elsewhere -- which source and which binaries? RH places no restrictions on the redistribution of source or binaries received pursuant to Section 3 of the GPL. RH simply terminates the business relationship if you decide to build a 1:1 clone. What you're reading into the GPL is a duty not to terminate a business relationship, and to deliver new and distinct sources and binaries, after the business relationship is terminated.
That quote, at no point, says they violated. Simply, that they don’t care. Which they do not. They care about money. It amazes me how many people want to split hairs for a billion dollar corporation. You can be compliant and still be morally bankrupt and not care about the GPL. Not mutually exclusive. And important note: “which guarantees that users are free to use, share, and modify the software without paying anyone for it.”
All that said, I will just admit that I am upset with RHEL and need to do some more research into the GPL.
- takes non commercial open source and does integration and sells support. Also contributes to a megaton of open source projects across all layers of Linux.
The other you have the rebuilds:
- take Red Hat's commercial but open source work
- does no integration work whatsoever, since RHEL's already done that
- trivial contributions to almost no open source projects that aren't only necessary for their position as a clone
- undercuts RHEL in support offering since they don't have to do practically anything themselves.
So yeah, RHEL is an excellent citizen of open source and the others are just parasitic freeloaders.
I used to build on centos to check my code would run on red hat. That doesn't seem particularly parasitic. Since they canned centos I no longer try to check whether anything will run on red hat.
As a developer, I never considered buying an enterprise license anyway. CentOS/RHEL with 10-years stability was kindof the canonical base for development of backend apps when you have better things to do than keeping dependencies up to date. Especially when RHEL themselves change things all the time in a zero-sum fashion without new capabilities (cough systemd cough). Now I don't care about RHEL at all indeed.
there are conflicting or at least mutually differing goals for an OS and the products. It seems from this desk that part of the extended systemd unrest is actually about spending resources for one set of aims, not another, when both are legitimate. It seems obvious the companies acquire tech with finance, and finance often cares about security and adding new locks, fences and cameras in the product fabric. systemd and the EFI boot seem to becoming more vehicles for new locks, fences and cameras than adding features to the product.
I used to test on centos because red hat was _the_ enterprise Linux platform and I wanted my code to work there unmodified. It also helped avoid hardcoding assumptions from the Debian world.
I don't test on centos stream because I'm skeptical anyone deploys it to production and code working there wouldn't tell me much about working on RHEL. If my code crashes on their bleeding edge, do I try to fix it or wait to see if something under it is broken? Could waste a lot of time there for zero benefit.
I personally think this is the beginning of the end times for RHEL. It will not survive IBM.
Everyone is busy getting mad at Red Hat when the ones they should be directing their furor towards is Oracle. In simple terms, Oracle fucked this up for everyone and forced Red Hat's hand. They've been stealing megacorp contracts from RH left and right by undercutting them on price and how could they not? Their development is minimal. Truly "we're gonna build an OS...and make Red Hat pay for it." So while this situation sucks for everyone involved, this was indirectly Oracle's doing.
And if you're building infrastructure on free software that has dependencies on RHEL, or rather "free RHEL", shame on you. RHEL is for shops with wheelbarrows of money that used to run Solaris or HP/UX and are running proprietary software. What is happening is IT project managers are trying to justify their existence and cut costs, so they switch the contract to Oracle Linux so they can earn that bonus check.
This is a weird take. Nothing Oracle did was wrong. RedHat's model can be used by anyone, why shouldn't another company make use of the source's? It's the risk of the model RedHat has gone for and also RedHat has added clauses to they're terms preventing resharing of sources which is against GPL.
Red Hat's EULA does not violate the GPL and what Oracle does is obviously wrong, it's parasitic and in the long term will kill RHEL (and thus also Oracle's version).
This is correct, and the customer has full rights to redistribute. But the original customer may be limited to paying Red Hat customers only and still remain in full compliance.
Exactly right. The real problem here is a deficiency in the GPL, which GRSecurity pioneered and IBM is now using. Any company in the same situation would do the same thing.
I think the way this is going to play out is that a lot of that distro-specific code is going to have to be re-written. I’m lucky that my CentOS/Rocky exposure is not huge (maybe a dozen virtual machines) so it’s not a big deal for me to change.
Of course, having had licensed RHEL machines and VMs in the past, this whole thing makes me much less likely to ever pay RedHat/IBM for them again… Definitely already time to look for alternatives. It is really quite a shame though, given the amount of Linux and related open source development RedHat developers did.
At any point in building your entire business' infrastructure so it was dependent on RHEL, or more likely an ersatz clone, did you ever consider you might have to buy a license at some point?
It's like building a diet exclusively based on eating the free samples at Costco then going "oh those evil bastards, I'll starve to death" when they take them away.
Maybe use platform-agnostic architecture next time or don't build your house of cards on proprietary-adjacent distros.
Red Hat never indicated that they had any trouble with CentOS, rather the opposite; their disposition towards it has always been very positive until recently. It would have been like using Ubuntu Server and worrying that Canonical might kill it off and force you to buy Ubuntu Pro; not completely out of the question, but also not something you would expect.
That's because CentOS didn't meaningfully cut into their major business which is support. Anyone running CentOS outside of a lab setting understood they were on the hook for their own support. Most CentOS users were never going to be paying RHEL customers. You can't lose what you didn't have to begin with. Along came Oracle which is taking big customers and literal bags of money away from RH's core business by reselling a warmed over version of their own product at a lower cost.
Nice example, but to be fair your analogy is flawed since there's no consideration on the GNU Public License, which is at the center of this conflict. Those free food samples were part of the 'contract' Costco made with the food producers... ;)
Maybe, maybe not. The GPL does not allow any restriction on the redistribution of sources. Is retaliation in this manner a restriction? It is to a layman, lawyers are not in consensus. The Software Freedom Conservancy has warned Red Hat they believe this is not following the letter of the law, for example.
"Now, to be clear, the GPL agreements did not obligate Red Hat to make its CCS publicly available to everyone. This is a common misconception about GPL's requirements"
"Due to this ongoing bad behavior by IBM's Red Hat, the situation has become increasingly complex and difficult to face. No third party can effectively monitor RHEL compliance with the GPL agreements, since customers live in fear of losing their much-needed service contracts. Red Hat's legal department has systematically refused SFC's requests in recent years to set up some form of monitoring by SFC. (For example, we asked to review the training materials and documents that RHEL salespeople are given to convince customers to buy RHEL, and Red Hat has not been willing to share these materials with us.) Nevertheless, since SFC serves as the global watchdog for GPL compliance, we welcome reports of RHEL-related violations."
TL;DR: To be sure they were complying, marketing department is as important as the legal one, and they were fearful of people taking a good look there.
As someone who's not a coder, out of curiosity, what kind of services and applications can only work on RHEL, and how hard would it be to make those distro-agnostic?
Often things can be ported easily without much effort, but the issue lies in validation and testing, there are often corner cases that need to be identified and tested, it can cost a lot of time and effort and it's not always feasible. Redhat knows it may be cheaper to purchase RHEL subscriptions in that case.
It depends. Most of them are undocumented, have no testing and have accumulated years of RHEL specific stuff (RPMs, using EPEL for dependencies, ansible). At the same time they service hundreds of important users per day, making them difficult to change. Our "cloud" also only offers RHEL-like images (Centos and now Rocky), so getting another distro involves getting a special exception and installing it from iso.
What? So far the consensus is "probably is compliant (minimally), but a good set of lawyers may be able to argue either way, depending on the jurisdiction"
As I understand it (not a lawyer!): When you have a business relation with Red Hat (agreed to their T&C) and you choose to use the GPL-ed sources outside of the T&C you agreed, Red Hat has the right to terminate this business relation. The GPL-ed Sources you got during that business relation are under the terms of the GPL and thus it is within your rights after the business relation is terminated to use those sources anyway you like within the terms of the GPL. If you don’t like this arrangement, do not use RHEL.
The GPL does not allow you to put further restrictions on the redistribution of sources. The termination of your business relationship can be argued to be a restriction. It's not settled.
> The termination of your business relationship can be argued to be a restriction.
It's not a very good argument. The GPL does not state nor does it imply a continuing duty to deliver you source code. You have a right to the source which corresponds to the binary you've been delivered. Period.
If I release a new binary to which I hold full copyright, after having delivered GPL sources to you, and I wish to change the license of that software to fully proprietary, your rights are not restricted re: the GPL bits you've previously received. Why? Because you should still have the source to the binary you received from me that was licensed as GPL.
the fuss is when this whole arrangement goes to an outside party for contract: companies that indemnify their partners; that have compliance requirements by law; that sign contracts to provide service that have strict clauses, all need the commitment of strong contracts with their OS supplier. Those kinds of customers are exactly RHEL customers, in many cases.
I really think this is all due to the Rocky/NASA deal. Their sales team (IBM/RH) must have freaked out. If Rocky can put a deal like that together then so can Oracle.
I felt bad for Mike McGrath when I read his apologetics. The technical guy playing as a pawn in a proxy battle between salespeople and lawyers.
This is mostly true, but there's nuance to that which I believe doesn't make Stream a "fully GPL compliant target for RHEL sources".
Some sources do not hit Stream in a way that makes it possible to rebuild a release of RHEL verbatim, and devs can and have reported issues with compiling against Stream for deployment to RHEL, especially for the latest versions, where Stream and RHEL are diverged for a time.
Why bother? The Venn diagram of people that need a bug-for-bug clone of RHEL and think that the proposed process is in any way appropriate is two seperate circles.
Are there really so many users who rely on 100% RHEL compatibility, and support for 10 years of the same ancient kernel? And all these users are companies who can't afford a license? Or universities who can't afford an education license?
What are these users doing, that can't be done with good ol' Debian, or any other of the million distros? I'm genuinely interested in that.
Things are more complex when requirements and documents were drafted time ago.
A requirement may specifically include all security updates asap for that software on that version and it is nobody's interest to change kernels (especially by who charges the clients for this routine constant work).
We have plenty of licensed RHEL, but in isolated environments the hurdle of connecting to a Satellite server or their subscription hub on the internet is too high -- at least with Rocky and the ilk available. For this set up, the licensing model doesn't match reality, at least not easily.
Are we really going to build out compatible configuration management, monitoring, logging, etc? -- it's not a seamless transition. How much time do we have to put towards this?
And yes -- there is software compatibility issues. Look at the OpenHPC software distribution, it's designed for SUSE or Enterprise Linux: https://github.com/openhpc/ohpc/wiki/2.X
I guess testing with broken licensing terms is a valid usecase, thank you. But does that mean most of the uproar is caused by this root cause? This noise is actually coming from actual RHEL subscribers, who don't want to pay such throwaway systems (rightfully), and not from non-RHEL subscribers?
> Are there really so many users who rely on 100% RHEL compatibility, and support for 10 years of the same ancient kernel?
It's not unimaginable. Think systems which have been certified by some regulatory body.
So, most of finance and banking, some of health, all of munitions and arms, many aviation systems, many industrial systems, etc.
I worked in EMV and munitions, and a lot of the time it was simply cheaper to continue making the old system than it was to certify a whole new system.
The fastest certification process I knew off took about 6 month. The longest took about 2 years.
But I imagine these industries are exactly the ones who will not rely on random free rebuilds, but will shell out the RHEL subscription without flinching, and then sleep with a peace of mind. I guess not these users making this big news (Though this is a blind guess, and could be totally wrong...)
Actually you're on the money and I should have considered more context when making my previous reply.
Those users (of which I used to be part of) find it a lot cheaper (almost negligible) to pay for things like RHEL instead of re-certifying.
You do make me wonder, though, about who the vocal users are: RHEL is not important enough to license, but important enough to not move to a different distro?
> You do make me wonder, though, about who the vocal users are: RHEL is not important enough to license, but important enough to not move to a different distro?
The scientific community, who run extremely high core counts and thus get a raw deal on licensing, but need the drivers for their hardware to be completely reliable as well as software compatability to work with anything from proprietary vendors that their community might need. Eg. CERN who are backing Alma linux.
At my previous employment, we used RHEL. Why? It is the only linux on the governments list of "security acceptable software products".
And lot's of CentOS. Mainly for development. If I needed a virtual machine to troubleshoot something, I would make a CentOS one. A lot easier to not worry about the license keys. Same for build machines and temp lab setup machines, CentOS was quick to set up.
Delivered machines required RHEL. The others did not.
Honestly I don't think Rocky provides any values to the community but that may be just me a arch user on desktop and debian on server (switched from redhat)....
but i don't think the issue is with them, the real issue is huge corporation like Oracle who are ought to destruct Redhat and I can understand where they are coming from... Rocky, Alma, they are casualty..
Regardless on where you stand about Red Hat's decision, I can't imagine any company relying on a distribution that's built from these methods (Rocky, I mean).
Scraping source using dodgy methods almost sounds like "pirated" Linux.
107 comments
[ 2.8 ms ] story [ 168 ms ] threadAnd “mostly sponsored” is just another way of saying sponsored. Just because you sponsor something does not mean you own it. It does not really give you many rights as I understand. Because you are a sponsor, not an investor.
You make the argument for GCC but that is a piece of GNU which I feel furthers my point. Cool, RHEL put some money into an already free and open piece of software… that makes them exempt from violating the GPL?
edit: Stallman, any thoughts?
They aren't violating the GPL as per legal point of view.
Whatever morals people think should go beyond legal matters is wishful thinking.
Anyone is also welcome to up their game and pay the projects Red-Hat is putting money on.
Whose the first?
I guess I am curious what the legal reasoning is behind them skirting it is.
You're obviously confused as to the terms of the license. Red Hat seems to be fully compliant.
The GPL requires that the distributor place no restriction on redistribution of the sources or binaries by their clients. The subscription agreement, however, is terminated if you exercise this right, despite Red Hat not being allowed to restrict the exercise of this right. This is on the very edge of legality and may be found illegal - they're shifting the consequence somewhere else to say that it's not redistribution that's restricted, but that if you redistribute then they restrict everything else.
This one. Though they can add any restrictions (like asking money for the sources, which GPL is fine with).
You can only ask in exchange for sources for the cost of physically distributing the source, nothing more, and in that case you must offer it to anyone asking at all, even if they do not have the binary. Otherwise, you have to distribute it for free on the same medium as the binary itself.
You can not either add any restriction to the act of distributing the program or it's sources. The GPLv2 says for example "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.". The question is whether or not terminating the subscription is a restriction, which it totally is to any reasonable reading by a layperson, and may be as well in front of a judge.
The value of the code has to exist in really different economies.. London to Algiers so to speak. So there has to be some room for different kinds of deals IMHO
Again -- you've said this elsewhere -- which source and which binaries? RH places no restrictions on the redistribution of source or binaries received pursuant to Section 3 of the GPL. RH simply terminates the business relationship if you decide to build a 1:1 clone. What you're reading into the GPL is a duty not to terminate a business relationship, and to deliver new and distinct sources and binaries, after the business relationship is terminated.
All that said, I will just admit that I am upset with RHEL and need to do some more research into the GPL.
On one side your Red Hat:
- takes non commercial open source and does integration and sells support. Also contributes to a megaton of open source projects across all layers of Linux.
The other you have the rebuilds:
- take Red Hat's commercial but open source work
- does no integration work whatsoever, since RHEL's already done that
- trivial contributions to almost no open source projects that aren't only necessary for their position as a clone
- undercuts RHEL in support offering since they don't have to do practically anything themselves.
So yeah, RHEL is an excellent citizen of open source and the others are just parasitic freeloaders.
RHEL is for big business having bespoke applications; unless you need the stability nobody expects normal open source devs to make RHEL their testbed.
Because that doesn't say anything about stuff running on RHEL, and you can test on Debian just as well so why bother?
Like, why do you care about RHEL at all in a way that isn't covered by CentOS Stream?
I don't test on centos stream because I'm skeptical anyone deploys it to production and code working there wouldn't tell me much about working on RHEL. If my code crashes on their bleeding edge, do I try to fix it or wait to see if something under it is broken? Could waste a lot of time there for zero benefit.
I personally think this is the beginning of the end times for RHEL. It will not survive IBM.
And if you're building infrastructure on free software that has dependencies on RHEL, or rather "free RHEL", shame on you. RHEL is for shops with wheelbarrows of money that used to run Solaris or HP/UX and are running proprietary software. What is happening is IT project managers are trying to justify their existence and cut costs, so they switch the contract to Oracle Linux so they can earn that bonus check.
It is business as usual with any of them.
Maybe they should remove their Linux contributions as well, that they have been doing since around 2000.
Of course, having had licensed RHEL machines and VMs in the past, this whole thing makes me much less likely to ever pay RedHat/IBM for them again… Definitely already time to look for alternatives. It is really quite a shame though, given the amount of Linux and related open source development RedHat developers did.
It's like building a diet exclusively based on eating the free samples at Costco then going "oh those evil bastards, I'll starve to death" when they take them away.
Maybe use platform-agnostic architecture next time or don't build your house of cards on proprietary-adjacent distros.
"Due to this ongoing bad behavior by IBM's Red Hat, the situation has become increasingly complex and difficult to face. No third party can effectively monitor RHEL compliance with the GPL agreements, since customers live in fear of losing their much-needed service contracts. Red Hat's legal department has systematically refused SFC's requests in recent years to set up some form of monitoring by SFC. (For example, we asked to review the training materials and documents that RHEL salespeople are given to convince customers to buy RHEL, and Red Hat has not been willing to share these materials with us.) Nevertheless, since SFC serves as the global watchdog for GPL compliance, we welcome reports of RHEL-related violations."
TL;DR: To be sure they were complying, marketing department is as important as the legal one, and they were fearful of people taking a good look there.
Every time you ask why use busybox for userland utilities its always some bullshit reason around security or resource usage that doesn't hold water.
My time is more valuable than shaving off a few milliseconds running gimped core utilities with major functionality missing on a non embedded system.
https://news.ycombinator.com/item?id=36420259
https://news.ycombinator.com/item?id=36436786
https://news.ycombinator.com/item?id=36479882
Just use Centos Stream to build your value and contribute back.
Red Hat bases its model on dwelling in the grey zone.
So if Rocky aspires to be a Red Hat clone... they can adopt this bit, too :)
It's not a very good argument. The GPL does not state nor does it imply a continuing duty to deliver you source code. You have a right to the source which corresponds to the binary you've been delivered. Period.
If I release a new binary to which I hold full copyright, after having delivered GPL sources to you, and I wish to change the license of that software to fully proprietary, your rights are not restricted re: the GPL bits you've previously received. Why? Because you should still have the source to the binary you received from me that was licensed as GPL.
I felt bad for Mike McGrath when I read his apologetics. The technical guy playing as a pawn in a proxy battle between salespeople and lawyers.
Some sources do not hit Stream in a way that makes it possible to rebuild a release of RHEL verbatim, and devs can and have reported issues with compiling against Stream for deployment to RHEL, especially for the latest versions, where Stream and RHEL are diverged for a time.
What are these users doing, that can't be done with good ol' Debian, or any other of the million distros? I'm genuinely interested in that.
A requirement may specifically include all security updates asap for that software on that version and it is nobody's interest to change kernels (especially by who charges the clients for this routine constant work).
Are we really going to build out compatible configuration management, monitoring, logging, etc? -- it's not a seamless transition. How much time do we have to put towards this?
And yes -- there is software compatibility issues. Look at the OpenHPC software distribution, it's designed for SUSE or Enterprise Linux: https://github.com/openhpc/ohpc/wiki/2.X
It's not unimaginable. Think systems which have been certified by some regulatory body.
So, most of finance and banking, some of health, all of munitions and arms, many aviation systems, many industrial systems, etc.
I worked in EMV and munitions, and a lot of the time it was simply cheaper to continue making the old system than it was to certify a whole new system.
The fastest certification process I knew off took about 6 month. The longest took about 2 years.
At those timescales it becomes expensive.
Those users (of which I used to be part of) find it a lot cheaper (almost negligible) to pay for things like RHEL instead of re-certifying.
You do make me wonder, though, about who the vocal users are: RHEL is not important enough to license, but important enough to not move to a different distro?
The scientific community, who run extremely high core counts and thus get a raw deal on licensing, but need the drivers for their hardware to be completely reliable as well as software compatability to work with anything from proprietary vendors that their community might need. Eg. CERN who are backing Alma linux.
And lot's of CentOS. Mainly for development. If I needed a virtual machine to troubleshoot something, I would make a CentOS one. A lot easier to not worry about the license keys. Same for build machines and temp lab setup machines, CentOS was quick to set up.
Delivered machines required RHEL. The others did not.
but i don't think the issue is with them, the real issue is huge corporation like Oracle who are ought to destruct Redhat and I can understand where they are coming from... Rocky, Alma, they are casualty..
Scraping source using dodgy methods almost sounds like "pirated" Linux.