Re: The draft Position statement on the GFDL
Raul Miller wrote:
>>Raul Miller wrote:
>>
>>>On Mon, May 10, 2004 at 09:44:27AM -0700, Josh Triplett wrote:
>>>
>>>>Unless the derived document falls under section 7, "AGGREGATION WITH
>>>>INDEPENDENT WORKS" (which requires that more than half of the document
>>>>consists of independent work not derived from the GFDLed document), you
>>>>must put the covers around the entire derived work, not just part of it.
>>>
>>>This is a solvable problem.
>
> On Mon, May 10, 2004 at 11:55:28AM -0700, Josh Triplett wrote:
>
>>How would you suggest solving it, given that you should be able to make
>>a derived work of the document as a whole without just referencing it?
>
> There are at least three solutions:
>
> [1] Add more original content
>
> [2] Let the document be referenced under its original title.
>
> [3] Strip out more of the bulk from the GFDL document.
>
>>(Also note that even if this "workaround" works and you only need to
>>include the Cover Texts and Invariant Sections in an appendix, that
>>would still be non-free; this "workaround" only solves the inaccuracy
>>problem, not the Freeness problem.)
>
> I agree that this is independent of the freeness issue.
OK. I had though you were suggesting this workaround as a solution to
both the freeness and inaccuracy problems. Obviously, if the license is
not free, it can require you to jump through as many hoops as it wants
in order to get something you can distribute.
>>>Exactly.
>>
>>A Free license should allow you to create a derivative work of the
>>document, instead of just referring to it.
>
> It does.
To rephrase: A Free license should allow you to create a derivative work
of the _entire_ document, instead of just referring to it, without
having to include unmodified Cover Texts or Invariant Sections (either
because they are inaccurate or just because they are not modifiable).
>>For example, you should be
>>able to write a manpage for "ls" based on the coreutils documentation,
>>without including the entire document in an "appendix" of the manpage,
>>or including the Cover Texts on the "front and back covers" of the
>>manpage.
>
> Coreutils documentation is not at all structured like a man page.
> I think it would be better to copy the ideas and not the content.
True, but it should still be possible to copy the content, or the
license is not Free. Also, you might want to copy _portions_ of the
content when making the manpage.
>>It should also be possible to take the entire GNU coreutils
>>manual, and modify it to document a different implementation of the same
>>commands, without having to include inaccurate Cover Texts or Invariant
>>Sections (or accurate ones either, for that matter).
>
> This line of thought has potential, but a concrete practical instance
> (with some specific reference to some DFSG clause(s)) would probably help.
Suppose busybox didn't exist, and you were writing it. For your
documentation, you take the coreutils manual and modify it to document
your commands, with information about what #defines must be enabled for
each option to be available. Suppose also that the coreutils manual had
the standard GNU Cover Texts and a couple of Invariant Sections. You
would be required to include:
* The front-cover text, "A GNU Manual", even though your software is not
part of the GNU Project and your manual is not a GNU manual. This is
fraud and misrepresentation. (As Anthony DeRobertis pointed out in
http://lists.debian.org/debian-legal/2004/05/msg00434.html , this is "a
false designation of origin, in violation of Title 15, Sec. 1125." This
violates DFSG3, since derived works cannot be distributed at all unless
they are a GNU manual.
* The back-cover text, "You have freedom to copy and modify this GNU
Manual, like GNU software. Copies published by the Free Software
Foundation raise funds for GNU development.", has the same problem.
This violates DFSG3 as well.
* The Invariant Sections might include statements like "GNU coreutils is
Free Software", which is true but irrelevant, or "We recommend the
GFDL", which is inaccurate if you believe the GFDL is non-free and
advocate against it, or "This software is Free Software under the terms
of the GPL", which is inaccurate if your software is LGPLed. This last
one also arguably violates DFSG9.
Apart from those issues, all three are unmodifiable, which violates DFSG3.
>>>Where's the DFSG requirement that requires the license permit distribution
>>>without the unpatched sources?
>>
>>I don't know what the consensus is about licenses that require source to
>>accompany the binary in the same package, but even if they were allowed,
>>a Free license must still allow derivative works based on those sources
>>and some patches, and those derivative works must not be required to
>>include the unmodified original work or any particular unmodified
>>portions of the original (either large Invariant Sections or small Cover
>>Texts).
>
> Ok, but where is the language stating this?
Consider what it would mean for a program. A license that required
derived programs to include a copy of the unmodified program (or a
specific unmodified portion of the program) in the compiled version of
the derived program would be obviously non-free. Now s/program/document/g.
- Josh Triplett
Reply to: