Re: Why will no-one sue GrSecurity for their blatant GPL violation (of GCC and the linux kernel)?

Re: Why will no-one sue GrSecurity for their blatant GPL violation (of GCC and the linux kernel)?

[gameonlinux]

I am a lawyer. GrSecurity is violating section 6 of version 2 of the 
GPL, which is the license in question.

GrSecurity does not have an independent right to create nor distribute 
non-separable derivative works of the Work(s) in question. By default 
they have NO right to do so.

The copyright holders have unilaterally granted permission (it is not a 
contract: there is no consideration (payment) on the side of GrSecurity 
in-order to receive these permissions) to others, but not in an 
unlimited fastion.

The Copyright holders have chosen to decide that any derivative work can 
ONLY be distributed if NO additional restrictive terms are proffered 
between the licensee and furthur licensees.

Section 6 states this. If the licensee proffers additional restrictive 
terms his license is terminated [(note: the copyright holder, in this 
case, can also step in and terminate the license for any reason he 
wishes: the free-licensee does not have any contract-law 
breach-of-contract defenses to raise against the copyright owner since 
there is no contract: only a copyright license (permission) (not a 
copyright license contract (bargained for rights purchased from the 
copyright owner))].

Here GrSecurity (Open Source Security) has, indeed, produced an 
additional restrictive term governing the relationship between it and 
the further-licensees relating back to the Work(s) in question.

GrSecurity's restrictive covenant can also be shown to the court to have 
been a success additionally: no down-the-line licensee has defied it and 
released the source code.

Under the Original Copyright Owners writing, which is explained in 
detail in the license, the down-the-line licensees are to have Free 
choice in distributing any derivative work (obviously the derivative 
work has to be non-seperable, grsec is non-seperable, that is not in 
dispute). Here GrSecurity requires them to agree /not/ to ever exercise 
that which the Copyright holders explicitly permitted and forbade the 
excision of.

Yes, GrSecurity's writing is an additional restrictive term, yes they 
are violating the express terms of the license, yes they are committing 
copyright infringement, yes their license has terminated.

And yes IAAL.

The courts do NOT take your 
absolute-literal-we-can't-do-anything-about-it programmer's approach.

Anyway, I was not asking if you think it is a violation: I know it is a 
violation, and a blatant one at that: I'm asking why no-one will SUE 
them for it, so far.

You can read a good write-up here:
perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/




On 2019-11-05 11:19, Paolo Bonzini wrote:
> On 31/10/19 20:23, gameonlinux@redchan.it wrote:
>> RMS:
>> Could you share your thoughts, if any, of why no one will sue 
>> GrSecurity
>> ("Open Source Security" (a Pennsylvania company)) for their blatant
>> violation of section 6 of version 2 of the GNU General Public License?
>> 
>> Both regarding their GCC plugins and their Linux-Kernel patch which is 
>> a
>> non-separable derivative work?
>> 
>> They distribute such under a no-redistribution agreement to paying
>> customers (the is the only distribution they do). If the customer
>> redistributes the derivative works they are punished.
> 
> IANAL, but see after my signature an email about a similar case.
> Unfortunately some pieces of that story are lost to bitrot and broken
> links, but the text quoted there is from a former GPL compliance 
> manager
> at the FSF.
> 
> tl;dr, the GPL does not forbid GrSecurity from rejecting money from
> people that have exercised their rights under the GPL.  And anyway, if
> anything it would be a breach of contract law (similar to some episodes
> involving gay marriage) and not copyright.
> 
> Should a future GPLv4 cover this case?  Is it even possible?  I have no
> idea and this is off topic anyway, so let's all cut this thread short.
> 
> Paolo
> 
>> Xref: main.gmane.org gmane.org.freifunk.wlanware:251
>> 
>> [...]
>> 
>> Subject: [WRT54G] FSF fully aproces the Sveasoft subscription model
>> Date: Freitag 18 Juni 2004 00:47
>> From: "sveasoft" <james.ewing-yJk5bNGmrfNWk0Htik3J/w@public.gmane.org>
>> To: WRT54G-hHKSG33TihhbjbujkaE4pw@public.gmane.org
>> 
>> The final word on the Sveasoft subscription model has been rendered
>> by the FSF. The FSF concludes that the Sveasoft model is fully
>> compliant with the GNU license stipulations.
>> 
>> Transcript:
>>>   Okay, so here is the Sveasoft business model, as I understand
>>>   it:
>>> 
>>>     1. Sveasoft produces GPL'ed code which runs on a GNU/Linux based
>>>    router.
>>> 
>>>     2. Sveasoft distributes pre-releases of their software on a
>>>    subscription basis and provides priority support to the 
>>> subscribers.
>>> 
>>>     3. The pre-releases are offered under the GPL and subscribers
>>>     are entitled to distribute them publicly if desired.
>>> 
>>>     4. If a subscriber *does* redistribute the pre-release code
>>>     publicly, before it becomes a production release, they are
>>>     considered to have "forked" the code and do not receive future
>>>     pre-releases under the subscription program.
>>> 
>>>     5. Once a pre-release works its way through the testing
>>>     program and becomes a production release, it is made available 
>>> under
>>>     the GPL for public download, both "free-as-in-speech" and 
>>> "free-as-in-
>>>     beer".
>>> 
>>>   James, please step in here if I've missed anything, or if I
>>>   haven't accurately characterized some piece of the above.
>>> 
>>>   I look forward to getting the FSF compliance lab's feedback on
>>>   Sveasoft's business model.  Thanks for your help!
>>> 
>>> Hi Rob,
>>> 
>>> I would just underscore that whenever we distribute binaries they
>>> are *always* accompanied by the source code.
>>> 
>>> Subscribers are free to do whatever they like with the
>>> pre-releases with the proviso that if they distribute it publicly
>>> we are not responsible for support and they need to develop the
>>> code further themselves from that point forward.
>> 
>> I see no problems with this model. If the software is licensed
>> under the GPL, and you distribute the source code with the binaries 
>> (as
>> opposed to making an offer for source code), you are under no 
>> obligation to
>> supply future releases to anyone.
>> 
>> Please be clear that the subscription is for the support and
>> distribution and not for a license.
>> 
>> Peter Brown
>> GPL Compliance Manager
>> Free Software Foundation

Why will no-one sue GrSecurity for their blatant GPL violation (of GCC and the linux kernel)?

[gameonlinux]

(Note: Sending here now as this the other list was for tech discussions 
instead)

RMS:
Could you share your thoughts, if any, of why no one will sue GrSecurity 
("Open Source Security" (a Pennsylvania company)) for their blatant 
violation of section 6 of version 2 of the GNU General Public License?

Both regarding their GCC plugins and their Linux-Kernel patch which is a 
non-separable derivative work?

They distribute such under a no-redistribution agreement to paying 
customers (the is the only distribution they do). If the customer 
redistributes the derivative works they are punished.

That is: GrSecurity (OSS) has created a contract to /Defeat/ the GPL and 
has done so successfully so far. Very successfully. The GPL is basically 
the BSD license now, since such as been allowed to stand.

This is how businesses see the GPL. They are no longer afraid: They will 
simply do what GrSecurity has done. Something that was supposed to stay 
liberated: a security patch that helped users maintain their privacy by 
not being immediately rooted when using a linux kernel on a GNU system; 
is now non-free.

With this the GPL _fails_.

NO ONE has sued GrSecurity. Thus they are seen as "having it right" 
"correct" "we can do this".

Wouldn't the FSF have standing regarding the GCC plugins atleast?
Couldn't you all rally linux-kernel copyright holders to bring a joint 
action?

References:
perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/

perens.com/static/OSS_Spenger_v_Perens/0_2018cv15189/docs1/pdf/18.pdf
(Page 10 onward of this brief gives a good recitation of the facts and 
issues