[Samba] vfs module license particulars

[Jeremy Drake]

On Thu, 11 Aug 2005, Jeremy Allison wrote:

> It's probably in violation, but the writer and distributor is not in
> violation - the user who links the two together is. I told you it was
> complicated :-). IANAL - this is similar to the NVidia case, where NVidia
> is not in violation as they don't ship Linux, but people who ship the
> Linux kernel + the NVidia driver probably are.

The user who links them together is not in violation of the gpl as the
gpl only applies if you distribute it.  People who ship the linux kernel
on the same media as the nvidia driver are not either, since the gpl says
that putting gpl and non-gpl software on the same media is ok.  The only
violation would be if someone distributed the two linked together.

Now back to my original original question...

Looking at extd_audit.so as an example vfs module, it does not dl any
samba code at all.  A quick grep of source/include shows no inline
functions.  This means that a compiled binary of a vfs module would not
have any gpl code in it (only information for later on what functions it
could need to use, maybe) and would not contain code which would link it
with gpl'd code at runtime.  The user could, if they so desired, instruct
samba through the config file to load this module.  This act would
"violate" the gpl, but only in the sense that the resultant code could not
be distributed (no core dumps allowed).  Plus the vfs api seems to pretty
much just mirror standard filesystem functions (mkdir, open, close, etc)
which makes writing code to it even less a derivitive work of samba, since
it could just as easily be deriving from any ansi c filesystem library or
posix filesystem spec.

I feel sort of rude arguing this stuff, and I apologize if I am coming
across as rude, but I feel that this is an important issue to argue
thoroughly, if only to reduce potential future confusion on the part of
someone else who may want to implement this api.

>
> Jeremy.
>

-- 
"If you want to eat hippopatomus, you've got to pay the freight."
-- attributed to an IBM guy, about why IBM software uses so much memory