kdelibs and the GPL
Andreas Pour
pour at mieterra.com
Thu Jun 20 14:02:20 BST 2002
Hi,
Some further elaboration below.
Rolf Magnus wrote:
>
> On Thursday 20 June 2002 10:43, Andreas Pour wrote:
>
> > A program which links with kdelibs does not, as a general matter, link
> > with the plugins, and so, it would seem, the plugin license has no
> > bearing on the program. However, if the program was written such that
> > it does not work without the plugin, or specifically relies on it, then
> > all bets are off.
>
> According to the GPL FAQ, this is not true.
> See http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
> IMHO, this doesn't make sense, but I'm no lawyer, so I don't know if something
> like this can be enforced. I mean, if I write a program, I don't know what
> plug-ins will be used with it later, and if I write a plug-in, I don't know
> which programs will use it later. So who is responsible for not using a GPL
> plugin with a non-free program?
The FAQ covers a different situation than the one we are considering.
The FAQ addresses the question of what the license of the program using
the GPL plugin has to be. For example, if you wrote a GPL plugin for
use by a proprietary program (say Netscape 4.x), the FAQ indicates
someone could not use the plugin with Netscape 4.x unless an exception
is made in the plugin's GPL license.
In the case of a program making use of a library which uses a plugin,
the situation is different. In the situation we are pondering, a
proprietary program wants to use kdelibs. The more straightforward case
is where the proprietary program does not know about any plugins, or
doesn't particularly care about them. The question is, does a GPL
plugin opened by kdelibs place any obligations on this proprietary
program. Note that this is one step removed from the FAQ you linked
and, it seems to me, does not violate the GPL license of the kdelibs
plugin even under the reading of the GPL which seems to underpin the
FAQ.
Read on if you are interested in why I think so.
The question in all cases of the GPL and other works is if the other
work is a "derivative work" of the GPL program. "Derivative work" is
incorporated into the GPL from copyright law, and supplemented with the
explanatory phrase, "a work containing the Program or a portion of it".
Under US law, which presumably is most relevant since the GPL was
written in the US, "derivative work" is defined to mean:
A ''derivative work'' is a work based upon one or more
preexisting works, such as a translation, musical
arrangement, dramatization, fictionalization, motion
picture version, sound recording, art reproduction,
abridgment, condensation, or any other form in which
a work may be recast, transformed, or adapted. A work
consisting of editorial revisions, annotations,
elaborations, or other modifications which, as a whole,
represent an original work of authorship, is a
''derivative work''.[1]
The question turns on what is meant by "based upon". The congressional
record contains the comment that to be a derivative work, "the
infringing work must incorporate a portion of the copyrighted work in
some form."[2] Courts have read this to mean incorporating a
"substantial portion" of the copyrighted work.[3] In addition, some
courts have imposed a requirement that the incorporation be of a
"concrete or permanent form", which condition was not satisfied when a
program was used to modify a bitstream being sent from a game cartrige
to a game console.[4] In any event, the GPL also explicitly raises the
requirement that the other work contains a portion of the GPL'd work.
Now in the GNU FAQ example, such might arguably be the case, since the
GPL plugin uses the APIs of, and shares data structures with, the other
program. One can diagram it as:
MP = Main Program
P = Plugin
L = Library
IDF= interface definition files
FN = functions
DS = data structures
+-----------------+
| |
| PROPRIETARY | * dlopens P
| PROGRAM | * calls P FN
| (MP) |
| |
+-----------------+
|
| [ dlopen ]
|
v
+-----------------+
| |
| GPL | * contains MP IDF
| PLUGIN | * shares MP DS
| (P) | * calls MP FN
| |
+-----------------+
As it stands, I don't agree with the conclusion in the FAQ. The terse
phrase "we believe they form a single program" has no support or
explanation. Granted, the "single program" view holds true once the MP
loads P, but not when P is being distributed (this is important because
the GPL deals only with "copying, distribution and modification", not
use, of the GPL work - in fact, Section 0 explicitly states that "[t]he
act of running the Program is not restricted", and the "single program"
situation arises only when "running the Program").
At the time of distribution, it seems to me that P is a separate work
from MP, except for possible MP IDFs which are incorporated by P. Since
it is P which includes the IDFs of MP, MP is obviously not a "derivative
work" of P, but Section 3 of the GPL requires someone distribute the
"complete source code", which includes any IDFs. Hence, if the MP IDFs
are GPL'd, this should be OK (of course the IDFs can be dual licensed,
GPL and proprietary, so GPL programs can make use of the GPL'd IDFs).
In the past, I have also been confronted with the (rather creative)
argument that if something is designed to work with another work, and
will not work otherwise, it is a derivative work of that other work,
copyright law concepts and the text of the GPL be damned. Under this
(apparently political rather than legal) interpretation, since P is
designed to be used with MP and (presumably) has no other useful
purpose, P is a derivative work of all of MP, and hence MP forms part of
the "complete work" which must be distributed under Section 3 of the
GPL.
Now, the situation we are contemplating is, as already noted,
different. I would diagram it like this:
+-----------------+ +-----------------+
| | | |
| PROPRIETARY | [ link ] | LGPL | * dlopens P at
runtime
| PROGRAM |--------->| LIBRARY | * calls P FN
| (MP) | | (L) |
| | | |
+-----------------+ +-----------------+
* links to L at runtime |
* calls L FN | [ dlopen ]
|
v
+-----------------+
| |
| GPL | * contains L IDF
| PLUGIN | * shares L DS
| (P) | * calls L FN
| |
+-----------------+
Let's consider the two reasons why there may be a problem in the FAQ
case. There are (1) incorporating IDFs; and (2) written in
contemplation of.
First, as is clear, P does not incorporate any IDFs of MP. In fact, P
does not know about MP at all. Hence, there is no link at all between P
and MP.
Second, as a general matter, MP is not designed to work with P, and has
a use apart from P. Now, if these suppositions are false, then you
would fall within the realm of the (political) interpretation of the
GPL, hence my comment in the prior mail that in this case "all bets are
off".
So, to sum up, to be on the safe side, don't use the GPL for kdelibs
plugins which form an essential component of kdelibs, or which provide a
service which proprietary programs are likely to consider specifically
when writing their software.
Hope that helps, since this took far more time than I can afford :-/.
Ciao,
Dre
Speaking as a layperson
[1] 17 USC 101 - http://www4.law.cornell.edu/uscode/17/101.html.
[2] MONTGOMERY v NOGA (No. 95-3000 11th Cir. 1999) -
http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=search&case=/data2/circs/11th/953000opn.html
[3] Lewis Galoob Toys, Inc. v. Nintendo of Am., Inc.,
964 F.2d 965 (9th Cir. 1992).
[4] E.g., MICRO STAR v FORMGEN INC (96-56426 9th Cir. 1998) -
http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=search&case=/data2/circs/9th/9656426.html
More information about the kde-core-devel
mailing list