Re: GPL compatibility of DFCL
On Thu, Jun 13, 2002 at 10:32:00PM -0500, Branden Robinson wrote:
> People might incorporate DFCLed documentation into a C file. Think of
> standards documents, or just damn good manuals and damn poorly commented
> code.
Hmmm... if you incorporate the whole thing, you may have a problem, but
if you're quoting bits, that's "Fair Use" - maybe "Fair Use" should be
explicitly incorporated for the benefit of those living in countries
that don't have such a concept, but...
Besides, is it appropriate to use the GPL if you are incorporating the
whole document into the code? What does the GFDL say about this?
> But that's going to be a tough sell. :)
And I'm no salesman.
> > If the FSF don't believe it's appropriate for docs to be GPLed, then
> > surely they don't regard it as essential that docs contained within a
> > package of GPLed software be GPLed?
>
> Uh, I'll try to put this diplomatically, but I don't believe the FSF is
> being entirely consistent on issues surrounding the FDL.
Has anyone asked RMS what his position on incorporating (potentially
large) bits of GFDL-licensed docs into GPLed programs is? That it will
never be necessary? or that it should not be allowed? Or does the GFDL
have an exception for this because the only purpose of the GFDL invariant
sections as far as he is concerned is to push the GNU Manifesto, and
if the docs are being incorporated into GPLed programs, then that fact
is judged to be adequate pushing on its own?
> If they're just distributed together in tarball -- if it's just "mere
> aggregation", then probably not, no. However, see above. The document
> might mingle with the source more than that. Free music, images, or
> textures might be integrated tightly into a game, for instance.
And might reasonably be separately licensed (like allowing distribution of
a game engine, but not allowing distribution of the "full version" of the
data to go with it, kind of like quake)...
> Remember, the DFCL isn't just for manuals.
No.
OK, I think if you are really really convinced that you must have GPL-
compatibility (which I am not convinced of myself, but hey...), then you
*might* be able to twist a clause like clause 6 of the GPL to make sure
that the endorsements come back into force if the docs are pulled back out
from the program. But really, GPL-compatibility is probably a red herring -
I think that GPL-compatibility may well detract from the overall usefulness
of the license, as as others have pointed out, it is likely to render the
doc essentially GPLed. Which a lot of authors will not go for.
What happens now if you create a document from a program that is licensed
under the GPL? Is the document forced to be GPLed? But the GPL applies only
to Programs... someone needs to corner RMS on this (with a very well-defined
list of very specific questions), since we're stuck with the GPL.
I really think is that the GPL is in need of a revision anyway, as it appears
to fail to consider lots of things that are happening today. Like the mess
we are in with the OpenSSL crap - the OS exemption appears to give
proprietary OS vendors a potential advantage over Debian. It also does not
acknowledge the distinctions (or lack of) between a Program and any other
information which may need to be distributed, nor does it consider how
tightly such things may be integrated with Programs.
Cheers,
Nick
--
Nick Phillips -- nwp@lemon-computing.com
You are confused; but this is your normal state.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: