LWN: Comments on "AlmaLinux's response to Red Hat's policy change"

AlmaLinux's response to Red Hat's policy change

farnz — Fri, 14 Jul 2023 13:24:25 +0000

It's in the Software and Support Subscription Agreement, section 1 (Use of Subscription Services) (specifically in 1.2 (g) through 1.4), as combined with the baseline Enterprise Agreement section 4 (termination).

AlmaLinux's response to Red Hat's policy change

lproven — Fri, 14 Jul 2023 13:14:50 +0000

> they say "if you do X in a way that lets someone without a Red Hat subscription get the benefit of that subscription, we'll stop doing business with you after a 30 day notice period expires".

[[Citation needed]]

Not because I am doubting you. I'm not. But I wrote about this, and even got cited by the SFC, and subsequently people are asking me on Twitter for specific chapter & verse from RH EULAs or similar documents, and I don't have them.

I was merely reporting on the conversations I have seen lots of people having online -- including here.

AlmaLinux's response to Red Hat's policy change

kleptog — Wed, 12 Jul 2023 16:32:15 +0000

I think it was Groklaw that pointed out: the legal system is not a computer, the law is not code. Context is everything.

> Making that kind of distinction, as to what the user is or is not allowed to do with the source and who they are or are not allowed to redistribute it to, is not allowed by the GPL. "No further restrictions" means "no further restrictions". No asterisk.

IANAL but doing some research, the distinction between "restriction" and mere "contractual terms" depends on the severity of the penalty, and in most jurisdictions withdrawing service not considered severe because businesses are generally not obliged to continue service anyway. So asterisk or not, it's not so black and white. Elsewhere the word "imposed" is similar, implying something that cannot be negotiated away.

And frankly, the idea that a sentence in a copyright licence could constrain the agreement between two businesses (ie RedHat and a customer) just doesn't pass the smell test. Nowhere in the GPL does it say you can't voluntarily give up some rights in exchange for something else. As long as the conditions only apply to the parties in the contract and are not extreme, all is fine. If the GPL had intended to override standard contract law rights, it should have said so explicitly.

I suppose while it feels like the intent of the GPL was to give people a stick to beat businesses with, the stick is not of unlimited power.

AlmaLinux's response to Red Hat's policy change

pizza — Wed, 12 Jul 2023 15:02:49 +0000

> In every way, the exact point of the GPL is exactly to ensure that "someone else" can get the benefit of the source code. That's the ENTIRE REASON the license exists. If you don't agree with that you should not be distributing GPL'd software.

No, the point isn't to ensure that "someone else" gets the benefit of the source code.

The point is to ensure that *the recipient of the software* gets the (full) benefit of the source code.

Nothing in the GPL *forces* the recipient to redistribute it, much less to random third parties. It only says that *IF* they choose to redistribute it, they also pass along the source code (via one of several enumerated methods), with no (additional) restrictions beyond what the GPL allows.

And the GPL does allow for some restrictions; eg with respect to trademark/branding, and crucially to this kerfuffle, support -- The GPL makes it quite clear that support/service/updates lie outside the scope of the GPL, and explicitly states that the mere act of supplying sources is sufficient reason to terminate any support/service agreements, and stop providing further updates.

AlmaLinux's response to Red Hat's policy change

farnz — Wed, 12 Jul 2023 14:54:44 +0000

But, importantly, Red Hat aren't restricting your ability to redistribute the GPLv2 software. Go nuts, do it - no matter what you do, you will not have restrictions placed on your ability to redistribute GPLv2 software. Indeed, Red Hat will even supply you the sources you need to do that distribution if you got a binary from them - even if you're not longer a Red Hat customer.

What Red Hat are restricting is your future ability to do business with Red Hat if they think that you're abusing the business terms they asked you to agree to. You have no restrictions at all on your redistribution of Red Hat Enterprise Linux - you can redistribute freely; what you cannot do is demand that Red Hat continue to distribute future versions to you in the future if they choose not to.

Further, Red Hat offer RHEL under GPLv2 3b terms - a written offer. You can continue to get the sources for the latest version of RHEL by taking up Red Hat's written offer, even if they won't let you have a subscription; it's just that you lose access to the Red Hat Knowledge Base, and Red Hat stop pushing updates on you, if they choose to no longer do business with you.

AlmaLinux's response to Red Hat's policy change

Wol — Wed, 12 Jul 2023 13:52:58 +0000

> The theory under test is that if you don't redistribute the source, or redistribute to only certain people or in certain ways, RH will continue support you. If you do redistribute the source to certain other people, or in certain other ways, they will stop supporting you. The response is that this is against the intent, at least, of the GPL; I will leave the legalities up to others. The GPL (famously) doesn't allow you to make any sort of distinction based on the uses that the software will be put to: you either provide source and you don't restrict them from redistributing it, or you can't distribute at all.

The GPL *DOES*, however, EXPLICITLY allow charging for support, iirc. So if you help people dodge paying, you are acting *against* the explicit intent of the GPL (else why would it mention it?).

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

anselm — Wed, 12 Jul 2023 13:37:07 +0000

But if they provide a support contract then disallow it, and the material difference between users who are allowed to keep their support contract and those who are not is whether or not they take advantage of Freedom 2 with source code they got from Red Hat in a way that Red Hat doesn't approve of, then this is against the intent, at least, of the "no further restrictions" clause.

“No further restrictions” means you don't get to impose further conditions, on top of what the GPL stipulates, on redistribution of the GPL code. E.g., no redistribution on Sundays, or no redistribution to people south of the equator.

But this is not what Red Hat does. Red Hat doesn't restrict the redistribution of GPL sources that you obtained from Red Hat. Red Hat simply reserves the right, in its own service contract that is completely separate from the GPL, to stop providing services to you under that contract you if you do things that are deemed by Red Hat to be detrimental to Red Hat's business, including using Red Hat 's published source code to offer a competing Linux distribution that is identical to RHEL in all respects except it isn't called RHEL, or otherwise let people take advantage of your Red Hat subscription who don't pay for a Red Hat subscription of their own.

IOW, as long as you deal responsibly with GPL source code from RHEL, including redistribution, Red Hat isn't likely to go after you for breach of contract. They would presumably much rather keep you as a paying customer than kick you out. It's only when you go into active competition with them for market share, based on their own product, that they will take steps to prevent that, which is basically what any business would do, so it's really hard to fault them for that.

AlmaLinux's response to Red Hat's policy change

madscientist — Wed, 12 Jul 2023 13:06:58 +0000

> Your principle is one that Red Hat already complies with - they do not refuse to do business with you SOLELY for exercising freedom 2, but specifically for using your subscription so that someone else benefits from a Red Hat subscription without having their own subscription.

I've already said this is not compliance IMO (although somehow that turned into a totally irrelevant side-discussion about sending software to Putin or North Korea).

The theory under test is that if you don't redistribute the source, or redistribute to only certain people or in certain ways, RH will continue support you. If you do redistribute the source to certain other people, or in certain other ways, they will stop supporting you. The response is that this is against the intent, at least, of the GPL; I will leave the legalities up to others. The GPL (famously) doesn't allow you to make any sort of distinction based on the uses that the software will be put to: you either provide source and you don't restrict them from redistributing it, or you can't distribute at all.

> And no, you've failed to explain why there's pushback, because you're addressing the wrong thing - RH have already promised that you can exercise your Freedom 2 rights per the GPLv2 without any impact on your RH subscription; what you can't do is use your RH subscription (source, binary or other data) to give someone else the benefit of an RH subscription.

Making that kind of distinction, as to what the user is or is not allowed to do with the source and who they are or are not allowed to redistribute it to, is not allowed by the GPL. "No further restrictions" means "no further restrictions". No asterisk.

In every way, the exact point of the GPL is exactly to ensure that "someone else" can get the benefit of the source code. That's the ENTIRE REASON the license exists. If you don't agree with that you should not be distributing GPL'd software.

> I'm still waiting for someone to explain why Red Hat must continue to do business with someone they see as competition, given that RH don't care about you exercising your GPL rights at all if you're not aiming to compete with RH.

If Red Hat decides whether or not to renew support based on some other criteria that has nothing to do with redistributing source code, that would be fine. For example if they don't provide support to ANY Linux vendor, regardless of whether that customer redistributed Red Hat source to anyone ever, I have no problem with that.

But if they provide a support contract then disallow it, and the material difference between users who are allowed to keep their support contract and those who are not is whether or not they take advantage of Freedom 2 with source code they got from Red Hat in a way that Red Hat doesn't approve of, then this is against the intent, at least, of the "no further restrictions" clause.

AlmaLinux's response to Red Hat's policy change

farnz — Tue, 11 Jul 2023 09:06:22 +0000

Here's the rub - Red Hat will not engage in a retaliatory, punitive act specifically for exercising their GPL rights to redistribute. You share code with me (and I don't have an RH subscription), and that's fine, because any reason you have to do so is not to give me "the benefit of your Red Hat subscription".

This is the framing used initially, as far as I can find, by CQI, who sell support for a RHEL rebuild - they've framed it this way because their business model is giving other people the benefit of a Red Hat subscription for a lower price, and by saying that they'll cut you off for doing that (which includes - for example - sharing the list of binary RPM versions available in a given RHEL point release), they've made CQI's business model that bit less tenable.

AlmaLinux's response to Red Hat's policy change

paulj — Tue, 11 Jul 2023 08:49:57 +0000

That is a good way of framing this. It's not about some general right to free association, or some onerous requirement to offer one's support services for ever and unconditionally, it is about a distributor of GPL software engaging in a retaliatory, punitive act against a downstream recipient /specifically/ for exercising their GPL rights to redistribute - which the GPL says must not be restricted.

AlmaLinux's response to Red Hat's policy change

farnz — Mon, 10 Jul 2023 17:12:03 +0000

And I don't think your "without being punished" qualification is useful. You are "punishing" me in the same way by not doing business with me that I want to do, on the terms I want to do business. LWN is "punishing" me by refusing to let me continue my subscription for free, when I don't want to pay them.

Your principle is one that Red Hat already complies with - they do not refuse to do business with you SOLELY for exercising freedom 2, but specifically for using your subscription so that someone else benefits from a Red Hat subscription without having their own subscription.

And no, you've failed to explain why there's pushback, because you're addressing the wrong thing - RH have already promised that you can exercise your Freedom 2 rights per the GPLv2 without any impact on your RH subscription; what you can't do is use your RH subscription (source, binary or other data) to give someone else the benefit of an RH subscription. So, for example, if I took the kernel source from a RHEL subscription and sent it to my friend to help me debug an issue on my RHEL box, that'd be fine. If I sent it over to CQI so that they could use it to address customer issues that are already known to be fixed by RH, that wouldn't be fine.

This nuance is the thing that nobody is addressing - the deal on offer is that if you choose to compete with Red Hat, they will stop dealing with you in future. They'll still comply with the licence, they'll still let you distribute what you have from them - they just won't do business with you in future. I'm still waiting for someone to explain why Red Hat must continue to do business with someone they see as competition, given that RH don't care about you exercising your GPL rights at all if you're not aiming to compete with RH.

AlmaLinux's response to Red Hat's policy change

madscientist — Mon, 10 Jul 2023 16:56:35 +0000

> First, you can exercise your Freedom 2 right.

I believe I've always been careful to qualify this as "without being punished". If I forgot this in some material place I apologize. I fully agree that RH is not saying they will sue you for copyright or license violation if you redistribute.

> So, the underlying question to answer: when is it OK for Red Hat to refuse to do business with you in future, and when is it not OK? What is the principle that I can apply to split out "Red Hat is punishing people" from "Red Hat is just exercising its right to Freedom of Association"?

I already discussed this. We don't have to treat all reasons as equivalent, such that if one reason is OK then all reasons are OK, or if one reason is not OK then no reasons are OK. All reasons are not the same!

The principle you are looking to apply is the license. RH is redistributing software published under the GPL, which contains a clause saying you cannot add "further restrictions" to downstream recipients' use of the software. So, what makes this different from general free association such as the color of socks, bank problems, or not being profitable, is that by distributing the GPL'd software they are agreeing to the terms of the GPL and the GPL has requirements about allowing downstream distribution, while it doesn't say anything about those other things.

In other words, once RH decided to do business with you notwithstanding the color of your socks, the question is can they decide to STOP doing business with you SOLELY because you exercised your GPL rights (not for other reasons, but for THAT reason)?

Whether the support contract clause really constitutes "further restrictions" in a legal sense is up to the lawyers, and whether it is ethically OK is of course up for debate (clearly). But again I entered this thread to explain to people who couldn't understand why there was pushback, exactly what the problem is. I have hopefully done that.

AlmaLinux's response to Red Hat's policy change

farnz — Mon, 10 Jul 2023 15:23:21 +0000

First, you can exercise your Freedom 2 right. That's not in doubt - the worst case is that Red Hat will decide that they won't do business with you in future. You can also find that Red Hat go down the same route without you ever exercising your Freedom 2 right - for example, just sharing all the binary RPMs will do that, or even a version list so that someone else can reconstruct a bug-for-bug RHEL from CentOS Stream sources.

But this isn't the only reason for Red Hat to decide not to do business with you - they could decide to not do business with you because your bank is being problematic about transferring payments to them. Or because they have reason to believe that you're a front for a sanctioned entity, and they legally cannot do business with you. Or even because they've decided that entities of your type are not profitable customers. They could also refuse to do business with you because you've got an employee who's suing IBM, or because they think you're likely to be a competitor of theirs.

So, the underlying question to answer: when is it OK for Red Hat to refuse to do business with you in future, and when is it not OK? What is the principle that I can apply to split out "Red Hat is punishing people" from "Red Hat is just exercising its right to Freedom of Association"?

AlmaLinux's response to Red Hat's policy change

madscientist — Sat, 08 Jul 2023 12:45:59 +0000

By which I clearly and obviously meant "either Red Hat allows Freedom 2, or it does not", as I said in my reply but you cut out. It makes no sense to blame Red Hat for the government's restrictions and no one would realistically think I meant that. But, fine, you also win a point for parsing the text to find a place where it doesn't explicitly disavow the most extreme and ridiculous positions. Congratulations.

AlmaLinux's response to Red Hat's policy change

Wol — Fri, 07 Jul 2023 21:27:08 +0000

"There has grown up in the minds of certain groups in this Free Software movement of ours the notion that because a man or corporation has made a profit out of the generosity of others for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary to the public interest. This strange doctrine is not supported by statute or common law. Neither individuals nor corporations have any right to come into court and ask that the clock of history be stopped, or turned back."

You do not have the right to demand others work for you. That's called Slavery. I thought you fought a war to abolish it.

(And if Red Hat's work isn't worth having, why are you demanding they work for you?)

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

Wol — Fri, 07 Jul 2023 20:25:10 +0000

Please explain how Red Hat are going to "punish" you. Other than refusing to be "friends" with you, and I'm sure you'd REALLY scream if you had your freedom of association removed from you, and other people told you who you were - and were not - allowed to be friends with.

You're basically placing your freedoms - specifically Freedom 2 - over and above other peoples' freedoms, specifically their Freedom Of Association and Freedom Of Choice.

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

pizza — Fri, 07 Jul 2023 18:32:04 +0000

> Do I really have to explain the distinction between RH telling me I can't exercise my Freedom 2 or else they'll punish me, and the government telling me I can't do something or they'll punish me?

To quote you own words, this is a "distinction without a difference. Either you have Freedom 2, or you do not."

AlmaLinux's response to Red Hat's policy change

madscientist — Fri, 07 Jul 2023 18:20:46 +0000

Do I really have to explain the distinction between RH telling me I can't exercise my Freedom 2 or else they'll punish me, and the government telling me I can't do something or they'll punish me? The government is not a party to the GPL license or the understanding under which I received it, or which it was given to me. The government has no obligations to the software author (not that they would care anyway).

Or are you just trying to score a point by showing that I didn't take into account completely irrelevant things in the text of my reply, and instead of "you either have it or you don't" I should have explicitly said "Red Hat either allows it or they don't"? I wouldn't think that this was needed if we're engaged in a good-faith discussion as everyone understood what I meant, and also did not mean, but anyway congratulations you got a point.

AlmaLinux's response to Red Hat's policy change

farnz — Thu, 06 Jul 2023 09:55:19 +0000

Then no-one in the USA has Freedom 2. Supplying software to people on the USA's sanctions list (such as Vladimir Putin) is a criminal offence, and you must, by law, query the recipient's status to make sure that they're not a front for someone on the sanctions list. Similar rules apply in most European countries, although the sanctions list differs - and of course, China and India have their own variations on this theme.

Further, because it's "the benefit of a subscription" that matters, and not the sharing of source, you could well find that sharing just the exact versions of all RPMs in RHEL 9.5 triggers the clause, while sharing the complete kernel source from the version of RHEL you're using on a system does not.

AlmaLinux's response to Red Hat's policy change

madscientist — Thu, 06 Jul 2023 01:04:39 +0000

The reason Red Hat is in a position to make their product in the first place is that they have used work that I (the copyright holder) produced, and I allowed them to redistribute it with the understanding that they would not restrict the freedoms of others that they distributed it to. If the others want to take advantage of the freedoms that I intended them to have, and Red Hat won't allow them to do that without inflicting some harm on them as punishment for exercising that freedom, then they are abrogating that agreement: maybe not according to the courts (we don't know) but certainly morally. If they didn't want to be held to that standard then they should not have made the agreement with me (by using my work).

Of course RH is not obligated to support anyone, and they can stop offering support for all sorts of reasons. If their support contract says they won't support anyone who wears loafers without socks, fine with me. But if it says that they will cancel the contract if someone exercises the freedoms they agreed to allow when they redistributed my software, that's a completely different thing and I have to suspect that difference is obvious to everyone.

I certainly have no problem with Red Hat restricting the redistribution of non-copyleft software (things under the MIT / BSD license for example). In fact they should absolutely do that if they want to; the copyright holders of that software explicitly said they should feel free to do it. But at least some of us who provide GPL'd software have what I think are clear expectations in return for making it available and in my opinion Red Hat isn't meeting those expectations any longer.

Anyway I have no interest in getting into a lengthy back and forth which will no doubt descend ultimately into Godwin's law. The question was asked Honestly, I am asking hoping that somebody with a different perspective can explain to me as I feel like I must not understand and taking that at face value, I've provided an honest explanation to the best of my ability. You may not agree with it but hopefully you understand it, just as I understand your argument... and don't agree with it.

AlmaLinux's response to Red Hat's policy change

pizza — Wed, 05 Jul 2023 22:52:46 +0000

> I'm sorry, but this is a distinction without a difference (IMO). Either you have Freedom 2, or you don't. If you have to query the recipient's status to determine if they're allowed to receive the source before you give it to them, otherwise "Consequences",

Um, if I supply _any_ software to folks in certain countries, I can get thrown in jail. Legally, I'm responsible for making sure that anyone I do business with isn't on one of several "naughty" lists.

By your logic, I therefore don't have Freedom 2 at all.

AlmaLinux's response to Red Hat's policy change

pizza — Wed, 05 Jul 2023 22:46:21 +0000

> However you can only do so under threat that your business may no longer be viable in the future (if you require a Red Hat support contract, which many places do require for various reasons).

There's nothing that forces you to redistribute GPL software you've received; it's just that you can, if you choose to. And similarly, you can choose not to, for any reason whatsoever.

"I choose to not do X because I get something more valuable in exchange" is not only perfectly legal, but is IMO the fundamental underpinning of all human societies.

AlmaLinux's response to Red Hat's policy change

madscientist — Wed, 05 Jul 2023 21:35:09 +0000

> And one difficulty with this argument is that Red Hat doesm't say "if you actually do X that we are required to allow you to do then we'll stop doing business with you"; they say "if you do X in a way that lets someone without a Red Hat subscription get the benefit of that subscription, we'll stop doing business with you after a 30 day notice period expires".

I'm sorry, but this is a distinction without a difference (IMO). Either you have Freedom 2, or you don't. If you have to query the recipient's status to determine if they're allowed to receive the source before you give it to them, otherwise "Consequences", then that's no different _in effect_ than any other proprietary software you happen to have access to the source code for. You are punished for exercising your freedoms that the the software author wanted and expected you to have... "sometimes, with the people we (Red Hat) don't approve of". The punishment won't involve being taken to court but it is there and it can certainly have severe impacts.

AlmaLinux's response to Red Hat's policy change

madscientist — Wed, 05 Jul 2023 21:21:37 +0000

> That should read: "...without losing access to FUTURE releases that Red Hat might create."

Yes, correct. I guess I thought that was clear from the context but maybe not. You can fully exercise your Freedom 2, as they must allow, for the software you already have... anything else would be a _clear_ violation of the GPL. However you can only do so under threat that your business may no longer be viable in the future (if you require a Red Hat support contract, which many places do require for various reasons).

AlmaLinux's response to Red Hat's policy change

farnz — Wed, 05 Jul 2023 20:03:32 +0000

And one difficulty with this argument is that Red Hat doesm't say "if you actually do X that we are required to allow you to do then we'll stop doing business with you"; they say "if you do X in a way that lets someone without a Red Hat subscription get the benefit of that subscription, we'll stop doing business with you after a 30 day notice period expires".

In turn, that means that a lot of distribution of Red Hat Enterprise Linux packages isn't going to trigger Red Hat into cutting you off - giving just one to a consultancy so that they can fix it, or sharing source with someone who already has their own Red Hat subscription agreement isn't going to trigger Red Hat cutting you off.

Whether this is, or isn't in the spirit and intent of F/OSS is a different question, but it's not nearly as cut-and-dried as "if you distribute any RHEL SRPMs, you will immediately lose access to RHEL".

AlmaLinux's response to Red Hat's policy change

Wol — Wed, 05 Jul 2023 19:41:09 +0000

> The recipients of that software get source code. But they cannot exercise the Four Freedoms (specifically Freedom 2) without losing access to the software. Because this can mean loss of livelihood or other serious consequences, _in effect_ they are prevented from exercising Freedom 2, even if _legally_ they are allowed (that is, no one will sue them if they do).

The problem with that, as I see it, is that the people making this argument are missing one FUNDAMENTAL point. They are telling me that I am NOT ALLOWED TO EXERCISE FREEDOM OF CHOICE, which to me is FAR more important than the Four Freedoms.

Okay, as an individual, Freedom 2 is important to me. But as a company not in the software business, Freedom 2 is much less important than staying alive. In fact, Freedom 2 is pretty much worthless! If I can trade that for something I value, like a support contract, there's simply no valid argument not to.

Why should I act in THEIR best interests, rather than my own?

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

pizza — Wed, 05 Jul 2023 19:39:02 +0000

> The recipients of that software get source code. But they cannot exercise the Four Freedoms (specifically Freedom 2) without losing access to the software.

That should read: "...without losing access to FUTURE releases that Red Hat might create."

Under no scenario do they lose access [1] to the software they've already obtained. Nor do they lose access to the complete corresponding source code to this software; if their access to RH systems is cut off -- according to the written offer, RH will supply the complete corresponding source code to your current binaries for $5.

[1] They can't download _new_ copies of said software from Red Hat, but the copies they already have remain fully accessible and functional.

AlmaLinux's response to Red Hat's policy change

madscientist — Wed, 05 Jul 2023 19:02:56 +0000

The argument being made goes like this:

The authors of GPL software believe that all recipients of that software should be able exercise the Four Freedoms.

Red Hat is shipping GPL software; their entire business is predicated on it.

The recipients of that software get source code. But they cannot exercise the Four Freedoms (specifically Freedom 2) without losing access to the software. Because this can mean loss of livelihood or other serious consequences, _in effect_ they are prevented from exercising Freedom 2, even if _legally_ they are allowed (that is, no one will sue them if they do).

Red Hat is saying "we have agreed to a license (GPL) which requires us to allow you to do X, but if you actually do X that we are required to allow you to do then we'll stop doing business with you". There is an argument to be made about whether that complies with the GPL but even if it does, it's certainly reasonable to believe that what they're doing is against the spirit and intent of F/OSS. And that upsets people.

You can say "well, CentOS is almost the same" which may be true, but it's beside the point: the GPL talks about the actual source, not "almost the same" source. You can say "well, people are cheating RH by taking their work and redistributing it without giving back themselves" and that's true, and very unfortunate, and I can sympathize with them about that. But that's also beside the point of the argument being made above.

AlmaLinux's response to Red Hat's policy change

jmalcolm — Wed, 05 Jul 2023 17:59:01 +0000

Can you specifically identify the "loophole" that Red Hat is exploiting? Honestly, I am asking hoping that somebody with a different perspective can explain to me as I feel like I must not understand given the strong emotions Red Hat has aroused.

Some people seem to think that the "loophole" is only providing source to those they directly distribute RHEL to. In my view, that is specifically what the GPL asks you to do. Is "full compliance" the loophole? Not only that, Red Hat actually goes beyond the requirements of the GPL and provides full source to the world at large via CentOS Stream.

Is the loophole that they enforce contract terms above and beyond the license? I guess I can understand that argument but it just seems very straightforward to me that copyright licenses, trademark licenses, patent licenses, and contracts are all different things that can be managed via individual agreements. Having any one of these agreements individually does nothing to imply the others. For example, getting a Red Hat authored package via the GPL license does not entitle you to support from Red Hat unless you have a contract with them ( even though they may have such agreements in place with others ).

Is the loophole that Red Hat is not offering the entirety of RHEL via the GPL? That is obviously not possible as RHEL is made up of a great many individual components made available a number of licenses ( the GPL being only one ). Also, the GPL itself states quite clearly that an "aggregate" that includes a GPL "covered work" is not in any way itself bound by the GPL. So that cannot be the loophole.

So what is the loophole? Or is it one of the above and I just do not understand specifically what makes the situation so intolerable?

For purely optics reasons I was not in favour of this move. Honestly though, the reaction has caused me to side quite firmly with Red Hat. I have not seen a single justification for why CentOS is not good enough and EXACTLY the RHEL packages have to be available that does not boil down to somebody else wanting to make money off RHEL without paying. It seems that it is the "community" that is focused on free as in beer here and not free as in freedom. Making the copycat distributions work a little harder and making it a little harder to claim absolutely that you are identical to RHEL does not sound like a bad thing at all.

AlmaLinux's response to Red Hat's policy change

jmalcolm — Wed, 05 Jul 2023 17:41:52 +0000

Small clarification in that Red Hat provides sources to anybody that they distribute to. As there are several non-paying ways to get RHEL, not everybody that they provide sources to is paying them money. For the purposes of this conversation, the pertinent fact is that they distribute to "subscribers" and all subscribers have accepted contractual terms with them.

Red Hat provides subscribers GPL software via the GPL license and this license empowers them to share the sources. These subscribers agree to contractual terms that specify that they will not. Subscribers that "breach the contract" by distributing RHEL are not subscribers anymore. You are not going to see any GPL license violation suits from Red Hat but you may ( probably will ) see them cancel subscriptions.

Three points that always have to be made in any post regarding this debacle since they are so bitterly misrepresented over and over:

1 -RHEL is a Linux distribution made up of very many packages. Only some of those packages are GPL. Lots of other licenses are used. RHEL contains Red Hat trademarked stuff. RHEL contains Red Hat authored stuff that may not be licensed under the GPL ( thought Red Hat DOES license pretty much all the software they author and contribute to via the GPL - by choice - not force ).

2 - Red Hat makes substantially all their changes available to everybody ( the public ) via CentOS Stream. Red Hat is not taking anything "closed source". What they are doing is obscuring which commit you would have to take for each package to get the "identical" behaviour as their RHEL product. They are not refusing to share source code, they are trying to eliminate exact duplication of their distribution ( not the code -- the packaging if you will ).

3 - With regards to licensing, individual packages are GPL licensed. When the GPL talks about "the work" or a "covered work", it is referring to the individual package. RHEL itself is what the GPL calls an "aggregate". For all those "RHEL has to be licensed under the GPL or it is a violation" folks, here is a sentence pulled verbatim out of the GPL itself ( go read it ): "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate". To say that in a more specific way, according to the actual text of the GPL itself, inclusion of GPL packages in RHEL does not cause the GPL to apply to other parts of RHEL beyond that specific package -- RHEL itself does not fall under the GPL license just because it includes some GPL software. Almost all the bombastic commentary that I read on this completely ignores that this sentence exists. Again, this is not an analysis or opinion, this is the actual wording within the text of the GPL itself.

AlmaLinux's response to Red Hat's policy change

skissane — Wed, 05 Jul 2023 07:33:19 +0000

> I think one needs to bear in mind that the Oracle's of this world can arm twist client companies that use their products (like the oracle database), to switch to Oracles distribution.

> I've seen this happen first hand.

I worked at a place once where we were migrating from Solaris to Linux. We already had some SUSE (since we were a big NetWare shop and Novell had positioned the SUSE-based OES as NetWare's successor.) Our DBA told us that in his past experience, installing Oracle RAC on SUSE was a big pain, because Oracle's install scripts had various SUSE-specific bugs, whereas he said on RHEL it all just worked. We asked him to try again, and he did, and once again got stuck, and Oracle Support wasn't being helpful, so we ruled SUSE out. (This was over 15 years ago, so I hope those bugs are all fixed by now.)

We ended up choosing Oracle Linux over RHEL. Why? (1) We had a pre-existing relationship with Oracle Sales, and they were eager to come visit us in person and sell us on using their Linux, meanwhile we struggled to get Red Hat sales team to agree to come out and visit us; (2) Oracle Linux had a free download on their website so we could "try-before-you-buy", we asked Red Hat for the same and all they told us "we'll get back to you on that" and they never did; (3) the support contract price Oracle was quoting us was significantly less than what Red Hat was quoting; (4) since it was mainly to run Oracle products anyway (RDBMS, Forms, Reports, Portal, LDAP), we thought going with Oracle would reduce the possibility of inter-vendor finger-pointing if things went wrong. I can't remember any Linux support tickets being logged while I was there – we hit a few bugs, but they were all in the Oracle products we were running, not in the underlying Linux. We didn't feel like Oracle was "arm-twisting" us, on the contrary it felt like Red Hat wasn't really trying to win our business.

Disclaimer: I used to work for Oracle (after this all happened), so I can't claim to be a completely unbiased source on this topic

AlmaLinux's response to Red Hat's policy change

farnz — Mon, 03 Jul 2023 12:43:24 +0000

Then you get into the problem of defining "upstream source" sufficiently well to avoid the shell game, without other unintended consequences.

The shell game has party A modify the source, and distribute binaries. Party B gets source and binaries from A, and passes on an unmodified binary to party C. Party C is now in a position to claim that as far as they know, they're distributing binaries from unmodified upstream source; this is backed by an affidavit from party B that they are distributing the binary as supplied to them by party A.

You find out that party C is distributing a binary that doesn't match your source, and start the enforcement process; party C notifies party B who notifies party A, causing party A to be wound up by its owner. Now you have a problem - party C does not have source, but is distributing a binary that's unmodified from the sources party A published (but has stopped publishing now they're out of business). Party B has source, so can seed a new party A, but you've run out of enforcement options, since party B can also prove that they distributed a binary built from unmodified sources from A, and thus they do not have a requirement to publish source, either. Party A does have an obligation to publish their sources, but they no longer exist, so you can't enforce against them.

This is why I've proposed an "ensure people can get the source" requirement, instead of a "distribute sources" requirement - C is then requirement to make sure that people can get the source, but if A is distributing sources, then C meets their requirements by pointing to A's distribution, for as long as A continues to distribute. If A stops distributing, C can't do that any more, and has to find a new way to meet their obligations.

AlmaLinux's response to Red Hat's policy change

paulj — Mon, 03 Jul 2023 12:21:59 +0000

It definitely would need legal review, yes. If others are interested in this kind of licence, and we can iron out any "programmer obvious" issues, definitely be an idea to try approach those, yes.

AlmaLinux's response to Red Hat's policy change

Wol — Mon, 03 Jul 2023 12:10:23 +0000

Bit late to the party, but I guess it's the following:

(1) Oracle re-badge RHEL.
(2) Oracle charge their customer support for rebadged RHEL
(3) Oracle pass the customers' bug reports to RH and do the minimum of support work themselves.

If I were Red Hat (or pretty much any normal human being) I'd be pretty much pissed off at that.

(And this is different to most "play fair" FLOSS guys, because if I'm taking support money, I'd either find the fix myself and upstream it, or talk to upstream and say "we need it fixed, can we negotiate a fee". As I said in a different post, it's the "warm fuzzies".)

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

Wol — Mon, 03 Jul 2023 12:03:00 +0000

An exception I've thought of granting is that downstream can ignore the source requirement AS LONG AS they are distributing binaries that have not been modified from upstream source.

So if they do modify source, they're under pressure to upstream it :-)

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

farnz — Mon, 03 Jul 2023 10:49:49 +0000

Note that you have a potential loophole any time I can distribute a binary without source, where I can play a shell game to ensure that the entities you can pursue for damages don't deploy or distribute modified code, and the entity that modifies code stops existing the moment you try to get hold of the modified code.

If, instead, you put an obligation on all distributors of binaries to ensure source is available (similar to the one I've drafted in this pull request to your FOPL repo), then the loophole is closed. Note, too, that "ensure source is available" does not necessarily require you to host source yourself - if you get a binary from Debian, and you trust Debian to keep source available indefinitely, then you can rely on that safely. Similarly, in a commercial situation, you can pay Collabora to keep hosting source for the binary they gave you until 2 years after you stop using the binary, and thus not have a problem.

Where it gets murky is when binaries are being passed around between individuals - if I die unexpectedly, then sources I'm hosting may go offline. If you're depending on me to host source for a binary that I created as a modification of someone else's source code, and my hosting goes offline, you're now in a problem case - you may not even have bothered to get a copy of the source before the offlining event. But this is somewhere where I'd consider it reasonable to rely on the discretion of the licensors if it happened, since it's a rare case.

AlmaLinux's response to Red Hat's policy change

mathstuf — Sun, 02 Jul 2023 16:43:45 +0000

> Regardless, changing the wording to make the intent - deploying or distributing unmodified code shouldn't trigger source distribution requirement - clear would be good.

What about a compiler with a builtin `-Dsome_internal_function=some_other_internal_function` definition (or similar)? The source isn't modified, but the interpretation is.

AlmaLinux's response to Red Hat's policy change

mathstuf — Sun, 02 Jul 2023 11:49:00 +0000

> It seems much simpler just to make it an unconditional requirement to publish the changes to software in use."

This runs into export and ITAR controls (at least in the US; presumably other countries have similar issues). The US government does have some strong FOSS usage internally, but forcing that to be *public* would definitely curtail a lot of that use (some due to scared lawyers, but mostly probably due to nobody wanting to do the paperwork).

AlmaLinux's response to Red Hat's policy change

Wol — Sun, 02 Jul 2023 10:49:50 +0000

I missed out that - with a contract the third party can make a counter-offer.

And with a contract, the offeror can refuse to accept the third-party's offer/acceptance.

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

Wol — Sun, 02 Jul 2023 10:42:02 +0000

Did you see elsewhere, where I explicitly talked about all this?

If I release something under the GPL, it is an "offer to treat". If a shop puts a price tag on a shelf, it's an "offer to treat".

Both require acceptance by a third party.

The main difference between a licence and a contract is that a licence contains the offeror's acceptance in the offer. A contract doesn't.

Cheers,
Wol