[development] Modules that integrate non-GPL PHP apps violatethe GPL.
metzlerd at metzlerd.com
Sat Sep 8 01:39:42 UTC 2007
I think the core question in this still is, "What constitutes a
derivative work", which if my research is correct, cannot be answered
as a technical question.
I actually just started with searching for wikipedia on the GPL and
looked from there. Here are a couple of interesting things I found.
Linus Torvald on the subject:
from - http://lkml.org/lkml/2006/12/17/79
For example, glibc could easily have just come out and said the thing
is obvious to any sane person: "using this library as just a standard
library does not make your program a derived work".
... and later in the same post....
And don't get me wrong: I do not say that "linking" _never_ creates
derived works. I'm just saying that "linking" is just a technical step,
and as such is not the answer to whether something is derived or not.
Things can be derived works of each other _without_ being linked, and
may not be derived works even if they _are_ linked.
And some other stuff from a Lawrence Rosen, a lawyer for OSPI:
These questions are important because some licenses require you to
publish the source code of your portion of the resulting derivative
work program, a burden you may not want to accept. Here's how I would
decide in the cases described above.
1) The primary indication of whether a new program is a derivative
work is whether the source code of the original program was used,
modified, translated or otherwise changed in any way to create the
new program. If not, then I would argue that it is not a derivative
2) The meaning of derivative work will not be broadened to include
software created by linking to library programs that were designed
and intended to be used as library programs. When a company releases
a scientific subroutine library, or a library of objects, for
example, people who merely use the library, unmodified, perhaps
without even looking at the source code, are not thereby creating
derivative works of the library.
3) Derivative works are not going to encompass plugins and device
drivers that are designed to be linked from off-the-shelf,
unmodified, programs. If a GPL-covered program is designed to accept
separately designed plugin programs, you don't create a derivative
work by merely running such a plugin under it, even if you have to
look at the source code to learn how.
4) In most cases we shouldn't care how the linkage between separate
programs was technically done, unless that fact helps determine
whether the creators of the programs designed them with some apparent
common understanding of what a derivative work would look like. We
should consider subtle market-based factors as indicators of intent,
such as whether the resulting program is being sold as an
``enhanced'' version of the original, or whether the original was
designed and advertised to be improvable ``like a library''.
Anyway, I thought this might help us get past the technicalities of
what "linking" means.
On Sep 7, 2007, at 8:33 AM, Larry Garfield wrote:
> On Fri, 7 Sep 2007 09:14:52 -0600, Laura Scott <laura at pingv.com>
>> On Sep 6, 2007, at 4:28 PM, Thomas Barregren wrote:
>>> Assume you write a module for Drupal. Any meaningful module to
>>> Drupal implements at least one hook. That alone makes the module a
>>> derived work of Drupal.
>> I wonder whether that in fact is true. By this logic, if you write an
>> application that interfaces with Word, then Microsoft owns it as a
>> derivative of their product. Is that how copyright works? Every time
>> two different applications touch, we have litigation as to who has
>> the most cooties?
> No, only if Word's license explicitly said that they own any Macros
> you write. AFAIK it doesn't (although I've not actually purchased
> a copy of Word since last century).
> If Word were GPLed, they still wouldn't own your macros. There is
> no transfer of ownership in the GPL. There is only a requirement
> of GPL re-licensing for derivative works, e.g., Word plus your
> Macros wrapped up together.
>> If someone pulls on a door handle, does he become a derivative of the
>> door? Some things are designed to be utilized by other systems. APIs
>> exist in large part to allow different systems to interface with each
>> other. To claim that not only must a bridge module (to use the
>> example we've been tossing about) be GPL but anything it touches must
>> be GPL as well seems to be a rather far-reaching legal claim ... or
>> tragically self-isolating interpretation for policy.
>> Can GPL exist only in isolation from all other systems? Does mere
>> communication or interaction imply derivation? That's what the RIAA
>> and MPAA claim in their dragnet lawsuits, pre-litigation settlement
>> demands and things like the Sony Rootkit. What next? A GPL rootkit?
>> I wonder how Lawrence Lessig would interpret GPL.
> The amount of FUD in this thread is starting to amaze me. (Not you
> specifically, Laura; in general.) I think some people here are
> reading from the Microsoft anti-GPL playbook with the "transfer of
> ownership" nonsense.
> Folks, the GPL is not as evil ("viral") as some here are making it
> out to be. It says, simply, "you can do anything you want with
> this code, but *if* you redistribute it, *even if it's part of a
> derivative work*, then it, and as a result the derivative work,
> must be distributed under the GPL." That is all. There is no
> transfer of ownership, no "viral infection", no "loss of
> property" (since copyright is not property to start with, but we
> won't get into that.)
> The only question at hand is exactly where the line for "derivative
> work" is, in particular for modules that interface with 3rd party
> systems. The only relevant questions here are:
> 1) If a Drupal module exists only to interface between Drupal and a
> non-GPL system using in-process PHP function calls, does that
> violate the GPL? (FSF, according to Jeff, believes it does. I say
> to ask a lawyer not in the FSF's employ in order to get a more
> unbiased answer.)
> 2) If a Drupal module exists only to interface between Drupal and a
> non-GPL system using non-in-process APIs (SOAP, RSS, REST, reading
> a CSV, exec/fork, etc.), does that violate the GPL? (FSF,
> according to Jeff, says "not in letter, but in spirit". Given the
> number of RSS feeds coming off of non-Free systems that we all read
> on a regular basis using Aggregator, I don't think many people
> agree with the "spiritual violation". For the letter, again, we
> should ask a lawyer.)
> Bottom line: Unless you are a lawyer or have recently spoken to one
> on this subject, you have nothing constructive to contribute to
> this thread any more. Yes, I include myself in that statement as I
> am not a lawyer. Can we move the GPL FUD to some other forum and
> get back to something useful, like getting Drupal 6 finished?
> --Larry Garfield
More information about the development