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

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

[nipponmail]

You are incorrect. GPL version 2 section 6 states that one shall not add 
additional restrictions between the agreement between the licensee and 
further licensees. It governs that relationship vis-a-vis the protected 
Work.

GrSecurity has, indeed, stipulated an additional restrictive term.
 From: You may distribute derivative works freely.
GrSecurity has forced customers to agree to: We shall not distribute the 
(non-separable) derivative work EXCEPT to our own customers (when 
required).

That is clearly an additional restrictive term.

Yes, I am a lawyer. A court would not be "tricked" by GrSecurity putting 
it's additional restrictive term in a separate writing. The license is 
instructions about what you are allowed to do with Copyright Holder's 
work; He EXPLICITLY forbade additional restrictive terms.

GrSecurity does not have a pre-existing legal right to create 
non-separable derivative works at all. The default rights are: nothing 
(all rights reservered).

On 2019-11-04 17:36, ams@gnu.org wrote:
> One is not under obligation to guarantee that new versions are
> distributed to someone, which also means obligations can be terminated
> for any reason.  So while grsecurity might not be doing the morally
> and ethically right thing, I do not think they are violating the GNU
> GPL.  You're still free to redistribute the patches, but grsecurity
> isn't under obligation to give you future updates.
> 
> Their agreement text is located at
> https://grsecurity.net/agree/agreement_faq

Re: Will no-one sue GrSecurity for their blatant GPL violation (of GCC and the linux kernel)? - BP and EFF have addressed

[nipponmail]

Bruce Perens and the EFF have addressed this, it is indeed a violation 
to add an additional restrictive term such as that: they are threatening 
a penalty, using a negative covenant, if the customer utilizes the 
permissions granted to him (and GrSecurity) by the Copyright holder of 
the original Work. GrSecurity does not have an independent legal right 
to create non-separable derivative works _at_all_, they only have 
permission to do so IF abiding by the terms the Copyright holder set 
regarding HIS Work: which are NO additional restrictive terms. Here 
GrSecurity HAS added an additional restrictive term: NO free 
redistribution of the derivative work: and they enforce this via 
penalty:

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

Page 10 onward has discussion on the copyright issue aswell:
perens.com/static/OSS_Spenger_v_Perens/0_2018cv15189/docs1/pdf/18.pdf

(And yes, IAAL)


On 2019-11-04 17:36, ams@gnu.org wrote:
> One is not under obligation to guarantee that new versions are
> distributed to someone, which also means obligations can be terminated
> for any reason.  So while grsecurity might not be doing the morally
> and ethically right thing, I do not think they are violating the GNU
> GPL.  You're still free to redistribute the patches, but grsecurity
> isn't under obligation to give you future updates.
> 
> Their agreement text is located at
> https://grsecurity.net/agree/agreement_faq

Re: Will no-one sue GrSecurity for their blatant GPL violation (of GCC and the linux kernel)? - He is violating, but you can also rescind the license

[nipponmail]

You do know, correct?, that the Copyright holder can simply rescind the 
license if he is displeased with the way the licensee is behaving - 
since the license is not supported by a contract.

The licensee would then rush to the Federal Court in his district to 
seek a declaratory judgement regarding his rights, and then you're in a 
diversity and federal-question suit.

But that is an option where the licensee paid no consideration for the 
non-exclusive licensee grant (and no: obeying a pre-existing legal duty 
is not sufficient for consideration)

I would like to note that in the Kasner(sp)? decision in the 9th circuit 
the uneducated like to bandy about; the Artistic License was found NOT 
to be a contract but a simple copyright license.

Also in the lower-court (California) Artifex decision the court didn't 
even identify the "GPL" correctly, conflating it with the 
offer-to-do-paying-bushiness preliminary writing (pay us, or accept the 
GPL), but the court then allowed the Copyright holder to choose which 
theory to go ahead with: Contract damages for the price of the 
proprietary license OR pure Federal Copyright damages under the GPL 
(because the GPL is not a contract: it's only a license. If the court 
found it to be a contract it would limit the recovery to contract 
damages under state law: which is WHY in Kasner the violator wanted the 
Artistic license to be deemed a contract: damages of 0 (free))

However, GrSecurity is violating the GPL so you can just sue for 
Copyright damages off the bat (as my other 2 posts quickly explain, I 
haven't repeated the arguments here).

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

[nipponmail]

It does not matter how common this way of doing buisness is.
It is still a blatant violation of the Copyright holders terms.

The Copyright holder has allowed GrSecurity to do something they, by 
default, have no right to do (create and distribute [non-seperable] 
derivative works), ONLY if they follow the Copyright holder's 
directives.

The Copyright holder has stipulated that each distributee has the 
permission to FREELY create derivative works based on the work and 
FREELY distribute said original work and said derivative works, but that 
they ONLY have this permission IF they also extend those rights to 
down-the-line-distributees AND they DO NOT add ANY additional 
_RESTRICTIONS_ on that right.

If GrSecurity was _NOT_ adding an additional restriction it would NOT 
need an "access agreement" (no-redistribution agreement).

They are BLATANTLY violating section 6.

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

Please.

The reason why this business model works is because:

1)Not-any-old-lawyer can walk into Federal Court.
You have to be accepted into the Federal Bar for that 
district/circuit/etc (IIRC). Which means one of the 
allready-on-federal-bar lawyers has to allow you in and vouch for you. 
That makes for fewer high priced lawyers

2) The costs will be high: half a million plus in legal fees in the end.

3) You win court-costs ONLY if you have registered your copyright BEFORE 
the violation you are suing defendant over, and also BEFORE any 
same/similar violation. Otherwise you only get regular damages (revenue, 
or profits, or what the defendant would have paid you for a license (0 
dollars), whichever the court wishes). (Note: you have to register your 
copyright at the time of the suit atleast, but if it is after the 
violations you don't get statutory damages nor do you get attorney's 
fees)

Also read this EFF brief, page 10 etc. It has some discussion on the 
violation: 
perens.com/static/OSS_Spenger_v_Perens/0_2018cv15189/docs1/pdf/18.pdf

On 2019-11-04 21:14, Florian Weimer wrote:
> * nipponmail:
> 
>> You are incorrect. GPL version 2 section 6 states that one shall not 
>> add
>> additional restrictions between the agreement between the licensee and
>> further licensees. It governs that relationship vis-a-vis the 
>> protected
>> Work.
>> 
>> GrSecurity has, indeed, stipulated an additional restrictive term.
>>  From: You may distribute derivative works freely.
>> GrSecurity has forced customers to agree to: We shall not distribute 
>> the
>> (non-separable) derivative work EXCEPT to our own customers (when
>> required).
>> 
>> That is clearly an additional restrictive term.
> 
> I assume they did this as part of their subscription agreement.  Their
> customers are free to terminate that agreement and exercise their
> rights under the GPL.  They just can't have it both ways.
> 
> I believe this a fairly common approach to subscription and service
> agreements for GPL software.