> Rocky Linux remains dedicated to its mission of delivering a community-based, accessible, and transparent EL operating system. The project pledges to keep its promise to maintain the full life-span of support for Rocky 8 and 9, and to continue to produce future RHEL-compatible versions as long as the option remains, allowing organizations to maintain the flexibility, control, and freedom they rely upon for their critical infrastructure. This is the open source way.
Despite the title, this press release doesn't say much really, not how they are going to source patches, or they are going to continue their RHEL 1:1 bug compatibility.
I think Almalinux's press release was much more direct to the point.
> Red Hat has decided to continue to use the Customer Portal to share source code with our partners and customers, while treating CentOS Stream as the venue for collaboration with the community.
> Unfortunately the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.
Pretty sure that's a gpl violation.
> 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
Sure, IBM can kill the red hat distribution. What they can't do is keep shipping new versions of it as closed source, where needing to be one of their customers to have the source is indistinguishable from closed to anyone who isn't their customer.
This is "IBM openly violates GPL, waits to see if there are consequences". Not very like redhat as was.
Sister thread seems to think that new versions of red hat aren't covered by the gpl, but I can't see how that conclusion is being reached.
> What they can't do is keep shipping new versions of it as closed source,
They aren't proposing to do that.
> This is "IBM openly violates GPL
It isn't. GPL applies when you give someone a copy of the covered software. The GPL specifically allows selling copies of the software which would grant the recipient the same rights. But the GPL doesn't compel you to give someone a copy of the software to begin with.
It's a violation because they placing a contractual restriction on redistribution of sources they've provided to you.
GPL is a licensing agreement. Purchasing RHEL is a licensing agreement. Together they form a single, but incompatible licensing agreement, as the RHEL licensing term would violate the GPL licensing terms.
Both of you seemed to be talking past each other. You were saying RedHat can stop selling to someone. They were saying RedHat can't stop a customer from redistributing the source.
If I understand correctly, both are correct. Though, I imagine it just takes one customer to share the source under their GPL rights to open Pandora's Box.
In today world everything is a subscription and so is Red Hat..
You buy a subscription from Red Hat and it give you access to a number of RHEL installations as well as related material like the sources for GPL licensed stuff, but those are meant for the benefit of whoever is paying for the subscription.
Lets say that i have a software that was developed by a third-party that is designed to run in RHEL that i have a subscription for and this software have a bug that require me to patch something in the RHEL software to fix, i can share the sources with the developer of this software so it allow them to fix it for me and provide me with the patch to apply in my system. This would not breach the subscription because even tough i shared the sources is for my own benefit.
The problem is when sharing the sources give the subscription benefits to someone that does not have a subscription, at that point RHEL terms say they can cancel your subscription with 30 days notice.
They are not preventing you from sharing the sources, they are preventing you to give someone access the value added by an RH subscription without them having to pay for it.
Now, GPL say that you can share the sources.. you can and so RH will not sue you for that.. But they will cancel your subscription and you will loose access to support and updates..
GPL version 3 is even explicit in this, it literally say that it does not require the developer to provide support, warranty or updates. So RH decide to link those things to the requirement of you not providing access to your subscription benefits for others.
> i can share the sources with the developer of this software so it allow them to fix it for me
But is that realistic? Will you be able to convince a third-party to work with RHEL code if they can't actually install a system themselves? You could provide the code for the errant library, but to really test it, the developer would probably like to try it on a full RHEL system. And if that is now difficult to do w/o a RHEL subscription, what's the third-party developer to do?
What you'll find is a slow migration away from third-parties supporting RHEL. I'm not sure what the end game here is for IBM, but it makes the entire ecosystem significantly more difficult to work with.
> This clearly violates the spirit of the gpl, but it is not clear whether it violates the license itself
The courts will decide, if the issue ever gets presented to them. But even if the (e.g) American courts reach one conclusion, the (e.g) German courts may reach the opposite one.
Red Hat’s problem is it only takes one jurisdiction to rule against them, and then they have to comply - unless that jurisdiction is so unimportant to their business that they can just walk away from it.
I see your point and I'm not a lawyer so maybe I'm in the wrong here but to be honest this:
> The vendor can decide NOT to share the next version with you [because you shared the previous verison].
Sounds a lot like a new restriction on sharing. The threat of future action if you share something under GPL is a restriction on sharing.
If someone is prevented from sharing GPL code because of some kind of contract, license or TOS how is that not a new restriction being placed on the GPL?
If the boot disc has GPL code and you modify the code, the GPL applies. You would have to make your modifications available under the GPL when you distribute and allow others the same freedom you just used. It's the whole point of having the GPL.
Red hat wants their fork to be different, I don't see why it should be.
GPL say what rights you have and what Red Hat can sue you for, not what Red Hat need to give you in the future.
You have the right to change and share the sources and Red Hat cannot sue you for that if you choose to do it.
GPL does not say anything about Red Hat giving you access or selling you new versions.
An example, lets say you buy whatever 1.0 under GPL from Red Hat, and they make the sources available.
GPL say that Red Hat cannot sue you for sharing the sources to whatever 1.0, but they will not sell you whatever 2.0 if you do so, and there is nothing in GPL require then to.
The restriction is not on GPL, is in your business relation with Red Hat going forward, and that does not break GPL.
I'm not saying it does. I'm saying refusing to give me future versions if I share the first one is a restriction on the first one. That's a violation of the license.
I think business heads are putting pressure and they're trying to walk in the grey space of what the GPL forbids clearly by intent but not by explicit language. Whether this ends up in court is another matter.
As written, yes, this is not a GPL violation, they're not directly stopping you from redistributing what you were given, they're just choosing to not do future business with you.
In practice, judges often really hate people trying to do cute end runs around the intent of things, particularly anything that's more than a handshake, like a license.
I would suspect they're betting heavily on nobody being big enough to be willing to try suing IBM-sized legal departments, and settling without losing the ability to argue this is valid if they're wrong.
From what I understand here, RedHat will terminate the contract to future code if you actually exercise your rights to the GPL code that the GPL grants you. This is effectively adding new restrictions to end users of the code which the GPL expressly prohibits.
Now, just because it isn't part of the same contract (since they haven't added some clauses to the GPL), doesn't mean it isn't part of the same distribution agreement, since it is part and parcel of the same distribution.
If the US government said "yes you have the right to free speech, but if you exercise it, then afterwards we will strip you of citizenship and deport you to Mexico" that would be considered infringement on the free speech statutes. Retaliation for invocation of the agreed upon licence terms effectively nullifies those terms, and should (IMO, IANAL) revoke RH's licence.
If a company gives you a binary of a GPL licensed program they _must_ give you a way to view the source. If they stop giving you the binary you are no longer entitled to the source.
Yup, IBM can stop distributing RHEL anytime, but they cannot continue to distribute it while preventing their users to share the source code with some GPL-violating TOS, which is what they claim to do.
Except that threatening to unilateral breaking a contract explicitely violates the licence:
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Whether or not this clause would be ruled valid in court is an open question, but the violation isn't. Unless you consider that “threatening customers to leave their business without the support they paid for” doesn't count as “imposing”, but that requires some mental gymnastic (what could this word even mean if not? Of course no company is going to use armed force to impose anything…)
But this is intellectual gymnastics though, because the GPL cover the redistribution of the code, which is the topic here.
If I commercialize GPL code and say in my TOS that you cannot redistribute the code <or something bad will happen>, then I'm adding a restriction to the code redistribution, and it doesn't matter what kind of “bad thing” it is, as the GPL says “any further restrictions”.
TOS applies to the commercial service, not to GPL code. You can do whatever you want with the code within the bounds of the GPL. But the GPL doesn't magically obligate me to continue doing business with you. I can't sue you for re-distributing GPL code. But you can't make me provide you new versions of the software after you've breeched our agreement.
> TOS applies to the commercial service, not to GPL code.
Come on, the TOS almost litterally say “you shall not re-distribute the code or we terminate you” and now you're arguing that the TOS isn't about GPL code? This is Olympic level gymnastic at play here.
They are terminated the additional services they would have otherwise provided you. They can't terminate the GPL. If you find this difficult to understand maybe ask a lawyer.
The only reason ibm(redhat) has to provide the source is because they provide the executable artifact the source generated.
If ibm(redhat) decides to not provide you an exactable artifact(perhaps they say they don't want to sell you a rhel licence), they don't have to provide the source that generated that artifact.
Its a stupid shitty way to behave but the gpl does not say you have to redistribute the source to every body(most people do because this is easier) only that you have to redistribute the source to people that get the binary.
To all of you saying this is a GPL violation, I highly doubt a company with the size and pedigree of Red Hat doesn’t have lawyers that thoroughly understand the GPL. I’m not a lawyer, but the way I read it, yes this is against the spirit but not the law.
That being said, I feel like GPLv4 will be here any day now to close this loophole, like they did with the anti-Tivoization clause for v3.
Companies violate the law all of the time. The procedural hurdles of enforcing GPL are significant, to the point where blatent violations normally go unpunished. Assuming someone with standing decides to sue and ends up winning the lawsuit, the punishment is generally minor. Mostly the outcome is that the company must comply going forward.
If you can get years of non-compliance in beforehand, and use that to reshape the market in your favor, why is the fact that a court might eventually tell you that you violated the license a problem?
But the user would have to be granted the source under the same GPL license which permits redistribution. So disallowing their customers to redistribute the source of the GPL software that you are providing them isn't allowed.
don't forget that gpl applies to software itself.
what is the license of rpm build specs that redhat provides ? all the pre/post install scripts and other magic that goes into creation of rpm package ? which is the real work that allows to build redhat compatible packages
Where I work, our target devices run RHEL but many of our dev workstations run Rocky Linux.
If the software I write behaves on my workstation but then malfunctions on my target device because a bug was only fixed in Rocky Linux, that would be very annoying.
I want stuff to run the exact same way on both so that I can develop workarounds if needed before even deploying to the targets.
I don’t see why Rocky wouldn’t be able to continue existing using old CentOS Stream releases. It wouldn’t be as easy or work as well as it currently does but there’s no reason why it wouldn’t work tk make a RHEL like OS.
0. Government or affiliated that require scap/stig or other compliance frameworks like fips140 or hipaa and actually use stuff like fapolicyd or aide.
1. Large companies that build "support" into the risk matrix for leadership who are obligated by law to protect shareholders.
Other companies that just "use Linux" probably use alma or rocky, but certainly aren't joined at the hip.
Personally I hope this comes back to bite big blue. For this to have any effect on Oracle you'd need to have started doing it like a decade ago before they too started eating customers from #0
They did something similar with the Kernel in 2011. It's not an entirely new strategy.
They stopped publishing the git tree or separate patches for the RHEL kernel and only published the tarball with no version control. At the time, Oracle started a project to reverse engineer it back into a set of unique patchsets called "RedPatch". Was kindof wild.
Not sure how long it lasted. It doesn't seem live now, though.
This is a little off topic, but can someone tell me the different between Rocky Linux and Alma Linux. Reading a few blog posts the only different I can't find is a slightly different release schedule, and different levels of funding.
They have the same goal: free enterprise Linux OS that is essentially RHEL with all "red hat"s piped through sed. They are run by two different organizations. Alma achieved RHEL 9 rebuild a lot faster than Rocky, interestingly. Overall both seem to have high quality.
Would you build a business around unofficially obtained source? It would make supply chain attacks possible if only a couple of people are downloading the source and sharing it, only a couple of people need to be compromised and users would not be able to verify it. RH could also make it hard to get the source in an automated manner.
> The Rocky Linux community strongly believes in the open source value of collaboration. Rocky Linux contributors have participated as a responsible part of the EL ecosystem, regularly contributing upstream to CentOS Stream as well as Fedora, and other open source projects. These contributions strengthen the entire EL community.
I'm really happy to hear this, but what sort of upstream contributions has Rocky sent?
As a CentOS user when that was a thing, I looked for ways to contribute fixes to red hat for inclusion in future updates of RHEL. I came up empty. It seems the way at the time was to contribute the fix to fedora. Now I’m supposed to contribute it to CentOS stream. That’s not really a useful approach when the problem exists in the latest RHEL bits but not in these channels where they maybe accept contributions.
If I am experiencing a bug in RHEL 8.x and others with similar hardware could also experience the same bug, it would be swell for me to be able to submit a fix that would stand some chance of making it into a future RHEL 8.x release as well as RHEL 9.x releases. If it is fixed in CentOS Stream, I think the earliest release this will feed into is RHEL 10, since RHEL 9.x is already released. It's quite possible the problem is already fixed in Stream because the package was upgraded but that upgrade is unlikely to ever make it into RHEL 8.x.
Personally, I regularly contribute to Fedora and EPEL, as well as Stream (and RHEL). In addition, I am a Core Reviewer for OpenStack-Ansible and am part of the OpenInfra community.
A lot of wishy washy talk without anything to back it up.
Anyone using alma or rocky should start planning their stream/RHEL Dev or Ubuntu/Debian migration.
* Utilize RH subscriptions to access CDN sources and create local source mirrors for every package which we can then import from
Q for legal: we need to review the licensing terms
Red Hat isn't changing the terms of the GPL. What they're doing is making access to the GPL code a benefit of maintaining an active Red Hat subscription, which has its own terms and conditions. If you have an active Red Hat subscription, then you can look at the source code all day long and may be able to redistribute it for purposes of bug fixes, etc.
What you can't do is use your subscription to obtain the source code, which you then redistribute to someone that doesn't have a RH subscription. This would violate the terms and conditions of the RH subscription.
Basically, they've inserted a new licensing layer 'above' the GPL: you can't obtain the GPL code unless you agree to the terms of the RH subscription in the first place. In other words, the RH subscription Ts and Cs supersede the GPL.
Isn't this similar to the way things were before Cent OS was acquired? Or did they make source rpms available to everyone freely back then?
EDIT: I looked into it a bit more and it looks like there used to be an FTP site with SRPMS. ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/
Not personally a consumer of RHEL or other binary-compatible distros, so I'm probably out of the loop, but the phrasing of this comes across like Rocky may be less honest than the other companies you have listed. Is this the way it is meant (i.e. have they exhibited dishonest behavior)?
Despite the title, this press release doesn't say much really, not how they are going to source patches, or they are going to continue their RHEL 1:1 bug compatibility. I think Almalinux's press release was much more direct to the point.