mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Paul G. Allen" <pgallen@gmail.com>, nisus@redchan.it
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Yes you have standing to sue GRSecurity
Date: Sat, 29 Jul 2017 16:07:26 -0400	[thread overview]
Message-ID: <20170729200726.6qxlnh7mmfpfxkq3@thunk.org> (raw)
In-Reply-To: <CAN4-gUESAsBGkwtztoEEyEaPm_=snh2jQLFRsUxAY2ykEQRtuQ@mail.gmail.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

  reply	other threads:[~2017-07-29 20:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-29 13:06 nisus
2017-07-29 15:32 ` Paul G. Allen
2017-07-29 20:07   ` Theodore Ts'o [this message]
2017-07-29 23:20     ` Paul G. Allen
2017-07-30  5:55       ` David Lang
2017-07-30  7:14         ` David C. Rankin
2017-07-31 14:46           ` Yes you have standing to sue GRSecurity - Two options that can be used in concert or separately nisus
2017-07-30  9:47         ` Yes you have standing to sue GRSecurity Pavel Machek
2017-07-30  9:47       ` Pavel Machek
2017-07-30 10:09     ` Yes you have standing to sue GRSecurity - Yes there is a blatant violation nisus
2017-07-30 10:15       ` nisus
2017-07-30 15:18         ` Mike Galbraith
  -- strict thread matches above, loose matches on Subject: below --
2017-07-29 12:30 Yes you have standing to sue GRSecurity nisus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170729200726.6qxlnh7mmfpfxkq3@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nisus@redchan.it \
    --cc=pgallen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®