Messages in this thread |  | | Subject | Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL | From | Nils Philippsen <> | Date | 19 Oct 2001 10:26:21 +0200 |
| |
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? [unhandled content-type:application/pgp-signature] |  |