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

[John Malmberg]

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.

Jeremy Allison wrote:

> On Fri, Dec 21, 2001 at 01:53:06PM -0600, John Malmberg wrote:
> 
>>The important question then becomes:
>>
>>Why does Foobar, Inc. have less rights than all of their end users?
 
> Quite simple. This is an erroneous conclusion.
> 
> 
>>But any end user of Foobar, Inc.'s products who has no other connection 
>>with Foobar, Inc. is allowed to create and distribute a GPL'ed plugin 
>>that uses LIBSMBCLIENT, as long as that plug in is also GPL'ed.
>>
> 
> No, distributing this is also disallowed by the GPL. If their plugin
> requires libsmbclient, then it also must be GPL. If it is GPL, it
> is not allowed to be distributed as a plugin for FooBar Inc.'s
> proprietary code.


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.
 
> Neither you nor I are lawyers. If you want to explore these issues
> further I suggest you hire one. We are represented by the FSF lawyer,
> who has done a lot of work for us in the past. If you wish clarification
> I can give you his contact details (off list) if you'd like.

The issue does need clarification.

> 
>>In 1999, I would not have had a conflict with your GPL policy if I 
>>distributed the editor commands, but because of an employment change, It 
>>now can definitely be an important legal point, if I chose to do it now.
>>
> 
> I don't see what an employment change or time since 1999 has to
> do with our licensing.


The editor can call LIBSMBCLIENT directly with it's editor macro 
language just like EMACs can.  But the editor is a component of the 
commercial operating system.

Before 1999, I was not employed by that company.  If I had released 
editor macros that easily allowed anyone to easily use LIBSMBCLIENT with 
it, are you saying that would not have been allowed?

At the time, I had no connection with the company that produced the editor


And it is documented in the editor on how to call routines from any
shared image on the system.

> 
>>LIBSMBCLIENT is one of the few GPLed products that have this clear
>>conflict in their licensing terms.
>>
>>So you can understand why I have a particular interest with this issue.
>>
> 
> No, not really. I don't see libsmbclient having a conflict at all.
> It's GPL.


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

The GPL shared images that are part of the operating system or the 
compiler runtime are allowed to be used by non-GPLed programs.

> You cannot use it in proprietary products, as plugins or
> otherwise. What is so difficult about that? What are you trying to
> achieve here ?


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?

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?


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.


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?


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


-John
wb8tyw at qsl.network
Personal Opinion Only