Re: using GPL api to be used in a properietary software

[Stefaan A Eeckels]

On Mon, 14 Mar 2005 12:12:29 +0100
Martin Dickopp <expires-2005-04-30@zero-based.org> wrote:

> Stefaan A Eeckels <tengo@DELETEMEecc.lu> writes:
> 
> > On Sun, 13 Mar 2005 10:37:43 +0100
> > Martin Dickopp <expires-2005-04-30@zero-based.org> wrote:
> >
> >> I find it unconvincing to argue that a program is not a derivative
> >> work of a dynamic library just because this case is not properly
> >> covered by a non-limitative list of illustrations.
> >
> > The enumeration illustrates the way in which "based upon"
> > should be construed. A program in source code formar references 
> > a library, but is not based upon the library in the sense
> > of the definition in 101 USC 17 (which would require an
> > adaptation, transformation, etc. of the material in the
> > library).
> 
> That depends on what you mean by "etc." It would not, according to the
> words of the law, require an adaption or transformation, since the list
> of illustrations is not limitative.

But that doesn't mean that the judge can suddenly decide
whatever she pleases is a derivative work. The list is
indeed not limitative, but neither is it non-existant.
In other words, actions very substantially similar to those
in the enumeration would have to occur for something to
be considered a derivative work.

You seem to believe that the definition could just have well
been "anything the judge finds acceptable", and that is just
not correct in any jusrisdiction.

> > Once you claim that a dynamically linked executable is a derivative
> > work of the libraries it "uses", you have precious few arguments left
> > to argue the source code is an independent work.
> 
> That depends on how the program has been created and other details. If a
> program uses the ISO-standardized C library API, and uses no components
> of a particular C library while it is being created, then a derivative
> work of the program and a particular C library is created the moment the
> program is run (and therefore linked with the library). 

What you say here is that you do not believe a source code program
like this:

#include <stdio.h>
int main(int argc, char* argv[]) {
  printf("Hello world\n");
}

is not a derivative of the standard 'C' library, but that the
copy that is created at run time in memory is a derivative 
work of both the source code and the standard 'C' library
(or for Alex, a compilation, but that doesn't matter because
the same protections are extended to compilations as to 
derivative works). 

What you also say is that the dynamically linked executable,
that only contains references to the standard 'C' library, 
is _not_ a derivative work. This is not what the FSF says.

> But I can also
> imagine different circumstances under which a derivative work is already
> created when the programm is written.

This is obviously happening when one takes an existing
source code, and modifies it. 


> I do believe that a look at a work is not enough to judge if it is a
> derivative work of something, but the act of creation has also to be
> taken into account. Imagine I take a program FOO and make some
> modifications to it, forming a derivative work BAR. And now imagine a
> different case where I write a program BAZ which is identical to BAR,
> but I wrote it all myself and I didn't even know FOO existed. Even
> though BAR and BAZ are identical bit by bit, I believe that BAR is a
> derivative work of FOO, but BAZ it is not (regardless of the fact that
> that might be hard to prove).

You're describing clean-room reverse engineering.

> My opinion is therefore that there isn't a single rule, but that it can
> only be decided on a case-by-case basis if something is a derivative
> work of something else.

It don't think so. If you write a Harry Potter story you're obviously
preparing a derivative work. If you write a story that features
wizards, you'd not be making a derivative work unless you would
copy specific Rowling-isms. 

Take care,

-- 
Stefaan
-- 
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh