vfs-module lincense

Dmitry Borodaenko d.borodaenko at sam-solutions.net
Wed Feb 27 08:35:04 GMT 2002

On Wed, Feb 27, 2002 at 09:13:38AM -0600, Esh, Andrew wrote:
> How does that apply to VFS modules that are dynamically linked, and
> referred to in smb.conf via the "vfs object" tag? By including
> dynamically linked libraries, this implies that Samba's license
> controls that of libc, libcrypt, libnsl, and many others. I don't
> believe it does.

I think that this is not a case of library, but a plug-in instead.


 If a program released under the GPL uses plug-ins, what are the
 requirements for the licenses of a plug-in?

    It depends on how the program invokes its plug-ins. If the program
    uses fork and exec to invoke plug-ins, then the plug-ins are
    separate programs, so the license for the main program makes no
    requirements for them. 

    If the program dynamically links plug-ins, and they make function
    calls to each other and share data structures, we believe they form
    a single program, so plug-ins must be treated as extensions to the
    main program.  This means they must be released under the GPL or a
    GPL-compatible free software license. 

    If the program dynamically links plug-ins, but the communication
    between them is limited to invoking the `main' function of the
    plug-in with some options and waiting for it to return, that is a
    borderline case.

This means to me that the VFS modules applies (as long as it is not
invoked via fork/exec or main()) and hence, "must be released under the
GPL or a GPL-compatible free software license."

> Perhaps you are referring to the other type of VFS "module": One that
> is linked directly into Samba as a .o file, in the same way smbd/vfs.o
> is. I agree that such modules are controlled by Samba's license.

As you can see from above, it depends not on static/dynamic compilation,
but rather on complexity of the interface between module and the main

Dmitry Borodaenko

More information about the samba-technical mailing list