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

Re: GPL and command-line libraries

Scripsit "Wesley W. Terpstra" <wesley@terpstra.ca>

> > If your library has a well-specified API, anyone could make a library with
> > the same API, and his client could use that.

> I am perfectly fine with this.
> If he uses someone else's source code to implement my API, so be it.

> Of course, that new source code would have to be able to decode the same
> encoded data, which I am also fine with.

Not necessarily. It is quite possible that someone could find
mr. Wontshare's application useful when linked against a library that
encodes data in a different way from your library. It is not a given
that everybody will find interoperability with instances that use your
library important.

> > Under those circumstances, his client is not a derivative work of your
> > library 

> I don't see the difference here between a real library and a command-line
> interface.


> So how can the FSF talk about linked applications being derivative
> works.

They use a legal loophole known as "freedom of speech", which enables
them to make claims that may not be actually be true as stated. If the
question of whether a given work is derived from a GPLed library ends
up in court (whit, ttbomk it yet never has), there is no guarantee
that the court will accept the FSF's claim as the natural basis for
making the judgement.

One can certainly imagine cases where any judge in his right mind (and
of sufficient technical understanding) would rule that this particular
program using that particular GPL'ed library is in fact a derived work
in a pro forma technical disguise, and should therefore be covered by
the library's licensing terms.

However, one can also imagine cases where any judge in his right mind
would rule differently. And there is a large grey area between those
two extremes. The only thing that is certain is that the matter is not
as clear-cut as the FSF would like to make people think.

> Whether the library and binary form a single file seems irrelevant.
> Otherwise, .dll's or .so's would also avoid this 'binary image' issue.
> What is the difference between 'dlopen' and 'system'?

Not very large, legally speaking. It is a common error for people with
a primarily technical viewpoint to think that the legal questions are
decided primarily by the tecnical nature of the connection between the
two works. In fact, the technical details make little difference once
we get past the opening question of "does this directly contain some
of his bits or not?".

The important consideration is the high-level *intention* of the
connection, including what the different parts actually *do*.

If library L provides to program P an well-defined generic service
with a simple black-box interface, and it is provided in a way that is
essentially independent that the client is P rather than an unrelated
program Q, then I think it is very hard to argue that the source code
for P is derived from L (and similarly for compiled versions of P that
do not include a statically linked L).

On the other hand, if L exports a lot of hooks for P to inject its own
code into whatever L does, or P depends intensively on internals of L
that are not easily decribed as a generic service interface, then a
good case could be made that P is effectively derived from L.

Between these two extremes are, as always, a big scary grey area.

> I am not taking away any of his rights; he is shipping my code!
> Without a grant of licence from me, he can't do that.

It is of course completely true that you as an author have the power
to forbid him from distributing your code, and you can set any odd
conditions for giving a license that you want.

However, you can forbid this and still give your source code a license
that Debian would consider "free" is a more difficult question. Here I
am inclined to think that the answer is "no".

> The error-correcting code algorithm and implementing source code are not
> themselves simple---only the API is simple.

But that does mean that your library provides a generic black-box
service, which makes is *unlikely* that you cound succesfully argue in
court that the source code for the application is derived from your

> > 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.

> As far as I can see, I haven't misunderstood it at all;
> what you describe is what's happening here.

No, there is no modified version of your library in your scenario.

> Mr. Wontshare has taken my work and integrated it as a critical component
> into his project which he then ships together with my work.

As far as you have described it, there is no real "integration" going on.

> He has taken a modified version of my library proprietary.

No, he hasn't. He hasn't even *created* a modified version of your library.

> In my case, it would be a 'black box'.


> I've never advocated preventing him from writing a compatible program.

What you seem to be doing is exactly saying that you don't want him to
write a program that is compatible with (= can use) your library's
black-box service.

> I claim that 4+3+2 means he did not obey the GPL and cannot do 1.

Your own information about the black-box nature of the service
indicate that your claim is most probably wrong.

Henning Makholm                             "... and that Greek, Thucydides"

Reply to: