Licensing ambiguities with GPL and LGPL - was Re: Can Samba co-operate?

[Jeremy Allison]

On Fri, Dec 21, 2001 at 04:45:24PM -0600, John Malmberg wrote:
> Thank you for taking the time to respond.  It is an issue that
> affects any one who works for a company that supplies a
> commercial operating system and SAMBA.
> 
> I am trying to determine if it is a violation of the GPL for me
> to produce a LIBSMBCLIENT shared image.

Sorry for being ratty about it. Chris just told me off for being
an *sshole over how I'm explaining the licensing :-).

> Here is the crux, the plug-in may not explicitly require libsmbclient, 
> it just may be able to use it if it is present.
> 
> The plug-in may not have even been designed with libsmbclient in mind, as it
> could be written in PERL, PYTHON, or TCL/TK.  All of which programs can
> directly call libsmbclient.  PERL is not covered under the GPL, it is
> covered under the Perl Artistic License.
>
> And there are many other programs that have the same abilities to
> use any shared image on the system to extend themselves.
> 
> The issue does need clarification.

As an example, I can point at the GNU dbm library, gdbm. This is
also GPL and RedHat do not ship it on their version of Linux, due
to this exact reason.

> It is one of the few GPL products that is a shared image, but not 
> extensively a part of the operating system.

gdbm is the same. I would look at who is distributing this and
what they do about it. I know RedHat don't ship it, not because
they can't - but because they know that if people build proprietary
software on RedHat that depended upon it, then the proprietary
software company would be violating the GPL.

They wish people to be able to build proprietary software on RedHat
and not be covered by the GPL, hense their decision not to ship
libgdbm.so.

> As of now, I am employed by that company.  If I produce a build of 
> LIBSMBCLIENT as a shared image, there are many products that run on that 
> platform that can immediately take advantage of it.
> 
> This includes any product that is based on the default editor, or uses 
> any of the popular cross platform scripting languages, some covered by
> GPL, and some that are not.
> 
> I have no control over that, so would I be held responsible?

I am not a lawyer, but just creating the library is not a crime
as far as I know. The issue comes with creating non-GPL programs
that use GPL libraries.

> But from what you say, if anyone uses libsmbclient to extend a program 
> like my normaly used editor that is not GPLed, that is a violation of 
> the GPL?

Technically, yes. I believe so. If someone does this on their own system
I'm not sure...

> Interestingly, if the editor spawns a shell that issues the SMBCLIENT 
> commands, and returns the results back to the editor, that is expressly 
> permitted under RMS's interpretation of the GPL.

Yes.

> This is also an issue for any employee of a firm that produces a 
> commercial Operating System, as there are many non-GPLed programs that 
> can directly call libsmbclient on them.  This is with out being directly 
> linked against libsmbclient.
> 
> So is a build of libsmbclient for a commercial platform now prohibited, 
> because a non-GPLed program can directly use it?

No. I don't think so. But people building non-GPL software on that
platform must be aware not to link with it. I refer you back to
the RedHat example above.

> And then what is the story on SMBMOUNT and it's friends.  Are they only
> licensed for use on GPL'ed operating systems?

Yes, again - as they are GPL this is the case.

Cheers,

Jeremy.