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. *** EMPHASIS ADDED *** 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, either. 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