[Top][All Lists]

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

Re: Use of GPL'd code with proprietary programs

From: Christopher C. Stacy
Subject: Re: Use of GPL'd code with proprietary programs
Date: Fri, 09 Jul 2004 09:18:29 GMT
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

>>>>> On Thu, 08 Jul 2004 23:27:29 +0200, Martin Dickopp ("Martin") writes:

 Martin> Alexander Terekhov <> writes:
 >> Now, do you seriously believe that they will be able to convince 
 >> a non-drunken district judge (appellate and supreme folk aside
 >> for a moment) that "works that use the library" are in fact
 >> derivative works under copyright law?

 Martin> Yes.

People who want their library program to be potentially useful for
proprietary programs, but preserve GPL protections for their code
per se, can always just use the LGPL (or even some modified version
of it) rather than the GPL.  Also, having missed the beginning of 
this thread, I'll assume we're now talking about some kind of 
dynamic linking rather than static linking.

We know that merely providing the library (for example, in a tarball 
or on a CD) is not creating a derivative work, because even the GPL
says that it's not (section 2 "mere aggregation...does not bring the
other work under the scope of this License."   Taking a whole GPL'd
work and just distributing it alongside other separable works 
(eg. in separate files) is not violating the GPL.

If we're talking about a program that dynamically downloads GPL'd
content into memory and displays it for the user, that seems like it
might be creating a derivative work if it combines it with some other
content or rearranges or modifies the content.  (If your program just 
reads a GPL'd file and displays it wholesale, that's not creating
a derivative work.  That's called "the print command" or something.)
But taking bits and pieces and incorporating them by decomposition into
a new document would constitute a derivative work.  Whether such a
program would be a problem probably depends on details like whether 
it can splice and dice documents in general. Also, some other case 
law that would probably come into play in this example would be 
about hypertext linking.

But I think that's all different from linking a library.  

A library is a whole work or some entire "chapters", none of which
is being modified, and which are being "combined" under different
circumstances than the above.  In particular, dynamically linking 
a library is nothing more than running two programs on the same computer.  
Eben Moglen argues that the "The language or programming paradigm in 
use doesn't determine the rules of compliance".  I would agree that
the implementation detail of whether the two programs simultaneously 
reside in the same flat address space, or in different segments of a
segmented address space, does not determine whether a derivative work
has been created.  But we would come to entirely different conclusions.
FSF states that two programs communicating with each other do not
represent a "derivative work", and I think the fact that they just 
may happen to be in the same address space doesn't change the fact
that they are still two separate programs.

By contrast, when you package them up into a file by statically
linking them, that's something we understand to be an original work.
(But that's just because we think a file is like a book of paper.  
I'm not sure sure that it is.  But I certainly don't think that 
an address space per se is a book!  One thing's for sure that we
can all agree on, though: IP law is fairly bankrupt in light of
digital technology, and this is to the detriment of modern society.)

I think the more relevant question is whether one has modified 
the other or whether they have been made inseparable.

The basis of Eben Moglen's theory, that dynamically linking creates a
derivative work, seems to be summed up as, "Your code, in order to operate, 
must be combined with the GPL'd code, forming a new combined work...".
He says it again in his affidavit in the PROGRESS v. MYSQL case: 
"Anyone who combines GPL-licensed software with other program code 
must release the combined work under GPL, and must provide the source
code for the entire derivative work."

But as far as I am aware, copyright law does not speak of "combining"
works like that and gives no legal basis to his theory.  In order to 
create a "derivative work", one must "modify" the original work (that
is, copy something from it) into an "original work of authorship".
He disagrees when he says, "...nor does whether the GPL'd code has 
been modified".  He's arguing for a very different meaning!

The biggest flaw in the theory is the fact that your program does not
require the GPL'd code in order to operate.  It only requires some code
that meets the interface requirements.  Dynamic linking is precisely
about *not* requiring a particular file in order to operate. The decision
of which library to load is deferred until the program is actually running
and calls for it.  And it does not necessarily specifically call for the
GPL'd library.  Any other library would be just as good as the GPL'd one, 
and that library could have been provided by anyone at any time.

Maybe Eben's thinking that when the program is executed, it will call 
into the computer's memory a copy of the library.  At that moment, the 
two programs have been "combined" in some sense.  The FSF has published 
a statement that they believe this to be the issue: "If modules are designed
to run linked together in a shared address space, that almost surely means
combining them into one program."  But asserting that the programmer has
made this combination is a major inconsistency in their own argument.
The GPL only restricts how copying is done by distributors. 
With dynamic linking, it's the end-user that is copying the library into
memory and creating this combination, and the GPL explicitly allows users 
to make copies (and even derivative works) if it's for their own use.
(This provision of the GPL also defeats any idea that the programmer 
has created a device for contributory infringement, since the program 
is merely facilitating activity that the GPL definitely intends to allow.)

If you try to follow the reasoning that dynamic linking constitutes creating
a derivative work, then all computer programs are always creating mutually
derivative works.  Following that chain of reasoning, one could claim that 
all programs running under an operating system are derivative works of that
operating system.  An operating system is nothing more than a collection of
libraries that all the programs are dynamically linking with, and the
programs are definitely designed to work only when the two are "combined"
with the operating system.  So that interpretation isn't likely to hunt.

Eben's other assertion is that the GPL is a license contract that specifies
certain terms, and its intent is clear when it describes that that library
linking constitutes creating a derivative work and that such works are
required to follow the GPL (thereby "infecting" the user's program and
causing it to become GPL'd as well).  GPL says: "4. You may not copy,
modify, sublicense, or distribute the Program except as expressly
provided under this License."  This contract argument does seem like the
most plausible justification. But the GPL is purported to be a carefully
crafted document, and here it's using terms of art like "derivative
work", and explains itself as being based on the copyright laws.  
It seems a little disingenuous to then come along and defend the license
by suggesting that the authors and their esteemed legal counsel who
drafted and are defending it didn't quite understand the accepted
meaning "derivative work" in copyright law.

It seems more likely that they knew exactly what they were doing, and that
from the outset they were hoping to establish new case law by changing the
legal meaning of "derivative work", thereby simultaneously expanding the scope
of their rights and introducing certain fundamental problematic issues into 
the arena of software copyrights .  Trying to set such precedents would be
consistent with the goals of their clearly stated agenda, which boils down
to a radical de-legitimization of intellectual property rights

I think they're way out on a limb, hoping for a very odd interpretation.
(Even given that interpretation, the GPL is inconsistent about the requirements
it would bring,  But with this ammunition they would probably successfully
argue on the clarity of the greater intent in the contract.)

The last I heard, there were no actions pending that would resolve this.
The only GPL related case to date was PROGRESS.  The judge did correctly
identify that a major issue was the definition of "derivative work", 
but no conclusions were reached at all.  The GPL-touting plaintiff succeeded
in the courtroom only on some non-GPL trademark issues, and the parties settled.
The only thing we learned from this case, a couple of years ago, was that the
GPL was not entirely thrown out right away (which is significant), and that
the provisions of the GPL being discussed here are still legally untested.

So, Martin Dickopp, can you explain the answer that you gave Alexander
Terekhov by telling us what "derivative work" you are referring to and
how it was created?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]