Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Nils Philippsen <nils@wombat.dialup.fht-esslingen.de>]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Fri, 2001-10-19 at 09:16, Kai Henningsen wrote:
> kaos@ocs.com.au (Keith Owens)  wrote on 18.10.01 in <8658.1003375433@kao2.melbourne.sgi.com>:
> 
> > EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
> > available to modules with a GPL compatible license.  This is
> > independent of the kernel tainting, but obviously takes advantage of
> > MODULE_LICENSE() strings.
> 
> Incidentally, an argument can be made that using EXPORT_SYMBOL_GPL  
> actually renders your code incompatible with the GPL, insofar as it  
> violates the "additional restriction" clause. Which doesn't matter as long  
> as it's *only* your code (author can always do different things), but  
> *does* matter if you add *other* people's GPL code (such as the rest of  
> the kernel), because it's *their* GPL that you're breaking ...

[IANAL]

Not the least -- there is no such thing as code "(in)compatible with the
GPL" -- you can alter (or write) GPLed code to do (or don't do) anything
you want when it comes to the GPL. The additional restrictions provision
in the GPL you talk about means restrictions in licensing, not technical
ones. For what it's worth I could alter the glibc to not work when used
by a process called "acroread" or "vmware" or whatever (not that that
would make sense) and still be in full compliance with the GPL as long
as I adhere to the GPL when distributing it.

Nils
-- 
 Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg //
+49.7152.209647
nils@wombat.dialup.fht-esslingen.de / nils@redhat.de /
nils@fht-esslingen.de
        Ever noticed that common sense isn't really all that common?

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]