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
interpretation.
>>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,
>methinks.
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
>analysis.
Oh yeah...
--Nathanael
Disclaimer: This is not legal advice!
Reply to: