Since any changes to the source code Redhat makes eventually flows back
to the rights-holders, even if there was a technical violation, it would
be unlikely that said rights-holders to the Linux Kernel (of which
RedHat itself is one) would bring suit, and even if a suit was brought
what would the damage to the rights-holders be? They received the
derivative work (source code).
The point, more or less, in the RedHat situation is moot since the
derivative source code is distributed and makes it's way into the hands
of the original rights-holders, the dispute is just simply over it's
form, and how it's accessed, if it's convenient etc. It's unlikely the
rights-holders would bother with a case since the appear uninjured and
still benifit as they intended to when they adopted the GPL (they put
out source code, and derivative works are in fact freely distributed).
Basically the line was walked up to, but if crossed, not in a way that
would cause a claim of damages to arise (as far as I see).
As you said: this was mostly all-ready available backports etc. RH
doesn't seem to be making kernel enhancements and then preventing those
enhancements from being distributed.
The GRSecurity situation is wildly different though the scheme seems
familiar at first glance.
Here the aim is to prevent any further distribution of the derivative
work which comprises of kernel enhancements, and said scheme has been
successful: not one line of the now closed source has been "leaked".
Customers of GRSecurity have stated publicly that they dare not do such
under threat of retaliation by canceling of any future business
dealings. GRSecurity has taken the derivative work hostage and has
successfully prevented further distribution.
On 2017-06-15 17:56, Florian Weimer wrote:
(Note: last month the GRSecurity Team removed the public testing
patch,
they prevent the distribution of the patch by paying customers by a
threat of no further business: they have concocted a transparent
scheme
to make sure the intention of the Linux rights-holders (thousands of
entities) are defeated) (This is unlike RedHat who do distribute their
patches in the form the rights-holders prefer: source code, RedHat
does
not attempt to stymie the redistribution of their derivative works,
GRSecurity does.).
I don't think Red Hat distributes the Red Hat Enterprise Linux 7
kernels to the general public, only to customers who have entered a
subscription agreement. Debranded kernel sources are available from
centos.org, though.
Based on what I have read, the legal construction for the Red Hat
agreement and the grsecurity agreement are somewhat similar. Source
code access is a subscription service (among many others in the case
of Red Hat), and you cannot use a subscription to provide the very
same service you obtain from the provider to third parties.
The situation with Red Hat Enterprise Linux is further complicated
because as part of the subscription services, subscribers can access
the Red Hat Code Browser, which provides broken-out and fully
cross-referenced kernel patches, something that is not available as
part of the CentOS offering. The GPL certainly allows subscribers to
share these patches freely (and almost all of them are just backports
from upstream anyway), but I think Red Hat's intent is that this is
not permitted while the subscription agreement is in force. (And
subscribers are expected not to use these patches to support their own
kernel backporting efforts, either.)
_______________________________________________
legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx
