More than two years ago, Red Hat introduced CentOS Stream as the focal point for collaboration around Red Hat Enterprise Linux (RHEL). CentOS Stream shortens the feedback window between Red Hat engineers and partners, customers, and communities while at the same time providing even greater visibility into the next innovations in RHEL. We’ve seen great success in the Special Interest Group (SIG) community to help integrate and bring new technologies together faster than ever. The Automotive SIG is an excellent example of this. Hardware partners have also ramped up to use CentOS Stream for more rapid support of new hardware technologies. Because of CentOS Stream, Red Hat Enterprise Linux development is more transparent and open than ever before.
As the CentOS Stream community grows and the enterprise software world tackles new dynamics, we want to sharpen our focus on CentOS Stream as the backbone of enterprise Linux innovation. We are continuing our investment in and increasing our commitment to CentOS Stream. CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal.
This is peculiar, but not entirely unexpected. This change is going to have some serious effects for third party RHEL-compatible Linux distributions, such as Rocky Linux, Alma Linux, and so on. Alma Linux published a blog post about what this means for the future of the project, and the gist seems to be “we don’t really know yet”.
Doesn’t this violate the GPL?
nevermind
jgfenix,
The quote from AlmaLinux kind of makes it sound like it. However I couldn’t find any redhat sources that support their claims. Redhat’s post doesn’t quite say the same thing…
Like you said, it would be a GPL violation assuming GPL projects were being restricted. But again, I didn’t read anything in redhat’s announcement that suggests this is the case. I read this quote “CentOS Stream will now be the sole repository for public RHEL-related source code releases.” to mean a change in their internal publishing procedures rather than a restriction on the outside world, though it could use some clarification.
I’d like to know what AlmaLinux’s claims are based on. Maybe there’s something else in the “subscription agreement”? It will definitely be controversial if redistribution restrictions are somehow true, Is it possible they’re only talking about non-GPL redhat software? There seem to be more questions than answers.
CentOS is where all of the work for RHEL is done. It’s a few weeks ahead of RHEL, and for all intents and purposes, it is RHEL.
If someone wants to build a RHEL compatible distro, they now need to start from the CentOS SRPMs. That’s all it means.
I was already bought into CentOS, so I see the clones working within the CentOS project as a good thing.
There’s something in the user portal, from what I’ve heard. I don’t have any RHEL boxes, so I haven’t looked at the mechanisms to enforce the “no-clone” policy.
Their anger about having to work within the CentOS community and do work to build a distro. Their whole value proposition is “We’re a RHEL clone!”, so yeah, they’re a little miffed.
If their enhancements make their way into CentOS, I will be very happy. 🙂
Flatland_Spider,
It’s obvious why IBM/redhat don’t want there to be RHEL clones; they don’t pay. But for better or worse I think GPL implicitly makes clones permissible. If IBM tried to put in restrictions to stop it, those restrictions could conceivably run afoul of the GPL.
As Eugenia Loli has posted below, I wonder if IBM’s long term solution to this might be to increase the amount of code that is part of RHEL that is not GPL. This will increase the workload and incompatibility for direct clones, thereby attacking their viability and appeal. Although it makes me wonder how RHEL customers would feel about it.
I agree with all of this.
However, I don’t see how RH doing all of their RHEL work in the very public CentOS repos and asking asking people to collaborate and within the very public upstream project is a problem. Everyone collaborating and sharing is kind of the point of the GPL and definitely in the spirit of the FOSS movement.
It’s kind of backwards. Have people internalized the abuse by “open source” corporateware so much that they think that should be the norm for FOSS projects? Is this topic getting astroturfed by pro-proprietary people or Ubuntu-stans?
Take Android for instance. Google does not develop Android in the open and does code dumps when they feel like it. Google prohibiting GPL, outside of the kernel, and slowly removing features only get a little hate unlike RH getting more open with RHEL.
It’s possible. They haven’t shown any signs of turning away from the GPL though, and CentOS as upstream makes RHEL development even more transparent. RHEL development was kind of a black box before.
I don’t think RHEL customers would care considering who RHEL customers are. If the quality, stability, or support slips, they will care, but code license is far down the list of things they care about.
Something to consider in all of this… I’ve heard JBOSS profits dwarf RHEL profits for RH. RHEL is not the profit center for RH it once was.
It’s been a while since I’ve read the GPL, but it seems Red Hat is making use of a loophole that if they don’t provide binaries to someone (in this case public downloads), then they don’t have to make sources available as they never entered into the GPL agreement with random internet users. I don’t really see a lot in GPL V2 that would stop them from saying “no updates because you redistributed that last update.” While clearly against the spirit of the license, I don’t see exact wording against such a practice.
Maybe they’ll have to get permission from Torvalds on this distribution model under article 10, and then every other author of Linux, which would be hilarious.
It doesn’t matter if it’s either public or private, the GPL requires to make the source code available and you cannot restrict it’s redistribution. BSD and other licenses are another story.
The GPL requires you to make the source code available to the people paying for the binary you are providing, it doesn’t require you to release the code to the open world explicitly based upon my readings so mileage will vary here I guess. Red Hat is making the versions of the source code available to their paying customers without any restrictions on the source code itself. The restrictions they are placing are on the SPEC files that are used to build the binaries which means distros like Alma and Rocky cannot freely use the those SPEC files to easily rebuild for binary compatibility.
Not sure if this is a wise move by Red Hat, but I am guessing this is being pushed by IBM which is a shame.
I know. But a paying customer should be able to redistribute the source code however he wants. So a customer could give Alma Linux the souce code “acquired through the customer portal”.
Also the spec files are covered by the GPL. From version 2:
You need to look up the concept of legal standing. If you didn’t receive the code, you have no standing, and thus can’t sue in any dispute because you never entered into an agreement (in this case the GPL) and aren’t an affected party. The GPL doesn’t explicitly state any updates have to be made public to the world. (which would likely be unenforceable contract law as you’ve just tried to make the entire world a consenting party to the agreement.)
That’s not a loophole. The GPL doesn’t force you to share the modified source with anyone, only with those who obtain a copy (section 5.c of GPL3 and FAQ https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic).
dark2,
Parodper,
The “loophole” is not a loophole at all, it’s intended that service providers be able to use and change software without distributing it if they want to use GPL software internally. This is different that agpl, which covers services of providers who do not distribute software.
https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License
So for a company like netflix for example, they would be required to provide source code for any AGPL software they used to build their service, but they are not required to do so with GPL software. However in this case Redhat, they are very clearly redistributing GPL software to customers. And per the terms of the GPL, they are required to provide the source without additional restrictions and redhat knows this.
If they were to take retributive action against their own customers for redistributing the source of GPL software it does seem they would be in violation of the GPL license and redhat would loose the right to use the software. However I think a hypothetical court case could get extremely complicated over technicalities because the customer suing redhat might not have legal standing to enforce the GPL against redhat. A party that would have legal standing would be a GPL developer who’s code is being used by redhat in violation of the license, but this developer might not be a party to the retribution suit. So I’m not sure how this would pan out in court, So much depends on individual judges that I don’t make predictions for court cases.
We may be chasing phantom infringements though because I didn’t see anything in redhat’s post indicating that they intended to do any of this.
This seems to be correct.
They have to distribute the source code along with the binary. But they don’t have to make that source code publicly accessible. If I recall correctly, I think there was even be a clause in GPL to charge a reasonable fee for downloads / physical mailing, but I have never seen that used in practice.
If you are not their customer, you won’t have access to source code.
sukru,
After reading the GPL I believe that redhat are supposed to offer the source to literally anybody if they didn’t distribute the source with the binaries…
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
And GNU’s FAQ…
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#WhatDoesWrittenOfferValid
Alfman,
Isn’t this an OR statement?
As for the other one, it also seems to apply to a specific OR case again (using “provide source through a written offer” option).
(My main evidence would be FSF or any other source not publicly objecting to this behavior change).
sukru,
It is an OR case, but since they’re not doing A because they’re distributing the binaries and source separately, and they don’t qualify for C, so by the process of elimination that leaves B. And since redhat does/did distribute the source, they were generally complying with B, although the GPL does explicitly requires them to offer the source to everyone.
Since the source does not accompany the binaries, they don’t quite fit under A. But even if we wanted to say that they did, I still find this comment at least a bit misleading…
“If you are not their customer, you won’t have access to source code.”
Anyone who got the source explicitly with the binaries (as required by A) has the right under GPL to make it public. Moreover, if they make changes for distribution, as is their right, then they’ll not only have the right to distribute the source but also the obligation to do it.
IBM may not like it, but the GPL is designed to protect downstream access to source code in exactly situations like this. It’s the whole point of the GPL.
I don’t agree, the lack of a statement isn’t evidence. They might well speak about this in the future, but it just doesn’t seem warranted given that Redhat’s own post doesn’t really give any details to judge them by IMHO. For sure I am interested in how this plays out, but I feel a lot of the criticism remains hypothetical for now.
no GPL violations here…
Red Hat is making all the changes that it makes to GPL software available to the public via CentOS Stream. It is not as if they are taking their GPL derivatives closed source as some have claimed. Now, CentOS is upstream of Red Hat Enterprise Linux ( RHEL ) and so CentOS cannot claim to be “identical” to RHEL as AlmaLinux, Scientfiic Linux, Rocky Linux, and Oracle Linux have been doing.
Some people are saying Red Hat is violating the GPL because the CentOS sources are not identical to the sources used to create RHEL. But…
Red Hat only “distributes” RHEL to people that buy RHEL ( to RHEL customers ). RHEL customers have access to a portal that allows them to download the exact source and configuration used to create RHEL. So, no GPL violation from Red Hat anywhere.
Some people are claiming that Red Hat is violating the GPL because they are placing restrictions on their customers which violation the GPL. But…
It is true that Red Hat will not let customers redistribute RHEL. It is also true that RHEL customers cannot redistribute the source RPMS they get from Red Hat. These SRPMs contain more than just source code and not everything is GPL licensed. A pre-existing example is all the Red Hat trademark stuff like logos and such. Even before today, Rocky Linux could not produce a distribution with Red Hat’s name, logos, images, and copyrighted text in it for example. Previously, Red Hat actually provided tooling that made it easier to create SRPMS that did not include this stuff. My read on this latest announcement is that they are taking things like the spec file private as well. The spec file is required to actually produce an RPM from an SRPM. They could also keep the RPM headers private and probably many configuration files as well. Placing distribution restrictions on these things is not a GPL violation. Even if you have the SOURCES directories for RHEL, you cannot necessarily build RHEL. At least, you cannot without doing a lot of work. Also, you should not be able to get your hands on the real RHEL source unless you are a customer.
I do not really agree with what Red Hat is doing here but let’s not misrepresent what they are doing either. They are making it far less convenient for to create binary identical duplicates of RHEL. They are not committing any GPL violations.
tanishaj,
All code that is GPL though can be redistributed without restriction, though I agree it’s possible that RPMS may contain non GPL sources. Restricting trademarks in FOSS isn’t new. The best example I can think of is debian having to rename firefox to iceweasle because mozilla wouldn’t permit debian to modify firefox source while using their trademarks. This wasn’t a GPL dispute so much as a trademark dispute. This article explains it well.
https://www.pcworld.com/article/419749/iceweasel-will-be-renamed-firefox-as-relations-between-debian-and-mozilla-thaw.html
I think it’s a bit ambiguous whether this would violate the GPL or not. GNU themselves say this…
https://www.gnu.org/licenses/gpl-faq.en.html#InstInfo
So while redhat might claim their control scripts are not subject to GPL, GNU would probably claim that they are. If it ever came to a head in court, a judge would end up ruling one way or the other.
As mentioned above, this is debatable. Users do have the right to build working software under the GPL, but it’s not obvious to me how much the source and build scripts can be obfuscated and still remain compliant. It makes me wonder if anyone has ever tried to offer up obfuscated code to comply with GPL requirements?
As far as the GPL license is concerned, redhat is only obligated to distribute modified sources to redhat’s customers. But those customers would be free (under the GPL) to redistribute redhat’s modified code to the public even if redhat themselves won’t.
I think that last paragraph is the key one.
You raise interesting points but, even by an extreme reading of the GPL, Red Hat is fully complying if you look at what they provide to the parties that they DISTRIBUTE to. I do not think that anybody can credibly make the claim that Red Hat is directly violating the GPL.
The question is then what restrictions Red Hat can place on its customers with regards to redistribution of what they receive. You and I would agree that those customers can certainly redistribute any GPL code. We also agree that Red Hat customers cannot distribute logos and other copyrighted material that is not GPL licensed. At the very least, a customer would have to do a bit of work to extract out the distributable bits and it would be open to interpretation how “identical” to RHEL the result is. That is all Red Hat really wants.
Again, Red Hat is not only massively contributing to the ecosystem they leverage but also fully sharing everything not only with customer but even the rest of us via CentOS. All Red Hat is trying to stop is distributions that say “this is literally bug-for-bug an exact clone of RHEL without the logos and the registration hassle because we build it from the exact source RPMs that we get from Red Hat”.
I used to use Red Hat ( or CentOS ) as my go-to server system more than a decade ago but I have no direct horse in this race other than as a beneficiary of software they contribute and services run on their distribution. I use Podman quite a bit. That is about as close as I get to being a Red Hat user at this point.
Replying to my own comment. First, I want to echo what others have said in that we do not even know if Red Hat is trying to place any new restrictions on redistribution at all. All we know is they will not be directly distributing to the public themselves. Regardless, I agree with those that say this change is FOSS hostile, perhaps risky for them from a brand perception point of view, and perhaps pointless if the clones just work around it. My only point here is that aggressively painting Red Hat as a GPL violator is hyperbole at this point. They are certainly satisfying the terms of the GPL to their customers ( those they actually distribute to ). They have said nothing at all about redistribution and so nothing has changed on that front as far as we know. What GPL violation?
Makes me glad I went the Debian direction, as opposed to the Red Hat direction while learning Linux. Between this and modern Windows, avoiding corporate platforms looks like the smarter decision by the day.
kbd,
Redhat had a very FOSS friendly culture before IBM, but since IBM’s purchase of them redhat is more prone to butting heads with others. They took control over centos to make it less stable for enterprise environments. Now they may be making it harder for other redhat forks to exist. This is the way IBM rolls, they want to take out the competition.
IBM… But what happened to “Peace, Love, Linux”?
https://www.zdnet.com/article/ibm-gets-100000-fine-for-peace-love-and-linux-campaign/
Haha, I never heard that. Amusing 🙂
Yeah I didn’t believe it either. One day I saw someone mention it in an online discussion, and I just had to look it up and see if it actually happened.
Gavin Newsom. I remember this campaign but probably had no idea who he was at the time.
The culture is still there. “Hey, CentOS is the upstream of RHEL! We do all our work there, and it’s open to community contributions!” is very much a FOSS attitude.
RH took over a nearly dead project. People forget how the doomsday clock on CentOS was half a tick away from midnight before RH hired the project maintainers (all two of them) and provided resources. CentOS 6 almost didn’t happen, but CentOS is too valuable, from a marketing perspective, to let it die.
CentOS wasn’t a stable distro. It was very much YOLO on the part of most businesses.
It’s easier for RHEL forks to exist and contribute. Branch from upstream and work in the community. There isn’t any obfuscation of patches like there was previously in the RHEL sources.
Flatland_Spider,
You might follow it closer than I do, but I have a hard time believing it would have died, it was so popular and prominent particularly in hosting circles. The user base was there. IBM took centos away because RHEL clones obviously detract from RHEL itself.
I’m not trying to invalidate anyone else’s opinions about the merits of centos and centos stream, but being upstream of RHEL does make centos stream less desirable.for many enterprise hosting environments, which is exactly what IBM was aiming to do.
It was the last RHEL clone standing, barely standing. Like recently, there was a flurry of activity and lots of RHEL clones popping up when RHEL was originally announced, but they slowly died off. It was the OpenSSL situation except with a distro.
I was skeptical Alma, Rocky, or Navy were going to last more then a few years before this announcement. I’ve this play before, and courting the miser crowd isn’t profitable.
I’m all for more RHEL compatible distros, and I’m all for those distros adding new features and contributing their work upstream to CentOS. I would like to see Rocky become a full-fledged community distro in it’s own right rather then just being a RHEL clone. I would feel much more certain about it’s future if it had a mission of being RHEL compatible and a source of innovation in the enterprise Linux space.
It might have been popular, but that didn’t translate into people contributing anything to the project. Most people just wanted RHEL without having to pay for it.
There were a host of other problems moving CentOS upstream of RHEL solved for RH and the CentOS community.
One, it was hard to contribute to CentOS since it had to be bug-for-bug compatible with RHEL. CentOS wasn’t a very dynamic distro, and they couldn’t really change things because they were chained to whatever RH decided to do with RHEL.
Two, it was hard to contribute to RHEL because the disconnect between Fedora and RHEL was so large. RHEL will be a much more community based and less secretive project then it was.
Yeah, there are a lot of freeriders complaining about this because it’s much clearer they have to put in some work. The same problems existed before the change, but they weren’t acknowledged. The freeriders still get RHEL, but they get the upstream RHEL which I think is a fair trade off.
Flatland_Spider,
I cannot agree, or at least I do not understand what makes you say it. Releasing a bug for bug clone is so much easier, less costly, and more attainable than developing a distro into something original and different. Realistically many distros that do the later have more work and expenses with fewer resources than centos. A CentOS failure would have suited IBM just fine, but I would argue that IBM’s motives for taking control was not because because centos was failing, but rather because it was succeeding and taking away RHEL customers in the process.
To be fair though, centos had some significant industry and government contracts from fermilab to nasa, etc. After IBM repurposed centos as a staging distro, these customers migrated to almalinux and rocky linux, spiritual successors of centos.
https://www.theregister.com/2022/12/08/cern_fermilab_almalinux/
https://sam.gov/opp/2e0365ce1e3c4c179b50fb15573d68e4/view
Yes. These direct clone distros are trying to get “something for nothing”. I totally understand that and the moral judgement that comes along with it. However we should still agree that there’s a very large user base for these bug for bug RHEL clones. I’d even go so far as to suggest that when it comes to enterprise environments, they prefer distros that do not innovate. A distro putting in more work to change things would actually get shunned.
Exactly. I think the uncomfortable truth may be that GPL enables/justifies this sort of leeching.
I understand the merit in having a distro there. The community would have been happy with a new upstream distro to fill the gap you speak of.
However I think it’s fair to say this is not what centos’s core demographic wanted. They actually wanted a bug for bug clone and this was a huge part of centos’s success. All the appeal of RHEL without the high cost. No innovative surprises!
Decommissioning centos in favor of centos stream was done because it’s what IBM wanted rather than what centos’s enterprise users wanted.
I take it, Redhat and so IBM would lose a huge portion of their Free developer help in this process. I guess they weighed things out. Although I don’t agree with this decision, as I’ve witnessed financial institutions migrate from Redhat to Ubuntu since the upstream process of Centos took place. This may as well be the nail in their coffin of Redhat for many other corps to follow suit and to Microsoft’s happiness. CREAM (WuTang Clan) really is the case in this situation
It is possible they could lose some of their free developer help here, especially if they are judged overly harshly. That said, I do not imagine they got much “help” creating RHEL in the first place. Rather, they did all the work and then 3rd parties would piggy-back on that to make clones.
Where the “help” could have been in the past I suppose in supporting CentOS Stream. Ultimately anything done there contributes to RHEL down the line. It makes sense that, if RHEL were to become less popular, that CentOS Stream would find itself less popular as well. I am not totally sure what that dynamic looks like and who uses CentOS Stream instead of Rocky Linux or something totally different ( and why ).
Most of the “Free developer help” is likely in the sub-projects though. GNOME, Systemd, RPM, GCC, Podman, and other stuff are where the actual dev happens. They are probably totally ok doing the distribution part by themselves.
The part I’m worried more, is that Red Hat’s new code about Color profiles and HDR (that they said they’re working on) will be closed source or something. I see them going into the direction of developing things that will be closed source eventually.
It’s my understanding the work HDR and color profile work is happening directly in Gnome.
I can’t imagine desktop/workstation RHEL is a big enough profit center to justify the money spent on Gnome developers. 🙂 The conventional wisdom is to run Fedora if someone wants a desktop/workstation in the RH ecosystem.
Closed source is not really the RH culture, and being more transparent with the development of RHEL was the main reason CentOS was repositioned. RH is even less secretive about RHEL now.
It’s true culture can change. However, RH isn’t shying away from GPL software. It would be concerning if they were, but they aren’t.
Everything Red Hat develops is done in the open. For projects like GNOME, they do it directly in GNOME. Almost everything in RHEL appears in CentOS Stream first. The last controversy around the stuff you mention was Fedora saying they did not want to package LibreOffice anymore. Now, Red Hat are making it less convenient to make bug-for-bug clones of their flagship commercial product ( RHEL ). They are not doing anything else that I can see to participate less openly in Open Source overall. They are still one of the strongest and most open contributors. Regardless of what we think of this move, we should not lose site of this.