Red Hat’s announcement last week caused quite a bit of a stir, so today, Red Hat published a blog post to defend itself.
We will always send our code upstream and abide by the open source licenses our products use, which includes the GPL. When I say we abide by the various open source licenses that apply to our code, I mean it. I was shocked and disappointed about how many people got so much wrong about open source software and the GPL in particular —especially, industry watchers and even veterans who I think should know better. The details — including open source licenses and rights — matter, and these are things Red Hat has helped to not only form but also preserve and evolve.
I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.
In the strictest sense, Red Hat has a point in that as long as the company abides by the various licenses covering the code they use, alter, and redistribute, there’s really nothing anyone else can really demand from them. Abiding by the licensing terms of open source code is the bedrock and foundation upon which the entire open source ecosystem is built, and suddenly demanding people do more is actually not fair – if you want to demand more from the downstream users of your code than, for instance, the GPL demands, then you should choose a different, stricter license.
That being said, the open source community is also, as the term implies, a community, and taking something you have been providing for decades away from a community merely for financial gain – which is ultimately what their reasoning comes down to – is never going to go down well. And since you’re building upon and are part of that same community, you’re biting the very hand that feeds you.
I understand Red Hat’s position, and as long as they abide by the licensing terms in question, I’m not going to be mad about it. However, it’s still shitty, and it still negatively affects a ton of people.
“taking something you have been providing for decades away from a community merely for financial gain”
I do not really agree with Red Hat but I do think they are being treated too harshly here. There is a another perspective to all this that I personally find compelling.
What Red Hat provided “for decades” was actually a system where they developed their flagship product pretty much behind closed doors and only shipped “the code” when it was done. CentOS used to be an example of what you were able to build at the end of this process ( downstream of RHEL ). Actually building it was a hassle. There was really no way to “contribute” to CentOS back then as it was, by definition, strictly a copy of what Red Hat shipped.
What Red Hat provides now is a system where they develop out in the open with changes appearing to “the community” even before they appear for Red Hat customers. CentOS Stream is now upstream of RHEL with most changes appearing in CentOS first. Red Hat also provide much better tooling to allow these sources to actually be used to build a product like RHEL.
If we are being balanced, I think it is fair to say that the overall development process for Red Hat is actually more open today than it used to be. In terms of being a viable enterprise operating system, CentOS Stream is arguably superior to the old CentOS. Unlike the old CentOS, CentOS Stream is something that the community can actively contribute to.
The one way that CentOS is now inferior to the past, and the challenge for Alma and Rocky is that they want to be “identical” to Red Hat. The only reason that being “identical” is valuable is that you want exactly RHEL without paying for it ( not something that competes with RHEL or meets the same needs but literally exactly RHEL ). In other words, the only reason to demand exactly RHEL is “merely for financial gain”. Criticizing Red Hat so severely for merely making this blind copying a bit more difficult seems a bit disingenuous if the motivations are at best symmetrical.
CentOS Stream is arguably a much better FOSS project than Rocky Linux is. What values are we fighting for?
tanishaj,
It sounds like an upstream distro does add value and you make tons of good points throughout your post. However I’d like to point out that “centos” did not need to be discontinued in order for an upstream “centos-stream”. type distro to exist. It’s like arguing which hand to chop off and which hand to keep, sure we could debate the pros and cons of one versus the other, but framing the distros as mutually exclusive was wrong to begin with. So with this in mind, I think we should stop using the merits of centos-stream as a justification for taking away centos. The logical reason centos was taken away was that it competed with RHEL and not because upstream was better for the centos user base.
Agreed
Yes, exactly. There is talk about a SIG adding btrfs into CentOS. Btrfs and in-place upgrades are two things I would like to see added to CentOS.
RH (Rawhide, Fedora, Fedora ELN, CentOS, RHEL) now has structures similar to the structures Debian (sid, testing, release) and Suse (OpenSuse Tumbleweed, OpenSuse LEAP, Suse SLES) already had.
Indeed. Alma smells like Oracle Linux, and the main sponsor of Rocky is a consulting company headed by the Rocky project leader.
I am not as cynical about Rocky. At least with Rocky, there is a foundation, and they are producing some different spins. They have an RPi image which is cool. If Rocky is serious about being a community EL distro, they should work upstream, and I hope they are serious.
I could go for a EL distro which takes a much more progressive attitude about desktops. The stable kernel and stable GNU coretools are nice, but the stale Gnome version and lack of btrfs is not.
Viability and longevity of FOSS is the banner I’m flying.
Really well made points. Oracle basically get their own distribution for free currently. As such, they can undercut Redhat on prices, knowing they can also fall back on Redhat Support. There is definitely financial gain to be had!
“What values are we fighting for?” We’re fighting for the GPL. The GPL doesn’t mention value of use, it only guarantees that you can have the same freedoms with the software as the person who gave it to you (or sold). The GPL also forbids adding barriers to exercising those freedoms. This is precisely what Red Hat is doing by cancelling the subscription of anyone who distributes the binaries. Who gave Red Hat the authority to block access to upstream developers works? Certainly not the upstream developers. Otherwise they wouldn’t have used the GPL. They provided that software to Red Hat with no strings attached. Why wouldn’t they expect the same of Red Hat?
There are actually a lot of reasons for needing a identical free option. One is for development. Even Red Hat has upstream projects using the clones for development of their own products. This is especially critical for containers where you simply cannot build a legal RHEL container with certain libraries due to licensing issues. Doesn’t Red Hat owe anything to the upstream community in exchange for the free software? Like allowing them to have a free unsupported version of RHEL? Its not like Red Hat is paying all upstream developers for the software they are selling.
It’s the source RPMs (SRPM) which are the problem. People can distribute the binaries all they want, but that would be a GPL violation since they couldn’t provide the source code.
The SRPMs allow Rocky, Alma, etc. to rebuild RHEL. The source code inside the RPM is GPL, and people are free to distribute the GPLed source code independent of the files needed to build the RPM itself.
Yes, and that is CentOS or the RHEL developer accounts with 16 licenses.
RH has the UBI for containers.
https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
The licensing was very liberal last time I looked.
Most of RH’s work is done in the upstream projects. They aren’t hording fixes. CentOS and RHEL are mostly backports of security and bug fixes from newer versions to their older version.
RH does, or funds, quite a bit or work in the Linux ecosystem. RH disappearing would be a big blow. Canonical isn’t going to do the same amount of work. Suse is pretty close.
Well, redhat does have a point, but then so too do the naysayers. GPL allows other distros to take RHEL software released under the GPL and redistribute it for a profit. It’s easy to see why IBM/redhat don’t like this, but it’s kind of disingenuous on their part to be critical of those using the GPL as intended.
Of course we can debate whether these rights should be allowed or not. But the fact of the matter is the GPL does not allow redhat to impose downstream restrictions. So if redhat really wants us to believe that people shouldn’t be allowed to repackage RHEL, that’s fine but frankly to that end they are using the wrong license for that.
The GPL isn’t as viral as people think it is. It only applies to the project itself. How the project is processed for packaging doesn’t come into scope of the GPL, and the GPL is perfectly fine with distribution of the code being difficult as long as the option is there.
It’s kind of like making sausages. Anyone can get cattle, pork, mutton, chicken, etc. (GPL code), and they can even get the tools easily (RPM, DEB). Even the ingredients have to be public (autoconf, make), but it’s the process of making the sausage ready for consumers which can be protected. Everyone kind of knows the process since there aren’t that many ways to make and package sausages, but sausage makers respect the other sausage makers and strive to have their own product.
I think people should work from the upstream and contribute to the community. That’s my entire platform, and I think it’s reasonable to levy that tax. People need to pick up a shovel and help dig rather then just taking from the commons.
This is a hard lesson for many, it’s not specific to RH. Making FOSS sustainable is a big topic, which I’m sure you know about.
Flatland_Spider,
The GPL intends for downstream users to not only have the source, but also be able to use it. It explicitly includes the configure and build scripts needed for compilation and installation. Obfuscation goes against the spirit of, if not the letter of, the license.
So if redhat were to make things difficult by withholding bits that are needed for compilation and installation, then I maintain that would be a GPL violation.
Yes, you’ve made this point many times and I agree that it is a reasonable point, but technically it’s not relevant in terms of the GPL. Redhat isn’t allowed to add new conditions/restrictions/requirements like that whether it’s fair or not. My point here isn’t to argue that direct clones should be allowed, because I honestly don’t know. Still the fact is they are allowed under the GPL, of this there is no question. So if people have a problem with clone projects, then by extension they have a problem with the GPL.
Yes, I do understand what you are saying. You make good points and I agree with you on sustainability. But for better or worse though it’s not part of the GPL and I don’t think switching licenses is practical so I don’t know where we go from here?
Edit: I meant to provide a citation for the short GPL quote contained in my post, so here it is…
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
RH’s RPM spec files aren’t part of the project, and “make install” doesn’t depend on the RPM tools.
If people want to keep having FOSS software, it’s relevant.
I also think the GPL should be harder left and close the capitalist loopholes, so there’s that. If people want to get mad, they can start working on a Communist Public License, maybe GPLv6t++ Limited Edition Lime Green.
The clones are allowed, provided the license on the SRPM spec files allows it, and it’s because RH has to publish the source code. However, the clones need to figure out a better plan to ensure their viability. “Clone RHEL” is not a long term strategy.
Maybe rebase on Suse SLES.
Or Ubuntu. People would like an un-Canonicaled Ubuntu.
As an aside…
GPLv2: “You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.”
Reading this, it sounds like RH could charge per download of the individual SRPMs.
My tact is outlining how people have to pay for “free” software, and point out that upstream projects don’t offer contracts and risk mitigations requires them to self-insure the software that’s in use if they aren’t willing to get a support contract.
Weaponized SOC2!
Also pointing out the GPL is pretty milquetoast, and trying to build consensus that there needs to be harder left licenses.
Flatland_Spider,
These kinds of manifest files that instruct the build environment how to compile/run/install executables are typically included with source in environments that are sophisticated enough to support them, like visual studio sln files or android AndroidManifest.xml, etc. So personally I feel spec files are also covered by the GPL if not by name, then by function. My own distro uses a similar concept and I consider these to be extensions of the original work because logically they are. Anyway, at a minimum I feel there is room for debate.
We don’t get to overrule what a licenses says though, even if we think it’s detrimental to FOSS.
There are more forks than anybody can keep track of. If Canonical were to charge for ubuntu, I imagine someone would come up with a bug for bug clone of it.
Agreed that would be permissible under the GPL.
Yes, I agree those who aren’t paying for RHEL don’t deserve any support benefits. However the “problem” is that many users don’t actually want RHEL support at the prices they’re asking.
There are more licenses than I have time to read, would any of them cover your ideals?
That doesn’t matter! The GPLv3.0 states in section 5c:
Since the SPEC files are part of the “work”, then the SPEC files are also covered under the GPLv3.0. This part is fairly straight forward, and RedHat/IBM are not arguing otherwise.
It was stated earlier that the GPL is not as viral as people think. It seems that is indeed the case.
The GPL does not expand out infinitely to whatever boundary you want to define for “the work”. If SONY themselves offered a GPL Playstation 4 emulator that required a binary blob of the BIOS, they would not be forced to license the BIOS under the GPL because it was magically part of “the work”. The emulator could be GPL with the blob remaining fully proprietary. What have all these years of arguing about the licenses around firmware blobs and documentation and the like been about in projects like Debian? According to this thread, all those things automatically became GPL the moment you added them to Debian. Do people really think that?
I guess we should all be using OpenZFS as well. No need to worry about the license. It must be automatically GPL licensed if you can ship it alongside the Linux kernel in a Linux distro. I mean, it would be part of “the work” right?
Forgetting for the moment about patents and contracts and other areas of law outside of copyrights that can absolutely place further constraints regardless of the language in a software license. Even sticking to just to licensing it is clear that the GPL is not as viral and all powerful as people are claiming it to be. If you do not have to GPL license any of the examples I cited above when shipping alongside GPL licensed software, why does the GPL wield such absolute power over the SPEC files or other potentially proprietary Red Had assets that go into RHEL?
I got a Windows NT CD from Microsoft in the 90’s that had a copy of GCC on it. Shouldn’t they have been forced to give me the source code to Windows NT since it was part of “the work”?
People should be happy that things do not work the way they think they do as it could go both ways. If the GPL could magically override all other rights that a company has over the work it produces, they could just as easily incorporate GPL software into their stuff and claim that the GPL was overridden by their own proprietary licenses because of incorporation into “the work”.
“The work” is an individual body of code like GCC. That is what is GPL licensed. You can ship Clang alongside it and it can be BSD licensed. You can ship DotNet and it will be Apache 2.0. A “distribution” is a collection of a bunch of stuff that is independently and individually licensed.
The GPL says that, if you distribute GPL software you have to be prepared to make the source code available. Red Hat distributes GPL software to its customers. Red Hat makes the source code available to its customers. Red Hat licenses this software to their customer using the exact same GPL license that was offered to Red Hat. No problem so far. Red Hat also provides stuff that is not GPL licensed. Red Hat also enters into contractual arrangements with their customers unrelated to software licensing. What am I missing?
THANK YOU. If RedHat wants to act like they are using a more permissive license, they need to release under a BSD or similar license. And I say this as someone who is more in favor of permissive licensing in general than the GPL; while I feel the open source world wouldn’t be where it is without the GPL, it’s not best license for every situation, as this whole debacle clearly shows.
@RedHat: You should either re-license, or else stop trying to invalidate the GPL by strongly and incorrectly implying that other projects can’t profit from your GPL licensed code. You can’t have it both ways.
I think this is what I genuinely don’t understand. And please do correct me if i’m wrong, as I’d like to learn.
My understanding;
Redhat Do release the source (and will continue to do so) under the CentOS brand instead of the Redhat one.
CentOS is owned by Redhat (which is in turn owned by IBM)
So Redhat are still releasing all the code for RHEL 10 under that umbrella.
CentOS will then diverge from it, and thats fine, but RHEL source from the release will still be there, still be available just like they have with 8 + 9 here
https://gitlab.com/redhat/centos-stream/src
My understanding is that RedHat is restricting the distribution of source code for binaries obtained via subscription only, even though those binaries are built from GPL licensed code, which is in violation of the GPL. The sticking point is that the binaries are distributed period, it doesn’t matter if you have to pay for them, the GPL requires the code to be freely available and openly published. They want to eat their cake and have it too, and that’s not how the GPL works. This would be fine if they were using a more permissive license that allows an entity to release (or not) their code and binaries as they see fit. That is why so many corporations prefer BSD and similar licenses instead of the GPL.
In short, RedHat wants to build off of GPL’ed software and keep their modifications proprietary and behind a paywall. That’s not how the GPL was designed to work, and they are trying to weasel-word their way around it which is bullshit.
And again, I say this as someone who is not normally a staunch defender of the GPL, but in this case I make an exception because it’s a direct slap in the face to the wider Linux community.
I didn’t have time in the edit window to add this to my post, but this is what gnu.org has to say about it:
So, by distributing binaries built from GPL licensed source code, RedHat MUST make said code publicly available or they are in violation of the license.
That’s where your misunderstanding is. RedHat is not releasing these binaries publicly, so they do not have to release the source publicly.
They are releasing the binaries only to their customers, which is completely permissible by the GPL. As such, they are releasing source code only to their customers, which is completely permissible by the GPL.
The GPL only requires you to make source available to those you distribute binaries to.
@Drumhellar:
I think the definitions of “public” and “release” are what is really in contention here. RedHat’s customers are not RedHat employees, so they are not covered by the part of the GPL that says an organization can keep any modifications internal without having to release the code. The GPL only distinguishes “released” and “not released”. Therefore, by releasing the binaries and source code to their own customers, isn’t that considered a release, period?
And beyond that, they are enforcing restrictions on what their own customers do with the source code and binaries that are provided, which is also in violation of the GPL. Once you give your source code out, you don’t get to tell people what they can do with it, else you’re violating the license. That is something RedHat is doing by threatening their customers with cancelling their subscriptions if they share the code or the binaries. RedHat simply doesn’t have the right to do that under the GPL, so in my opinion they need to either release under a more permissive license or backpedal all this nonsense.
Drumhellar,
They’re allowed to distribute to just their own customers under section 3 a of the GPL, however this section applies when the source is distributed along with the binaries. Under section 3 b, they don’t have to be distributed together, but the GPL explicitly requires them to “give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code,”
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Regardless of who redhat sends the source to, they’re still not allowed to add downstream restrictions. I don’t really think it’s fair to pass judge on redhat over something they haven’t yet done, but depending on how things actually play out there could be a legitimate problem for GPL rights.
The GPL says nothing about “the public”. It is not a manifesto. It is a license. It talks about recipients.
Has anybody here actually read the GPL? Let me quote to you a line directly from GPL 3. Please explain your position on Red Hat and RHEL in the context of the following language from the GPL:
“Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.”
Red Hat uses GPL software. They distribute that GPL software. They make the source to that software available to “the recipients”. It makes that software available via the GPL. They are an absolute adherent to the requirements of the GPL. Can we all please pause and acknowledge that?
What Red Hat does not want to do is to allow the entirety of “exactly” RHEL to be distributed. Doing so is a breach of contract. They do allow you to distribute a full enterprise grade Linux distribution that contains all their code. That distribution is CentOS Stream ( which may or may not be bug for bug “identical” to RHEL ). That “may not be” part is what has Rocky and Alma so worked up. That is all they are taking away though. Some nitwit YouTuber posted that “Red Hat is proprietary garbage”. For the love of God….
Read this line again:
“Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.”
Each piece of GPL software used in RHEL is a “covered work”. Red Hat makes each and every one of these “works” available under the GPL. RHEL itself is “an aggregate” ( using the language of the GPL ). Red Hat does not make RHEL itself available via the GPL and, as very clearly stated in the GPL itself, they do not have to.
Red Hat authors A LOT of GPL software and gives it all away for free under the GPL. They develop and share a lot more software than the vast majority of the people now calling for their heads. I was not a supporter of what Red Hat was doing initially but honestly the “community” reaction has pushed me deeper into their camp. Red Hat has done nothing unethical or illegal no matter how many “have not read the GPL” reactionaries say they have. Red Hat does a lot more for me, the software I used, and my freedom than this “community” has or will as far as I can tell.
At first, it was my concern that Red Hat was going to alienate the community but with friends like these, who needs enemies?
I side with Red Hat.
Jeesh.
@tanishaj:
The authors of the GPL disagree:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic
Red Hat is actively distributing binaries from GPL’d code without providing access to that source unless you pay them for a support subscription. That’s about as big of a GPL violation as you can get. There’s not much to debate here.
That may not sound “fair” in terms of exploitation of GPL code, but just saying, IBM has been exploiting GPL’d code for decades and has profited greatly from it. In fact, I’d say the “freeloading” done by IBM is greater than all CentOS (of old, for example) user combined. That’s how much IBM makes from GPL’s software.
And guess what? That’s ok. That’s what free sofware and the GPL is about. Making sure that source code is available. And allow people to directly benefit from that. Not holding source code for ransom or saying you must purchase a support subscription to get at it. That’s not free software anymore. That’s no different than the millions of lines of closed source IP that IBM has.
Red Hat needs to go back to FOSS. If anyone working for Red Hat would please stand up for FOSS, that would be greatly appreciated.
Btw, Red Hat, who makes a heaping ton of money, can make money. The idea of a “support subscription” is indeed outside of the GPL and perfectly fine. But any and all modifications to GPL software made by Red Hat must be made available. It’s the very definition of the GPL. And by “available”, not by tacking on the extra requirement of a “support subscription” (this is where they made their mistake).
You can turn this any way you want to try to show that Red Hat somehow deserves to violate the GPL, but sorry, they cannot.
Its perfectly fine for Red Hat to only offer the source code to customers. This is clearly established. The problem is that they are restricting what customers can then do with that source code. BTW, IBM has a division called “Global Services” which was using CentOS up until the point that Red Hat killed it. I am not sure what they are using now.
Open access to source code is a convention famously championed by the OpenBSD project. Open access wasn’t always the case, and still isn’t in some companies.
The GPL is a capitalist license, and this is 100% in the spirit of the license as well as the letter. I have worked for companies which have done this, and it is perfectly legal. That company made it harder to obtain the source code then RH is, but still perfectly legal as far as the GPL is concerned.
The GPL doesn’t live up to it’s hype. A lot of FUD has been spread about the GPL, and people believe it. People on both sides believe the FUD. The GPL is very lukewarm in the grand scheme of things. It could be a lot more vicious, but Stallman is a capitalist.
They do make the source code available though. CentOS upstream and via the subscription portal, so two ways!
The GPL doesn’t define what mechanisms meet the “available” criteria. Is available a git repo, tarballs on a website, having to send a postcard and having the tapes delivered by camel? As long as a person can make a request and receive the GPL source code at some point then the license is fulfilled.
Yeah, it’s a crappy loophole and one that’s there on purpose.
It really doesn’t matter what they do with CentOS Stream. They cannot restrict what their users do with the source code they obtain under the GPL. Its very clear. Cancelling their subscription if they distribute the source is a further restriction. And the source for stream is NOT the source for RHEL. Otherwise they would be binary compatible and we wouldn’t be having this argument.
Learn how the reply button works.
Distributing the SRPMs. There are more files in the SRPM then just the source code.
Is there evidence for this? This would be an interesting study.
Evidence which takes into account how, to my knowledge, the build systems don’t produce reproducible artifacts and CentOS is a little bit ahead of RHEL.
> Cancelling their subscription if they distribute the source is a further restriction.
That’s not a restriction. That’s a consequence.
It’s not only another restriction, it’s in direct violation (again) of the GPL. They are giving their customers access to GPL licensed code, then trying to restrict what the person does with the code, which is one violation, then if the customer distributes the code anyway, RedHat cuts off the customer’s access to the code, which is the definition of restriction. This is also a GPL violation.
RedHat should either re-license, or they should stop this nonsense altogether.
Parodper,
Logically if the policy is to terminate those who redistribute, then it’s both, the question is whether it’s allowed.. Forget about GPL for a moment and really consider the consequences to licensing contracts here.
Take any FOSS or even proprietary license, now setup a power dynamic where one entity is willing and able to punish those for performing actions that are expressly allowed by a contract. If retaliation is allowed to stand, then it would largely nullify any and all rights that consumers are granted under a license contract.
> Red Hat is actively distributing binaries from GPL’d code without providing access to that source unless you pay them for a support subscription. That’s about as big of a GPL violation as you can get.
They don’t distribute the binaries without a license, so no, they are not violating the GPL.
> There’s not much to debate here.
True. The only debate is from people who don’t know how the GPL works.
“Red Hat is actively distributing binaries from GPL’d code without providing access to that source unless you pay them for a support subscription. That’s about as big of a GPL violation as you can get. There’s not much to debate here.”
There is lots to debate in what you say here because it is absolutely, totally wrong. Red Hat are distributing the binaries to their subscribers ( many of whom get it for free ). They share the full source to those that they distribute it to. They are not adding any additional licensing constraints to GPL “works” that they distribute. They meet 100% of their obligations under the GPL.
First, the code they modify is available to the whole world in CentOS Stream. So all their code is actually available to everyone without a subscription of any kind ( even the stuff that is not GPL ). I do not see any mention of that in your description.
Second, the exact point in time collection of packages that makes up RHEL is available to RHEL subscribers, including full source code, whether they are paying or not. All the GPL “works” in RHEL are licensed to its recipients via an unmodified GPL ( license ) that includes no additional constraints. RHEL itself being an “aggregate’ ( using the language of the GPL ) is not, in its entirety, licensed under the GPL. Red Hat subscribers are contractually obligated not to share the SRPMS.
I said this elsewhere but to counter your statement “That’s about as big of a GPL violation as you can get. There’s not much to debate here.”, please consult the following line from the GPL itself:
“Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.”
I would agree that there is “not much to debate here” if you were reaching a different conclusion. Somehow, there seems to be much to debate after all.
tanishaj,
I’m not privy to RHEL contracts, so I cannot verify this is accurate. But assuming this statement is true and redhat are contractually prohibiting subscribers from distributing SRPMS of GPL projects, then I would argue that they are violating the GPL by placing restrictions on derivative works.
Other FOSS licenses may permit such restrictions, but GPL does not.
I genuinely don’t see the issue here. The red hat brand only distributes the source code to its paid users and the licence there means they can’t redistribute that source from that point. In isolation, I can see how this would impact “downstream” distros. However, Red hat also have the CentOS brand, which at points in time IS RHEL. Completely the same code compatibility. So if you want the red hat source, download it from CentOS. Done. You still have the source code that’s 100% compatible with RHEL. The only thing you “lose” is being able to claim brand compatibility with Red Hat name.
So IBM (as the parent of all of this) are distributing the code for every release, as before, just branded differently.
Yeah, the only issue is that there are people who think they know the GPL and copyright law better than IBM’s lawyers.
Trust me, you can’t trust corporations on such a topic 😉
You say: “The red hat brand only distributes the source code to its paid users and the licence there means they can’t redistribute that source from that point.”
I take it that “the licence there” is the GPL, right? And the GPL says they are always allowed to redistribute the source code. If it is not the GPL but some other license, then it is obviously a restriction that is forbidden by the GPL. Then “red hat” as a consequence can no longer distribute GPL-ed software themselves.
You cannot place a “licensing restriction” on covered “works” ( the GPL stuff ) and Red Hat does not. The GPL works are still “GPL licensed”.
Red Hat places restrictions on the “aggregate” which the GPL allows. Also, the restrictions that everybody is getting bent out of shape about are contractual terms and nothing to do with the copyright license anyway.
You can subscribe to Red Hat, you can download the GPL sources for RHEL and you can distribute them. You can provide full GPL rights to everybody you distribute it to. Red Hat cannot and will not pursue you for license violations because you have not violated the terms of the GPL. However, Red Hat may cancel your subscription. I suppose they could even pursue you for financial damages for any “harm” done by your “breach of contract” as that has nothing to do with the software license. Finally, if you distribute all of RHEL, you may in fact be in violation of their copyrights as well. Not all of RHEL is GPL licensed. Certainly their logos and trademarks are not. Other things they author may or may not be GPL licensed as well, like the SPEC files others have mentioned. I mean they could author a man page and copyright that fully and sue you for unlawful distribution if you include it in any re-distribution of RHEL. What would that have to do with the GPL?
I think the interesting thing here is the comments by Red hat that the economic back pinning of Open source that made them a billion dollar company is not working well. The bough centos which was the biggest redistributor because they thought there was value in having that, now they are essentially saying they saw no benefit to RHEL from Centos. They made a mistake, so they are now trying a controversial interpretation of the GPL to protect RHEL as a profit source. I mean I get that someone has to pay the bills and historically Red hat has bankrolled a lot of Open source development. Its parent IBM is largely responsible for it not simply being a hobbyist OS but a serious for business operating system.
Regardless of the GPL question raised by their actions, I don’t know the just and equitable solution for opensource funding.
Bill Shooter of Bul,
Yes this is the conundrum as I see it as well.
I don’t think it was a mistake, even in hindsight. IBM wanted to put a stop to bug for bug clones of RHEL and centos was the most prominent. They succeeding in shutting down the original centos by taking it over, but new distros spouted up to take its place. I don’t think IBM/redhat’s intentions have changed at all. their actions today are a continuation of their desire to stamp out RHEL clones using new tactics.
Yeah, these are real tough questions for FOSS for which I have no good answers. Stepping into IBM/redhat shoes, I wouldn’t want to compete with clones of my own product either. But even with that said I feel they are contorting the GPL in ways that are highly unnatural and contradictory to the essence of the license. It seems to me that IBM disagrees with the license internally, but don’t have a good way to cope given that almost all of RHEL’s assets are knotted to the GPL
Neither do I. While redhat captures the headlines, the exact same questions crop up for developers of all sizes including those with far fewer resources and more pressing existential threats than redhat. FOSS adds immense social value, but finding ways to fund it has always been difficult. For me this uncertainty has gone on for decades and I don’t feel closer to an answer.
So woke people canceled Stallman but still rely heavily on GPL. To preserve their freedom. At least some of them. How about instead of canceling giving some credit when the credit is due? Historically speaking we have seen what commercial grade operating systems we get when proprietary license is used, when BSD license is used and when GPL license is used. I feel it’s safe to say that only GPL licensed one is preserving end users freedoms. The rest of them don’t come close.
Agreed.
And like Morgan said, one of their options is to use a different license. They could just become a BSD distributor, and do what they want to do here. Of course, that’s not a viable course of action for them. I think they will bleed users and mindshare for a number of years, and then… relent? Or not.
I particularly enjoyed their cries that they would “refuse to use everything RMS has ever touched”, with some of them even pledging to move out of the GNU coreutils altogether and migrate to FreeBSD. Of course, none of that happened, those people need the GNU toolchain to power their Tinder For Cats or Uber for Tuk Tuks app and actually moving to FreeBSD is too much work for the average Silicon Valley startup bro.
Don’t get me wrong, Richard Stallman’s behaviour around the campus has been highly questionable, and so are some of his opinions, but the effort to turn him into an “unperson” so they can wave his scalp around (in the typical woke fashion) was ridiculous from the start. As you say, there is something called “giving credit where credit is due”, which means RMS is the lead of some very important projects (despite his personal failing), and no amount of crybullying can change that. But good luck explaining that to the average woke.
Also, nobody forces any of those wokes to be friends with RMS. But again, good luck explaining that to the average woke. Woke people see everyone as either a friend that always agrees with them or a sworn enemy.
* despite his personal failing = despite his personal failings
Red Hat does not lack the resources to replace the GNU toolchain. Let’s be honest, it is not even that hard.
You can use Clang instead of GCC. You can use Musl instead of Glibc. You can use the FreeBSD userland instead of GNU CoreUtils. Oh look, I just described Chimera Linux. I bet it runs Tinder for Cats or Uber for Tuk Tuks just fine. Red Hat 11 could easily make these changes without breaking any of its brand promises to customers. Honestly, they have the scale to replace all of these things from scratch if they wanted. If they did, they would probably GPL license them though because that is what they have always done. Trying to paint them as freeloaders is ridiculous.
Much of what makes Linux different than something like FreeBSD was created by Red Hat and given to the rest of us ( eg. systemd ). The kernel itself would be the hardest thing to move away from but Red Hat is one of the largest contributors to that as well.
You can be a fan of RMS but I am not sure what it has to do with anything being discussed here. He was certainly involved in writing GPL 3 though which fully supports what Red Hat is doing here.
BTW, I still haven’t 100% understood what exactly RedHat did to prevent “rebuilding”, there is so much ideological infighting between the two sides that the actual technical details are rarely discussed. I mean, can’t you just write a letter to RedHat and demand a link to the source code? I wish there was a thorough write-up on the whole saga.
kurkosdr,
I agree, I feel that a lot of this has been hypothetical. That is fine for discussion, but I haven’t seen any actual accounts of people being denied their GPL rights. It could happen, but there’s a big difference between criticizing redhat over hypothetical complaints versus actual GPL violations. I’ve statement my position that GPL gives clones a right to exist. I don’t technically have a gripe against anything redhat has done so far. It’s only if they start taking retribution against downstream redistributors, thereby making the hypothetical complaints real, then that changes things.
Well, if you are just talking about software capabilities, everything in RHEL is available via CentOS Stream. In fact, Red Hat generally contributes their changes there first. You can get all the source for CentOS Stream anytime you want.
To keep things simple, you can think of RHEL as being a copy of CentOS Stream at a specific point in time. To expand on that, RHEL is a collection of software packages, each of which can be found in CentOS Stream at a point in time but perhaps not all the exact same point in time. So, even though all the source is available, it is hard to know EXACTLY what RHEL is made of.
In terms of capabilities, there is not much difference between CentOS Stream and RHEL. However, if you want “exactly” RHEL then even very small differences can matter. Some people want “bug for bug”, every package checked out from Git at the exact same time “identical” copies of RHEL ( they want “exactly” RHEL without paying for it ).
Previously, Red Hat made the actual RHEL sources publicly available. They want to stop doing that. If you want the source to the changes they make to GPL software, they want you to get that from CentOS Stream. The issue is that this does not allow you to easily make exact RHEL clones.
Red Hat DOES make the actual specific sources for RHEL available to their customers. RHEL subscribers do not need to write a letter. They can log into the Red Hat Developer Portal and download the source RPMs any time they want. Red Hat makes all of this available to the people that they “distribute” RHEL to which is what the GPL requires of them ( to RHEL subscribers ). Red Hat is now saying though that they WILL NOT make RHEL source packages available to the general public. To answer your question: No, I do not think you can just write a letter to Red Hat and demand a link to the source code. I mean, you can. I would expect them to respond with a link to the sources for CentOS Stream. They are saying that they will not send you a link to what they specifically used to create a specific version of RHEL ( unless you are a subscriber ). By the way, not all RHEL subscribers pay them money.
It is absolute nonsense to say that “Red Hat has gone proprietary” as their development is all done out in the open, you can get access to the software that Red Hat develops even before Red Hat customers, and Red Hat customers get everything they need to fully rebuild RHEL from source. However, Via contractual language, they restrict RHEL subscribers from re-distributing the exact sources for RHEL to others. This is what people are upset about.
If you want to make an exact clone of RHEL and convince people that it is an exact clone then that is getting harder than it has been in the past. Previously, you just rebuilt the Red Hat sources and then told your customers that what you built was exactly the same as RHEL because you built it directly from the RHEL source. Cloning RHEL can still be done. It is just harder. You may not be 100% percent sure you got exactly the right source to guarantee that it is truly identical. The inability to make that guarantee and to convince your own customers that you can guarantee that your Enterprise Linux build is an exact copy of RHEL is what Red Hat wants. The only way to be sure that you are using something that is “for sure” RHEL compatible is to use RHEL itself.
Red Hat continues to make massive contributions to the FOSS ecosystem. Red Hat contributes to and authors a lot of software and they generally make everything they do available via the GPL ( not just stuff that is already GPL licensed but stuff that is GPL licensed because Red Hat chose to share their work ). You can get the source for all of this stuff from Red Hat. Do not listen to people that say that you cannot.
However, if you write a letter demanding a link to the specific code used to build a specific version of RHEL, do not expect to get exactly that back as a reply.
tanishaj,
The challenge for centos stream isn’t in capabilities, but in stability. We might say an upstream distro who’s purpose is to merge stuff (the very role that centos-stream was designed for) is less suitable for production enterprise use cases.
They do make big contributions, and as long as they comply with the GPL that’s all we can ask for. We are fortunate to have companies committing so much to the FOSS movement. It’s not clear to me how much corporate culture has changed since the takeover. Do others feel that IBM may be harmful to redhat’s good reputation?
I don’t think it’s optional. They cannot release one version of the software for RHEL and another for centos-stream and then point RHEL users to go download sources from centos-stream. If you cannot build the same binaries, it doesn’t seem like that complies with the GPL I guess some people may give redhat a pass because they’re redhat, but if microsoft pulled that move don’t you agree there would be an uproar?