It has come to my attention that some entities are claiming that you,
dear Linux Hackers, (1)need to go through some foundation or get some
permission from upon high in-order to sue the progenitors of GRSecurity
for their violation of section 6 of the terms underwhich the linux
kernel is distributed (version 2 of the GPL). And, furthermore, that
(2)this foundation has no intention of bringing such a suit.
(1) is false.
(2) may very well be true.
You do have standing to sue GRSecurity for their blatant continuing
copyright violation if GRSecurity has made a derivative work of your
code contribution to the Linux Kernel as-long as (a)you have not
assigned your copyrights, and (b)you are not a work-for-hire.
How do you know if you are a work for hire or if you have signed away
your copyrights?
If you are working for a company and as your job duties you are
programming the linux kernel, there is a good chance that you are a work
for hire and thus the company owns said copyrights.
How do you know if you signed away your copyrights? Well if you singed a
document transferring ownership of your copyrights for the code you
produced at some point.
If you are not working for a company while hacking linux and you haven't
assigned your copyrights away then YOU OWN YOUR CONTRIBUTIONS.
This means most of you hobby hackers, if GRSecurity has modified your
code, YES YOU HAVE STANDING TO SUE.
Yes your "betters" are lying to you.
You have individual separate standing to sue.
Yes you SHOULD consult a lawyer of your own.
Yes you SHOULD consider a joint filing with other individual
rights-holders willing to bring suit against GRSecurity for their
blatant violation of your terms, and yes you should consider starting
CLASS ACTION since the number of Linux Kernel Contributors seemingly
numbers in the multitudes upon multitudes upon multitudes.
And yes, I am an attorney.
But no, I'm not looking for clients. Just correcting some false
information that has been spreading.
And yes, GRSecurity will try to claim that the linux-kernel is a work of
Joint ownership (so as to shield themselves via procedural law) and yes
they will try to claim fair use (probably de minimus), and yes your
Lawyer will have to respond to these claims. The Joint ownership claim
will go down quickly but it will have to be responded to. De minimus
Fair Use depends on how much code is modified and how signifigant the
modifications are. Don't let anyone but your own legal council dissuade
you from bringing suit: Remember the statute of limitations is only a
few years, so the clock is ticking on the CURRENT violation.
Also make sure you register your copyright of the version of the
linux-kernel that GRSecurity is using in its violation prior to bringing
suit. The registration must be for the specific version. Yes you can
register after the violation has occurred, however if you have
registered before the violation then you can also pursue recovery of
legal fees, pursue statutory damages, etc.
( NOTE: If you would like to read on how your copyright is being
violated by GRSecurity, Bruce Perens posted a good write-up on his
web-page )
(
perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/
)
( There was also a discussion on the linux section of slashdot, and on
the debian user mailing list, and on the dng devuan mailing list and on
the openwall mailing list and the fedora legal mailing list )
I have not contributed to the kernel for some time (I have been
working on some stuff, but nothing that's been contributed), so I
don't know if any of my code would be infringed (or if it's even in
the latest kernels).
My work was on AGP and VIA drivers, so I am wondering if GRSecurity's
patches affect that code?
Thanks,
PGA
On Sat, Jul 29, 2017 at 7:06 AM, <[email protected]> wrote:
> It has come to my attention that some entities are claiming that you, dear
> Linux Hackers, (1)need to go through some foundation or get some permission
> from upon high in-order to sue the progenitors of GRSecurity for their
> violation of section 6 of the terms underwhich the linux kernel is
> distributed (version 2 of the GPL). And, furthermore, that (2)this
> foundation has no intention of bringing such a suit.
>
> (1) is false.
> (2) may very well be true.
>
> You do have standing to sue GRSecurity for their blatant continuing
> copyright violation if GRSecurity has made a derivative work of your code
> contribution to the Linux Kernel as-long as (a)you have not assigned your
> copyrights, and (b)you are not a work-for-hire.
>
> How do you know if you are a work for hire or if you have signed away your
> copyrights?
> If you are working for a company and as your job duties you are programming
> the linux kernel, there is a good chance that you are a work for hire and
> thus the company owns said copyrights.
>
> How do you know if you signed away your copyrights? Well if you singed a
> document transferring ownership of your copyrights for the code you produced
> at some point.
>
> If you are not working for a company while hacking linux and you haven't
> assigned your copyrights away then YOU OWN YOUR CONTRIBUTIONS.
>
> This means most of you hobby hackers, if GRSecurity has modified your code,
> YES YOU HAVE STANDING TO SUE.
>
> Yes your "betters" are lying to you.
> You have individual separate standing to sue.
>
> Yes you SHOULD consult a lawyer of your own.
> Yes you SHOULD consider a joint filing with other individual rights-holders
> willing to bring suit against GRSecurity for their blatant violation of your
> terms, and yes you should consider starting CLASS ACTION since the number of
> Linux Kernel Contributors seemingly numbers in the multitudes upon
> multitudes upon multitudes.
>
> And yes, I am an attorney.
> But no, I'm not looking for clients. Just correcting some false information
> that has been spreading.
>
> And yes, GRSecurity will try to claim that the linux-kernel is a work of
> Joint ownership (so as to shield themselves via procedural law) and yes they
> will try to claim fair use (probably de minimus), and yes your Lawyer will
> have to respond to these claims. The Joint ownership claim will go down
> quickly but it will have to be responded to. De minimus Fair Use depends on
> how much code is modified and how signifigant the modifications are. Don't
> let anyone but your own legal council dissuade you from bringing suit:
> Remember the statute of limitations is only a few years, so the clock is
> ticking on the CURRENT violation.
>
> Also make sure you register your copyright of the version of the
> linux-kernel that GRSecurity is using in its violation prior to bringing
> suit. The registration must be for the specific version. Yes you can
> register after the violation has occurred, however if you have registered
> before the violation then you can also pursue recovery of legal fees, pursue
> statutory damages, etc.
>
>
> ( NOTE: If you would like to read on how your copyright is being violated by
> GRSecurity, Bruce Perens posted a good write-up on his web-page )
> (
> perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/
> )
> ( There was also a discussion on the linux section of slashdot, and on the
> debian user mailing list, and on the dng devuan mailing list and on the
> openwall mailing list and the fedora legal mailing list )
>
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting
http://www.randomlogic.com
On Sat, Jul 29, 2017 at 09:32:36AM -0600, Paul G. Allen wrote:
> I have not contributed to the kernel for some time (I have been
> working on some stuff, but nothing that's been contributed), so I
> don't know if any of my code would be infringed (or if it's even in
> the latest kernels).
>
> My work was on AGP and VIA drivers, so I am wondering if GRSecurity's
> patches affect that code?
It's not even clear that there is infringement. The GPL merely
requires that people who have been distributed copies of GPL'ed code
must not be restricted from further redistribution of the code. It
does not require that that someone who is distributing it must
available on a public FTP/HTTP server.
Brad Spengler has asserted that he has not forbidden any of his
customers from further redistribution of the code. Other than his
claim of being in compliance with the GPL, I do not personally have
any information either suggesting that he is or is not violating the
terms of the GNU Public License.
Personally, I think I don't think it makes any difference one way or
another. GRSecurity has made themselves irrelevant from the
perspective of upstream development. If someone wants to find some
embedded device which is using GRSecurity, and wishes to purchase said
device, and then demand access to source code under the terms of the
GPL, and then post those sources on some web site, that is all within
their right to do. For the most part, though, it's rarely useful to
get dead code posted on a web site. This is the same reason that
people who do drive-by open sourcing of code largely don't make much
difference. You can make a code drop of (for example) Digital's old
Tru64 advfs and make it available under an open source license. But
even though it was a very good file system for its time, unless it
comes with a community of developers, the code drop will very likely
just sit there.
So personally, I don't think it's a particularly good use of *my* time
to investigate whether or not folks who are responsible for grsecurity
are violating the terms of the GPL, and to get involved in a lawsuit.
It may be that there is no "there" there, in which case it will be a
waste of my time. And even if we can find proof that GRsecurity has
forbidden its customers from redistribution code derived from the
Linux kernel, in violation of the GPL, it will be messy, it will
enrich a bunch of attorneys --- and at the end of the day we will get
a dump of code that probably won't make any real difference to the
upstream development of the Linux kernel, since it will probably be
based on some ancient 3.18 kernel or some such.
Cheers,
- Ted
> It's not even clear that there is infringement. The GPL merely
> requires that people who have been distributed copies of GPL'ed code
> must not be restricted from further redistribution of the code. It
> does not require that that someone who is distributing it must
> available on a public FTP/HTTP server.
>
> Brad Spengler has asserted that he has not forbidden any of his
> customers from further redistribution of the code. Other than his
> claim of being in compliance with the GPL, I do not personally have
> any information either suggesting that he is or is not violating the
> terms of the GNU Public License.
>
> Personally, I think I don't think it makes any difference one way or
> another. GRSecurity has made themselves irrelevant from the
> perspective of upstream development. If someone wants to find some
> embedded device which is using GRSecurity, and wishes to purchase said
> device, and then demand access to source code under the terms of the
> GPL, and then post those sources on some web site, that is all within
> their right to do. For the most part, though, it's rarely useful to
> get dead code posted on a web site. This is the same reason that
> people who do drive-by open sourcing of code largely don't make much
> difference. You can make a code drop of (for example) Digital's old
> Tru64 advfs and make it available under an open source license. But
> even though it was a very good file system for its time, unless it
> comes with a community of developers, the code drop will very likely
> just sit there.
>
> So personally, I don't think it's a particularly good use of *my* time
> to investigate whether or not folks who are responsible for grsecurity
> are violating the terms of the GPL, and to get involved in a lawsuit.
> It may be that there is no "there" there, in which case it will be a
> waste of my time. And even if we can find proof that GRsecurity has
> forbidden its customers from redistribution code derived from the
> Linux kernel, in violation of the GPL, it will be messy, it will
> enrich a bunch of attorneys --- and at the end of the day we will get
> a dump of code that probably won't make any real difference to the
> upstream development of the Linux kernel, since it will probably be
> based on some ancient 3.18 kernel or some such.
>
If there is something to this (that GRSecurity is somehow in violation
of the GPL), then it would probably be a very good idea for someone
(the community, Red Hat, etc.) to protect the kernel. From my
understanding, at least in America, protections under any license or
contract (especially dealing with copyright and trademark
infringement) are only enforceable as long as the party with the
rights enforce the license/contract/agreement.
There is also something in law called "setting a precedent" and if the
violating of the Linux license agreement is left unchecked, then quite
possibly a precedent could be set to allow an entire upstream kernel
to be co-opted. I've know a LOT of engineers over the past 30+ years
that ignore the legal ramifications of what they do (because most
engineers want to engineer, not deal with legal garbage), and end up
losing in the end (or causing lawsuits for their company).
In other words, if things like this are left unchecked, then
eventually Linux possibly becomes co-opted by a company that violates
the license and everyone else is left having to pay them.
I have had code stolen in the past (an entire game in fact). That was
at a time when I was not financially able to do anything about it, and
even if I was, I was too young tot know any better and would not have
pursued any action. I now know better and have seen - since then -
people lose and be diminished because some entity took the fruits of
their long, hard work.
In summary, I think dismissing such a thing out-of-hand is a mistake.
Looking into it and making sure of the issue helps everyone, and
continues to keep the kernel free (who here remembers SCO?).
Thanks,
PGA
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting
http://www.randomlogic.com
On Sat, 29 Jul 2017, Paul G. Allen wrote:
>> It's not even clear that there is infringement. The GPL merely
>> requires that people who have been distributed copies of GPL'ed code
>> must not be restricted from further redistribution of the code. It
>> does not require that that someone who is distributing it must
>> available on a public FTP/HTTP server.
what I have seen reported is that they are adding additional restrictions, that
if any of their customers redistribute the source, their contract with
grsecurity is terminated.
> If there is something to this (that GRSecurity is somehow in violation
> of the GPL), then it would probably be a very good idea for someone
> (the community, Red Hat, etc.) to protect the kernel. From my
> understanding, at least in America, protections under any license or
> contract (especially dealing with copyright and trademark
> infringement) are only enforceable as long as the party with the
> rights enforce the license/contract/agreement.
You are thinking of Trademarks, they must be defended or you loose them.
Contracts and Licenses do not need to be defended at every chance or risk
loosing them.
> There is also something in law called "setting a precedent" and if the
> violating of the Linux license agreement is left unchecked, then quite
> possibly a precedent could be set to allow an entire upstream kernel
> to be co-opted.
This is a potential problem.
David Lang
On 07/30/2017 12:55 AM, David Lang wrote:
> You are thinking of Trademarks, they must be defended or you loose them.
> Contracts and Licenses do not need to be defended at every chance or risk
> loosing them.
No, not always, it can apply in plain contract as well. The defenses that
could be later raised by grsecurity if this issue goes unaddressed is are (1)
latches; and (2) waiver. It is a slippery slope. While, without commenting on
the dubious nature of the current use of the defenses (as catch-all,
kitchen-sink affirmative-defenses), they can be expected to be raised if
rights under GPL to insure no further restrictions are placed on subsequent
use of the kernel-code are not enforced.
I hope there is a centralized forum that will be established for this issue
(there may be and I'm just not smart enough to have found it yet). Certainly,
if for nothing else, so the advantages and disadvantages of both action, and
inaction, can be peer-reviewed on both the legal and technical side.
--
David C. Rankin, J.D.,P.E.
Hi!
On Sat 2017-07-29 17:20:52, Paul G. Allen wrote:
> > It's not even clear that there is infringement. The GPL merely
> > requires that people who have been distributed copies of GPL'ed code
> > must not be restricted from further redistribution of the code. It
> > does not require that that someone who is distributing it must
> > available on a public FTP/HTTP server.
> >
> > Brad Spengler has asserted that he has not forbidden any of his
> > customers from further redistribution of the code. Other than his
> > claim of being in compliance with the GPL, I do not personally have
> > any information either suggesting that he is or is not violating the
> > terms of the GNU Public License.
> >
> > Personally, I think I don't think it makes any difference one way or
> > another. GRSecurity has made themselves irrelevant from the
> > perspective of upstream development. If someone wants to find some
> > embedded device which is using GRSecurity, and wishes to purchase said
> > device, and then demand access to source code under the terms of the
> > GPL, and then post those sources on some web site, that is all within
> > their right to do. For the most part, though, it's rarely useful to
> > get dead code posted on a web site. This is the same reason that
> > people who do drive-by open sourcing of code largely don't make much
> > difference. You can make a code drop of (for example) Digital's old
> > Tru64 advfs and make it available under an open source license. But
> > even though it was a very good file system for its time, unless it
> > comes with a community of developers, the code drop will very likely
> > just sit there.
> >
> > So personally, I don't think it's a particularly good use of *my* time
> > to investigate whether or not folks who are responsible for grsecurity
> > are violating the terms of the GPL, and to get involved in a lawsuit.
> > It may be that there is no "there" there, in which case it will be a
> > waste of my time. And even if we can find proof that GRsecurity has
> > forbidden its customers from redistribution code derived from the
> > Linux kernel, in violation of the GPL, it will be messy, it will
> > enrich a bunch of attorneys --- and at the end of the day we will get
> > a dump of code that probably won't make any real difference to the
> > upstream development of the Linux kernel, since it will probably be
> > based on some ancient 3.18 kernel or some such.
> >
>
> If there is something to this (that GRSecurity is somehow in violation
> of the GPL), then it would probably be a very good idea for someone
> (the community, Red Hat, etc.) to protect the kernel. From my
> understanding, at least in America, protections under any license or
You probably still have code in the kernel. So you probably can sue
them. I'll have my fingers crossed for you :-), but otherwise don't
expect much help.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat 2017-07-29 22:55:22, David Lang wrote:
> On Sat, 29 Jul 2017, Paul G. Allen wrote:
>
> >>It's not even clear that there is infringement. The GPL merely
> >>requires that people who have been distributed copies of GPL'ed code
> >>must not be restricted from further redistribution of the code. It
> >>does not require that that someone who is distributing it must
> >>available on a public FTP/HTTP server.
>
> what I have seen reported is that they are adding additional restrictions,
> that if any of their customers redistribute the source, their contract with
> grsecurity is terminated.
Question is if this is legal thing to do.
Because if it is, there could be other "more interesting" abuses of
the GPL (*), and we may want GPLv4 to fix it.
Pavel
(*) Such as: you give us million dollars. You are free to distribute
the sources under the GPL, but if you do, our contract ends and we
will not be returning the million.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 2017-07-29 20:07, Theodore Ts'o wrote:
> It's not even clear that there is infringement. The GPL merely...
Yes it is.
Here's a posting from before that explains it:
----------------
GPL v2
Section 6 states simply
"You may not impose any further restrictions on the recipients' exercise
of the rights granted herein."
From GRSecurity's "Stable Patch Agreement":
"Notwithstanding these rights and obligations, the User acknowledges
that redistribution of the provided stable patches or changelogs outside
of the explicit obligations under the GPL to User's customers will
result in termination of access to future updates of grsecurity stable
patches and changelogs."
Clear as day. What some lay people do not understand is that the terms
in section 6 are governing what agreements and actions the distributee
can take regarding furthur distributees, in reality, in the flesh.
Here the ACTIONS of GRSecurity are to RESTRICT the exercise of the
redistribution rights of the further distributee.
This is an action prohibited by the terms offered by the linux-rights
holders, and they have written as another term that the permission they
give to use their property is revoked upon violation of their terms.
Very simple.
(Someone previously said on another thread:)
> And none are imposed. However, you are given the option to agree to
> them. Clear as day.
The proffering of the additional restrictive terms is in and of itself a
violation of section 2. You are holding the clients to an additional
restriction and enforcing this restriction via a threat to suspend
business relationships.
(YES YOU HAVE IMPOSED AN ADDITIONAL RESTRICTION)
----------------
Here's it put another way:
----------------
------------------------
Correction to common
programmer's misunderstanding
------------------------
They don't have to add a term to the GPL per-se as the GPL is not a
party to the agreement, it is "merely" the (not-fully integrated)
writing describing the license that the rights-holders have granted
GRSecurity et al.
That is: the GPL in-part describes the license grant that the linux
rights-holders have extended.
(There may be other parts described elsewhere, even verbally or through
a course of business dealings or relationship)
(Copyright law, being quite bare on it's own, often borrows much from
contract law)
Licensees must extend the same grant to Distributees, they cannot add an
additional term to that relationship.
GRSecurity has added such a term.
They did not pen it into the text of the GPL.
But, according to existing testimony they did make it clear that
redistribution will not be tolerated.
It is unknown if an electronic or hard copy of this additional term
controlling the relationship exists,
or whether it was a verbal agreement, or even some implicit
understanding. Any which way: it is a forbidden additional
term.
Or as Bruce Perens put it (and yes Bruce Perens is correct, and yes I am
an attorney)
----------------
Bruce Perens wrote:
"Currently, Grsecurity is a commercial product and is distributed only
to paying customers. Under their Stable Patch Access Agreement,
customers are warned that if they redistribute the Grsecurity patch, as
would be their right under the GPL, that they will be assessed a
penalty: they will no longer be allowed to be customers, and will not be
granted access to any further versions of Grsecurity. GPL version 2
section 6 explicitly prohibits the addition of terms such as this
redistribution prohibition."
"By operating under their policy of terminating customer relations upon
distribution of their GPL-licensed software, Open Source Security Inc.,
the owner of Grsecurity, creates an expectation that the customer’s
business will be damaged by losing access to support and later versions
of the product, if that customer exercises their re-distribution right
under the GPL license. Grsecurity’s Stable Patch Access Agreement adds a
term to the GPL prohibiting distribution or creating a penalty for
distribution. GPL section 6 specifically prohibits any addition of
terms. Thus, the GPL license, which allows Grsecurity to create its
derivative work of the Linux kernel, terminates, and the copyright of
the Linux Kernel is infringed. The GPL does not apply when Grsecurity
first ships the work to the customer, and thus the customer has paid for
an unlicensed infringing derivative work of the Linux kernel developers
with all rights reserved. The contract from the Linux kernel developers
to both Grsecurity and the customer which is inherent in the GPL is
breached."
perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/
Stable patch agreement:
perens.com/wp-content/uploads/2017/06/grsecstablepatchaccessagreement_additionalterms.pdf
----------------
Again, Yes I am an attorney, yes Bruce Perens is correct, Yes I know
what I'm talking about in this field more than you American Programmers,
no you do not know what you are talking about if you have not studied
law.
On Sun, 2017-07-30 at 10:15 +0000, [email protected] wrote:
>
> Again, Yes I am an attorney, yes Bruce Perens is correct, Yes I know
> what I'm talking about in this field more than you American Programmers,
> no you do not know what you are talking about if you have not studied
> law.
If your motivation for posting to LKML, a technical forum, is to
dispense pro bono publico advice to hapless victims, bless you, but
LKML is not the appropriate forum. Nor is it appropriate for pro bono
advocatus, pro bono piscator, or any other conceivable variant of pro
bono discussion not ending in the latin word for kernel.
-Mike
Thank you Mr. Rankin for saying this. Bruce Perens blocked me* (also
calling me a "fool" later to a 3rd party) after I started to brainstorm
the defenses that would be raised about a week or two ago: letting
everyone in the world know what he thought of me for mentioning laches
etc.
Such talk is naivete to him and he "doesn't suffer fools willingly".
Brainstorming what defenses the opposition will raise is the thinking of
a naive fool according to Bruce Perens.
I also noticed that Bruce Perens friend Professor Moglen hasn't
commented, instead opting to sit and silently judge, but I did bring up
the fact that GPL v2 lacks a no-revocation clause, thus (barring
estopple) said license can be revoked at any time by the grantor. Which
is the actual reason v3 of the GPL needed to be drafted (the patents
issue being a foil). I guess Professor Moglen (RMS, ESR) and the rest
don't want too many people to know about that part either and thus would
rather downplay anything else I have written.
To be clear: Rights-Holders can sue GRSecurity for the copyright
violation stemming from the flagrant violation of section 6 of the
license. Rights-Holders can also revoke GRSecurity's license to their
code by notice and then sue them if they continue to make derivative
works of said work. So Rights-Holders have two options there at their
disposal.
The GPL v2, by itself, does not give rise to an estopple situation where
there has been no communication to the other party that they relied upon
that the license would never be revoked by Rights-Holder.
The permission flows from the Rights-Holder and not through
intermediaries. Thus even if Linus made communications that HE would
never revoke the permission he has given regarding his works of
authorship, that does not bind other Rights-Holders regarding their
code.
*( lists.debian.org/debian-user/2017/07/msg00830.html )
On 2017-07-30 07:14, David C. Rankin wrote:
> On 07/30/2017 12:55 AM, David Lang wrote:
>> You are thinking of Trademarks, they must be defended or you loose
>> them.
>> Contracts and Licenses do not need to be defended at every chance or
>> risk
>> loosing them.
>
> No, not always, it can apply in plain contract as well. The defenses
> that
> could be later raised by grsecurity if this issue goes unaddressed is
> are (1)
> latches; and (2) waiver. It is a slippery slope. While, without
> commenting on
> the dubious nature of the current use of the defenses (as catch-all,
> kitchen-sink affirmative-defenses), they can be expected to be raised
> if
> rights under GPL to insure no further restrictions are placed on
> subsequent
> use of the kernel-code are not enforced.
>
> I hope there is a centralized forum that will be established for this
> issue
> (there may be and I'm just not smart enough to have found it yet).
> Certainly,
> if for nothing else, so the advantages and disadvantages of both
> action, and
> inaction, can be peer-reviewed on both the legal and technical side.