vfs-module lincense

[Simo Sorce]

First of all, can you avoid sending html to the list?

On Wed, 2002-02-27 at 18:30, 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?

It is not what you think an external vfs plugin is!
an external object cannot be an API, it is an object that uses the vfs
API (and may be other APIs as well) to be part of samba (dynamically or
statically loaded) as a plugin!

> 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.

Libc is a "system" library! and Samba uses it, Samba does not add
anything to libc, libc exist without Samba!
Instead your plugin uses Samba, add a service to Samba, can't exist
without Samba!

> 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.

No!
Alternative file system can be accessed without problem, as the API the
kernel exposes through libc or other _system_ library is used by your
module! You do not need to have the system library that give access to
the filesystem GPLed!


> 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?
Of course not!


> Perhaps
> my interpretations are at fault, but I don't see how a non-GPL file systems
> could be used, without touching GPL code somewhere. The Linux kernel is GPL
> isn't it? That implies that all kernel modules must be GPL.
No, but only because Linus and others made a special exception to the
GPL license stating that binary modules can be added as they use the
module API and only the module API, if a module tries to suddendly use
some internal kernel function then it breaks the GPL!

> This is exactly the sort of creeping and spreading application of the GPL
> that Microsoft points to when they try to scare us into thinking that GPL is
> bad.

Microsoft FUD is just crap, forget it!

> 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?

No, I reapeat, only the module have to be under a GPL compatible
licence, not any _system_ library!

But remeber only system libraries! You can not make a library on your
own and declare it a system library and make an empty call-forwarding
module to move all your logic in a non-gpl compatible licence library!


> -----Original Message-----
> From: Alexander Bokovoy [mailto:a.bokovoy at sam-solutions.net]
> Sent: Wednesday, February 27, 2002 10:04 AM
> To: samba-technical at samba.org
> Subject: Re: vfs-module lincense
> 
> 
> On Wed, Feb 27, 2002 at 09:14:00AM -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.
> > 
> >    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.
> Please look at http://www.fsf.org/licenses/gpl-faq.html#GPLAndPlugins for
> detailed description why VFS modules for Samba must be under GPL-compatible
> license. It does not depend on type of linking, actually, but on usage
> pattern. An excerpt from GNU GPL FAQ page:
> 
>   "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."
> 
> Currently, VFS modules make calls to and share data with only one type of 
> different code than they themselves -- it is default VFS hooks provided 
> by smbd. But in near future (~ April) situation will change with cascaded 
> VFS layer.
> 
> And even in current situation smbd does not call plugins directly, they
> are integrated into it instead and their functions are being used as
> direct replacements for internal smbd's ones. This hardly can be
> classified as 'the program uses fork and exec to invoke plug-ins' or 'the
> communication between them is limited to invoking the `main' function of
> the plug-in with some options and waiting for it to return' as specified
> on GNU GPL FAQ page for differently-licensed plugins for GPLed software.
> 
> 
> 
> > 
> >    -----Original Message-----
> >    From: Andrew Bartlett [[1]mailto:abartlet at pcug.org.au]
> >    Sent: Wednesday, February 27, 2002 5:17 AM
> >    To: Sergey Akhapkin
> >    Cc: samba-technical at samba.org
> >    Subject: Re: vfs-module lincense
> > 
> >    Sergey Akhapkin wrote:
> >    >
> >    > Hello All,
> >    >
> >    > I'd wrote vfs-module for our antivirus daemon. I've question about
> >    > licence.
> >    > Are sources of vfs-module must be open or not ?
> >    > Are sources must be distributed under GPL (if must be open) ?
> >    > Can we distribute it not under GPL ?
> > 
> >    All VFS modules *MUST* be distributed under the GPL.  All code that is
> >    linked to Samba *must* be under distributable under the same licence
> >    as
> >    samba itself.
> > 
> >    That being said, you are free to also distribute it under a more
> >    liberal
> >    licence (the LGPL for example) or another licence *and* the GPL (at
> >    the
> >    user's option).
> > 
> >    Andrew Bartlett
> > 
> >    --
> >    Andrew Bartlett                                 abartlet at pcug.org.au
> >    Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
> >    Student Network Administrator, Hawker College   abartlet at hawkerc.net
> >    [2]http://samba.org     [3]http://build.samba.org
> >    [4]http://hawkerc.net
> > 
> > References
> > 
> >    1. mailto:abartlet at pcug.org.au
> >    2. http://samba.org/
> >    3. http://build.samba.org/
> >    4. http://hawkerc.net/
> 
> -- 
> / Alexander Bokovoy
> Software architect and analyst             // SaM-Solutions Ltd.
> ---
> The eagle may soar, but the weasel never gets sucked into a jet engine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20020227/313cd3cd/attachment.bin