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

[Martin Dickopp]

Stefaan A Eeckels <tengo@DELETEMEecc.lu> writes:

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

No, I don't believe that at all. 101 USC 17 defines a derivative work as
"a work based upon one or more preexisting works." If it can be clearly
decided whether this criterion applies, no illustrative list is needed.
In borderline cases, the illustrations could help the judge to under-
stand what intentions the makers of the law have had.

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

Too many "not"s. :)

I believe that this source code is not a derivative of any existing
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 [...].

Yes.

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

Not necessarily; that depends on the details.

If the <stdio.h> header contains a non-trivial inline implementation of
printf (which makes calls to other C library functions, so that linking
with the library is still necessary), I would consider the executable a
derivative of the <stdio.h> header.

If the executable has been created without a C library installed, I
wouldn't consider it a derivative of any particular C library.

If the executable has been created by linking against a stub library, I
would consider it a derivative work of the stub library and the headers.
The stub library and the headers might or might not have copyright
protection, and might or might not be derivatives of other works
themselves, depending on what they contain and how they have been
created.

While the previous two examples might hold some potential for people
trying to circumvent the library license, they do not represent (as you
are undoubtedly aware) how linking is _actually_ done on ELF systems
like GNU/Linux in practice, so let me move to more realistic examples.

If the executable references the symbol printf@GLIBC_2.3, I would indeed
think that it is "based upon," and therefore derived from, the GNU C
library. (Hypothetical example; I have not checked if this particular
versioned symbol actually exists in the GNU C library.)

If the executable merely references the unversioned symbol printf, this
is a borderline case on which I have not yet formed an ultimate opinion.
Presently I tend to think that for standardized APIs like the ISO C
functions, the executable is not a derivative of the library under these
circumstances, but for non-standardized APIs (when the only information
about the API is the library itself), it is, in particular if only a
single implementation of the API exists.

> This is not what the FSF says.

That may be the case, although
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

| If a library is released under the GPL (not the LGPL), does that mean
| that any program which uses it has to be under the GPL?
|
| Yes, because the program as it is actually run includes the library.

seems to agree pretty well with my opinion that a derivative work of
both the executable and the library exists at run time.

Anyway, it's not a pratical problem for me at all. I use only Free
Software, and in cases of incompatible Free Software licenses, I respect
the wishes of the copyright holders.

Martin