Licensing ambiguities with GPL and LGPL (long)

[Green, Paul]

I am also not a lawyer, but I've participated in multiple long meetings with
legal counsel thrashing out the meaning of the GPL and LGPL. I would like to
add a few thoughts to this discussion.

John Malmberg <wb8tyw at qsl.net> wrote:
> The GPL makes a special exception for shared images that are considered 
> part of the operating system, such as LIBC.  If they did not, there 
> would be a problem selling commercial [Simo: PROPRIETARY] software to run
on LINUX.

We need to be precise here. GLIBC is covered by the LGPL, not the GPL.
Reference: glibc/README.  The GPL itself never uses the term "shared
images"; in fact, it is remarkably devoid of any technical terms. IMHO that
is one of its strengths; albeit the source of much frustration when trying
to understand it.  There is a special exception in the GPL, but it has to do
with defining the boundary between the user program and the operating
system. The phrase (from section 3) is "However, as a special exception, the
source code distributed need not include
anything that is normally distributed (in either source or binary form) with
the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component itself
accompanies the executable."  So, software that references GLIBC has two
ways of avoiding tainting by the GPL: once because GLIBC is covered by the
LGPL, and once because GLIBC is part of the OS itself.

> As I have pointed out before, there is an ambiguity in the GPL in regard 
> to any GNU product that can be built as a shared image, like 
> libsmbclient can be, but are not really considered part of an operating 
> system.

If you accept that libsmbclient is not a part of the operating system, you
lose the special exception.  And since libsmbclient is covered by the GPL,
not the LGPL, you lose that exception, too.  Therefore, I claim there is no
ambiguity.  If you produce a "work" (using the term preferred by the GPL)
that REQUIRES the use of libsmbclient, then IMHO you fall under the language
in section 2 of the GPL and must abide by its terms.  It has nothing to do
with linking or images; it has to do with whether or not your program can
operate as a standalong work without reference to any GPL'd code.  The GPL
says "2. b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties under
the terms of this License."

The GPL FAQ gives guidance on what constitutes a separate work by saying
that if program A calls program B at its "main" entrypoint, then they are
clearly separate works.  It says that when two programs communicate via
sockets, pipes, or command line arguments, they are separate works.  It
takes the position that communicating any other way (shared memory,
subroutine calls, etc.) implies the two programs are the same work.  This
position is an *interpretation* of the GPL, since there is no such helpful
technical detail in the GPL itself. You are free to make your own
interpretation, but then you'll have to accept the fact that some members of
the software community may not agree with you, and may not cooperate with
you, and may even say things about you that you find unpleasant.

> I am trying to determine if it is a violation of the GPL for me
> to produce a LIBSMBCLIENT shared image.

I agree with Simo on this one; you are allowed to distribute binaries from
source code covered by the GPL as long as you meet the terms of the source
code redistribution requirements that are in the GPL.  You can even charge
real money for these binaries, but for the source code, you can (in the
words of the GPL) "charge no more than your cost of physically performing
source distribution". See section 3 of the GPL. Therefore, no, it is not a
violation of the GPL for you to produce, distribute, modify, or even sell a
libsmbclient shared image.  If you are a vendor, it is perhaps unwise to
offer clients shared images of GPL'd code because it makes it easy for them
to violate the GPL, but you yourself are not at fault (IMHO).

> But software does not need to be linked against a shared library
> to run it's routines. The software that can do so, just needs either a
script or an
> initialization file set up. The suppliers of the software supply neither,
but provide the
> instructions on how to do so with any syscall or shared image.

The GPL explicitly calls for all files needed to build the binary image to
be distributed, regardless of their source language. See section 3. The
GPL's phrase is "For an executable work, complete source code means all the
source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to control
compilation and installation of the executable." IMHO you are making a
distinction that the GPL does not accept.

Finally, the GNU GPL FAQ (http://www.fsf.org/licenses/gpl-faq.html) weighs
in precisely on the point at hand, and gives a clear interpretation.

	Q: If a library is released under the GPL (not the LGPL), does that
mean that
         any program which uses it has to be under the GPL?
	A: Yes, because the program as it is actually run includes the
library. 

	Q: Can I use the GPL for a plug-in for a non-free program?
	A: 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. So you can use the GPL for a
plug-in,
         and there are no special requirements. 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 that
         linking the GPL-covered plug-in with the main program would violate
         the GPL. However, you can resolve that legal problem by adding an
         exception to your program's license which gives permission to link
         it with the non-free main program. 

One item our outside legal consultants made perfectly clear.  Forget about
the legal meaning or standing of the twisted phrases in the GPL and LGPL.
Give more weight to the opinions of the free-software / open-source
community.  You need their help, cooperation, and good will.  Are the
actions you are taking in harmony with the thinking of most of the members
of this community?  If so, you will find support and encouragement for your
position.  If not, you'll be at odds with the community.  This litmus test
is a lot easier to apply, and I've also found it easier to explain to
management.

HTH
PG
--
Paul Green, Senior Technical Consultant, Stratus Computer, Inc.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
Speaking from Stratus not for Stratus