Re: (DRAFT 4) FAQ on documentation licensing
My suggestions, HTH:
s/software/programs and\/or libraries/g
{ RATIONALE: no two dictionaries seem to agree about
the meaning of the word "software". To avoid any
ambiguities, it would be better to spell out what you
are telling apart from documentation}
Jacobo Tarrio wrote:
>Q: Why does Debian apply the DFSG to documents?
>
>A: Debian applies the same standards of freedom to all works
>it distributes; some of these standards are written down in
>the DFSG. No good reasons have been provided to use a
>different standard with documents than with programs.
>
>Even if we were to treat software and documentation
>differently, first we would need to have a clear way to tell
>documentation apart from software. Many works, like source
>code annotated with Javadoc comments or Postscript files, are
>software and documentation at the same time, so it is easy to
>see that there is no such clear division.
s/it is easy to see.*$/it is very difficult to find any such
clear division./
{ RATIONALE: if it were easy to see, everybody would
have seen it by now :-) And it is very possible that
some genius comes with such a clear division in the
future, altough I don't believe so }
>
>Q: Some documents need to have some parts which must not be
>modified. For example, RFC or other standards documents
>should not be modifiable at all. Or a piece may contain the
>author's opinion on something, and nobody should be allowed
>to misrepresent the author's position by modifying that
>piece. Isn't this a restriction that should be allowed in
>documents and not in programs?
s/Isn't this a restriction that should be allowed/Shouldn't
this restriction be allowed/
{ RATIONALE: Aesthetic }
>
>A: Mainly, for three reasons: such a restriction is
>unnecessary, it is useless and it is not true that it would
>be less appropriate for software than for documentation.
>
>First, misrepresentation can be prevented without forbidding
>anyone to modify the work, by requiring all modified works to
>not claim that they are the original work or that they were
>written by the original work.
s/work.$/work's author(s)./
{ RATIONALE: The work cannot write anything :-) }
and, after,
s/$/ Concluding, such a restriction is unnecessary./
{ RATIONALE: For this and the two following items,
closure with the first paragraph of the answer }
>
>Furthermore, a clause in a copyright license would not stop
>anyone from misrepresenting the work or its authors. For
>example, I might create a new, original document titled "RFC
>2821, Simple Mail Transfer Protocol" with a distorted
>description of SMTP, and with this action I would not be
>contravening the license of the IETF's RFC 2821. The proper
>defense against this are the various laws dealing with libel,
>fraud and impersonation.
s/$/ Concluding, such a restriction is useless./
>
>Finally, if there were any reasons to allow such a
>restriction in documents, these reasons would allow it in
>programs too. For example, qmail's license forbids
>distributing modified versions of it, since its author
>believes that his reputation might suffer if someone
>distributed a version of qmail with bugs not introduced by
>him. If restrictions on modification of documents were
>allowed to save an author's reputation, they would be allowed
>on programs; this would make qmail free, but due to the DFSG
>it isn't, so these restrictions cannot be allowed.
s/$/ Concluding, such a restriction, if permitted, would not
be more appropriate for documentation than for programs./
>
>
>
>Q: I think that some "Debian Free Documentation Guidelines"
>should be created as an alternative to the DFSG for
>documentation. What should I do to have them adopted?
>
>A: First, you must write them; most people never manage this
>part.
>
>Next, for every license restriction permitted by your new
>guidelines that isn't allowed by the DFSG, you must give
>satisfactory answers to these three questions:
>
>1. How do we distinguish between packages where this
>restriction should and should not be allowed?
>
>2. Why should the restriction be allowed in for these
>packages?
>
>3. Why shouldn't the restriction be allowed in for every
>other package?
>
>Note that the answers to (2) and (3) should not involve
>special pleading or otherwise be contradictory. "Because it's
>documentation" is not a valid answer, and the answer to (3)
>should not apply to the packages in question.
>
>You'll need to discuss your proposal on debian-legal and
>debian-project to work out any problems with your proposal
>and to gather support for it.
>
>Finally, you'll have to propose a General Resolution to amend
>the Social Contract, and convince a 3:1 supermajority of your
>fellow Debian developers to vote for it.
>
>
>
>Q: If the DFSG are to be applied to documents as well as to
>programs, why is the text of the GPL included in Debian, if
>it says that it cannot be modified at all?
>
>A: Because the verbatim text of the license must be
>distributed with any work licensed under its terms. This is
>not specific to the GPL; almost all free licenses require
>that their text be included verbatim with the work. As a
>compromise, Debian distributes copies of the GPL and other
>licenses under which the components of Debian are covered.
>This compromise will not be extended to other types of works.
>
>(Note that according to the FSF, which is the author of the
>GPL, you're actually allowed to modify the text of the GPL
>and create a derived license if you remove the preamble and
>you do not call the results "General Public License". See the
>GNU GPL FAQ
>(http://www.fsf.org/licensing/licenses/gpl-faq.html#ModifyGPL)
>for more information.)
>
>
>
>Contributors to this FAQ
>
>Jacobo Tarrío, Andrew Suffield, Doug Jensen, Francesco Poli,
>Anthony DeRobertis, Raul Miller, Evan Prodromou, Ben Finney
>and Glenn Maynard.
>
Reply to: