Hacker News Reader

Comment by EvanAnderson | Hacker News Reader

Red Hat can't stop you from exercising your rights under the GPL to redistribute the code. You also can't compel them to do business with you. They've structured their support agreements such that if you do exercise your rights under the GPL they will stop supporting you (and decline to offer you future subscriptions).

The value proposition for RHEL is ostensibly support (and a "throat to choke", for whatever that's actually worth). Red Hat's gamble is that no "legitimate" Red Hat subscriber would risk their support entitlement (and the ability to contract with Red Hat for support in the future) by exercising their rights under the GPL.

It's a clever hack. It runs counter to ideals of Free software (and I find it personally repugnant) but it's clever.

View on HN

To be clear, it's not yet known for certain if the chilling effect of a terminated contract violates the "no further restrictions" clause of the GPL or not. Evidently IBM's lawyers think it doesn't. But it would be good to test it in court first.

GRSecurity started down this road. IBM though has deeper pockets

It's not grsecurity's idea, it started on the 90s when Spender was in kindergarten or so. It's always been the way free software companies made money.

More importantly, IBM has the best of the best in terms of lawyers. The likelihood of them ever losing a case is basically nil. They sustained and won a proxy war with Microsoft, when Microsoft was the richest company on the planet.

Much like GPLv3 was written to counter tivoization, I’d love a GPLv4 to kill what RedHat is doing before they do irreparable the entire free software ecosystem.

In this case, is the change you imagine GPLv4 would say "you cant prevent anyone, at any point from downloading the source code from a project you create" because that is super slippery slope?

I'd also like to ask, what damage do you see this change in behavior doing to free software ecosystem ?

It seems pretty mad. Apparently Redhat doing all of their work as GPL'ed OpenSource and upstreaming everything so that everyone benefits, and anyone can take the software and build their own, sell it, etc, isn't good enough.

Is literally the only thing that would make people happy is to give away RHEL for free for people to run their production servers on?

Part of the open source social contract is downstreaming too. You can't just take, promise to give back, and then hoard what you've built.

There is no hording though.

What changes have they made to RHEL that isn't available?

downstreaming ? How is the open source social contract anymore than making source code available?

That's what I mean. Not putting up a EULA dam. They don't have to build CentOS or assist anyone, but they can't block the code from flowing downhill.

According to Red Hat the source of RHEL is publicly available on CentOS Stream Gitlab, without a EULA.

It's the upstream source, not the source used to build RHEL. RHEL is downstream of CentOS stream. Much like linux kernel's source is available, it does not help you much.

However, it is "exactly" that code, isnt it.. thats been my understanding.

It may incidentally be in some cases, but isn't guaranteed to be. Things don't necessarily flow back up from RHEL to CentOS stream, and even if they do in a general sense, it may not be sufficient to build the exact same tag that RHEL uses. Someone else mentioned that they were not able to build RHEL packages from CentOS stream.

Do you have an example of this, since the project I work on definitely has its code synced to gitlab..

I believe that would be actuall evidence of gpl non compliance, not this dismisive current interpretation that people have.

I don't think that most people who commented have a subscription.

Pushing things back to CentOS stream is not a requirement of GPL. GPL's role ends once RHEL customers get the source. Do you mean evidence of CentOS stream not being enough ? The post talks about it. Rocky needs to collate sources from several places now to create 1:1 RHEL rebuilds.

> Do you mean evidence of CentOS stream not being enough ?

I think this is what I mean, yes.

The rhel trees are synced from the centos trees. If centos git trees couldnt build, rhel couldnt build. Afaics the only time this seems to be in conflict is for important and critical cve's , which are built on a rhel specific branch. After package release these branches are merged with centos, and the local rhel branches deleted and business continues as normal.

This is an attempt not to break embargo agreements with researchers who ask for it.

According to Red Hat it is. If you don't believe them you can get a Developer subscription to get a RHEL ISO to compare with a CentOS Stream ISO. I imagine a lot of people, myself included, would be interested in the analysis of that.

So you do that analysis. Two downstream distros of RHEL have said that they cannot continue to offer RHEL rebuilds/updates without substantial changes. That means that it is not possible to use CentOS stream alone to build RHEL packages. You are free to do all the analysis in the world.

The damage is corporations could now determine whether they classify downstream use of open source code as "valuable" or "not valuable", and determine (according to their own rubrics) whether to effectively end the open source gravy train in their own ecosystem, or be a member of the open source community and share alike.

Despite every attempt by Red Hat employees to call out CentOS Stream as being "Red Hat sources", it is not. If they wish to participate in the open source ecosystem, they can't coerce customers (paid or not) into a particular (very proprietary) usage pattern with their software. No matter how many tens/hundreds/thousands of employees they hire to code for open source projects.

So Red Hat is saying that CentOS Stream is how RHEL is built, you are saying it is not. Can you show the difference in packages from CentOS Stream and RHEL? Rocky says they pull packages from CentOS Stream, and with their project goal remaining 1:1 binary compatibility then that must be the case.

So far I have talked to two individual developers who have not been able to reproduce a RHEL 9.2 build only using what's available in Stream.

Reply on news.ycombinator.com