Samba into kernel

[Steve Langasek]

On Wed, Mar 27, 2002 at 10:03:43AM +0000, David Lee wrote:

>> This is a "special exception" and is not really allowed by the other parts
>> of the GPL. You couldn't distribute (use/compile?) samba for Solaris
>> without this exception because the libc would be mapped into the memory
>> space and added to the program.

>> The GPL regards the program + the linked libs as one "work".

> Fine.  But that would apply the same in both userspace and kernelspace
> wouldn't it?  Am I missing some subtle distinction here?

Basically, the GPL allows you to take someone else's GPL code, make
modifications to it so that it exports whatever interface you want it
to, and -- as long as you're willing to license your code under the GPL
-- distributed the resulting *source code* to whomever you want.  As the
sole copyright holder on the code being added to the mix to create the
derived work, you have the right to do this.  However, when you compile
and link the source code to create a binary, this binary is legally also
a derived work of the interface definitions used to create it (header
files, library symbol tables used when linking, etc).  Normally,
copyright holders of these interface definitions waive their rights to
derived works; but the GPL requires that they also be willing to license
their work to you under the GPL, otherwise you can't distribute your
binaries.

So as long as you only distribute in source form, you can create any
derivative you want to and put any interface on it that you like.  Once
you compile it, you're limited by the licenses on both sides, as
described in the GPL 'plugins' FAQ.

>> * http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF

> An interesting, though inconclusive, read.  And there is an explicit
> "exception" mechanism to facilitate a GPL "plug-in" into a non-free
> progam.

This exception is only available to you if you are the copyright holder
of the GPLed code: you can't add this exception to the license on behalf
of others who hold copyright interest in the derived work.

> (And for us, the main "program" is itself the other allowed
> exception of the OS.)

A literal reading of the GPL seems to support this interpretation.
However, IANAL, and I would recommend getting the relevant lawyers to
look over the question before deciding to distribute GPLed binary kernel
plugins.  In addition, since GPL is a strongly community-oriented
license, intent weighs more heavily than with more traditional license
agreements (in practice), which you might want to keep in mind if your
lawyers come up with a different answer than the actual copyright
holders have. :)

> Let me re-state the basic idea:

> Current:  Our GPL Samba product currently uses one set of interfaces onto
> the OS and the OS libraries (e.g. Solaris man(2) and man(3)).  This is
> explicitly OK under GPL.

> Proposal:  We adjust our GPL product to allow a site to choose a different
> set of interfaces (e.g. Solaris man(9) DDI/DDK) into that same OS/library
> set.

> In other words, two alternate but equivalent interfaces, onto the same
> non-free, but GPL-permitted, program (OS and libraries). 

Not knowing anything about DDI/DDK, I can only surmise based on the 
kinds of things that are allowed under the GPL:

 a GPL program can make syscalls to a non-free kernel.
 a GPL program can make function calls to non-free libraries.
 a GPL program can receive information back from non-free kernels in the
   form of POSIX signals.

It's not hard to find examples of precedent for GPLed programs using all
three of these interfaces.  If DDI/DDK involves exposing a lot more
functionality to the non-free kernel through callbacks, I think that's 
a much murkier issue -- particularly if the callbacks are set up in such 
a way that other non-free software running on the system can access them 
and benefit from them.

Steve Langasek
postmodern programmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020327/3667e455/attachment.bin