Live data from Hacker News

Keeping Open Source Open

rockylinux.org

191–200 of 253 posts

Re: Keeping Open Source Open

#191

> Moreover, Red Hat’s Terms of Service (TOS) and End User License Agreements (EULA) impose conditions that attempt to hinder legitimate customers from exercising their rights as guaranteed by the GPL. Does someone have more details on this?

I wrote this a couple days ago, sums it up: https://www.jeffgeerling.com/blog/2023/gplv2-red-hat-and-you tl;dr - GPLv2 requires no restriction on free/paid recipients of binaries to also freely redistribute source code. Red Hat EULA says your subscription will be canceled if you redistribute the source code. Is that a restriction? A couple OSS laywers I spoke to said no. Common sense says it feels an awful lot like i…

I am amazed that multiple OSS lawyers gave you the same answer and you still don't believe them.

> (what Fortune 500 company would like to have their Red Hat servers all go dead because some employee downloaded sources and uploaded them somewhere?)

What does this mean? Are you implying that RHEL has some sort of kill switch per customer embedded in it's source code that someone could exploit? I am not following this train of thought at all.

Re: Keeping Open Source Open

#192
post #162
post #94

Earlier quoted context omitted.

Give me a break. I have been in the "GPL arena" for almost 30 years (1996). When I started using free software I didn't even have Internet access at home and had to visit relatives one hour away to download it and send emails. I used SRPMs from a Red Hat Linux CD to study source code because it was not very handy to download it with a 33.6k modem.

So you should be well aware of community expectations. And so should Red Hat.

Community expectations aren't necessarily correct and probably won't help paying the salary of thousands of engineers.

Re: Keeping Open Source Open

#193
post #124

Earlier quoted context omitted.

So who should be doing that work? On whose payroll? Should Red Hat engineers be spending their time de-branding and wrapping things up neatly for rebuilders to use? Note that every minute they spend on that is a minute they're not spending on adding features, fixing bugs, or backporting fixes to the last ten years' worth of releases. You know, the things they're actually obligated to do by their contracts with custom…

Note that they're actually doing more work now (checking for contractual entitlements, playing whack-a-mole with rebuilders, trying to reassure ecosystem partners, etc etc) than they did before.

I'm not sure that's true at all. Having done a bit of packaging myself, I'm well aware that it's hard, tedious, frustrating work. Doing it twice, once for their own users and again for the benefit of those whose only practical effect is to fragment the ecosystem, is a substantial burden.

Re: Keeping Open Source Open

#194

Earlier quoted context omitted.

They seem to have been able to fund development before. So what changed? Just the new corporate overlord that wants a return on their investment?

Quoting Reddit: "The problem of rebuilders has been around forever. Things heated up a couple of months ago when we detected what we think was a continued bad-faith action from one of the rebuilders, not on the code/engineering side but on the commercial/money making side of their house. That's as far as I'll go publicly. After that it was just a matter of discussion on what to do about it, so we landed on the announ…

That quote is someone complaining that others are making money of "their" work, not that Red Had isn't making enough money to fund development.

Re: Keeping Open Source Open

#195
post #124

Earlier quoted context omitted.

So who should be doing that work? On whose payroll? Should Red Hat engineers be spending their time de-branding and wrapping things up neatly for rebuilders to use? Note that every minute they spend on that is a minute they're not spending on adding features, fixing bugs, or backporting fixes to the last ten years' worth of releases. You know, the things they're actually obligated to do by their contracts with custom…

Note that they're actually doing more work now (checking for contractual entitlements, playing whack-a-mole with rebuilders, trying to reassure ecosystem partners, etc etc) than they did before.

> playing whack-a-mole with rebuilders Are they playing whack-a-mole? Or was this one change that people are arguing (and Red Hat's lawyers seem to think) is within their rights under the GPL ? It will be whack-a-mole if Red Hat tries to stop supporting VPS instances or stop updating UBI, both of a 1% chance of going away.

Re: Keeping Open Source Open

#196
post #125

Earlier quoted context omitted.

This is not at all in conflict with the upstream first, if so please tell me how you see it being in conflict.

The blog post says: "Previously, we obtained the source code for Rocky Linux exclusively from the CentOS Git repository as they recommended. However, this repository no longer hosts all of the versions corresponding to RHEL. Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs." Why would you need RHEL SRPMS if the upstream pack…

I believe that currently RH send a patch to the upstream project, then apply/backport it to CentOS Stream, then if they consider it appropriate apply/backport that to RHEL, and it's the first step there being their first step that's the 'upstream first' part.

The additional hassle Rocky are having is that since Stream is ahead of RHEL divining whether the third step was taken and if so with what, if any, backporting tweaks required, is rather trickier so to recreate the end result of all such third steps to get an identical (bar debranding) set of SRPMs to the ones used by RHEL your best approach has become to source the various bits of information you need to do that from multiple places.

Also I -suspect- the 'pristine upstream packages' thing is referring to the fact that most package formats, rpm definitely included, prefer to have an untouched copy of the upstream sources plus a stack of patches in their source packages and combine them during package build for both clarity and debuggability reasons.

Re: Keeping Open Source Open

#197

Earlier quoted context omitted.

But they do make all of that source code available under CentOS Stream. GPL does not require an SLA for providing source code of all bugfixes and security patches free of charge in under 24h. Just embargoing security patches for 1-2 weeks from Stream would be a good enough move for RH to signal to enterprise customers that Rocky/Alma are not a drop-in gratis replacement for RHEL in production systems.

The GPL requires all source code be available including the scripts and glue code required to build the binary alongside the source. You can't pull a Stream and offer "most" of the source, but not the source required to rebuild the latest stable release. That's counter to the spirit and the letter of GPLv2. Legally speaking, the contract vs copyright issue is the only ground Red Hat has to stand on here.

The last time I recall a company doing the 'we will follow our GPL obligations and give you - specifically you, the recipients of the binaries from us - the source but if you exercise your right to redistribute don't expect to be able to renew your contract' thing I believe the eventual conclusion amongst the people who seriously knew what they were talking about* was 'this is obnoxious but legal.'

* I do not consider myself to be one of those people

Re: Keeping Open Source Open

#198

On another topic, we can finally see the motivation behind those SRPMs. The whole purpose of a SRPM is to take some upstream source code and repackage it into a different archive blob which has to be downloaded in its entirety and unpacked in order to determine whether any of the code is patched, or pure upstream. If, instead of a SRPM, you have some small, declarative text file which gives upstream URLs, SHA256 dige…

> If, instead of a SRPM, you have some small, declarative text file which gives upstream URLs, SHA256 digests and build config steps

That plus a stack of patches is what FreeBSD ports and other ports-like systems use instead.

(I'm afraid "ports-like" is intentionally vague because accurately enumerating the members of that category would involve substantial effort and I'd probably still get it wrong)

Re: Keeping Open Source Open

#199
post #78

What is RHEL compatibility so important and why is it always such a hot topic?

Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you) in bringing open source to the table against enterprise proprietary vendors. Other open source competitors like SUSE and Canonical have much smaller revenues, so Red Hat could be seen as having a bit more influence over Linux's overall direction (they employ a ton of devs, they have a t…

> Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you)

I'm not particularly fond of this latest move but I'm unconvinced they've fallen off the line yet.

Even with this decision in place I believe that Red Hat will still be by far a net positive to have around for open source overall.

They could change my mind about that, certainly, but they'd have to make a substantially more egregious move to do so.

Re: Keeping Open Source Open

#200
post #127

I originally had a strong anti-RedHat response to this change. When I thought about it and heard RH's response their sharp change makes sense. They sell RHEL. It's from what I gather their main source of income. Revenue from this funds things like SystemD, a lot of work in Gnome, many many things that RHEL customers and other users of Linux and desktop Linux benefit from. Of course many contributions to open source/G…

How did they survive and thrive for 25+ years then? Rebuilders have always existed. They've just dialled the "greed" knob a bit higher, that's all.

Historically they've generally politely ignored community rebuilders and got a trifle enervated by commercial rebuilders - they changed how they handled distributing kernel code (to a fully patched tree rather than a pristine tree and a stack of patches I -think- from memory) in response to Oracle doing a commercial rebuild.

Exactly what the triggering incident was this time they've been very careful not to officially say (which is likely a better option than the optics of getting into a finger pointing war with a smaller target), and I suspect we won't be able to fully judge their motivations unless/until the details leak and/or are inferred by people close enough to the situation to guess correctly.

Post reply on HN