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
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
More information about the samba-technical