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