vfs-module lincense

Alexander Bokovoy a.bokovoy at sam-solutions.net
Wed Feb 27 10:34:08 GMT 2002

On Wed, Feb 27, 2002 at 11:30:12AM -0600, Esh, Andrew wrote:
>    I understand what you're saying, but I don't consider what is called
>    by the external VFS object reference to be a plug-in. It is an API,
>    just like libc. So Samba requires all dynamically linked libraries it
>    refers to be GPL? Do Samba and libc form a single program?
This is not quite true. VFS module doesn't an API, it is a piece of code
that has access to all smbd internals ('internals' here are all global
functions and variables inside smbd). If you look, for example, into
examples/VFS/block/block.c, you'll see that it uses pm_process() which is
exported from source/param/params.c. This is clearly plug-in that calls
smbd functions and shares data with it. Same for any other VFS module
which uses smbd's facility to work with configuration file.

It is only one and simplest example of what actually VFS module could do
with smbd internals. Nobody could say that closed-source VFS module does
not exploit these possibilites when an interface clearly allows to do it
without any problems.

>    An external VFS module does no make function calls to Samba. Of course
>    data structures are passed, but not "shared". Data structures are
>    passed to libc in exactly the same way.
See above.

>    I believe this is a very unfortunate interpretation of the GPL. It
>    makes it impossible for non-GPL file system access methods to be
>    implemented, so encryption, accounting, or virtualization methods
>    cannot, in many cases, be added.
>    Now that my confidence is shaken, maybe I should ask this: Does the
>    storage of a Samba share on a non-GPL file system break the Samba
>    license? Perhaps my interpretations are at fault, but I don't see how
No, it doesn't. Samba communicates with this non-GPL FS via system calls.
System calls cannot be considered as breakthrough of a license (any, not
GPL only). If you look at Linux's license then it is clear that it doesn't
cover any application running on top of the kernel (this is
specified in the kernel license). And this phrase is applicable to any
program, regardless of its license. This is what we expect from OS, don't we?

>    Maybe the solution to this is to implement some sort of socket
>    interface. Would that de-couple Samba enough to allow non-GPL file
>    system access methods to be used?
Most of Samba VFS plugins which use commercial programs for providing their
functionality like on-the-fly antivirus scanners are built using the same
technique. VFS module _is_ that interface, not anything else. Write VFS
module as socket manager and then keep non-GPL-compatible code outside

/ Alexander Bokovoy
Software architect and analyst             // SaM-Solutions Ltd.
Anyone stupid enough to be caught by the police is probably guilty.

More information about the samba-technical mailing list