6 ms·

This issue has gotten a lot of attention on HN lately, but I'm still struggling to wrap my head around it. If anyone can clarify my understanding I'd appreciate

by jt2190 3y ago

This issue has gotten a lot of attention on HN lately, but I'm still struggling to wrap my head around it. If anyone can clarify my understanding I'd appreciate it. My understanding is that Red Hat Enterprise Linux can be thought of as Fedora + stability + patches, and that the patches themselves should be released downstream as part of the GPL. What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. This has made it more difficult for "repackagers" like CentOS, Rocky and Alma to keep their disros up to date. Assuming I have the above correct (and I may not), my suspicion is that Red Hat is looking at cloud providers who also have been repackaging, for example, Amazon Web Services' Amazon Linux has historically been RHEL repackaged and bundled with some aws tools. I'm not aware of AWS distributing their changes either. From this perspective, it looks like the AWS benefits from the stability + patches without paying RedHat for their development. (I'm also not aware of whether aws distributes the Amazon Linux sources and if so those are done in a way that is useful for the community... I'll do some further research on my own. edit: It looks like the Amazon Linux sources are here: https://github.com/amazonlinux/linux https://github.com/amazonlinux/linux)

dcow 3y ago
Nothing in the GPL says sources must be available to anonymous unauthenticated users. RHEL just requires you to sign in to download the sources, which is making some maintainers grumpy. I don’t believe this is some grand scheme to make maintainers grumpy, they are just curmudgeons.
- cesarb 3y ago
  > RHEL just requires you to sign in to download the sources, which is making some maintainers grumpy. From what I've read, what's actually making people grumpy is that signing in to download the sources, and later giving these sources to anyone else, could risk losing your RHEL account.
  - simiones 3y ago
    It's not that it could risk that, it's that it absolutely means you lose your RHEL account (and any other contract you had with IBM), at least if they find out about it.
    - jzb 3y ago
      I don't believe this is true. It's almost certainly not true for instances of distributing a limited set of sources. That is, I seriously doubt Red Hat or IBM are looking to cancel subscriptions if I download the latest package from RHEL 9.x for Bash or even the Linux kernel and distribute those sources quietly. If I download everything and advertise a rebuild based on those sources? I'd expect that my subscription will be going away soon. There's probably a line somewhere in between where Red Hat would take notice and care. But I would wager a good bottle of Scotch[1] that line is much closer to "everything" than a maintainer grabbing Red Hat's changes to their work via a sign-in to the no-cost account and incorporating those changes or something like that. [1] Say, Auchentoshan Three Wood or something good but not like 30-year-old Speyside. I'm not made of money...
      - tsimionescu 3y ago
        Per the RHEL subscription agreement, you lose your subscription if you do any of this. Of course, whether they will choose to act on the letter of the contract or not is up to them, but the letter is clear.
        ComputerGuru 3y ago
        No, per the RHEL agreement they have the right to terminate your subscription "upon review" if you do any of this. It's a subtle difference but it's also worlds apart from "you will have your subscription terminated" (i.e. automatically, as a matter of fact/contract) in the court of law (and in terms of real world repercussions for anyone that isn't building a competing distro).
        3y ago
lproven 3y ago
What @dcow said. > the patches themselves should be released downstream as part of the GPL. The GPL only says you must provide the source to your customers. Not to anyone else. It does not compel you to offer them the world, gratis, no, not if you don't want.
- ninkendo 3y ago
  But your customers are free to provide said source to anyone for free. In practice, letting your customers have the source means letting everyone have it.
  - tsimionescu 3y ago
    Not really, though: if you do so, you lose the right to continue doing business with IBM/RedHat, so you can only really do it once.
    - D7wEQ 3y ago
      I want to know what their DRM strategy is going to be. Are they just going to terminate the contracts of anyone who downloads the full sources?
    - ninkendo 3y ago
      Hmm, this seems counter to the notion of GPL, IMO. The GPL allows you to redistribute the source. I don't think it allows companies like RedHat to impose restrictions like "here's the source, but this is the end of the road: you can't take it any further than this"... it would surprise me if RedHat's terms weren't themselves a GPL violation, if what you're saying is true.
yjftsjthsd-h 3y ago
The thing is, AWS Linux has already moved to being based directly on Fedora. So it's probably not them specifically being targeted.
simiones 3y ago
> What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. This has made it more difficult for "repackagers" like CentOS, Rocky and Alma to keep their disros up to date. The situation is actually (c) - IBM RedHat is distributing the patches (and sources) as required by the GPL, but only to people who pay for their license. Re-distributing said patches or sources automatically invalidates your license, so if you exercise your GPL rights to re-distribute the GPL code you bought from IBM, you immediately lose both your support contract with them and any access to any future patches. This has meant that many companies and projects who were historically using CentOS for free have found that they either have to pay IBM to move to RHEL, or to switch to another distro. Projects like Rocky and Alma which were trying to replace CentOS are now on rather shaky grounds (though they are trying to find additional ways of surviving).
- op00to 3y ago
  The software is GPL, you do not pay for a license. You pay a subscription.
jzb 3y ago
Short version: Red Hat ceased distributing RHEL sources directly to git.centos.org in a way that easily enabled Rocky, Alma and others to rebuild "bug-for-bug" compatible clones to RHEL releases. Also, folks are realizing that Red Hat's subscription agreement allows it to terminate the subscription (and access to future source code) if someone redistributes code (including GPL'ed code) in a way that Red Hat doesn't like. People who misunderstand the GPL are accusing Red Hat of violating it by not widely distributing RHEL source to everyone. People who sort-of understand the GPL (or willfully misrepresent it) are accusing Red Hat of violating the GPL by "restricting" the ability to redistribute sources. IMO it is not, because customers have all their rights to the code they receive under the subscription prior to termination - they simply are blocked from later releases. Red Hat has basically acknowledged that it "sees no value" in a free RHEL clone, and is under no obligation to make it easy for clones to exist - so it's not going to anymore. It prefers you use Stream or pay for RHEL or do something else. I've been writing about this a lot on my blog, starting here: https://dissociatedpress.net/2023/06/24/red-hat-and-the-clone-wars/ https://dissociatedpress.net/2023/06/24/red-hat-and-the-clon... (Disclaimer: I'm a former employee of Red Hat, so I am potentially biased one way or another.)
dev_daftly 3y ago
You're understanding of what RHEL is seems to be off. Basically the current pipeline is Fedora->CentOS Stream->RHEL or CentOS Stream -> Fedora, RHEL. The downstream from redhat distros (centos, rocky, alma) were just recompiling the same packages as rhel and claiming 1:1 bug compatibility, which is a claim that might not even be true. They were able to do this because RHEL used to publish the packages that made up the distro to the public, but now they are only doing that for their customers. Everything that exists inside RHEL is available through centOS stream, the issue for the clones is that there also exists some changes that have not been added to RHEL yet. Ultimately, the issue is RedHat thinks people should be using centOS stream if they don't need enterprise support and a significant part of the community just want RHEL but free.
jjnoakes 3y ago
> My understanding is that Red Hat Enterprise Linux can be thought of as Fedora + stability + patches, and that the patches themselves should be released downstream as part of the GPL. > What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. My understanding is a bit different: Red Hat submits patches upstream and also back-ports those patches into existing RHEL releases that have long-term support. The upstream patches are still as open as ever, nothing has changed. The back-ports into existing RHEL releases are what Red Hat is trying to make harder for people to consume outside of a Red Hat subscription (the free developer subscription and the paid support contracts). I'm not making a judgement either way in this comment, just trying to help clarify my understanding.
- jt2190 3y ago
  > The back-ports into existing RHEL releases are what Red Hat is trying to make harder for people to consume outside of a Red Hat subscription That’s an interesting detail. Thanks!
teleforce 3y ago
I think the two main culprits for limiting RHEL sources are RHEL based cloud offerings including AWS Cloud for Compute and Rakuten Cloud for Telcos (Symphony)[1]. This is very similar case to the MongoDB situation when it finally decided to change the original open source license but instead Red Hat limits its source codes. [1]Has Rakuten made a Rocky-er road for Red Hat? https://www.mobileeurope.co.uk/has-rakuten-made-a-rocky-er-road-for-red-hat/ https://www.mobileeurope.co.uk/has-rakuten-made-a-rocky-er-r...
rewgs 3y ago
Piggybacking off your comment to add some additional questions; I'm in a similar boat as you. I've always been a user of the Debian and Arch worlds. The RHEL/Fedora/etc world has been this "other" part of Linux that I frankly haven't touched much, and haven't yet found a reason to. One thing I'm not totally clear on is what specifically Red Hat offers that people pay for, i.e. what are the details of the "+ stability + patches" of what GP mentioned. Are there paid applications as well? Is paid support a large part of the business model? And so on and so on. I'm still just a little mystified by the RHEL business model, and every time I hear someone talk about it, it's literally vague one-word answers such as "stability," "patches," "support," "enterprise stuff," etc. Even the RHEL FAQ offers essentially just that. I'm still not quite informed enough to be able to confidently lean one way or the other, but I have to say that I can't shake the feeling that RHEL's business model ultimately relies on exploiting their customers' desire to change their systems as little as possible, even if it means the customers eschew more modern systems that make obsolete the need for the kind of products and services RHEL provides. Or to put it another way, RHEL enables their customers to live with "the devil they know," and not adopt more modern best practices. Which isn't necessarily a bad thing, I get it, but also if that is indeed the case, it seems like a rickety foundation upon the already rickety foundation of trying to sell open source software that easily be unseated by, say, the nix model of doing things. I don't know, I could be dead wrong, but starting from what I've seen most other tech companies do and mixing it with a dash of "the idea of paying for Linux seems insane to me"...in lieu of better information, I can't dismiss the above out of hand.
- op00to 3y ago
  One benefit is if you pick a major version of RHEL or an LTS Ubuntu, you know that you’ll have 10+ years of consistent APIs and ABIs. If you stick to latest upstream distros, you can run into unexpected API incompatibilities causing bugs and breakage.
  - rewgs 3y ago
    Right, I get that, and I totally empathize with customers that would want that. But that's also part and parcel to the "devil you know" I mentioned. Like, in my experience -- which, sure, is absolutely not in a world that has ever touched RHEL, so once again I want to stress that I could definitely be talking out of my ass -- the safer place is actually to continually roll close to the cutting edge. Very, very generally, updates tend to play better with or expect that the software it's working with is also updated; and so, while yes it can be stable to stick with a particular version for 10+ years, the value of that stability drops as time goes on, as the software/OS in question has more and more trouble operating in the context of/with other/newer software, and so 5+ years into that 10+ year timespan, that stability you're supposedly paying for doesn't feel very stable at all -- and that doesn't even begin to touch what happens once those 10+ years run out and you need to get with the times. Which is all to say: this is why rolling releases exist. Better to get used to surfing the wave all the time, rather than sitting on the beach for years and then having to swim an Olympic race after you're out of shape. I'm mixing metaphors here but you get the idea. What's more, obviously riding the wave can be a little tiring, and thus more and more best practices are borne out of that problem -- which is why I mentioned nix in my last comment. I'm not even a nix user, have never done more than read about it, lest one think that I'm yet another nix zealot on HN, but I do think that it or something like it is a very very good solution to the pains that can be had by constantly staying up to date. I for one will always be more interested in that kind of route, rather than agreeing to the golden handcuffs of long-term support. While not in a RHEL-like setting, I've been bitten by the "I just want this old thing to keep going and never change" problem too many times before. Like, I was listening to the most recent episode of Linux Unplugged, and they had a member of the RHEL team on, and when asked about the value proposition of RHEL, he said something to the effect of that it's not just the software, but being able to offer the specific versions with the specific patches in particular combinations of other software with whatever patches. And I couldn't help but think -- isn't he basically just describing nix? Nix's whole thing is to super easily enable declaring specific versions of software in specific combinations, and to be able to recall it with a config file -- Matthew Croughan's talk at SCALE this year was essentially...that, and doing it super easily. And perhaps if we aren't keeping so much old software alive, it wouldn't all need so many patches to allow all the various combinations required. I don't know. It all seems like a very heavy-handed, people-y solution to a problem that we've mostly solved, and perhaps even eliminated the conditions for to exist in the first place. Anyways, this is all mostly hypothetical pontification, and I'm sure that those who actually work with RHEL on a daily basis could poke tons of holes in my point of view. Would love that actually, as like I said I feel very much like an outsider looking in. But it just seems like a goal that is fundamentally flawed.

by jt2190 3y ago

dcow 3y ago

Nothing in the GPL says sources must be available to anonymous unauthenticated users. RHEL just requires you to sign in to download the sources, which is making some maintainers grumpy. I don’t believe this is some grand scheme to make maintainers grumpy, they are just curmudgeons.

cesarb 3y ago
> RHEL just requires you to sign in to download the sources, which is making some maintainers grumpy. From what I've read, what's actually making people grumpy is that signing in to download the sources, and later giving these sources to anyone else, could risk losing your RHEL account.
- simiones 3y ago
  It's not that it could risk that, it's that it absolutely means you lose your RHEL account (and any other contract you had with IBM), at least if they find out about it.
  - jzb 3y ago
    I don't believe this is true. It's almost certainly not true for instances of distributing a limited set of sources. That is, I seriously doubt Red Hat or IBM are looking to cancel subscriptions if I download the latest package from RHEL 9.x for Bash or even the Linux kernel and distribute those sources quietly. If I download everything and advertise a rebuild based on those sources? I'd expect that my subscription will be going away soon. There's probably a line somewhere in between where Red Hat would take notice and care. But I would wager a good bottle of Scotch[1] that line is much closer to "everything" than a maintainer grabbing Red Hat's changes to their work via a sign-in to the no-cost account and incorporating those changes or something like that. [1] Say, Auchentoshan Three Wood or something good but not like 30-year-old Speyside. I'm not made of money...
    - tsimionescu 3y ago
      Per the RHEL subscription agreement, you lose your subscription if you do any of this. Of course, whether they will choose to act on the letter of the contract or not is up to them, but the letter is clear.
      - ComputerGuru 3y ago
        No, per the RHEL agreement they have the right to terminate your subscription "upon review" if you do any of this. It's a subtle difference but it's also worlds apart from "you will have your subscription terminated" (i.e. automatically, as a matter of fact/contract) in the court of law (and in terms of real world repercussions for anyone that isn't building a competing distro).
        3y ago

lproven 3y ago

What @dcow said. > the patches themselves should be released downstream as part of the GPL. The GPL only says you must provide the source to your customers. Not to anyone else. It does not compel you to offer them the world, gratis, no, not if you don't want.

ninkendo 3y ago
But your customers are free to provide said source to anyone for free. In practice, letting your customers have the source means letting everyone have it.
- tsimionescu 3y ago
  Not really, though: if you do so, you lose the right to continue doing business with IBM/RedHat, so you can only really do it once.
  - D7wEQ 3y ago
    I want to know what their DRM strategy is going to be. Are they just going to terminate the contracts of anyone who downloads the full sources?
  - ninkendo 3y ago
    Hmm, this seems counter to the notion of GPL, IMO. The GPL allows you to redistribute the source. I don't think it allows companies like RedHat to impose restrictions like "here's the source, but this is the end of the road: you can't take it any further than this"... it would surprise me if RedHat's terms weren't themselves a GPL violation, if what you're saying is true.

yjftsjthsd-h 3y ago

The thing is, AWS Linux has already moved to being based directly on Fedora. So it's probably not them specifically being targeted.

simiones 3y ago

> What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. This has made it more difficult for "repackagers" like CentOS, Rocky and Alma to keep their disros up to date. The situation is actually (c) - IBM RedHat is distributing the patches (and sources) as required by the GPL, but only to people who pay for their license. Re-distributing said patches or sources automatically invalidates your license, so if you exercise your GPL rights to re-distribute the GPL code you bought from IBM, you immediately lose both your support contract with them and any access to any future patches. This has meant that many companies and projects who were historically using CentOS for free have found that they either have to pay IBM to move to RHEL, or to switch to another distro. Projects like Rocky and Alma which were trying to replace CentOS are now on rather shaky grounds (though they are trying to find additional ways of surviving).

op00to 3y ago
The software is GPL, you do not pay for a license. You pay a subscription.

jzb 3y ago

Short version: Red Hat ceased distributing RHEL sources directly to git.centos.org in a way that easily enabled Rocky, Alma and others to rebuild "bug-for-bug" compatible clones to RHEL releases. Also, folks are realizing that Red Hat's subscription agreement allows it to terminate the subscription (and access to future source code) if someone redistributes code (including GPL'ed code) in a way that Red Hat doesn't like. People who misunderstand the GPL are accusing Red Hat of violating it by not widely distributing RHEL source to everyone. People who sort-of understand the GPL (or willfully misrepresent it) are accusing Red Hat of violating the GPL by "restricting" the ability to redistribute sources. IMO it is not, because customers have all their rights to the code they receive under the subscription prior to termination - they simply are blocked from later releases. Red Hat has basically acknowledged that it "sees no value" in a free RHEL clone, and is under no obligation to make it easy for clones to exist - so it's not going to anymore. It prefers you use Stream or pay for RHEL or do something else. I've been writing about this a lot on my blog, starting here: https://dissociatedpress.net/2023/06/24/red-hat-and-the-clone-wars/ https://dissociatedpress.net/2023/06/24/red-hat-and-the-clon... (Disclaimer: I'm a former employee of Red Hat, so I am potentially biased one way or another.)

dev_daftly 3y ago

You're understanding of what RHEL is seems to be off. Basically the current pipeline is Fedora->CentOS Stream->RHEL or CentOS Stream -> Fedora, RHEL. The downstream from redhat distros (centos, rocky, alma) were just recompiling the same packages as rhel and claiming 1:1 bug compatibility, which is a claim that might not even be true. They were able to do this because RHEL used to publish the packages that made up the distro to the public, but now they are only doing that for their customers. Everything that exists inside RHEL is available through centOS stream, the issue for the clones is that there also exists some changes that have not been added to RHEL yet. Ultimately, the issue is RedHat thinks people should be using centOS stream if they don't need enterprise support and a significant part of the community just want RHEL but free.

jjnoakes 3y ago

> My understanding is that Red Hat Enterprise Linux can be thought of as Fedora + stability + patches, and that the patches themselves should be released downstream as part of the GPL. > What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. My understanding is a bit different: Red Hat submits patches upstream and also back-ports those patches into existing RHEL releases that have long-term support. The upstream patches are still as open as ever, nothing has changed. The back-ports into existing RHEL releases are what Red Hat is trying to make harder for people to consume outside of a Red Hat subscription (the free developer subscription and the paid support contracts). I'm not making a judgement either way in this comment, just trying to help clarify my understanding.

jt2190 3y ago
> The back-ports into existing RHEL releases are what Red Hat is trying to make harder for people to consume outside of a Red Hat subscription That’s an interesting detail. Thanks!

teleforce 3y ago

I think the two main culprits for limiting RHEL sources are RHEL based cloud offerings including AWS Cloud for Compute and Rakuten Cloud for Telcos (Symphony)[1]. This is very similar case to the MongoDB situation when it finally decided to change the original open source license but instead Red Hat limits its source codes. [1]Has Rakuten made a Rocky-er road for Red Hat? https://www.mobileeurope.co.uk/has-rakuten-made-a-rocky-er-road-for-red-hat/ https://www.mobileeurope.co.uk/has-rakuten-made-a-rocky-er-r...

rewgs 3y ago

Piggybacking off your comment to add some additional questions; I'm in a similar boat as you. I've always been a user of the Debian and Arch worlds. The RHEL/Fedora/etc world has been this "other" part of Linux that I frankly haven't touched much, and haven't yet found a reason to. One thing I'm not totally clear on is what specifically Red Hat offers that people pay for, i.e. what are the details of the "+ stability + patches" of what GP mentioned. Are there paid applications as well? Is paid support a large part of the business model? And so on and so on. I'm still just a little mystified by the RHEL business model, and every time I hear someone talk about it, it's literally vague one-word answers such as "stability," "patches," "support," "enterprise stuff," etc. Even the RHEL FAQ offers essentially just that. I'm still not quite informed enough to be able to confidently lean one way or the other, but I have to say that I can't shake the feeling that RHEL's business model ultimately relies on exploiting their customers' desire to change their systems as little as possible, even if it means the customers eschew more modern systems that make obsolete the need for the kind of products and services RHEL provides. Or to put it another way, RHEL enables their customers to live with "the devil they know," and not adopt more modern best practices. Which isn't necessarily a bad thing, I get it, but also if that is indeed the case, it seems like a rickety foundation upon the already rickety foundation of trying to sell open source software that easily be unseated by, say, the nix model of doing things. I don't know, I could be dead wrong, but starting from what I've seen most other tech companies do and mixing it with a dash of "the idea of paying for Linux seems insane to me"...in lieu of better information, I can't dismiss the above out of hand.

op00to 3y ago
One benefit is if you pick a major version of RHEL or an LTS Ubuntu, you know that you’ll have 10+ years of consistent APIs and ABIs. If you stick to latest upstream distros, you can run into unexpected API incompatibilities causing bugs and breakage.
- rewgs 3y ago
  Right, I get that, and I totally empathize with customers that would want that. But that's also part and parcel to the "devil you know" I mentioned. Like, in my experience -- which, sure, is absolutely not in a world that has ever touched RHEL, so once again I want to stress that I could definitely be talking out of my ass -- the safer place is actually to continually roll close to the cutting edge. Very, very generally, updates tend to play better with or expect that the software it's working with is also updated; and so, while yes it can be stable to stick with a particular version for 10+ years, the value of that stability drops as time goes on, as the software/OS in question has more and more trouble operating in the context of/with other/newer software, and so 5+ years into that 10+ year timespan, that stability you're supposedly paying for doesn't feel very stable at all -- and that doesn't even begin to touch what happens once those 10+ years run out and you need to get with the times. Which is all to say: this is why rolling releases exist. Better to get used to surfing the wave all the time, rather than sitting on the beach for years and then having to swim an Olympic race after you're out of shape. I'm mixing metaphors here but you get the idea. What's more, obviously riding the wave can be a little tiring, and thus more and more best practices are borne out of that problem -- which is why I mentioned nix in my last comment. I'm not even a nix user, have never done more than read about it, lest one think that I'm yet another nix zealot on HN, but I do think that it or something like it is a very very good solution to the pains that can be had by constantly staying up to date. I for one will always be more interested in that kind of route, rather than agreeing to the golden handcuffs of long-term support. While not in a RHEL-like setting, I've been bitten by the "I just want this old thing to keep going and never change" problem too many times before. Like, I was listening to the most recent episode of Linux Unplugged, and they had a member of the RHEL team on, and when asked about the value proposition of RHEL, he said something to the effect of that it's not just the software, but being able to offer the specific versions with the specific patches in particular combinations of other software with whatever patches. And I couldn't help but think -- isn't he basically just describing nix? Nix's whole thing is to super easily enable declaring specific versions of software in specific combinations, and to be able to recall it with a config file -- Matthew Croughan's talk at SCALE this year was essentially...that, and doing it super easily. And perhaps if we aren't keeping so much old software alive, it wouldn't all need so many patches to allow all the various combinations required. I don't know. It all seems like a very heavy-handed, people-y solution to a problem that we've mostly solved, and perhaps even eliminated the conditions for to exist in the first place. Anyways, this is all mostly hypothetical pontification, and I'm sure that those who actually work with RHEL on a daily basis could poke tons of holes in my point of view. Would love that actually, as like I said I feel very much like an outsider looking in. But it just seems like a goal that is fundamentally flawed.