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

Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

Anthony DeRobertis said:
> I'm not sure if you're thinking of this when mentioning "public 
>domain", but many header files (for example, ones giving simple structs 
>and numeric defines) probably have no copyrightable work in them, and 
>thus would be essentially in the public domain. So, using those is 
>fine, no matter what the copyright notice says.
I was, indeed, thinking of this. :-)

> I point out Lotus v. Borland[0] and note that the commands used by the 
>shell script are the same as used by a human, and thus are a method of 
>operation, not protected by copyright.
This is an interesting case, the details of which I was not aware.

This case leads to the following test:  if you are 
accessing a program through an interface which is a "method of 
operation", referring to the "means by which a person operates 
something", you incur no obligations, because that is not copyrightable.

There are various possible extrapolations from this.

First, any interface which could be used by humans is a "method of 
operation".  This is essentially all interfaces.  Since dynamic linking 
involves the copying of small, (usually) uncopyrightable, code segments, 
together with the use of an interface, dynamic linking incurs no 
obligations, and the FSF's interpretation is quite wrong.

Second, any interface which is designed for use by humans is a "method 
of operation".  This is more restrictive, but does not touch the 
question of secret interfaces.  Suppose that passing 
"-EF)#I^FMCVS)*@34%)GS234@$#7sd" on the grep command line gives access 
to the secret operations -- is this the means by which a "person" 
operates something?  Suppose the corresponding scheme is the passing of 
a specific 255-byte string, designed with the intention that it will 
only be used by computers?

Third, any interface which is usually used by humans is a "method of 
operation".  This is also unclear on important points, like the last 

>>So in regards to "declawing", this makes a *non-arbitrary* distinction,
> Not really. You essentially said that if I, as the author of a 
>non-GPL program that wants to use a GPL'd work says "I need a program doing
>foo, bar, and baz to work, such as GNU frob" instead of saying "I need GNU 
>frob to work" I'm fine. That's a rather pointless distinction, 
It consists of creating interface documentation in a publically 
accessible way; one which allows, and even encourages, creation of 
replacement programs.  This is intended as a defense against the 
claim that the program *relies* on copyrighted elements of the GPLed 
program.  ("No, it doesn't rely on anything in GNU grep.  Any user of my 
program can write an appropriate 'grep' program; I told them what they need
to do!")

If my first extrapolation from the mentioned case is the correct one, then
the documentation status of the interface is truly irrelevant, and 
incidentally the GPL doesn't cover dynamic linking.

If my second extrapolation is the correct one, then the documentation 
status *may* be relevant as evidence for whether the interface was 
designed for humans or not, though what matters is whether the GPL 
program creator documented it.  Writing out what features are used is 
still a way to insulate yourself against claims that you're relying on 
copyrighted elements of the GPLed program, however, since this 
extrapolation doesn't clearly resolve the 'secret interfaces' issue.

Here, however, we see something interesting.  When a library is distributed 
independently, its *only* interface designed for 'a person to operate' 
it, is its library linking interface.  Accordingly, the FSF's claims 
about the GPL covering dynamic linking of such libraries are no good, 
and we can stop worrying generally about dynamic linking of GPL libraries.

(In fact, its other interface designed for 'people to operate it' is the 
interface for being statically linked with programs, so use of static 
linking probably isn't covered either!  Although in that case the 
combination is probaly a 'derived work' and may not be redistributable; 
but individuals can do the linking themselves quite freely.)

If my third extrapolation is the correct one, then the FSF's 
library linking interpretation is valid, but we've wandered into a 
remarkably fuzzy realm.  Certain command-line options are rarely, if 
ever, used by humans; for instance, options designed to produce better 
program-readable output.


>>It's a matter of whether the linkage is integral to the
>>program, or not.  Admittedly the distinction must be applied carefully
>>on a case-by-case basis, but that's often what makes good law.
> I'd say its a matter of if the linkage causes program B to rely on 
>copyrighted elements of program A, then there could be infringement. 

You're better at stating things clearly.  :-)

However, if the 'linkage' causes program B to rely on copyrighted 
elements of program A, but the 'linkage' is not actually performed 
except by the end-user, then there is no infringment on the part of the 
distributor.  And the GPL puts no restrictions on 'use', or indeed 
creation of derived works as long as they're not distributed, so 
there's no cause for contributory infringment, as far as I can tell.

The distributor would be infringing if the 'pre-linked' program A 
(without program B) consistutes a derived work derived from program B.  
This is basically an issue of copyrightability of header files, however, 
unless the *interface* to program B is copyrightable.  Which according 
to Lotus v. Borland, it probably isn't.  (Unless my third extrapolation 
is the correct one.)

>But I can at least agree that the border cases require careful case-by-case 
Oh yeah...


Disclaimer: This is not legal advice!

Reply to: