Why does no one care that Brad Spengler of GRSecurity is blatantly violating the intention of the rightsholders to the Linux Kernel?
Why does no one care that Brad Spengler of GRSecurity is blatantly violating the intention of the rightsholders to the Linux Kernel? He is also violating the license grant, Courts would not be fooled by his scheme to prevent redistribution.
The license grant the Linux Kernel is distributed under disallows the imposition of additional terms. The making of an understanding that the derivative work must not be redistributed (lest there be retaliation) is the imposition of an additional term. The communication of this threat is the moment that GRSecurity violates the license grant. Thence-forth modification, making of derivative works, and distribution of such is a violation of the Copyright statute. The concoction of the transparent scheme shows that it is a willful violation, one taken in full knowledge by GRSecurity of the intention of the original grantor.
Why does not one person here care? Just want to forget what holds Libre Software together and go the way of BSD?
(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.).
------ ( This song is about GRSecurity's violation of Linus et al's copyright**: youtube watch?v=CYnhI3wUej8 (A Boat Sails Away 2016 17) )
On Thu, Jun 15, 2017 at 11:39 AM, aconcernedfossdev@airmail.cc wrote:
Why does no one care that Brad Spengler of GRSecurity is blatantly violating the intention of the rightsholders to the Linux Kernel? He is also violating the license grant, Courts would not be fooled by his scheme to prevent redistribution.
The license grant the Linux Kernel is distributed under disallows the imposition of additional terms. The making of an understanding that the derivative work must not be redistributed (lest there be retaliation) is the imposition of an additional term. The communication of this threat is the moment that GRSecurity violates the license grant. Thence-forth modification, making of derivative works, and distribution of such is a violation of the Copyright statute. The concoction of the transparent scheme shows that it is a willful violation, one taken in full knowledge by GRSecurity of the intention of the original grantor.
Why does not one person here care? Just want to forget what holds Libre Software together and go the way of BSD?
(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.).
Okay, I'll bite. Fedora, as a matter of policy, only ships one kernel variant, the upstream kernel. We have never used the PaX/grsec patchset as it is fundamentally incompatible with other security mechanisms we use in Fedora and breaks userspace without concern. So, the whole matter of what PaX/grsec do is pretty much irrelevant to Fedora because we never shipped it.
I'm sure there are people who are concerned about this matter, but as a project, Fedora is not really involved in that mess.
You may have kernel contributors within you organization or association; there is a fairly good chance their copyright is being violated now by GRSecurity (Brad Spengler and PaX Team) (Since GRSec code snakes through nearly the entirety of the Linux Kernel code tree). If said copyright is not defended, it is not far fetched to imagine that more and more entities will see that there is no teeth to the license grant and basically will treat your code as if it were BSD licensed. The "payment" one gets for working on a work licensed under a CopyLeft license is labor: the derivative works. If that incentive is known to no longer exist I imagine less people will contribute.
It will become a "good in theory, does no longer work in practice" situation and Linux will be in the same state as BSD with less individuals willing to sacrifice their time to donate code to entities that will never give back.
I don't think it is a good idea to let this one go.
On 2017-06-15 16:02, Neal Gompa wrote:
On Thu, Jun 15, 2017 at 11:39 AM, aconcernedfossdev@airmail.cc wrote:
Why does no one care that Brad Spengler of GRSecurity is blatantly violating the intention of the rightsholders to the Linux Kernel? He is also violating the license grant, Courts would not be fooled by his scheme to prevent redistribution.
The license grant the Linux Kernel is distributed under disallows the imposition of additional terms. The making of an understanding that the derivative work must not be redistributed (lest there be retaliation) is the imposition of an additional term. The communication of this threat is the moment that GRSecurity violates the license grant. Thence-forth modification, making of derivative works, and distribution of such is a violation of the Copyright statute. The concoction of the transparent scheme shows that it is a willful violation, one taken in full knowledge by GRSecurity of the intention of the original grantor.
Why does not one person here care? Just want to forget what holds Libre Software together and go the way of BSD?
(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.).
Okay, I'll bite. Fedora, as a matter of policy, only ships one kernel variant, the upstream kernel. We have never used the PaX/grsec patchset as it is fundamentally incompatible with other security mechanisms we use in Fedora and breaks userspace without concern. So, the whole matter of what PaX/grsec do is pretty much irrelevant to Fedora because we never shipped it.
I'm sure there are people who are concerned about this matter, but as a project, Fedora is not really involved in that mess.
(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.)
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.)
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.)
Then that is an additional term imposed not present in the linux licensing agreement and Red Hat _is_ violating the terms. Additional terms can be verbal, or communicated in some other way other than a writing.
However:
(and almost all of them are just backports from upstream anyway)
Makes it quite unlikely that a rights-holder would feel harmed by said copyright violation.
RedHat, however cannot, on the side, impose additional terms. They have made a business decision, however, to violate the terms and Linus et al have made a similar decision to not enforce said terms on RedHat since RedHat does alot of open kernel work (why bite the hand that feeds you over a legal technicality?).
The situation with GRSecurity is distinguishable in that the violator has successfully stymied any distribution of it's derivative work via the imposition of an additional term, and this derivative work is not reachable by the linux-kernel rightsholders: thus they may feel injured.
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@lists.fedoraproject.org To unsubscribe send an email to legal-leave@lists.fedoraproject.org
-
aconcernedfossdev＠airmail.cc -
Florian Weimer -
Neal Gompa