EXPORT_SYMBOL_GPL recursive for shim and/or wrappers

EXPORT_SYMBOL_GPL recursive for shim and/or wrappers

[Luis R. Rodriguez]

The intention behind EXPORT_SYMBOL_GPL seems clear to me -- prevent
proprietary drivers from using GPL-only symbols. Something that to me
is clear but perhaps not to others is the the extent to which this
reaches for proprietary modules. As I interpret it proprietary modules
could _not_ make use of wrappers or shims which export new symbols
with EXPORT_SYMBOL but that those modules were themselves using
EXPORT_SYMBOL_GPL. That is create non-gpl-compatible wrapper symbols
for GPL-compatible-only symbols.

There is a cases though where the intent behind "shim" or "wrappers"
may actually not be to circumvent the GPL-compatible requirement of
code built using EXPORT_SYMBOL_GPL and although I believe it would
still constitute a violation I'd like feedback or more clarity on this
from others. The case would be where the "shim" or "wrapper" provides
realistic APIs for a framework of abstraction for different buses. In
that case the bus-agnostic API layer does make use of
EXPORT_SYMBOL_GPL for USB for example but may not make use of it for
other buses. In any case the intent here would then not to circumvent
the GPL-compatible requirement but to simply implement a bus-agnostic
API.

Does EXPORT_SYMBOL_GPL imply that modules which make use of these
symbols must also use EXPORT_SYMBOL_GPL for their own symbols? If so
then it would be clear of the recursive nature of intent.

To me the recursive nature is clear, but just wanted to ask. I also
don't see this documented in Documentation/ or in the header files,
but perhaps it should be there if such a patch is welcomed.

  Luis

Re: EXPORT_SYMBOL_GPL recursive for shim and/or wrappers

[Pavel Roskin]

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

Re: EXPORT_SYMBOL_GPL recursive for shim and/or wrappers

[Alan Cox]

On Mon, 1 Jun 2009 12:41:58 -0700
"Luis R. Rodriguez" <mcgrof@gmail.com> wrote:

> The intention behind EXPORT_SYMBOL_GPL seems clear to me -- prevent
> proprietary drivers from using GPL-only symbols. 

It's a guide as to what symbols are most definitely internal interfaces.
Nobody but a lawyer (or more accurately a court of law I guess) can tell
you what is or isn't a derivative work. It can be that without using _GPL
symbols, and I would imagine there may even be cases the reverse might be
true.

Re: EXPORT_SYMBOL_GPL recursive for shim and/or wrappers

[Greg KH]

On Mon, Jun 01, 2009 at 12:41:58PM -0700, Luis R. Rodriguez wrote:
> Does EXPORT_SYMBOL_GPL imply that modules which make use of these
> symbols must also use EXPORT_SYMBOL_GPL for their own symbols? If so
> then it would be clear of the recursive nature of intent.

I have had a group of lawyers and law-students study this very topic a
lot in the past.  It comes down to "intent".  If you are creating a
"shim" kernel module to merely export the symbols into the "non-gpl"
namespace, the "intent" of such a piece of code is to obviously
circumvent the original "intent" of the GPL-only marking.

This argument was successfully used to cause at least one company to
stop doing this very thing.

Now if you try to explicitly document this somehow, well, I think you
fall into the old "try to explicitly define everything" problem, which
is counterproductive as people try to work around such definitions.  I
say leave it as-is, and let my lawyers have fun if anyone tries to abuse
it :)

thanks,

greg k-h