I must be ancient then. I recognized, and I think used, all of those cards/chips.

Some personally. Some at work. At work I used to maintain and MS-DOS / early Windows graphics program. I had to test the program’s compatibility with a stack of graphics cards.

Not what they did on the surface (limiting source to only customers). That’s allowed by the GPL. But they went beyond that which imo makes them non-compliant.

1. RH will cancel your access/agreement if you share the GPL’d source with others. That’s directly forbidden by section 6 of the GPLv2. RH is free to cancel your agreement when they want, but not because you exercised your rights under the GPL.

2. Once your agreement is canceled, you also lose access to the matching source for other GPL’d packages installed on your system. RH could offer other methods to be in compliance, but as far as I know, they have not.

Again, less than half of RHEL is even software released under the GPL.

I would be completely shocked if this were true. I’m calling BS here.

I used to be my company’s primary contact for our Red Hat TAM for almost 13 years. Our TAMs were very proud to claim that all of RHEL was FOSS software, licensed under the GPL or sometimes other FOSS licenses.

I spun up a RHEL 9.2 instance and ran:

$ sudo dnf list --all | wc -l
6671
$ dnf info --all | grep "^License .*:.*GPL.*" | wc -l
4344
$ python -c "print(4344/6673 * 100)"
65.11767351221705

So 65% of RHEL 9’s packages are under a GPL license.

Much of the software that is GPL was authored by Red Hat themselves. According to the text of the GPL itself, Red Hat is not required to distribute the code to the totality of the RHEL distribution or even to more than half the code.

Half?!? Again, where are these mysterious numbers coming from?

It doesn’t matter if Red Hat authored those packages or not. What matters is if they were distributed under a GPL license. If you’re claiming that Red Hat multi-licensed those GPL’d packages that they exclusively wrote so they don’t have to comply with the GPL, please point those out to me (or at least a few), so I can check them out.

As far as I understand, this discussion is still theoretical because Red Hat has not terminated anyone’s subscription or account yet due to distributing GPL’d source to a Red Hat product, so everything’s an assumption until it happens. Do you know if they have that has been publicly disclosed?

And guess what, they will give it to you.

Have they explained how they will do that after terminating my subscription?

I offered some alternative methods to how Red Hat could be GPL compliant. As far as I know, they have not disclosed such a process that meets the terms of the GPL.

They do not restrict your rights in any way with regards to the software they have already given you.

By terminating access to the source for GPL’d software I’ve already installed, yes, they have, unless they/you can clarify how they will still allow me to access the matching, buildable source for the binary packages I’ve already installed on my system.

Normally, I would download the matching source for a package via the dnf or other related tools, but they won’t work if my RHEL subscription or account is terminated. I would like to hear this new method. I offered a couple under my earlier post as possible examples.

Anyway, that’s inconsequential. By applying any additional restrictions when exercising the GPL granted rights, this violates the GPL. Those restrictions don’t have to be on the rights themselves, they just have to come into effect when the rights granted by the GPL are exercised, which in this case, they do.

As quoted earlier, GPLv2 section 6 states, “You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” It does not say, “You may not impose any further restrictions on the rights granted herein.” It’s not the rights themselves, but the mere exercise of those rights. As I mentioned before, what good is a right to vote if additional restrictions can be included such as paying a fine or tax? This is what section 6 is meant to prevent others from doing.

A cancelled subscription does not cause me to lose access to the software that has been distributed to me or to any of the rights and freedoms as stated in the licenses ( GPL and otherwise ) for the software that Red Hat has distributed to me.

You keep saying that, but not mentioning how. Would you please clarify for me how I access the buildable source for the exact version and release of a package I have already installed on my system post-termination of my subscription? Maybe I have missed this in Red Hat’s publications on this matter?

The subscription is not a software license, it is a contract.

It is a contract that includes licenses that are part of it, so I’m not sure of your point here?

Contract law comes into effect here. And fulfilling or breaking the terms of the licenses included as part of the contract are also in play.

As mentioned, there are certainly ways for Red Hat to terminate aspects of the RHEL support agreement that would comply with the GPL. I certainly accept Red Hat has the rights to terminate future access to newer versions of binaries or sources covered by the GPL. There are ways for them to do that without violating the GPL, and I would like to see them do that, but so far I’ve not seen how they will comply.

RHEL itself is not licensed under the GPL and so the whole premise is wrong on its face. The subscription agreement is for RHEL itself.

But components of RHEL are licensed under the GPL. The subscription agreement in part is how Red Hat fulfills the terms of the GPL for those components, so could you clarify the point of your statement?

If the RHEL software under the GPL did not rely on a working subscription for fulfilling GPL terms, then that would decouple the RHEL subscription from the GPL and covered components, but I have not seen a description yet of how Red Hat will do that.

Thank you for replying. I’ve had these points and questions for some time, but I have not seen a good rebuttal from someone GPL knowledgeable with Red Hat’s position. If you can clarify and answer the points above, that would help.

I would say that cancelling your subscription is a direct violation of the GPL for two reasons.

For example, say I’m someone who installed RHEL under a subscription. I downloaded the source to the kernel then distributed the SRPM to others leading Red Hat to cancel my subscription/account.

1. With a cancelled subscription/account, how do I now access the buildable source for say the GCC package I have installed on my system as guaranteed under the GPL?

   If Red Hat didn’t cancel my subscription/account, but restricted it to only accessing the matching source downloads for the packages on my system, that would be compliant. But they didn’t. They killed all my access for matching source which is non-compliant.

   If Red Hat provided a service where I could request buildable copies of the source for the packages I have installed , this would be compliant. But as far as I know, they have not.

2. Cancelling my subscription/account is a violation of Section 6 of the GPLv2 which states, " You may not impose any further restrictions on the recipients’ exercise of the rights granted herein."

   This clause is to ensure you can freely exercise your rights granted by the GPLv2. Cancelling your subscription/account for no reason other than exercising your rights is a direct violation.

   For example, I have the right to vote. If a government body imposes a hefty fine or tax if I attempted to vote, this would be considered further restrictions on my right to vote. This is what Red Hat has done.

   Red Hat is certainly free to cancel your subscription/account under the terms of their license, but not when it conflicts with the exercise of rights granted under the GPL.

All of them. Corp directive (now) is that hosts must be updated or reimaged every 90 days.

I think they’re trying to simplify the exposed interfaces simplifying everyone else’s job at the expense of making a more complex implementation.

At my company, we have around 400,000 servers in production. When we last surveyed them, we found several thousand over 12 years old, with the oldest at 17 years. And that wasn’t counting our lab and admin servers which could run even older because they’re often repurposed from prod decomms.

We had a huge internal effort to virtualize their loads, but in the end, only about 15% were transferred just due to the sheer number of hidden edge cases that kept turning up.