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

Re: GPL and command-line libraries



I am concerned there might have been some confusion about terms here.
Code here can mean three things:
	source code -- my copyrighted implementation of an:
	error correcting code -- an algorithm I developed which operates on:
	encoded data -- the data being transmitted in a special form

In this reply I try to use exactly those phrases and never 'code' alone.

On Fri, Nov 26, 2004 at 10:42:27PM -0500, Nathanael Nerode wrote:
> 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.

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. They could also reuse the same
algorithm since I don't find it ethical to patent algorithms.

> 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. Any library could have a command-line interface wrapped around 
it in order to avoid 'linking'. So how can the FSF talk about linked
applications being derivative works.

[I've moved your later paragraph to here]:
> (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.)

This is the case I care about.

Mr. Wontshare is shipping a binary version of his program which has hooks
via 'system' or whatever into my binary command-line library which he also
ships. 

What is a binary image? I think it makes most sense that it includes the
entire shipped product---both my executable and it's dependent: his.

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'?

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

I admit to being mostly clueless about legal issues, but it feels to me that
the difference here of 'can be linked' and 'requires to be linked' are two
different things. Are they or aren't they?

Regardless, this is not the main thrust of my argument. My main point is
that he is shipping a product including his compiled program and mine. His
compiled program is 'linked' via 'system' to my application. If you deleted
my application, his will stop working.

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.

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

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

As I understood it, however, the algorithm and would be protected by a
patent, not a copyright. In what way can I protect this with the GPL?

What are you proposing I could copyright as 'error correcting code'?
I think confusion of terms is perhaps the problem here?

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

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

Mr. Wontshare has taken my work and integrated it as a critical component
into his project which he then ships together with my work. Yes, he supplies
my source code, but not the source code of the rest of the combined project.
He has taken a modified version of my library proprietary. His project is
a modified/enhanced version of my library and his own work.

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

In my case, it would be a 'black box'.
So, perhaps this is not a 'derivative work' in the meaning of copyright law.
However, he still needed a grant of licence from me to ship my software.

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

I think that's a straw-man arguement resulting from a misunderstanding.
I've never advocated preventing him from writing a compatible program.

I have been saying that I don't want him to ship a project which includes
his and mine where his critically depends on mine.

A digression tangentially related to my arguement:

This relates to the 'contaminate other software' provision of the DFSG. 
I think this is what the GPL does, whether the DFSG #9 like it or not. 

The GPL prevents you from shipping a closed compiled program together with a
compiled GPL library that it depends on. Whether you can make a binary ABI
compatible library to replace the shipped one is irrelevant. Therefore,
there must be an implict exemption for dependency in DFSG #9.

> If such a license held up in court, it would allow Microsoft to prohibit
> Wine, Cygwin, Mingw32, reading the FAT file system, etc.

Again, I think you are not attacking my actual arguement.

I am not objecting to Mr. Wontshare writing his own source code that 
decodes encoded data output by my implementation. Rather, I don't want 
him to distribute software which, for correct operation, depends on and 
includes with my copyrighted source code.

I hope this clears some things up.

To recap, there are (at least) four integrated issues:
1. He is shipping my GPL'd library (including my source) with his product
2. His product uses my library via 'system' as opposed to 'dlopen'
3. Without my library in the shipped product, the product does not work
4. His source code is not available

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

-- 
Wesley W. Terpstra



Reply to: