Re: [tlug] A semi-related question

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Brett" == Brett Robson <b-robson@example.com> writes:

    Brett> On Mon, 25 Apr 2005 12:53:29 +0900
    Brett> Michael Moyle <washu@example.com> wrote:

    >> (NOT to the GPL, which requires that any code statically
    >> linking to GPLed code also be placed under the GPL, making the
    >> source openly available and non-proprietary).

This is (probably, until a court says otherwise) false on three
counts.  First, according to the received doctrine (strongly advocated
by the FSF, but _not_ invented by them) the GPL covers (as part of the
joint work) code that will be linked to a GPL work.  It doesn't matter
whether that linkage is static or dynamic; the boundary is the
process's memory space.  The kernel is not in the process memory
space, the kernel doesn't affect user programs.  Dynamic libraries
(including libc) _are_ part of the derived work, but certain special
exceptions are made (see below).

The second variance is that the GPL only places conditions on
redistribution.  That means that, for example, the rumored
enhancements to XEmacs made by Morgan Stanley Dean Witter (I've never
seen them, but they sound really cool) need not be published, since
use of the MSDW code by MSDW employees at work is not "distribution",
and use of that code anywhere else is "theft".  :-)  Similarly,
evidently both Google and Amazon make heavy use of proprietary mods to
GPL code (Mauro, can you confirm/deny?), but they'll never tell, and
don't have to.

Third, _you_ do _not_ have to publish the source, even if you
distribute.  You simply have to give it to your customer, and are not
allowed to restrict the recipient from publishing it.  Of course, if
the recipient considers your code to be a proprietary mission-critical
competitive advantage, you may not have to worry. :-)

    Brett> I normally don't take any notice of licencing stuff as it
    Brett> doesn't affect me. Does that means if you use the GNU std C
    Brett> libs they infect your project with GPL?

No.  The easy answer is that glibc is distributed under the LGPL.  It
does not extend itself to cover the whole of a derived work, but
simply requires that the parts can be separated so that the LGPLed
portion can be upgraded (at the customer's risk if the vendor uses
underspecified quirks in the current version).  In that case you need
not supply source for your code.

However, the GTK+ and GNOME libraries _do_ infect your code with the
GPL, AFAIK (I believe they are distributed under the GPL).

Second, to the extent that your work is written to a library API with
multiple implementations, not all GPL, you can distribute your work
separately (you can't distribute it with a GPLed library without
invoking the GPL) or with a permissive implementation.  So, for
example, for a long time the readline interface used by Bash was only
available as a GPL library, and rms was able to force Aladdin
Ghostscript (non-GPL) to remove the Makefile target that linked it in,
while "GNU Ghostscript" (the older version, under the GPL) was still
allowed to use it.  Today this is no longer possible, as there exist
free---oops---"permissively licensed" implementations of the readline
API.  Similarly, if you use only POSIX features of libc, and no GNU
enhancements, even if rms were to "upgrade" glibc to the GPL, it
wouldn't matter (and I think that's one important reason why he
doesn't do that).

However, if only the GPLed library implements some of the API that you
actually use, then the FSF claims that even if you don't distribute
the GPL library, distribution of your portion of the derivative work
constitutes distribution of the whole.  Thus your work becomes
"infected" with the GPL.  I think the legal argument is pretty tenuous
here---it is definitely true that in the case above with multiple
implementations, users are legally allowed to download your code and
the GNU version of library, link them, and run the combined program.
It's usually the case the implementing some sort of alternative for
the same API is fairly simple.  Eg, Ghostscript has a GIF writer that
doesn't use LZW.  This means that Ghostscript is not infringing on the
Unisys patent on LZW, even by the FSF interpretation.

Yeah, it's all very unclear and twisted.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.