Red Hat just erected a paywall in front of the source code to their Linux distribution.Are they burning bridges to the wider open source ecosystem?Referenced...
An exceptionally well explained rant that I find myself in total agreement with.
Except they’re aren’t violating the GPL at all. Their source code is still available to subscribers (and it isn’t behind a paywall because you can get a free license) and available to the public via CentOS Stream. Their code also goes into upstream projects as well.
The GPL exists so that companies can’t just take the code and contribute nothing back. But that isn’t what Redhat is doing here so I find your accusations that Redhat is exploiting users to be very hyperbolic.
My understanding is that if you redistribute the source they provide (whether Paywalled or free dev account) that they can and plan to 1) revoke your payed support access or 2) revoke your free dev account.
That means that people are inevitably going to share out RH source from free dev accounts right off the bat, and just cycle through new dev accounts. That’s an escalating war where they watermark/fingerprint their source so they know who’s redistributing, and any model or distro built on this won’t last or carry considerable risk. Enterprise customers are unlikely to take this risk, though. So this sets up a pretty stupid game and generally goes against the spirit of FOSS if not the letter.
I’d like to address one statement you made above: CentOS Stream is NOT RHEL source. It’s effectively the beta branch. Which means it’s not bug-for-bug which is quite frankly critical to any dev, enterprise or otherwise, and the key reason they moved it upstream of RHEL - because it screws over what they consider to be freeloaders on purpose. They may be targeting other distros, but it affects all developers who just want to test their applications. Now that dev has to explore options for a dev account, be careful not to redistribute or lose that access, etc.
Jeff does an excellent job of explaining it and whether or not RHEL contributes to the kernel or other source, stating it the way you do is akin to giving them an excuse. Oracle contributes. Users contribute (by testing, submitting bugs, providing guidance and configuration templates or advice), Countless Devs contribute. All of that should not excuse IBM Red Hat’s behavior because they want to squeeze more profit out of a model that’s not setup well. The fact that their SNAP is essentially “trust me bro” now and with this move, I’m done with anything dependent upon RH. That may not mean much in my home lab setup with maybe a dozen boxes, but at work, I am in a position to influence thousands upon thousands of instances and I’m just one person paying attention to this. RH is focusing on short term profits over long term health and without disclosing anything, I’m confident will swiftly bite them in the ass. And it will be their own doing.
Which means it’s not bug-for-bug which is quite frankly critical to any dev, enterprise or otherwise…They may be targeting other distros, but it affects all developers who just want to test their applications.
With the free RHEL licenses, I don’t think developers targetting RHEL are going to be affected at all by this, short of having to signup for an extra account. I also don’t think that there’s going to be many situations where a dev would accidentally redistribute in a way that’s so detrimental to RedHat’s business that it gets their license suspended.
You’re right that its mainly targeted at downstream distros and that’s where I think RedHat has a point. I think that it’s entirely fair for RedHat to be annoyed that someone can build a RHEL bug-for-bug compatible Linux distro and then sell support licenses off of it, which is literally RHEL’s business model.
That’s just my two cents. There’s really not many ways for a company to survive entirely off of open-source development like RedHat does and if we start saying that bug-for-bug compatible versions of their software have to exist, then we’ve essentially turned their business model into donations and it would lead to them dying anyways.
Don’t get me wrong, I am not entirely happy about RedHat’s changes, but I also don’t see anyone in this thread suggesting a viable alternative for RedHat to pursue and they’re just piling on the hate. It’s like saying, “Hey RedHat, sorry you’re dying. Thanks for all your hard work, okay good luck, bye.”
The problem is that the value RHEL provides. For my PERSONAL projects the value is less than the cost of renewing my free license every year from them. For a company shipping a system that will in the field for a decade with minimal updates is completely that must work with minimal downtime the value they are providing is higher than what they charge.
That difference in value by users requires RedHat to balance costs the they can charge against maximizing numbers of users versus income. The catch they are running into is some people they provide little value to will just leave, but those people were providing a lot of value for customers. 100 or so ansible roles that your customers were using is suddenly no longer going to be supported, and eventually likely not to work. That is likely a net negative for value provided to customers and goes against the spirit of open source.
The people using Rocky or Alma are unlikely to see cost of RHEL being worth it. So they will go elsewhere. But having a bigger number of users running on those systems provided value and network effect for RedHat even though they are not paying. That indirect benefit is now lost.
RedHat obviously feels all of that does not provide enough value to justify the cost of possible lost sales. I think they are wrong, but maybe they are right.
Maybe they are violating the GPL which explicitly says you cannot add limitations for users sharing code. From here it sure looks questionable at best, intentionally breaking the license at worst. That will have to be left for someone else to decide.
Well, the alternative is competing based on what you are actually selling in this model: Support for this product. If I can clone your distro and do better at supporting it than YOU do or at least good enough to sell my support, then you have a situation of possibilities:
Your support sucks
You’re charging too much or don’t have the right market / price options available
Your support in general is not really necessary, and thus your business model is weak in the first place. Another way of saying this one is that you aren’t offering anying particularly unique for new features on top of what’s already freely available to sweeten the deal beyond selling support.
You’ve done other things to your customers to weaken your relationships, and thus income flow
Locking out those “second run” vendors who are riding your coat tails is going to be a self-defeating path, however you slice it. Oracle has deep pockets - they are unlikely to sit back on this one as an example problem. The bigger problem is violation of the spirit of the GPL which alienates devs. You’re correct that they may only be inconvenienced, but inconveniencing any developer is a first class ticket to them working around your shenanigans or just opting out of supporting your platform in general. I already know 2 vendors in my small world who are subtly indicating support for RHEL and CentOS is being considered with some pushes on their customers to consider other distros. That’s in the last few days!
Anyway, they are throwing out the good will they have left with the bathwater of trying to short circuit low-bar competitors because they want to squeeze profit. You may not be wrong to stand by them, but I’m taking my support (and business) elsewhere as a result of their stance. A recent post looks like they are doubling down on the message.
If that were accurate, then what Redhat is doing would be fine. The issue is that they’ve been requiring that their customers not exercise their rights under the GPL to copy or share the source code that Redhat is providing, with the threat of cutting off their support if they do. There’s an unsettled argument on whether that is actually a violation of the law that grants them the ability to sell someone else’s work in the first place, or merely a gross violation of the spirit that most of the people who authored the source code they’re selling would be 100% opposed to. But it’s at least one of those things.
The GPL exists so that companies can’t just take the code and contribute nothing back.
This isn’t accurate, though. The GPL says nothing about contributing anything back in terms of authoring improvements or making them available. What it says is, you can redistribute our work, or even sell it, but you need to make sure that people who receive it from you also have those rights.
I’m aware that Redhat is comparatively speaking, a huge contributor to the FOSS ecosystem. But, if the amount of code they’ve written is huge, the amount that people outside Redhat wrote that they’re selling is gargantuan. I would be very surprised if as much as 5% of the code they’re selling to their customers was anything they authored. If they want to sell the other 95+%, I think it’s fair to ask that they obey the licensing that allows them to.
The source code is still available via CentOS Stream though. Does the GPL cover having to give redistribution rights to the exact same code used to replicate a certain build of a product?
Does the GPL cover having to give redistribution rights to the exact same code used to replicate a certain build of a product?
It does, and very explicitly and intentionally. What it doesn’t say is that you have to make that source code available publically, just that you have to make it available to those you give or sell the binary to.
What Red Hat is doing is saying you have the full right to the code, and you have the right to redistribute the code. However, if you exercise that right, we’ll pull your license to our binaries and you lose access to code fixes.
That’s probably legal under the GPL, though smarter people than me are arguing it isn’t. However, if those writing GPLv2 had thought of this type of attack at the time, I suspect it wouldn’t be legal under the GPL.
I’m not asking them to make available the exact same code; nothing says they have to make RHEL available to anyone other than their customers. It’s conventional in the open source world to do so, but not required, and they’ve chosen not to because they have this business model of selling GPL software and making it difficult to obtain for free what they’re selling.
Trying to make a profit through that business model is fine. Having that as their business model doesn’t give them the right to violate the license though. They are threatening their customers if their customers exercise their right to redistribute RHEL (with the apparent goal of making RHEL, the exact product, difficult to obtain for anyone other than their customers – basically building on other people’s work for free, without honoring the terms of free redistribution under which those people made their work available to Redhat for free).
In GPL v2, the relevant text is in section 6:
You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.
Except that Redhat is trying to literally stop one of the four essential freedoms - the freedom to redistribute. Arguably they might actually be breaking the terms of the GPL.
I don’t think they are. You can distribute the corresponding source for your binaries. You just won’t get updates to the binaries (and their corresponding source) afterwards.
Not only will you not get updates (after they end your subscription), but you’ll probably lose access to the entirety of their packages before you can download all of them in the first place.
Whether or not they’re violating the letter of the GPL is entirely separate from whether they’re violating its intent. The former is debatable but the latter is absolutely happening here.
The people using RHEL aren’t using CentOS Stream, and they aren’t able to redistribute the actual software they are actively using. I don’t know how to state this any clearer.
Those snapshots are not CentOS Stream. You are not running CentOS Stream, in the state in which it is provided, when you run a RHEL release. They arent entirely separate, but that’s exaggerating the claim and not what I’m arguing. The people who are using RHEL as provided are not able to redistribute the thing which they are using.
Whether the GPL says the redistributed code has to be a bug-for-bug compatible copy of RHEL is up for lawyers to decide. In my mind, saying “I am not running Software Foobar, I am running Software Foobar released a few months ago” seems like a silly distinction in this case, especially when talking about the health of FOSS.
you still have the binaries (and are allowed to, they’re GPL)
you want the source code again… but can’t. Account is closed.
Now you’re in a situation where you’re entitled to receive the source code, but can’t because they won’t let you.
If this will ever go to court, I suspect RedHat will pursue a “corner case” solution. A canceled account will probably have access to the source code from RedHat *up to that very cancel-date" and you’ll not get a new binary (from them). So it should be mostly legal for them to do so.
However, as long as no trademark of RedHat is violated, distributing individual RHEL binaries (not the full images, they contain trademarked assets) should be fine. So you could receive a binary through that route and be entitled to the source code for it, starting the whole process over again.
Except they’re aren’t violating the GPL at all. Their source code is still available to subscribers (and it isn’t behind a paywall because you can get a free license) and available to the public via CentOS Stream. Their code also goes into upstream projects as well.
The GPL exists so that companies can’t just take the code and contribute nothing back. But that isn’t what Redhat is doing here so I find your accusations that Redhat is exploiting users to be very hyperbolic.
My understanding is that if you redistribute the source they provide (whether Paywalled or free dev account) that they can and plan to 1) revoke your payed support access or 2) revoke your free dev account.
That means that people are inevitably going to share out RH source from free dev accounts right off the bat, and just cycle through new dev accounts. That’s an escalating war where they watermark/fingerprint their source so they know who’s redistributing, and any model or distro built on this won’t last or carry considerable risk. Enterprise customers are unlikely to take this risk, though. So this sets up a pretty stupid game and generally goes against the spirit of FOSS if not the letter.
I’d like to address one statement you made above: CentOS Stream is NOT RHEL source. It’s effectively the beta branch. Which means it’s not bug-for-bug which is quite frankly critical to any dev, enterprise or otherwise, and the key reason they moved it upstream of RHEL - because it screws over what they consider to be freeloaders on purpose. They may be targeting other distros, but it affects all developers who just want to test their applications. Now that dev has to explore options for a dev account, be careful not to redistribute or lose that access, etc.
Jeff does an excellent job of explaining it and whether or not RHEL contributes to the kernel or other source, stating it the way you do is akin to giving them an excuse. Oracle contributes. Users contribute (by testing, submitting bugs, providing guidance and configuration templates or advice), Countless Devs contribute. All of that should not excuse IBM Red Hat’s behavior because they want to squeeze more profit out of a model that’s not setup well. The fact that their SNAP is essentially “trust me bro” now and with this move, I’m done with anything dependent upon RH. That may not mean much in my home lab setup with maybe a dozen boxes, but at work, I am in a position to influence thousands upon thousands of instances and I’m just one person paying attention to this. RH is focusing on short term profits over long term health and without disclosing anything, I’m confident will swiftly bite them in the ass. And it will be their own doing.
With the free RHEL licenses, I don’t think developers targetting RHEL are going to be affected at all by this, short of having to signup for an extra account. I also don’t think that there’s going to be many situations where a dev would accidentally redistribute in a way that’s so detrimental to RedHat’s business that it gets their license suspended.
You’re right that its mainly targeted at downstream distros and that’s where I think RedHat has a point. I think that it’s entirely fair for RedHat to be annoyed that someone can build a RHEL bug-for-bug compatible Linux distro and then sell support licenses off of it, which is literally RHEL’s business model.
That’s just my two cents. There’s really not many ways for a company to survive entirely off of open-source development like RedHat does and if we start saying that bug-for-bug compatible versions of their software have to exist, then we’ve essentially turned their business model into donations and it would lead to them dying anyways.
Don’t get me wrong, I am not entirely happy about RedHat’s changes, but I also don’t see anyone in this thread suggesting a viable alternative for RedHat to pursue and they’re just piling on the hate. It’s like saying, “Hey RedHat, sorry you’re dying. Thanks for all your hard work, okay good luck, bye.”
They weren’t dying before, but they be might now.
The problem is that the value RHEL provides. For my PERSONAL projects the value is less than the cost of renewing my free license every year from them. For a company shipping a system that will in the field for a decade with minimal updates is completely that must work with minimal downtime the value they are providing is higher than what they charge.
That difference in value by users requires RedHat to balance costs the they can charge against maximizing numbers of users versus income. The catch they are running into is some people they provide little value to will just leave, but those people were providing a lot of value for customers. 100 or so ansible roles that your customers were using is suddenly no longer going to be supported, and eventually likely not to work. That is likely a net negative for value provided to customers and goes against the spirit of open source.
The people using Rocky or Alma are unlikely to see cost of RHEL being worth it. So they will go elsewhere. But having a bigger number of users running on those systems provided value and network effect for RedHat even though they are not paying. That indirect benefit is now lost.
RedHat obviously feels all of that does not provide enough value to justify the cost of possible lost sales. I think they are wrong, but maybe they are right.
Maybe they are violating the GPL which explicitly says you cannot add limitations for users sharing code. From here it sure looks questionable at best, intentionally breaking the license at worst. That will have to be left for someone else to decide.
Well, the alternative is competing based on what you are actually selling in this model: Support for this product. If I can clone your distro and do better at supporting it than YOU do or at least good enough to sell my support, then you have a situation of possibilities:
Locking out those “second run” vendors who are riding your coat tails is going to be a self-defeating path, however you slice it. Oracle has deep pockets - they are unlikely to sit back on this one as an example problem. The bigger problem is violation of the spirit of the GPL which alienates devs. You’re correct that they may only be inconvenienced, but inconveniencing any developer is a first class ticket to them working around your shenanigans or just opting out of supporting your platform in general. I already know 2 vendors in my small world who are subtly indicating support for RHEL and CentOS is being considered with some pushes on their customers to consider other distros. That’s in the last few days!
Anyway, they are throwing out the good will they have left with the bathwater of trying to short circuit low-bar competitors because they want to squeeze profit. You may not be wrong to stand by them, but I’m taking my support (and business) elsewhere as a result of their stance. A recent post looks like they are doubling down on the message.
If that were accurate, then what Redhat is doing would be fine. The issue is that they’ve been requiring that their customers not exercise their rights under the GPL to copy or share the source code that Redhat is providing, with the threat of cutting off their support if they do. There’s an unsettled argument on whether that is actually a violation of the law that grants them the ability to sell someone else’s work in the first place, or merely a gross violation of the spirit that most of the people who authored the source code they’re selling would be 100% opposed to. But it’s at least one of those things.
This isn’t accurate, though. The GPL says nothing about contributing anything back in terms of authoring improvements or making them available. What it says is, you can redistribute our work, or even sell it, but you need to make sure that people who receive it from you also have those rights.
I’m aware that Redhat is comparatively speaking, a huge contributor to the FOSS ecosystem. But, if the amount of code they’ve written is huge, the amount that people outside Redhat wrote that they’re selling is gargantuan. I would be very surprised if as much as 5% of the code they’re selling to their customers was anything they authored. If they want to sell the other 95+%, I think it’s fair to ask that they obey the licensing that allows them to.
The source code is still available via CentOS Stream though. Does the GPL cover having to give redistribution rights to the exact same code used to replicate a certain build of a product?
It does, and very explicitly and intentionally. What it doesn’t say is that you have to make that source code available publically, just that you have to make it available to those you give or sell the binary to.
What Red Hat is doing is saying you have the full right to the code, and you have the right to redistribute the code. However, if you exercise that right, we’ll pull your license to our binaries and you lose access to code fixes.
That’s probably legal under the GPL, though smarter people than me are arguing it isn’t. However, if those writing GPLv2 had thought of this type of attack at the time, I suspect it wouldn’t be legal under the GPL.
I’m not asking them to make available the exact same code; nothing says they have to make RHEL available to anyone other than their customers. It’s conventional in the open source world to do so, but not required, and they’ve chosen not to because they have this business model of selling GPL software and making it difficult to obtain for free what they’re selling.
Trying to make a profit through that business model is fine. Having that as their business model doesn’t give them the right to violate the license though. They are threatening their customers if their customers exercise their right to redistribute RHEL (with the apparent goal of making RHEL, the exact product, difficult to obtain for anyone other than their customers – basically building on other people’s work for free, without honoring the terms of free redistribution under which those people made their work available to Redhat for free).
In GPL v2, the relevant text is in section 6:
Except that Redhat is trying to literally stop one of the four essential freedoms - the freedom to redistribute. Arguably they might actually be breaking the terms of the GPL.
I don’t think they are. You can distribute the corresponding source for your binaries. You just won’t get updates to the binaries (and their corresponding source) afterwards.
Not only will you not get updates (after they end your subscription), but you’ll probably lose access to the entirety of their packages before you can download all of them in the first place.
Well there is a clause about how long source code needs to be available for. I wonder what the actual interaction will be there.
Whether or not they’re violating the letter of the GPL is entirely separate from whether they’re violating its intent. The former is debatable but the latter is absolutely happening here.
What do you think the intent of the GPL is though? Genuinely curious, this isn’t meant as a retort or anything.
They are specifically and explicitly trying to limit your freedom with regards to redistribution by making it a violation of their EULA to do so.
But the code is also available in CentOS Stream, which is basically the “git master” of RHEL, and that you can freely redistribute.
The people using RHEL aren’t using CentOS Stream, and they aren’t able to redistribute the actual software they are actively using. I don’t know how to state this any clearer.
Your logic would apply if they were entirely separate pieces of software, but RHEL is just essentially snapshots of CentOS Stream.
Those snapshots are not CentOS Stream. You are not running CentOS Stream, in the state in which it is provided, when you run a RHEL release. They arent entirely separate, but that’s exaggerating the claim and not what I’m arguing. The people who are using RHEL as provided are not able to redistribute the thing which they are using.
Whether the GPL says the redistributed code has to be a bug-for-bug compatible copy of RHEL is up for lawyers to decide. In my mind, saying “I am not running Software Foobar, I am running Software Foobar released a few months ago” seems like a silly distinction in this case, especially when talking about the health of FOSS.
Scenario:
Now you’re in a situation where you’re entitled to receive the source code, but can’t because they won’t let you.
If this will ever go to court, I suspect RedHat will pursue a “corner case” solution. A canceled account will probably have access to the source code from RedHat *up to that very cancel-date" and you’ll not get a new binary (from them). So it should be mostly legal for them to do so.
However, as long as no trademark of RedHat is violated, distributing individual RHEL binaries (not the full images, they contain trademarked assets) should be fine. So you could receive a binary through that route and be entitled to the source code for it, starting the whole process over again.