Cisco Cisco IPICS Release 2.1 Licensing Information

Page of 20889
             Open Source Used In  Cisco Instant Connect 4.10(1)                                                                                                                                   
2325
just a more clearly stated limitation on the "derived work" issue. If you
use standard UNIX system calls (with accepted Linux extensions), your
program obviously doesn't "derive" from the kernel itself.
 
Whenever you link into the kernel, either directly or through a module,
the case is just a _lot_ more muddy. But as stated, by default it's
obviously derived - the very fact that you _need_ to do something as
fundamental as linking against the kernel very much argues that your
module is not a stand-alone thing, regardless of where the module source
code itself has come from.
 
> Issue #4
> ========
> This last issue is not so much a issue for the Linux kernel
> exception, but a request for comment.
>
> Richard and I both agree that a "plug-in" and a "dynamically
> loaded kernel module" are effectively the same under the GPL.
 
Agreed.
 
The Linux kernel modules had (a long time ago), a more limited interface,
and not very many functions were actually exported. So five or six years
ago, we could believably claim that "if you only use these N interfaces
that are exported from the standard kernel, you've kind of implicitly
proven that you do not need the kernel infrastructure".
 
That was never really documented either (more of a guideline for me and
others when we looked at the "derived work" issue), and as modules were
more-and-more used not for external stuff, but just for dynamic loading of
standard linux modules that were distributed as part of the kernel anyway,
the "limited interfaces" argument is no longer a very good guideline for
"derived work".
 
So these days, we export many internal interfaces, not because we don't
think that they would "taint" the linker, but simply because it's useful
to do dynamic run-time loading of modules even with standard kernel
modules that _are_ supposed to know a lot about kernel internals, and are
obviously "derived works"..
 
> However we disagree that a plug-in for a GPL'd program falls
> under the GPL as asserted in the GPL FAQ found in the answer:
> http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins.
 
I think you really just disagree on what is derived, and what is not.
Richard is very extreme: _anything_ that links is derived, regardless of
what the arguments against it are. I'm less extreme, and I bet you're even
less so (at least you would like to argue so for your company).