[sldev] [META] GPL'd APIs (Re: Protocol Documentation)

[Argent Stonecutter]

On 03-Oct-2007, at 17:48, Rob Lanphier wrote:
> On 10/3/07 3:18 PM, Argent Stonecutter wrote:
>> There have been specific cases where independently developed
>> components that implemented the same API as a GPLed program have been
>> hit with legal action by the FSF, on the grounds that by
>> interoperating with an API that was part of a GPLed program they were
>> derived works and are thus covered by the GPL... even if there was no
>> GPLed code in them. There was no "huge amount of cutting and pasting"
>> involved... according to the FSF simply using an API documented in a
>> GPLed source makes your code covered by the GPL.

> Can you actually document this?

The best known case is libmp. I can't find the original discussion on  
this one but here's a reference fairly close in time...

"http://lists.debian.org/debian-devel/1997/06/msg00088.html"
> The issue in the libmp was a package containing a midified RSAREF that
> could be linked to libmp.  Libmp is aparantly faster than the standard
> multiprecision library available.  Libmp also has a slightly different
> interface, so it isn't a simple drop-in replacement for the standard
> library (as glibc or libc5 (theoretically) is).  The FSF contended  
> that
> the resulting modified package (which was not distributed with  
> binaries
> or source for libmp) must be GPLed, since the -product-, namely the
> executable binaries, must contain GPLed code (the libmp library), so
> must be GPLed.  The source is merely the preferred distribution method
> for the product.  In this case, the product was being distributed in
> two pieces.  The justification for this position was that libmp had a
> unique interface.  Any program written to use that interface had no
> choice but to use libmp, and thus the resulting binary was derived  
> from
> libmp.  In this particular case, the program was thus subjected to  
> both
> the GPL -and- the license on RSAREF, which are incompatable licenses.
> The FSF objected to the distribution of the modified package -at all-,
> since it would be impossible to fulfill the requirements of both
> licenses.
>
> That particular package is now distributed with a simple
> libmp-compatable non-GPLed multiprecision integer package (thus
> avoiding the unique interface issue, since now there are two libraries
> with the same documented interface), and instructions to link it with
> the FSF libmp, because it is a much better library.  RMS agreed that
> this would solve the problem.

The basic principle, that using the API of a GPLed component required  
that your code be GPLed if it was distributed, has not been  
changed... what changed is that creating a second implementation that  
provided the same API meant that t he API wasn't *just* an API for a  
GPLed application any more.

This incident also led to some concern about Linux and proprietary  
drivers, because loadable drivers that run in the Linux kernel would  
also be derived works under the same interpretation. Linus ended up  
carving out an ad-hoc exception that allowed closed-source drivers.   
I don't know whether LL can do the same thing, or even if they need  
to, but the point is that it's not unreasonable for people to be  
worried about it.

There's also the open question as to whether providing or using a  
"standard API" is a general escape, or whether RMS was just carving  
out an exemption for libmp... because U/WIN and Interix had similar  
issues because the FSF said that *on Windows* the UNIX API wasn't the  
native OS API distributed by Microsoft and thus it didn't serve as a  
wall between GPL and non-GPL software as it does in Linux.

Interix was bought by Microsoft, so that made it a standard OS API on  
Windows.

The thread starts here...

http://gcc.gnu.org/ml/gcc/2001-01/msg00415.html

The logic seems a bit twisty on both sides to me.