[ale] Maddog’s take on recent Red Hat source distribution changes
Scott McBrien
smcbrien at gmail.com
Sun Aug 20 09:15:45 EDT 2023
Your linked blog is from 2006, and is from someone who has been long gone from Red Hat (he left in 2014).
Hi, I’m Scott, and I’ve worked at Red Hat since 2001. Currently, I manage a small team of technical contributors in RHEL focused on making public facing technical product content like the Into the Terminal YouTube show (and generally managing the RHEL YouTube channel), lab.redhat.com hands on labs, and product roadmap and workshop content for our technical field employees to use.
The Free Software Conservancy “analysis” of the agreements is that they don’t violate the GPL. I used “s because that was after a couple of pages of Bradley Kuhn complaining about Red Hat and the agreements, until finally saying that he thinks it complies, but is unhappy about it.
The GPL doesn’t guarantee future access. It says when you have software distributed to you, you’re entitled to source code for it. The RH Enterprise Agreement does not affect the GPL or the rights granted within it, but instead future interactions and access to binaries that have not yet been distributed, and are therefore not yet subject to the terms of the GPL.
I disagree with your assessment of systemd. I will say to start, that systemd is the king of something we call “pizzas we didn’t order.” Meaning, no one was asking for systemd, and yet, an engineering team at Red Hat made it. When it was added into RHEL7, it was extremely disruptive and many people, including myself, hated it. I mean, no one had ever asked for it, why was it being subjected on us??!!?? For the first couple of years of RHEL7, it was worked on, including a rebase in 7.2 which, if you’re unfamiliar with RHEL package management, rebasing a package is kind of a big deal. All that said, looking at systemd today, it was the right call. It is a far superior solution to what we had previously. Is it perfect? No. But then neither were init scripts.
Having worked for Red Hat Training at the time, we inherited the RHEL Engineering decisions the same way as everyone else. There was a single course made that focused on differences between 6 and 7 which included systemd content, but a similar course had been made in the past and again for 7 to 9. Because some customers like the ‘updater’ course to get a focused training on changes to the distro. Personally, I don’t like them as they’re a lot of effort to make and have about a 1 year lifespan before no one enrolls in it. Red Hat Training and Consulting get access to early development content on which to base their work, but at that point, the engineering decisions have already been made for the release as the developers have assembled it enough to provide early access to other teams. Trust me when I say no one at Red Hat is making product engineering decisions in an attempt to make larger training and consulting sales.
Red Hat doesn’t advertise to other distros. Trust me, there is enough work to do within our own ecosystem that we don’t go meddling in other people’s linuxes. Which means Debian, Ubuntu, Suse, and all the rest, picked up systemd because they also saw it as a significant improvement in what they had been doing previously. You see that today with the cockpit project, trust me, Stef isn’t out there stumping for other Linix distros to include it, he’s got lots of other things to do at Red Hat… They include Red Hat developed software because it’s better than what they have, and is one of the key differentiators in the open source software community.
If everyone kept their enhancements proprietary, then what you’d end up with is minimal or near zero investment in open source. You’d see only enough work being done to keep the open source bits the proprietary software needs updated to further the proprietary software sales by a company. Oracle does this today with MySQL. They have an open core, but commercial MySQL includes a ton of features not in the open source version because they’re based on closed source. There are a fair number of companies that operate open source like this because it provides an easy differentiation to the customer on what they are buying when they buy the product. They’re getting all that secret sauce held back by the company that people who may use the open source components of the software can’t get without paying. But if the secret sauce is what is worth money to the company, where do you think they are spending their development dollars and effort? Sure, they’ll also work on the open source component, but only as much as is required to keep their proprietary stuff enabled.
“Freeloader” was a term used by The Register when publishing a story about the change of public availability of debranded RHEL sourcecode used for downstream builds. “In fact, what it was really doing was cutting off those that might be seen, from its perspective, as a bunch of freeloaders.”
https://www.theregister.com/AMP/2023/06/23/red_hat_centos_move/
These are The Register author’s words, not Red Hat’s.
-STM
> On Aug 20, 2023, at 2:52 AM, Steve Litt via Ale <ale at ale.org> wrote:
>
> Scott McBrien via Ale said on Mon, 31 Jul 2023 17:15:00 -0400
>
>> IBM, Red Hat and Free Software: An old maddog’s view
>> lpi.org
>>
>>
>> Maddog, I know you’re sometimes around. As a long time Red Hatter
>> (since 2001), not only did I learn some history from your article, I
>> appreciate its opinion and thoroughness.
>
> I liked the history too, but I'm skeptical about the parts about
> Redhat. Below is section 6 of GPLv2:
>
> =======================
> 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.
> =======================
>
> 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.
>
> 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.
>
> And yes, I know, you can't buy Red Hat without agreeing not to
> redistribute the source. Once again, Red Hat requires the breakage of
> section 6. They get away with this only because their army of lawyers
> provide a chilling effect on a paid-for recipient asserting his or her
> rights under section 6.
>
> Of course, I'm not surprised a bit at Red Hat's Microsoft style action.
> Within a few years of the spectacular Bob Young's departure, Red Hat
> became an anathema to Linux, culminating in their promotion of systemd
> to all distros. They could have kept quiet about systemd, which would
> have given them a competitive advantage had systemd been beneficial.
> But they knew that with Debian and Ubuntu as competitors, their sales
> would suffer, because their distro contained the inferior systemd, if
> they didn't promote Debian and Ubuntu to incorporate systemd. The
> purpose of systemd was to complexify Linux so they could sell their
> services and training.
>
> Yeah, I can't prove the final two sentences of the previous paragraph,
> but here's a smoking gun:
>
> http://asay.blogspot.com/2006/10/interview-with-red-hat-cto-brian.html
>
> In the preceding link, search for the word "complexity". The only way
> they make money is if software is complex.
>
> In the article, I resent the word "freeloaders". If Red Hat doesn't
> want other distros to redistribute them, they should switch to Linux or
> Mac. 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, although our present disfunctional Supreme
> Court might side with them because they're a business. Their license
> provisions not to redistribute are just there for chilling effect.
> Trouble is, FSF doesn't have the money to fight a legal battle with Red
> Hat.
>
> The article mentions "right to make a profit." Nobody ever suggested
> they should give away their training and consulting for free. Just don't
> violate GPLv2.
>
> The article also mentions, and I quote, "if you are not maximizing
> your revenue with the resources you have, you are not paying fiscal
> responsibility to your stockholders." Not true. You can't murder to
> maximize revenue. Not even if you won't get caught. You can't steal to
> maximize revenue. And I'm pretty darn sure you can't violate a license
> to maximize profit. The rest of this email concerns my personal opinion
> of Red Hat...
>
> I haven't used Red Hat since 2003, and I wouldn't use Red Hat if they
> were the last distro on earth. Matter of fact, I wouldn't use any RPM
> based distro just to make sure Red Hat doesn't somehow mess me up.
>
> 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.
> If Red Hat didn't enable Poettering, systemd never would have gone
> anywhere, and Linux would be better for it. Any systemd features that
> were really necessary would have long ago been incorporated outside of
> the init system. Systemd was never about improving Linux, it was about
> complexifying Linux.
>
> http://asay.blogspot.com/2006/10/interview-with-red-hat-cto-brian.html
>
> I very much liked the history, but I just don't buy the article's
> defense of Red Hat.
>
> SteveT
>
> Steve Litt
> Autumn 2022 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/bookstore/thrive.htm
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20230820/de454cf2/attachment.htm>
More information about the Ale
mailing list