Why [LWN.net]

Why

Posted Jun 25, 2023 14:04 UTC (Sun) by NZheretic (guest, #409)
In reply to: Why by nim-nim
Parent article: Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

> First, when you upstream, you will often work with someone whose salary is paid by Red Hat or one of its partners from money earned in the RHEL ecosystem.
> What those agencies did was take Red Hat work, and pay people to add and maintain a few components not present in RHEL, with a few fixes right and left.

Those statements wouldn't be so galling if Red Hat was the sole or even majority contribute to the open source base Red Hat includes in distribution.
However Red Hat & IBM are not even the majority contributors to the Linux Kernel itself.
https://lwn.net/Articles/923410/
https://www.linuxfoundation.org/resources/publications/li...
https://project.linuxfoundation.org/hubfs/Reports/2020_ke...
"From 2007 to 2019" Red Hat supplied only 8.9% of commits & IBM 3.79%

It's like you have not even bothered to read the original article
Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model by Bradley M. Kuhn
https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analy...

Also you utterly fail to address the point I have make repeatedly
As I have pointed out "The main problem is that OEMs test & even validate server/workstation/desktop/laptop hardware for both Microsoft & RedHat OSs on the OEM provided hardware, under agreements which MAY have caveats that effect competition."
The issue is ongoing as new processors & hardware is being released constantly & will become an even more significant problem with the increasing deployment of newer APUs & other application acceleration hardware rolled into upcoming CPUs, motherboards & IO cards.

Red Hat has a long history of not sending all the Red Hat Enterprise Kernel patches it applies the stock Linux kernel to Linus to incorporate into the stock kernel code.
https://www.theregister.com/2011/03/04/red_hat_twarts_ora...
So despite Red Hat is not the major contributor to the Linux Kernel project, its OEM & hardware vendor relationship agreements mean that some particular patches it applies to the Stock Kernel are necessary for competing Linux distributions to interoperate with said hardware and operate in the market.

Red Hat itself has forked upstream projects like MySQL & CUPS for inclusion in its distribution when the upstream developer has changed the project licence to impose further restrictions. Shouldn't the rest of us have the same right to do the same with code developed under GPL by the community?

to post comments

Why

Posted Jun 25, 2023 16:27 UTC (Sun) by pizza (subscriber, #46) [Link] (5 responses)

> However Red Hat & IBM are not even the majority contributors to the Linux Kernel itself.
> "From 2007 to 2019" Red Hat supplied only 8.9% of commits & IBM 3.79%

By that metric there are *zero* "majority" contributors to the Linux kernel.

Meanwhile, for every kernel version since approximately forever, LWN has broken down the top companies contributing to the Linux kernel. Red Hat has been at or near the top of that list for a *long* time, and RHEL subscriptions have funded all of that.

> The issue is ongoing as new processors & hardware is being released constantly & will become an even more significant problem with the increasing deployment of newer APUs & other application acceleration hardware rolled into upcoming CPUs, motherboards & IO cards.

Huh? All of this work is being done in the upstream kernels, not within the likes of RHEL. If you truly want bleeding-edge stuff you're going to have to use bleeding-edge software and distributions, not "stable enterprise" stuff that's obsolete before it ever ships.

> Red Hat has a long history of not sending all the Red Hat Enterprise Kernel patches it applies the stock Linux kernel to Linus to incorporate into the stock kernel code.

First, that article is a decade old. Second, that article doesn't say what you claim -- It talks about RHEL kernel sources combining all patches into a single file, not that that there are parts of it "not sent to Linus", or establish any sort of "history" of bad behavior. Red Hat has *always* shipped the complete corresponding source code for all GPL components to their customers and everyone else who receives binaries from them.

(Incidentally, *every* major distribution out there has out-of-tree patches in it. Linus and his lieutenants are infamously picky in what they accept, and sometimes you need to ship fixes or features before they are in a state mainline will accept. Red Hat also has a strict upstream-first policy, which means all new features are developed upstream first, and they won't ship (ie backport and support) any feature that hasn't first landed upstream.

> Red Hat itself has forked upstream projects like MySQL & CUPS for inclusion in its distribution when the upstream developer has changed the project licence to impose further restrictions.

Um, the original MySQL developer forked MySQL, not Red Hat, and pretty much everyone switched over to the new fork. CUPS was forked by OpenPrinting/Linux Foundation, not becaue of licensing issues, but because upstream (ie Apple) has long stopped caring about supporting anything other than current MacOS platforms and stripped out a lot of code that the Linux printing stack still needed. (Also, CUPS didn't "impose further restrictions" with their license change; they switched from GPLv2-only to Apache licensing, which strictly speaking is *incompatible* with GPLv2-only stuff. GPLv3 is compatible with ASL2, so that (and GPLv2+ stuff) wasn't affected)

Why

Posted Jun 26, 2023 4:58 UTC (Mon) by joib (subscriber, #8541) [Link] (4 responses)

CUPS is licensed under Apache 2.0 with the "LLVM exception" https://spdx.org/licenses/LLVM-exception.html which should make it compatible with the GPL 2.0.

Why

Posted Jun 26, 2023 13:40 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> CUPS is licensed under Apache 2.0 with the "LLVM exception" https://spdx.org/licenses/LLVM-exception.html which should make it compatible with the GPL 2.0.

Do you have a citation for that?

Because this isn't documented in the LICENSE file of either CUPS repository [1], nor is it mentioned in the handful of source files I just looked at, which all seem (only) say: 'Licensed under Apache License v2.0 See the file "LICENSE" for mode information.

[1] Apple CUPS or OpenPrinting CUPS

Why

Posted Jun 26, 2023 13:47 UTC (Mon) by joib (subscriber, #8541) [Link] (2 responses)

Quoting from https://github.com/OpenPrinting/cups/blob/master/NOTICE :

>
> -- CUPS Exceptions to the Apache 2.0 License --
>
> As an exception, if, as a result of your compiling your source code, portions
> of this Software are embedded into an Object form of such source code, you
> may redistribute such embedded portions in such Object form without complying
> with the conditions of Sections 4(a), 4(b) and 4(d) of the License.

> In addition, if you combine or link compiled forms of this Software with
> software that is licensed under the GPLv2 ("Combined Software") and if a
> court of competent jurisdiction determines that the patent provision (Section
> 3), the indemnity provision (Section 9) or other Section of the License
> conflicts with the conditions of the GPLv2, you may retroactively and
> prospectively choose to deem waived or otherwise exclude such Section(s) of
> the License, but only in their entirety and only with respect to the Combined
> Software.

Why

Posted Jun 26, 2023 13:59 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

> Quoting from https://github.com/OpenPrinting/cups/blob/master/NOTICE :

Thank you.

But it's not clear which files, if any, this NOTICE applies to -- Because all of the source files still only mention ASLv2 and the LICENSE, with no mention of the exception.

(Also, looking at the git history, the exception was added in 2019, nearly two years after the ASL2 relicensing...)

Why

Posted Jun 26, 2023 14:07 UTC (Mon) by joib (subscriber, #8541) [Link]

That's something you'll have to ask OpenPrinting; I'm not affiliated with that project in any way.

Might actually be a good reason for a bug report, I agree with you the situation is unclear.

Why

Posted Jun 26, 2023 6:09 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

> As I have pointed out "The main problem is that OEMs test & even validate server/workstation/desktop/laptop hardware for both Microsoft & RedHat OSs on the OEM provided hardware, under agreements which MAY have caveats" that effect competition.

And has anyone ever seen such an agreement Linux-side ? And how would such an agreement stand given that the software parts are all eventually published (nvidia aside which is an nvidia decision Red Hat disagrees with) so it would be mightily hard to hide anything special. The worst that you can say about new Red Hat arrangements is that in some cases sources are not published before Red Hat publishes the corresponding binaries, which is above and beyond what most OSS licensing requires (the whole of RHEL is treated as a GPL product secret building sauce included even though it embarks a lot of components with more lenient licensing).

OEM work with Red Hat because they are not a charity, if working with a few big players is sufficient to address the market why should they expend money working with small fishes ? Their time is valuable too you know.

Customers buy Red Hat because they know it will be there to fix things where their business-critical systems would go titsup (home owners have no such requirements which is why the Linux desktop never flourished, people do not see the point of paying someone for reliable youtube viewing).

> Those statements wouldn't be so galling if Red Hat was the sole or even majority contribute to the open source base Red Hat includes in distribution.

That’s irrelevant. You will pay a plumber an harm and a leg on week ends even though the parts he uses have been conceived by someone else, are readily available in hardware supermarkets, there are lots of online tutorials etc. You will pay an arm and a leg because you want things fixed *now*, he is available, you have no trust in your ability to fix things quickly yourself, and the über scientists that calculated the best materials and gaskets to use are not there (and are quite happy not to be there and deal with customer moods during their day off). And some people will blame the plumber for extortionate galling prices even though the hardware supermarket is this way and everyone else can see they could easily take up plumbing to correct the situation.