Rocky Linux Expresses Confidence Despite Red Hat's Announcement | Hacker News Reader

Rocky Linux Expresses Confidence Despite Red Hat's Announcement

rockylinux.org

99 pointsfariszr92 comments

> 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.

As it took me a while to find it, here’s Almalinux’s statement:

https://almalinux.org/blog/impact-of-rhel-changes/

And here's the discussion from a few hours ago:

https://news.ycombinator.com/item?id=36436375

> 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.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC1

> any version

Once they give you that version you can share it freely. That does not mean they can't stop giving you _new_ versions.

That's a restriction on sharing...

It's a more restrictive license. Doesn't matter what the restriction is. It's a restriction.

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.

> preventing their users to share the source

They can't and they aren't proposing to do that. Rather they can stop doing business with such users.

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…)

The GPL does not cover support contracts. No mental gymnastics needed.

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.

Honestly: It isn't. You can share what you were given.

The vendor can decide NOT to share the next version with you.

The GPL talks about your rights, etc, with regards to what you GET. Not guaranteeing any future updates, prices, etc.

I'm sure that if you got caught, Red Hat would "forget" with enough money. :)

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?

> 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.

It isn't. Giving you a boot disc doesn't obligate me to make future versions available to you.

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.

No, there is no new restriction..

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.

That seems like a terrible business idea to me, but hey, open source is more of a development model than a business model.

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.

The rights granted by GPL apply to the version I gave you. It doesn't obligate me to keep giving you new versions.

You're thinking about semantics, not intent. A judge would see through this argument instantly and come down hard on RedHat.

What do you think is more likely?

1. An entity that that has been dealing with GPL software and the attendent licencing issues for decades fundamentally got it wrong.

2. Your understanding of the GPL is incorrect.

I think they're probably correct, actually.

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.

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.

No lawyer would let something like this happen if it was going to break the GPL.

Breaking the GPL, and triggering the revocation of Red Hat's license to distribute various key pieces of GPL code is a massive no-go.

I've also spent my share of time talking to lawyers about various parts of GPL compliance etc. I'm pretty confident Red Hat is in the right here.

Do I like it: No.

Do I think it is stupid: Yes.

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.

That's not the way contracts work... the wording very much matters. RH might have a semantic argument, but it's a very defensible semantic argument.

Red Hat is not restricting access to the code. You can still get that.

They are restricting access to the RPM which is more than just code. The non-code bits are what is restricted.

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.

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.

The GPL covers derived work as well as the original. That's the whole point of it.

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.

No they are not.

You can share if you want and they can do nothing about it.

But then can and will ban you as a Red Hat customer and thus you will not have access to future versions.

GPL does not mandate they give you access to future versions.

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.

The thing is, wording is everything..

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.

I believe the parent means that redhat is going to terminate your contract and/or stop providing updates you if you share the code.

This clearly violates the spirit of the gpl, but it is not clear whether it violates the license itself.

> 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.

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

If you are not a user of RHEL, you don't necessarily get access to its source code. It was so far, but it's not a GPL violation if they stop doing so.

Only users do have this right, not bystanders and competitors, eating the income of the service provider.

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?

Wouldn’t Oracle have standing if what Red Hat did was a license violation? Why would they risk that?

There’s an old joke that Oracle is a company of lawyers with a small software engineering department.

Why would Oracle sue them? There is almost nothing for them to gain if they win, and a long and expensive court process regardless.

This move by Red Hat was aimed squarely at them. It makes it much more difficult and expensive for Oracle to make their RHEL clone.

Oracle sues Red Hat for violating one of Oracle's licenses. Red Hat comes into compliance and shares the source of whatever Oracle IP is in RHEL.

I'm sure Oracle can find some IP of theirs in RHEL, but I don't think they own enough to be useful.

Yeah, just OpenJDK, MySQL, and btrfs, nothing important, right?

https://github.com/oracle

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.

Sure, Red Hat may be obligated to distribute everything GPL/within kernel space.

But how about patches for packages licensed in a more permissive license, like MIT?

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.

From what i understood everything in CentOS Stream end up in RHEL, but not everything that is in RHEL came from CentOS Stream.

They pull changes from other sources that are not in CentOS Stream and this is the challenge.

> RHEL 1:1 bug compatibility.

Did they actually offer this, because CentOS never offered this.

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.

So get RHEL for your devs then. The only guaranteed bug compatibility

It might be very annoying but I still don't think they offer 1:1 bug compatibility, and I don't think they ever did.

CentOS stated: https://www.spinics.net/lists/centos-devel/msg19564.html

> We came up with the phrase "bug-for-bug" compatible during EL5 as a GOAL to aim for. CentOS was NEVER bug-for-bug compatible.

Rocky may have changed that line, but I would be surprised. CentOS was always "good enough".

I thought that RHEL was free for developer workstations with the free RHEL developer subscription.

What does Rocky provide you in this situation?

Free for personal use, not workplace.

Interesting, so they don't make a free dev service for corps?

How much does something like this cost a developer as part of an org?

https://developers.redhat.com/articles/faqs-no-cost-red-hat-...

According to https://developers.redhat.com/articles/2022/05/10/access-rhe..., the Red Hat Developer Subscription for Teams is zero-cost.

Realistically redhat only serves two customers:

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.

https://www.theregister.com/2011/03/04/red_hat_twarts_oracle...

https://www.theregister.com/2012/11/12/oracle_launches_redpa...

Centos streams made the kernel source available in git.

The source was always available; the difference was that RH stopped breaking out their enormous delta from the vanilla tree into itemized patches.

And as far as I can tell, that's still [1] just one giant patch wad for every update.

[1] - https://gitlab.com/redhat/centos-stream/rpms/kernel/-/commit...

Third option: your business relies on some expensive software that is unfortunately only supported on RHEL

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.

Can both continue in a post-RHEL-sources world?

The notion of a post RHEL sources world is rather silly.

This just makes things harder. As long as the source is out there, and the licenses of the code itself it permissive: Rebuilds will happen.

How will the code get to the people doing the rebuild? Good question. And even if I knew the answer... I probably wouldn't say :).

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.

You imply there's only a few. There's always a way.

If they make it hard to get the source code in an automated manner, they'll violate some of their licenses.

We'll see.. This is going to be a game of cat and mouse. It'll be fun.

> If they make it hard to get the source code in an automated manner, they'll violate some of their licenses.

There’s no legal requirement to provide source in any specific way. They can provide it on antiquated magnetic tape.

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.

> 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.

CentosOS stream feeds into the next release - isn't that where you want the fix to land ?

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.

CentOS Stream is a lot closer to RHEL than that. There is a CentOS Stream 8 that feeds into RHEL 8, and a Stream 9 to RHEL 9, etc.

If you want to get a fix into RHEL 8, you can submit it to Stream 8 and if accepted it will go into the next release of RHEL.

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.

The internal analysis does not sound that optimistic, from https://etherpad.opendev.org/p/r.24fab14385c0aa2db6fa7340a8b... ...

Options

* Buy a farm in Nebraska or Montana. Raise cattle

* 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

That sounds like a joke. It's also one of the very first things they wrote, not one of the last.

I'll take this announcement as being closer to reality.

I'm not sure what the order in which we write our jokes has to do with anything.

I'll work on my comedic timing, I guess.

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/

Other than money, what's stopping RL or anyone making a proper fork and supporting it ala old RH?

How is RHEL going to ensure that a customer does not redistribute the sources?

IBM/Red Hat have just handed Rocky Linux the possibility of becoming the de facto enterprise Linux.

The Rocky Linux team have already been selling support, but previously they could only hope to be an alternative to Red Hat.

With IBM/Red Hat effectively abandoning Open Source, Rocky Linux can step in and position themselves to fill that gap.

This will go down as yet another huge strategic blunder by IBM.

Very unlikely that Rocky will become defacto.

Companies I trust before Rocky:

- Oracle

- SuSE

- Canonical

Distros I know will survive pretty much no matter what:

- Debian

Now... What am I going to bet on if I'm a company who just got cut-off by Red Hat, and I really have little loyality to Red Hat.

If I like RPM: SuSE. I'm sure there's a way to work out terms that are win/win.

If I want to just have my own distro: Base off Debian. It has worked for Canonical for years now.

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)?

The Rocky Linux team does _NOT_ sell support.

Reply on news.ycombinator.com