Dynamic linking, was: Re: Dispelling BSD License Misconceptions

[Ben Tilly]

On 1/25/07, Lawrence Rosen <lrosen at rosenlaw.com> wrote:
> > Lawrence Rosen wrote:
> > > It is perhaps simpler to say that, to the extent that you write a
> > program
> > > that supports a particular API *without basing your expressive coding on
> > > someone else's original copyrightable work*, there is no derivative work
> > > problem.
> >
>
> Matthew Flaschen responded
> > Well, if you're statically linking the executable will actually include
> > code from the library; this is definitely a derivative work.  If you're
> > dynamically linking, it will be designed to load code from the library;
> > if only one library implements the API, the code is probably a
> > derivative work of that library.
>
> Would someone here please explain how the mere act of statically linking,
> which may automatically and without my interference take some bytes from
> program A and some bytes from program B and combine them in a memory image,
> result--without more--in a creative work suitable for independent copyright?
> Why shouldn't this be treated as "making a copy," which usually carries far
> fewer obligations under reciprocal/copyleft licenses.

Non-sequitor.  The question isn't whether the result is suitable for
an independent copyright, the question is what permissions the
copyright licenses for included copyrighted pieces gives you.

Let's suppose that one of those pieces is under the GPL.

The GPL gives you permission to copy 2 kinds of things.  The first is
the right to copy GPLed works.  The second is permission to copy GPLed
works which have been combined by "mere aggregation" with non-GPLed
works.  There is no permission to copy a single thing produced out of
GPLed and non-GPLed works.

However the complete compiled result is a single program.  You could
try to argue that this is "mere aggregation", but I think you'd have a
hard time of it.  (For one thing it isn't straightforward to determine
what parts of the final result belong to the GPLed piece and what
parts do not.  With mere aggregation that should be easy.)

Therefore the only way to find permission in the GPL to distribute a
program which has statically linked a GPLed library is to make the
entire program is GPLed.  Otherwise no permission is given.

> I can't find any principled distinction in a copyright sense between static
> and dynamic linking, although either kind of linking might be an indicator
> of an intention to create a derivative work. You don't create a derivative
> work unless you base one creative and expressive work on another, which you
> can do equally easily (and equally hard) with static and dynamic linking.

In an abstract copyright sense I agree with you, but I believe that
the GPL's terms draw a practical distinction.  However (and this will
be interesting to watch going forward) when you throw in various
virtualization technologies, the GPL may have some unexpected
consequences.  For instance suppose that I snapshot an image of a
running system and copy that snapshot elsewhere.  If that snapshot
included GPLed programs, does the whole snapshot have to be GPLed?
IANAL, but I find it interesting.

Another case of interest is the web.  Suppose that I write GPLed
software that produces a website.  There is no question that the web
pages that I display include lots of stuff that is part of my
codebase.  I think they should therefore be GPLed.  And every time you
fetch a page, a derivative work has been distributed.  Does every
page, therefore, need to include a copy of the GPL?

Cheers,
Ben