Scripsit "Wesley W. Terpstra" <[EMAIL PROTECTED]> > > 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. Agreed. > 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 work. > > 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'. Exactly. > 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"
