public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	corbet@lwn.net, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	gnomes@lxorguk.ukuu.org.uk, gregkh@linuxfoundation.org,
	jkosina@suse.cz, bhelgaas@google.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org, bp@suse.de
Subject: Re: [PATCH] Documentation: extend use case for EXPORT_SYMBOL_GPL()
Date: Thu, 28 May 2015 22:56:19 +0100	[thread overview]
Message-ID: <20150528215618.GE7232@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20150528211736.GV23057@wotan.suse.de>

On Thu, May 28, 2015 at 11:17:36PM +0200, Luis R. Rodriguez wrote:
> > ... while some of us consider that as pointless posturing and will refuse
> > to merge such exports regardless.
> 
> Can you elaborate why, for those maintainers not aware of such positions?

*shrug*

Either one states that all modules are derivative works of the kernel,
period (in which case attaching _GPL to specific exports is completely
pointless), or it's a claim that this specific export is something
special on its own, which is a fairly strong claim, completely unfounded
more often than not.  In the worst cases it's the former being misrepresented
as the latter.  That only serves to weaken our position in case of copyright
violations, IMO.  When obviously BS claims like "encoding and decoding
of UIDs between the numeric values as seen by userland and stored on
filesystem and opaque pointers as used by the userns stuff is so special
that its use alone is sufficient to change whether the code is derivative
of the kernel or not" are thrown around, we end up with weaker protection,
not stronger one.  If something like _that_ makes the difference between
derived and non-derived, the former can't be worth much...

  reply	other threads:[~2015-05-28 21:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28 18:56 [PATCH] Documentation: extend use case for EXPORT_SYMBOL_GPL() Luis R. Rodriguez
2015-05-28 19:09 ` Jonathan Corbet
2015-05-28 19:18   ` Luis R. Rodriguez
2015-05-28 19:35     ` Jonathan Corbet
2015-05-28 20:07 ` Al Viro
2015-05-28 21:17   ` Luis R. Rodriguez
2015-05-28 21:56     ` Al Viro [this message]
2015-05-28 23:10       ` Luis R. Rodriguez
2015-05-29  5:00         ` Christoph Hellwig
2015-05-29 17:40           ` Luis R. Rodriguez
2015-05-29  1:30 ` Rob Landley

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=20150528215618.GE7232@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=corbet@lwn.net \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jkosina@suse.cz \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=mingo@elte.hu \
    --cc=xen-devel@lists.xenproject.org \
    /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