[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPL and command-line libraries

Wesley W. Terpstra <wesley@terpstra.ca> wrote:
>What I am concerned about is the following scenario:
>Mr. John Wontshare writes a streaming multicast client.
>To deal with packet loss, he uses my error-correcting library.
>Without my library, Mr. Wontshare's client can't work at all.

That statement is probably incorrect!

If your library has a well-specified API, anyone could make a library with the
same API, and his client could use that.  Under those circumstances, his
client is not a derivative work of your library (although it may be a
derivative work of the *API and other specifications*, if the specification is
sufficiently clever and complex to be copyrighted).

The readline/editline situation is a good parallel here.  A program which can
be linked to either library is not a derivative work of readline, and does
not need to be under GPL.

(Incidentally, if your error correcting code or your API spec is in fact
copyrightable, you could put that under the GPL, which would achieve your
goal.  If it's really "quite simple", as you said, then it's probably not
subject to copyright.)

>Mr. Wontshare's client represents only a small investment of effort and
>without having had access to my library, he could have never written it.
Well, if that's *really* true, then his client is probably a derivative work.

>He then distributes his client along with my library to end-users.
>These users don't get Mr. Wontshare's code, even though he uses my library.
(but they do get your library's code).

>Even worse, he refuses to port his client to MacOS X for business reasons.
>(intentionally giving an unfair competitive advantage to another platform)
>To me anyways, this sounds like exactly the situation the GPL is supposed to
>protect against.

It isn't.  You've misunderstood the GPL.  The GPL is supposed to protect
against modified versions of your library being taken proprietary; that's the
exact situation it's supposed to protect against.

>Is this _not_ a derivative work?
That's a factual question.  It's most likely dependent on whether his program
simply used your library as a "black box", or whether his program was really
based on mucking about with the internals of your code in a way which really,
absolutely, involved using parts of your code.

Please note that it doesn't really have much to do with whether it's a command
line interface or not.  A sh script written to POSIX specs isn't a derivative
work of bash.  In contrast, an sh script loaded with dependencies on
undocumented internal features of bash might be a derivative work of bash.

(The FSF's statements that linking with a library creates a derviative work
of the library confuse people; it may help to remember that this only applies
to the *binary image* created by the linkage, which contains elements of the
library, not to the source code of the program using the library.)

>If that's really the case, is it possible that a GPLv3 might address this?

God, I hope not.  It wouldn't be a free license, since it would restrict
activities which are unrestricted under copyright law, namely the right to
make compatible programs.  If such a license held up in court, it would
allow Microsoft to prohibit Wine, Cygwin, Mingw32, reading the FAT file
system, etc.

Incidentally, this kind of question is suitable for debian-legal but not for

This space intentionally left blank.

Reply to: