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

Re: GPL compatibility of DFCL

On Thu, Jun 13, 2002 at 07:19:42PM -0700, Mark Rafn wrote:
> > > On Thu, 13 Jun 2002, Branden Robinson wrote:
> > They then turn to clause X of the
> > DFCL and see "if and while this work is incorporated into a different
> > work which is licensed under the GNU GPL, version 2, as published by the
> > Free Software Foundation, the reproduction of the endorsement section
> > immediately after this work's copyright notice is optional instead of
> > mandatory."
> Ok.  The combined work is now distributable under the GPL, right?  I
> recieve it from someone, along with source.  I modify the combined work by
> removing a bunch of stuff (which happens to be all of the Foo source).  
> Because I recieved a GPL package, I can distribute my modified version
> under the GPL as well.  How does the original license force me to put the 
> endorsement section back in?

Because the Foo manual still exists as an individually copyrighted work.

	These requirements apply to the modified work as a whole.

	If identifiable sections of that work are not derived from the
	Program, and can be reasonably considered independent and
	separate works in themselves, then this License, and its terms,
	do not apply to those sections when you distribute them as
	separate works.

	But when you distribute the same sections as part of a whole
	which is a work based on the Program, the distribution of the
	whole must be on the terms of this License, whose permissions
	for other licensees extend to the entire whole, and thus to each
	and every part regardless of who wrote it.

The above is the paragraph in the GPL after 2c).

	Thus, it is not the intent of this section to claim rights or contest
	your rights to work written entirely by you; rather, the intent is to
	exercise the right to control the distribution of derivative or
	collective works based on the Program.

	In addition, mere aggregation of another work not based on the Program
	with the Program (or with a work based on the Program) on a volume of a
	storage or distribution medium does not bring the other work under the
	scope of this License.

> > I think you're thinking about this completely the wrong way.
> I must be.  Maybe I'm misreading 2b of the GPL, and have an incorrect 
> understanding of what "GPL compatible" means.  I THINK it means that a 
> combined work must be distributable under the GPL.  Is it more subtle 
> than that?
> Or I'm misreading the GPL, which is possible (even likely, given the way
> we're gaping at each other as if we'd each grown another arm).

Well, do you or don't you think the material I quoted from the GPL text
above is applicable in this situation?

> > 3) you can distribute a non-GPLed work (such as an MIT or 3-clause BSD
> > licensed library) along with a GPLed work as long as the license on that
> > non-GPLed work does not run violate any of the GPL's terms.
> Sure, but the aggregate can be distributed under the GPL, and therefore 
> derivatives of the aggregate can be distributed under GPL.  I'd always 
> assumed that this meant that if someone really wanted, they could release 
> a fork of an MIT-licensed work under the GPL.  I'm just at this moment 
> reexamining that assumption.

No, you cannot take an MITed work and just slap the GPL on it.  The MIT
license *is* compatible with the GPL, but that doesn't mean that
original author's copyright doesn't apply.

It will be slightly more complex with the DFCL because it is also a
copyleft, and different from the MIT license in that people who license
under MIT terms are unlikely to ever take anyone to court, because
almost no one has any motivation to violate its extremely liberal terms.

Think about it this way:

1) Say the FSF decides to fork XFree86, and calls their work GNUFree86.
They do this only because they won permission from NVidia to write
GPLed, 3D accelerated drivers for NVidia's recent cards.  The GPL is an
unacceptable license to the XFree86 Project and they won't distribute
GPLed drivers, or check them into their CVS tree.  Now, individual card
drivers are fairly independent pieces of code in XFree86; there are of
course interface dependencies on the rest of the X server, but each
driver lives in its own directory and is pretty modular (and, in fact,
they exist as modules in binary form, too, which are demand-loaded by
the XFree86 4.x X server).  The driver that the FSF writes is thus
easily an independently copyrightable work.

2) Let's say the FSF makes a few other changes to XFree86, like, say,
xf86PciInfo.h, so that the NVidia cards' PCI IDs are properly registered
with the X server.  *This is a trivial change to the file.  No FSF
copyright attaches, and the license on the file remains XFree86's.*

3) The FSF slaps the GPL on the whole thing by putting into the
top-level copyright file, and releases GNUFree86 4.3.

Now you grab the source to GNUFree86 4.3.  Under what terms are the
files licensed to you?  The answer: the NVidia driver that the FSF wrote
is under the GNU GPL.  The rest, even the FSF's changes to
xf86PciInfo.h, remain under the XFree86 license.

*Only* where the FSF has written something independently copyrightable,
and not a mere modification or deriviative of existing, independently
copyrighted code, does the GNU GPL take root.

In truth, where the threshold of independent copyright is met when it
comes to collaboratively developed software (i.e., the same source file)
is a very, very gray.  The GNU GPL doesn't say, and I don't think the
FSF has an official, public policy (though I have heard that they have
some internal rule of thumb that says "10 lines" -- that could just be
rumor, though).  I don't think it's ever been ruled on by a court,

Here's a question for you.  If I get my mitts on the source code to
Windows 2000, and change one line in a source file, can I then
distribute that source file under any license I want?  The issue isn't
the GPL, it's whether copyright is preserved in a work despite its
modification or aggregation with a GPLed work.  The answer, as I
understand it, is "of course the copyright is preserved."

It doesn't *matter* under copyright law (as I understand it) whether I
passed a DFCLed document through a GPLed software strainer.  If what
comes out is a derivative only of the DFCLed document, only the DFCL
applies.  If what comes out is a derivative of both the DFCLed original
document and the GPLed software, then each licenses applies to various
parts of the work, depending on the circumstances.

> I'm with you here.  I see the use of the DFCL, I just don't see a way to 
> make it GPL-compatible without making it a pure superset of GPL. 

I do.  I have made my argument using the terms of the GPL itself.  :)

The "virality" of the GNU GPL has, perhaps, been overstated.  And for
that, I think, we have not Microsoft to thank, but mindless BSD
advocates from years ago.

> > There are a few forums I know of where I can shop this idea around.  I
> > want to have a draft first, though. 
> Excellent.  This is clearly the right plan, especially the FUD and 
> loathing from media tyrants as the sign of success.


G. Branden Robinson                |     There's nothing an agnostic can't
Debian GNU/Linux                   |     do if he doesn't know whether he
branden@debian.org                 |     believes in it or not.
http://people.debian.org/~branden/ |     -- Graham Chapman

Attachment: pgpctkrIbD71p.pgp
Description: PGP signature

Reply to: