[ale] Maddog’s take on recent Red Hat source distribution changes

[Steve Litt]

Solomon Peachy via Ale said on Sun, 20 Aug 2023 08:50:02 -0400

>On Sun, Aug 20, 2023 at 02:52:17AM -0400, Steve Litt via Ale wrote:
>> Seems pretty clear to me. If you let somebody have the program,
>> whether for free, for a million dollars, alone or bundled, if the
>> program was GPLv2 you have to give them the source, and more
>> importantly, you have the right to redistribute the source.  
>
>Sure.  But what you don't get is the right to any/all future versions
>of the software or any type of support, which is also something the
>GPL makes explicitly clear.

Correct, and nothing I wrote implied otherwise.

>From the GPLv3 text (ie covering most GNU software in Linux 
>distributions): "you may charge any price or no price for each copy
>you convey, and you may offer support or warranty protection for a
>fee."

I never said otherwise.

>
>Also:
>
>"The requirement to provide Installation Information does not include a
> requirement to continue to provide support service, warranty, or
> updates for a work that has been modified or installed by the
> recipient, or for the User Product in which it has been modified or
> installed."

I never said otherwise. 

>
>> I know, I know, we can argue about first, second, third, fourth and
>> fifths parties, but section 6 is clear that if you come into
>> possession of the software you have the right to redistribute it.  
>
>Red Hat's own agreement text explicitly contradicts this statement, 
>which (paraphrased) says something to the effect of "Nothing in this 
>agreement is intended to limit your rights under open source software 
>licenses"

Which license says this? I saw nothing like this in the following:

https://www.redhat.com/licenses/Enterprise_Agreement_Webversion_NA_English_20211109.pdf

In
https://www.redhat.com/licenses/Red_Hat_GPLv2-Based_EULA_20191118.pdf,
section 1 *seems* to say something like what you're talking about.

>
>> And yes, I know, you can't buy Red Hat without agreeing not to
>> redistribute the source.   
>
>No, you agree to not "give another party the benefit of the
>subscription services", which is emphatically _not_ the same thing.

So let me get this straight. If I want to distribute Red Hat source
code that I receive as RHEL licensee, I can do so, no harm no foul? If
this is the case, I'll bow out of this particular debate.

>That falls under a run-of-the breach of contract, and the worst-case
>penalty is that RH cuts you off from _future_ updates and support,
>something the GPL explicitly allows (as that's also the default state!)

I never said anything about future RHEL source, only the source given a
licensee.

>
>Meanwhile, anyone can get the complete corresponding sources to a
>given RHEL point release on a USB stick by sending Red Hat $5, with
>zero restriction on what you do with it beyond the software licenses
>itself.
>
>> Once again, I'm pretty darn sure that if there's a deep pockets
>> lawsuit from a Red Hat customer who chooses to follow section 6 of
>> GPLv2, Red Hat will lose,   
>
>No, it's called a legal, voluntary contract, which can have nearly any 
>terms in it, even the point of waiving fundamental human rights.

Try incorporating a non-compete clause in California and see how far it
gets you. Try an indentured servitude contract in the United States.
Contracts have limits. Because neither you nor I are lawyers, I'll stop
here. 

[snip remainder of contract discussion, and skip to systemd]

>
>> About systemd: If I and let's say six of my friends were paid half of
>> what Red Hat paid Poettering and his crew, we could have incorporated
>> every feature of systemd without creating a massively entangled
>> mess.  
>
>Funny thing is that a lot of people have claimed something like this, 
>yet nobody has produced even a _design outline_, much less anything
>more substantive.

Of course not. Nobody ever paid us, and very few people using
sans-systemd Linux see a need for 90% of what systemd claims as
benefits. I did, however, once use inotifywait to achieve systemd's
"event driven" running of software with respect to USB being plugged in
and unplugged. It took me two hours. If I gave a flying flamingo, I
could do the rest in C using the inotify library.

And let's talk about design outlines. I've never seen a block diagram
of systemd that includes both boxes representing modules or
functionalities, and lines representing interactions. Because the darn
thing is so entangled nobody knows how to do it.

Getting back to design outlines, the proper way to incorporate
systemd's supposed benefits would have been as separate things not
involving PID1. Years ago I made a diagram of Daemontools, a process
supervisor that can replace sysvinit's process supervisor for superior
performance and greatly lessened complexity:

http://troubleshooters.com/linux/djbdns/daemontools_intro.htm#daemontools_mental_model

The preceding is pretty much the same design outline as for the greatly
superior modern runit and s6 init systems.

If I needed this "per seat" nonsense, which I thought we got rid of
when we substituted cheap PCs for house-priced PDP-11s and VAXes and
mansion-priced mainframes, I'd create that capability as a standalone,
perhaps with a few thin interfaces to other things (not PID1), and
would diagram it.

>
>> I very much liked the history, but I just don't buy the article's
>> defense of Red Hat.  
>
>That's not surprising; you're coming into it with a very strong bias. 

You and I have that in common.

SteveT