Re: The draft Position statement on the GFDL
Raul Miller wrote:
> On Tue, May 11, 2004 at 09:33:52AM -0700, Josh Triplett wrote:
>
>>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.
>
> It can, though we might not want to distribute it in some cases.
Of course, but we won't distribute it in main in any case.
>>>>>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).
>
> My point of view is that "must allow derivative works" isn't completely
> general -- that it's fine if there are some kinds of limits on what kinds
> of derivations much be allowed. The obvious example is that we have
> no right to expect that the license allow the creatition of derivative
> works under some arbitrarily different license.
That requirement is explicitly stated in DFSG3:
> The license must allow modifications and derived works, and must
> allow them to be distributed under the same terms as the license of
> the original software.
We don't require the right to relicense. That isn't a restriction on
what kinds of derivations you can make, only a restriction on how they
may be licensed.
>>>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.
>
> I think I understand what you mean, but also don't see that this is a
> DFSG issue. There's some basis for this in the social contract, but
> probably not as a hard and fast rule.
The DFSG explicitly requires the legal right to make derived works, even
if making such works is not a good idea for technical reasons. "I think
it would be better to copy the ideas and not the content" is a technical
issue, but "it should still be possible to copy the content" is a legal
issue.
>>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.
> Also, once I'd written busybox, I couldn't really use the gnu
> documentation excerpts unchanged, because I'd have made many
> simplifications to how things work.
Of course, which is why you would want to modify that documentation.
>>Apart from those issues, all three are unmodifiable, which violates DFSG3.
>
> Being unmodifiable violates the usual "fully general" interpretation of
> the DFSG. Unfortunately, that interpetation isn't really fully general
> (and, if carried to the limit, would only allow us to distribute public
> domain software).
>
>>>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.
>
> And, just as obviously, the interpretation that supports this only
> allows software which can be distributed under any license whatsoever
> [that's public domain software].
Again, the DFSG does not require the right to relicense modifications,
only to make them and distribute them under the same license as the
original.
> Perhaps it's worth noting that, as it was originally written, the DFSG
> did not stand on its own but was a part of the social contract.
That is why the Social Contract forms the basis for interpreting the
Guidelines when we run into a gray area that the DFSG does not
explicitly cover (such as "you must send all modifications to the
author"). However, the right to make modifications and distribute them
under the same license is not a gray area, since it is explicitly
covered in the DFSG.
- Josh Triplett
Reply to: