From: Pavel Roskin <proski@gnu.org>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Greg KH <greg@kroah.com>, Al Viro <viro@ftp.linux.org.uk>,
Aaditya.Rai@atheros.com, Prem.Kumar@atheros.com,
Stephen.Chen@atheros.com, Rahul.Sridhar@atheros.com,
Allen.Tsai@atheros.com
Subject: Re: EXPORT_SYMBOL_GPL recursive for shim and/or wrappers
Date: Mon, 01 Jun 2009 16:37:12 -0400 [thread overview]
Message-ID: <1243888632.16765.12.camel@mj> (raw)
In-Reply-To: <43e72e890906011241u24b82cc3gc06bf7be4f43075e@mail.gmail.com>
Hello, Luis!
On Mon, 2009-06-01 at 12:41 -0700, Luis R. Rodriguez wrote:
> The intention behind EXPORT_SYMBOL_GPL seems clear to me -- prevent
> proprietary drivers from using GPL-only symbols.
I believe the intention was to warn the users that they know so much
about the kernel that they should be considered a derived work of the
kernel and thus should be under GPL themselves.
It doesn't fully exclude the "shims". I believe it could be
successfully argued in the court that proprietary code using shims is
not a derived work of the kernel if certain care is taken not to expose
the writers of the proprietary part to the internals of the GPL code.
I'm not taking the position of proponents of non-free software. GPL is
valuable both because of what it permits (e.g. commercial use) and by
what it forbids (e.g. making the code proprietary). It's better not to
change the rules, as it negatively affects the trust of other people.
Moreover, in this case we could be deceiving ourselves that we can
change the rules, as the definition of the derived work lies outside the
scope of GPL.
IANAL and IMHO
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2009-06-01 20:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-01 19:41 EXPORT_SYMBOL_GPL recursive for shim and/or wrappers Luis R. Rodriguez
2009-06-01 20:37 ` Pavel Roskin [this message]
2009-06-01 21:32 ` Alan Cox
2009-06-01 21:39 ` Greg KH
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=1243888632.16765.12.camel@mj \
--to=proski@gnu.org \
--cc=Aaditya.Rai@atheros.com \
--cc=Allen.Tsai@atheros.com \
--cc=Prem.Kumar@atheros.com \
--cc=Rahul.Sridhar@atheros.com \
--cc=Stephen.Chen@atheros.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@gmail.com \
--cc=viro@ftp.linux.org.uk \
/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