That language is referring to copyright permissions (i.e. promising not to sue people for copyright infringement for using or distributing the software in accordance with the GPL). It doesn't refer to providing access.
A trickier thing for Red Hat might be
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
One may argue about how to interpret that with regard to, for example, terminating a business relationship as a result. (I could see arguments on both sides.)
Also, Red Hat's method for complying with section 3 could be a subtle issue, because one of the options for compliance requires promising to provide "any third party" with the source code upon request. I don't know whether Red Hat is using that option or a different option.
>One may argue about how to interpret that with regard to, for example, terminating a business relationship as a result
I think there's been far too little focus on this, which is the crux of it. IMO (an IANAL) it seems pretty clear that even though this is not an explicit new license condition, it de facto does prevent redistribution: i.e. "you can do business with us, but only if you do not exercise one of your rights" in de facto limiting that right
I would love to see this adjudicated. Is there a company that builds statically against RHEL and resells, or modifies RHEL as a paying customer and resells that could show material injury by this move?
>> You may not impose any further restrictions on the recipients' exercise of the rights granted herein
Is it all that obvious or clear that "if we don't like what you do with our stuff, we will not renew your contract next year or sell you anything anymore" a restriction on the software they already delivered?
The software to which that clause applies was already delivered, and redhat is not, as far as I know, applying any restrictions on that software.
As a company, they are not obliged to sell to anyone who shows up with the sticker price, so this doesn't look, to me, like a restriction on the software itself.
After all, the right to choose your customers is a very basic one that only has few exemptions related to individuals in protected classes.
> Is it all that obvious or clear that "if we don't like what you do with our stuff, we will not renew your contract next year or sell you anything anymore" a restriction on the software they already delivered?
Red Hat is not using that option. In fact GPLv3 restricts that option to physical products, which RHEL is not. By distributing the packages via SRPMs, Red Hat has a single method that complies with GPLv2, GPLv3 and also with the attribution requirements of permissive licenses.
Recent versions of RHEL actually include a GPLv2-oriented written offer for source, but this is in addition to Red Hat simultaneously making corresponding source available along with binaries (for all packages regardless of license).
It's explicitly valid for any third party. I would assume that a customer could use it even where (as should normally be the case) the customer would have source code access under 3a.
There are a lot of drawbacks to use of the written offer option so I'm not sure if Red Hat will continue to use it with RHEL in the future.
I suspect that RH is not complying with the GPLv2. I can use yum to install a package from RH’s repo and it does not result in me having the source, so 3a is out. They don’t offer to distribute source code at cost to any third party, so no 3b. And 3c is non commercial distribution, so that’s out. There is no 3d.
You only need to enable the companion source repo(s) to get access to the source. To be able to access the binary & source repos via our CDN, you need to be a registered “customer” of Red Hat (which includes no-cost developer account agreements) which then gives credentials to access our CDN. If you have a valid credential to pull binary RPMs, you also have access to pull source RPMs.
> They don’t offer to distribute source code at cost to any third party, so no 3b.
If you are a customer of RHEL, then you do in fact have the ability to request a copy of the source code, including on physical media, and the ability to download it yourself from the customer portal, or from the srpm repositories.
The entire change is that the source code is now only being published in 2 places (CentOS stream and the customer portal) instead of 3 (the following two plus git.centos.org). I suppose it's 3 places instead of 4 if you include the srpm repositories.
Maybe that's covered as a 3a distribution by this additional language?
> If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
A trickier thing for Red Hat might be
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
One may argue about how to interpret that with regard to, for example, terminating a business relationship as a result. (I could see arguments on both sides.)
Also, Red Hat's method for complying with section 3 could be a subtle issue, because one of the options for compliance requires promising to provide "any third party" with the source code upon request. I don't know whether Red Hat is using that option or a different option.