LWN: Comments on "Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model"

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

kleptog — Tue, 11 Jul 2023 11:03:13 +0000

> European law now explicitly lets you sell on digital copies, on condition you destroy your original copy. I don't know the details, but I do remember something of the sort a good few years ago.

So I was thinking of writing something similar yesterday but figured I'd add sources for this claim... and came up blank. In fact, I found the opposite, namely the Tom Kabinet case before the ECJ which ruled that if you offer a site that allows people to download a copy of an e-book that that counts as distribution, even if you claim you're deleting your copy directly after the download. It doesn't help that in the EU software copyright and other copyrights are not handled the same way, see [1]

At a national level, similar cases where people selling an ebook to someone else by physically handing over media containing the ebook however have ruled the other way. Software copyright is regulated under the Software directive, and e-books under the InfoSoc directive. If you buy an MS Windows installation CD secondhand, MS cannot deny you downloading updates just because you weren't the first owner.

I think this is the reason why so many software businesses are moving over to subscription models because by offering a time-limited service, resale can simply by prohibited by contract law rather than relying on copyright law. Just like with Netflix & Spotify, since you never buy it, it can't be resold either.

[1] https://academic.oup.com/grurint/article/69/5/489/5854748

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

Wol — Mon, 10 Jul 2023 15:07:41 +0000

> if you download a musical recording as an MP3 file, according to copyright law you don't get to sell that recording to someone else,

I think copyright law has changed ... which is how you can buy eg OEM copies of Windows and stuff.

European law now explicitly lets you sell on digital copies, on condition you destroy your original copy. I don't know the details, but I do remember something of the sort a good few years ago.

I know MS is unhappy, but if they discover you are selling on OEM copies, all they can do is refuse to do any further business with you (that's how I've obtained most of my recent copies of Windows).

Cheers,
Wol

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

anselm — Mon, 10 Jul 2023 13:59:31 +0000

The rules are different for physical objects (like books or CDs) vs. “digital content”, such as software you download. If you obtain a copy of a copyrighted work as a physical object (book, CD, USB thumb drive, …), you get to dispose of that particular object as you please (including defacing it, selling it on, etc.), but your ownership of the copy doesn't let you make copyright decisions concerning the original work (such as making and selling more copies, or commissioning a movie based on (the content of) a book). The legal doctrine is called “copyright exhaustion”.

OTOH, whether copyright exhaustion applies to digital copies of a work is unclear. For example, if you download a musical recording as an MP3 file, according to copyright law you don't get to sell that recording to someone else, because that sale would result in the creation of an extra copy (even if you later remove your own copy of the file), and the creation of extra copies remains the copyright holder's prerogative. The same reasoning would apply to “defacing” an MP3 file – this would usually result in unauthorised copies being produced, and hence not be allowed, modulo the “fair use”-type provisions that exist in certain jurisdictions. (It has been long established that, e.g., the fact that a piece of software must be copied from secondary storage into RAM in order to execute it is irrelevant as far as copyright is concerned, but that of course doesn't give you blanket permission to make extra copies in order to “deface” it.)

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

Wol — Mon, 10 Jul 2023 12:54:45 +0000

Debatable ...

You can modify / deface a book, and pass it on without needing the copyright holder's permission, provided you haven't actually copied the original text.

To what extent that covers running a "defaced" copy of the original program is open to argument.

But as soon as you distribute it, all that is irrelevant. Either (a) you're distributing the one (defaced) copy you received, or (b) you're making copies. In case (a) the recipient gets all the rights and responsibilities you originally had and you're left with nothing, or case (b) the GPL bites.

Cheers,
Wol

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

anselm — Mon, 10 Jul 2023 12:29:26 +0000

The problem here is that modifying somebody else's copyrighted code is not something you get to do, under the defaults of copyright law. You need separate permission to do this, which the GPL provides, independently of whether you plan to distribute your modifications. There is nothing in the GPL, however, which forces you to make the source to your modifications available to anyone as long as you never distribute modified binaries to a third party.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

pizza — Mon, 10 Jul 2023 11:05:19 +0000

> More than that, the GPL itself only kicks in for acts of distribution, iirc.

FYI, It also kicks in for _modification_ as well. To quote GPLv3 section 9:

"You are not required to accept this License in order to receive or run a copy of the Program. [...] However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so."

So you have to _accept_ the GPL's terms in order to modify something covered by it, but the GPL places no obligations/restritions on you if you never actually distribute a modified (or indeed, an unmodified) copy.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

Wol — Sun, 09 Jul 2023 18:57:51 +0000

> > However, the GPL requires that it be made as long as that entity is themselves continuing to use the software and/or modify it.

> No, the GPL's source code clauses only kick in for acts of *distribution*. Actual "use" is effectively unlimited and perpetual, and that includes making your own (non-distributed) derivatives.

More than that, the GPL itself only kicks in for acts of distribution, iirc.

And, even worse from the GP's pov, the GPL explicitly contradicts him - does not the GPL itself say "Use of the software is outside the scope of the GPL"?

Cheers,
Wol

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

pizza — Sun, 09 Jul 2023 13:40:44 +0000

> However, the GPL requires that it be made as long as that entity is themselves continuing to use the software and/or modify it.

No, the GPL's source code clauses only kick in for acts of *distribution*. Actual "use" is effectively unlimited and perpetual, and that includes making your own (non-distributed) derivatives.

> But the GPL does not let Red Hat just keep the modifications they make to that software to themselves, but requires that those are also distributed to anyone who requests it, not just a direct paying customer for their support agreements. The GPL doesn't allow that....

Uh, the GPL allows you to keep all of your changes private. It only attaches requirements upon *distribution* of copies, be they modified or un-modified; source or binary. Additionally, it does not unconditionally require that you distribute your changes to whomever asks -- as your quoting of the GPL text clearly states!

> 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do *ONE* of the following: [emphasis mine]

Red Hat achieves compliance primarily through clause (a), but also through a written offer (ie clause (b)) that entitles anyone to get a copy of the precise source code that corresponds with the specific binaries in question, for $5.

I'm sorry, but I'm going to take the word of the FSF and the SFC over random internet commentators that what RH is doing complies with the letter (and the spirit!) of the GPL. Indeed, GPLv3's section 6 makes this explicit:

"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."

In other words, you get source code, RH can drop support/updates, and the GPLv3 (which surely embodies the "spirit" of the GPL) is perfectly fine with that.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

FallenKell — Sun, 09 Jul 2023 13:09:26 +0000

> Just because someone provided something to you for free of charge for a time, doesn't mean they are legally (or morally) obligated to continue doing so in perpetuity.

People keep saying this like it is a defense in this situation. Correct, they are not legally (or morally) obligated to continue offering the source code in "perpetuity". However, the GPL requires that it be made as long as that entity is themselves continuing to use the software and/or modify it. And if they can not agree to that, they are in violation of the GPL and not entitled to the software in the first place in order to make the changes that they have made.

Red Hat did not write the many of these packages. They do however, take these packages, contribute to them upstream, but also use them internally as a packaged product that they distribute and provide a support level agreement to end users. This is a great service to many who would not otherwise take the risk of using software that does not have support for bug fixes. But the GPL does not let Red Hat just keep the modifications they make to that software to themselves, but requires that those are also distributed to anyone who requests it, not just a direct paying customer for their support agreements. The GPL doesn't allow that.... The GPL says the following:

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

Now, look closely at the above, especially 3b. Notice the "give ANY third party" (emphasis added to the word "any"). This doesn't mean only those with a support agreement with Red Hat. It means anyone can ask for the source code from Red Hat and they need to provide it (for 3 years). Each modification/version that Red Hat makes or incorporates in the software they provide of the GPL'ed software is subject to this.

Why

ceplm — Tue, 04 Jul 2023 06:18:11 +0000

I think the author confuses CentOS and Scientific Linux. The latter truly was created mostly by CERN and Fermilab.

CentOS was nearly dead when RH acquired it

mattdm — Mon, 03 Jul 2023 06:03:55 +0000

> we don’t sell software, just support

This has never been the Red Hat strategy. Selling support causes bad incentives ("don't improve the UX -- that's a big reason people need support! And definitely don't document it!"). Red Hat subscriptions include support, but the value is in expertise and access.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

milesrout — Thu, 29 Jun 2023 21:37:38 +0000

I don't think marcan understands the AGPL at all. He seems to think contracts are code and all you need to do is execute them according to some abstractly-defined rules. Courts aren't computers!

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

farnz — Thu, 29 Jun 2023 15:55:33 +0000

A fix may be published upstream first simply because at the time of fixing, the author didn't realise that they were fixing a security issue - this was just part of normal bug fixing when you take part in upstream development (and note that RH employs a lot of people who take part in upstream development). And the further behind the RHEL version of a package is, the more likely this is to be true, since you're less likely to remember all the development that's happened between the RHEL version being picked, and you making this fix.

And while it's a workable definition of "withholding", it does mean that any time you ship a released version and not the latest development tree, you're withholding fixes and features from your users - this isn't what most people think of when you say that things are being withheld.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

madhatter — Thu, 29 Jun 2023 14:51:16 +0000

> I do not consider fixing something in place A before you fix it in place B to be "withholding" it from place B

I do. I'm not saying such withholding is avoidable or reprehensible or surprising or unique to this case, but it *is* (to my mind, and apparently to mcatanzaro's mind) happening. If you don't want to think of it as such, that is of course up to you, but you might want to better define your terms before making general statements.

> Note, too, that the fix may well be published upstream already (possibly even by Red Hat employees), and RH are simply applying it to the RHEL package.

I don't see how it would have been published by RH employees, given that we've been told they are forbidden from working on it under those circumstances. If the upstream fix already exists from another source, and they're forbidden from pushing it through the CentOS pipe simply because it has not yet been pushed through the RHEL pipe, well then, that's withholding.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

farnz — Thu, 29 Jun 2023 14:40:40 +0000

Note, too, that the fix may well be published upstream already (possibly even by Red Hat employees), and RH are simply applying it to the RHEL package.

In this circumstance, it's no more "withholding" a fix than Debian "withholds" fixes that are present in the latest upstream release but not in the most recent Debian package.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

pizza — Thu, 29 Jun 2023 14:24:46 +0000

Like many (most) things, this seems to be an argument over definition.

I do not consider fixing something in place A before you fix it in place B to be "withholding" it from place B. To me, withholding would be never offering that fix in place B to begin with.

Because by that same argument, RH is "withholding" *all* fixes from CentOS7 until after they are released in RHEL7. A practice that the rebuilders (and their users) were supposedly okay with for a couple of decades.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

madhatter — Thu, 29 Jun 2023 14:07:46 +0000

I'm not wading into the larger argument. I was simply responding to your question about who was holding back security fixes, which seemed to me to imply that you thought nobody was, when we'd just been told by an internal employee that they were.

You may be right that "very few issues are considered high-severity", but it's not just a numbers game: those are the very issues for which users most urgently need fixes, and for which there can be least justification for the withholding we are in fact assured takes place.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

pizza — Thu, 29 Jun 2023 13:56:36 +0000

> My understanding was that they are not allowed to fix *any* higher-severity security issues in CentOS (until a RHEL fix has shipped) and very few such issues are embargoed.

It was my understanding that very few issues are considered "high-severity" and even fewer of those are embargoed. So the vast majority of fixes land in CentOS *before* they end up in RHEL..

But even if you are completely correct, what exactly is the problem? Rapid access to serious updates is what RH's customers are paying for, after all! In the worst case it takes no longer to land publicly than it used to back in the old "we'll rebuild it after RHEL releases it" rebuilder paradigm, and everyone downstream was supposedly fine with that for the better part of two decades.

BTW, here's the full message, for context: https://lwn.net/ml/fedora-devel/D8JRWR.D2QFSVHOGZDV2@redh...

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

madhatter — Thu, 29 Jun 2023 13:38:41 +0000

> First, you realize this is for *embargoed* fixes, not "fixes" in general?

That is exactly not how I read what mcatanzaro said. My understanding was that they are not allowed to fix *any* higher-severity security issues in CentOS (until a RHEL fix has shipped) and very few such issues are embargoed. RH had already copped to the withholding in the case of embargoed issues, so I don't think his/her comment can be read any other way.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

pizza — Thu, 29 Jun 2023 12:56:25 +0000

> A security fix has been prepared, but because it hasn't yet gone through whatever internal processes are required for shipping in RHEL, it can't be released for CentOS. That is pretty much my working definition of "holding back a security fix".

First, you realize this is for *embargoed* fixes, not "fixes" in general?

Secondly, rebuilders *always* had to wait until after a fix shipped into RHEL before they'd get the source to generate a build? And that RH *never* released sources to the rebuilders for anything other than the _current_ point release of RHEL?

And meanwhile, CentOS Stream still has the same processes and QA requirements as RHEL, so either way you were *never* going to get a fix for something until RH's internal processes were satisfied.

Why

madhatter — Thu, 29 Jun 2023 11:28:23 +0000

> CentOS [was] created by government agencies

I'd not heard that before, and don't believe it to be true. Could you elaborate?

Where's the violation?

madhatter — Thu, 29 Jun 2023 10:11:23 +0000

> The GPL is a license, not a contract.

That is not as clear-cut as you think. See eg https://lwn.net/Articles/747563/ (full disclosure: I wrote the article, though I did not give the talk on which it is based).

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

madhatter — Thu, 29 Jun 2023 10:04:03 +0000

> Who, exactly, is holding back security fixes?

See mcatanzaro (who works for RH) above:

> We are not allowed to fix higher-severity security issues in CentOS Stream until the fix has shipped in RHEL.

A security fix has been prepared, but because it hasn't yet gone through whatever internal processes are required for shipping in RHEL, it can't be released for CentOS. That is pretty much my working definition of "holding back a security fix".

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

pizza — Tue, 27 Jun 2023 12:56:54 +0000

> Or you'd use a distro that doesn't hold back security fixes deliberately.

Oh, please. Who, exactly, is holding back security fixes? And how is that practice different from *any* other distribution, least of all the RHEL clones?

What you don't seem to understand here is that these security fixes are being created, or at least backported, by RH engineers, and that is what their customers are paying for. *everyone else* already had to wait until after the stuff went out to RHEL, and then create their own update incorporating the RHEL changes. (And, funnily enough, none of the rebuilders provided any support/updates for X.y after X.y+1 came out. So this hysteria about "holding back fixes" is talking about what has been the status quo *all along*.

> Basically you're telling the original poster to get screwed.

No, I'm telling the original poster that they can't expect to get what everything they want without having to pay something for it. RH owes its non-customers [1] *nothing*.

> Which is funny because Red Hat points to stream as the solution for everyone who wants to live in the RH eco system and doesn't fit their commercial target.

And that's ... wrong how?

[1] By "customers" I also include everyone who received binaries from RH.

CentOS was nearly dead when RH acquired it

TRauMa — Tue, 27 Jun 2023 12:36:28 +0000

Ugh, I thought I was the only one.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

TRauMa — Tue, 27 Jun 2023 08:25:41 +0000

> If you cared about timely updates you'd have signed a service agreement with Red Hat.

Or you'd use a distro that doesn't hold back security fixes deliberately. Basically you're telling the original poster to get screwed. Which is funny because Red Hat points to stream as the solution for everyone who wants to live in the RH eco system and doesn't fit their commercial target.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

farnz — Mon, 26 Jun 2023 14:20:52 +0000

Sure, but I was responding to the idea that "[no]one is claiming RedHat should not be able to distribute any code they wrote themselves under any terms they like". They are very definitely restricted in the terms they can use to distribute code they wrote themselves, as part of the GPL's mechanism for building a software commons.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

paulj — Mon, 26 Jun 2023 14:13:39 +0000

The GPL code they ship requires "the scripts used to control compilation and installation of the executable" (GPLv2) to be distributed as part of the source code of the work under the GPL.

Why

joib — Mon, 26 Jun 2023 14:07:09 +0000

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

pizza — Mon, 26 Jun 2023 13:59:02 +0000

> 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

joib — Mon, 26 Jun 2023 13:47:17 +0000

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

pizza — Mon, 26 Jun 2023 13:40:33 +0000

> 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

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

paulj — Mon, 26 Jun 2023 12:23:24 +0000

As per the reply to that other comment, the AGPL doesn't fix it, because the AGPL applies only where the software has "interactive" remote users. Which is just not true for much (nearly all?) of the software in a Linux distro.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

farnz — Mon, 26 Jun 2023 10:53:41 +0000

The spec files in the SRPMs for RHEL are source code, and are all written by Red Hat. If you're requiring RH to ship the specfiles for the binaries they ship to a third party (not their customers), then you're requiring them to ship code they wrote themselves under terms they don't like.

Where's the violation?

farnz — Mon, 26 Jun 2023 10:52:16 +0000

But where's the violation in RH ceasing further distribution of software (in either binary or source form) to you?

RH will ship you source and binaries as long as you comply with the subscription agreement. If you breach that agreement, then RH will not ship you anything after a 30 day notice period.

What legal theory compels RH to distribute software to you indefinitely, if they're refusing to take your money?

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

Karellen — Mon, 26 Jun 2023 10:09:24 +0000

Um, I don't think that anyone is claiming that RedHat should not be able to distribute any code they wrote themselves under any terms they like?

CentOS was nearly dead when RH acquired it

taladar — Mon, 26 Jun 2023 06:26:51 +0000

> which is why everyone wants RHEL

Not really. To be honest if I would never have anything to do with RHEL any more for the rest of my career as a sysadmin I would be happy. It is just so tiny in terms of number of packages and you have to jump through so many hoops to get something that works even half as well as Debian with RHEL.

Why

nim-nim — Mon, 26 Jun 2023 06:09:24 +0000

> 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.

Why

joib — Mon, 26 Jun 2023 04:58:33 +0000

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.

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

pizza — Sun, 25 Jun 2023 20:36:37 +0000

> It's not "Red Hat offers no value to me", it's "Red Hat is offering value I created to 3rd parties, but under terms that aren't compatible with the terms I intended those 3rd parties to receive".

Red Hat is offering value that *they* created to third parties, under their own terms.

Those third parties can get the value *you* created from many, many places, including (presumably) directly from you.