Clarification on license for embedded/API use?

[Jonathan S. Shapiro]

On Mon, 2007-09-03 at 20:14 +0200, Emanuele Aina wrote:
> Jonathan S. Shapiro dubitò:
> > 
> > If Mercurial publishes an API, and a separate application uses it, this
> > is NOT a violation of GPL. Having one program call the other is
> > perfectly okay. The violation of GPL occurs when the two programs are
> > combined into a single combined work.
> 
> Linking a program with a library will produce a combined work, and if 
> the library is GPL then the program has to be under a GPL-compatible 
> license.
> 
> If you don't want this you have to put your library under the LGPL (or 
> something else).

Legally, this issue is *much* more complicated than you say. GPL relies
on the notion of a "combined work", which is a very complex notion
because it is defined by judges and case law. The term "combined work"
is not actually defined in copyright law. This is intentional.

First, let me explain that my first comment above was strictly a
statement about APIs. A machine-readable API specification has very
peculiar status under copyright. For example, if I place a GPL notice in
a header file for a library, and that header specifies a public
interface for the library, it is unlikely that including the *header*
file contaminates the application.

For *static* linking, what you say is correct, because the resulting
binary is generally agreed to be a combined work.

For *dynamic* linking -- which is what John appears to be doing --
matters are much less clear. There are two issues:

  1. The run-time loaded program image in memory combines the library.
     It follows that any *copies* of that run-time load image must
     be distributed under GPL if they are distributed at all. It
     does *not* follow that they are permitted to be distributed.

     GPL does not prevent me from combining GPL software with
     non-GPL software for my own use. The terms of GPL only become
     relevant when the combination is redistributed.

     Since a portion of John's run-time program image is governed
     by a proprietary license, the user does not have the right
     to redistribute it.

  2. The static binary does NOT combine the library. This brings us
     to the question of what constitutes a combined work under
     copyright law.

     If you look, you will find that this term is not defined in
     the body of law. It is left to a judge to decide whether something
     is a combined work. Usually, judges will be guided by the sense
     of the community or commnunities involved.

     If I build a program that clearly cannot function without loading
     your GPL'd program, most judges are likely to consider the result
     a combined work. If I load your program as a plugin, but my program
     has other legitimate functions without the GPL'd subsystem, then
     matters quickly become unclear.

     If I use dynamic linking merely as another mechanism to achieve the
     results of a static link, or merely to evade GPL, the judge would
     probably rule that my program is still a combined work.

Scripting languages like python make this even more convoluted, but the
same intuition used for dynamic linking would probably apply.

All that being said, John should be careful here, because judges are not
always predictable. The conservative course of action is for him to run
HG in a subprocess.

> >> That would work if Selenic was the only copyright holder.
> >>
> >> Right now you would need to ask every Mercurial contributor to relicense 
> >> his portion...
> > 
> > Hmm. This is a major bug that needs to get discussed, because it creates
> > a potential legal problem for Selenic, but this exchange certainly is
> > not the place.
> 
> Why do you think so?
> 
> Until Selenic complies with the terms of the GPL I don't see how this 
> can be a problem.

I am not aware that Selenic is failing to comply. Selenic isn't the
issue here.
-- 
Jonathan S. Shapiro
Managing Directory
The EROS Group, LLC
www.coyotos.org, www.eros-os.org