(DRAFT 2) FAQ on documentation licensing
24 hours have passed, and this is the text of the current revision.
Additions, removals, rewordings, criticism, suggestions are welcomed and
requested. The latest revision is always available (minus network hiccups)
at http://jacobo.tarrio.org/Documentation_licensing_FAQ
When the text is stable, I will submit it for inclusion in the DFSG FAQ.
Q: Why does Debian apply the DFSG to the GFDL (and other licenses)?
A: The DFSG is a set of minimum criteria that are taken into account when
deciding if a particular work, with its copyright license, is free or not.
Everything that is distributed by Debian in its "main" distribution must be
free, so the DFSG are the criteria to be applied.
Q: But the GFDL (and other licenses) are not software licenses, but
documentation licenses. Software and documentation are not the same thing.
A: Even if by "software" you mean "programs", there's not always a clear-cut
distinction between programs and electronic documents. For example, a
Postscript file may contain the full text of the GNU Emacs manual (that is a
document), but it is really a program which is interpreted by
Postscript-capable printers to render that text on paper. Other examples
include literate programming (a style of writing programs in which what is
really written is an essay about how a program works, with code snippets) or
javadoc-like documentation embedded in program source code.
Of course, a copy of the GNU Emacs manual printed on dead trees is
definitely not software, but Debian doesn't distribute physical goods, so
this example is irrelevant to the question.
Q: Why are the DFSG applied to documentation? There should be some "Debian
Free Documentation Guidelines" (DFDG) to be applied to documents instead of
the DFSG.
A: See the previous question. Even if it doesn't convince you or you can
live with the ambiguity described there, the existence of different DFSG and
DFDG would mean that there are some freedoms that are necessary for programs
but are irrelevant for documents, and vice versa. Nobody has yet provided a
convincing rationale to explain *why* programs and documents should need a
different minimum set of freedoms. The Debian project claims that the same
freedoms are important for both programs and documents. Some examples of
this are given in the following questions.
Q: The ability to keep certain parts of a document is essential for some
kinds of document. For example, RFC or other standards documents should not
be modifiable. 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.
A: First, standards documents should be modifiable: that's how old standards
are improved and new standards are created. Modifying a copy of a standards
document, such as a RFC, does not modify the RFC itself; it just creates a
new work, derivative of the original RFC.
If what's really intended is to stop someone from passing a modified
document as the original, other means must be used, such as slander/libel
laws already existing in most jurisdictions. Clauses in copyright licenses
are completely useless for this purpose, since they can be easily worked
around by creating brand new works with defaming content, which would not be
contravening the clause.
In other words, one should be allowed by the license to write a document
derived from RFC 2822 and titled "New proposed extensions to SMTP", or a
document titled "A layperson's comments on the GNU Manifesto" which was made
by modifying the GNU Manifesto itself.
It is the same situation in a program. For example, if the license of an
email client forbade to add HTML mail support (because the authors are
philosophically against HTML mail), this license would be considered
non-free, even when it would be protecting the authors' own opinions.
Q: The authors of a document or a literary work deserve to be credited. They
should be able to add a restriction to the license so that their names must
be displayed prominently on the front cover. Shouldn't such a license be
considered free?
A: Debian would normally consider free a license that mandated that the name
of the authors appear "along with other credits" or something like that.
Specifying the form the credit must take, or its exact wording, or where it
must appear, are restrictions that aren't generally considered free.
Additionally, they have some problems of their own. For example, how do you
display a name prominently on the front cover of a text file? Or what if
someone makes a compilation of texts; should all names appear prominently on
the front cover?
Also, authors of programs deserve to be credited as well, and similar
restrictions have already considered non-free. For example, a license that
says that a three-screen credits text must appear on startup would be
unacceptable.
Q: Anyway, I think that some "Debian Free Documentation Guidelines" are
necessary 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: Who collaborated in writing this FAQ?
A: Jacobo Tarrío drafted the initial version. Additions and corrections by
Andrew Suffield ("how to propose some new documentation guidelines"), Doug
Jensen, Francesco Poli (HTML mail example) and Anthony DeRobertis.
--
Jacobo Tarrío | http://jacobo.tarrio.org/
Reply to: