Re: (DRAFT 3) FAQ on documentation licensing
On Sat, Apr 16, 2005 at 01:18:45AM +0200, Jacobo Tarrio wrote:
> Don't worry, I won't resend the text until Monday (at least :-)). I'm
> allowing until next Wednesday (a full week since first publication) for
> comments, additions, removals, rewordings, etc.
>
> The latest revision is always available (unless my UML "box" starts acting
> up) at http://jacobo.tarrio.org/Documentation_licensing_FAQ
>
> After Wednesday, when the text is stable, I will submit it for inclusion in
> the DFSG FAQ.
Thanks for the work on this. My initial impression is that it's a bit
long; I think FAQs like this need to be as to- the-point as possible,
giving as little opportunity for first-time readers to be sidetracked
by lesser issues, and not giving so much information that many readers
miss the important parts.
Note that I wrote this out of order, and in a couple places I suggest
a replacement text for a whole section, and then offer adjustments to
the original text anyway, usually wrotten first. Take whichever pieces
you want, if any. :)
> 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 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.
A more basic question is probably: "Q: Why does Debian apply the DFSG to
documentation?" It's a question with many answers, which I think are
being presented as the answers to different questions (which is probably
just a case of a Q/A format not working ideally). It's probably better
to condense them into a single question.
"Q: Why does Debian apply the DFSG to documentation?
A:
. Freedom is just as important for documentation as software.
. The rationale for our requirements of freedom for programs apply
equally to documentation. No rationale has been provided for holding
documentation to different standards of freedom than programs.
. To meaningfully apply different standards of freedom, a clear
division between program and documentation must be drawn. Many
works, such as source code with Javadoc comments[1], and Postscript
files, are both program and documentation. There is no clear boundary
between programs and documentations."
> 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
Probably best to sidestep the whole "what is software?" thing. This is
just another form of the above question.
> 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.
Is this paragraph important? (It did raise a fairly useless side-thread
about printed text being "software" on a strange "storage medium", which
is silly. :)
> 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
Careful: it's easy to be sidetracked here, with "well, just do it according
to (standards body)'s rules, then!" reasoning.
> document, such as a RFC, does not modify the RFC itself; it just creates a
> new work, derivative of the original RFC.
This is a bit confusing. If you modify RFC1234 to create RFC9999, you
are, in fact, modifying a copy of RFC1234. The important bit is that
you're (presumably) not trying to pass off your changes as the original.
"A: Misrepresentation is preventable without rendering a work unmodifiable,
by requiring that modified works not claim to be the original work, or by
the original author.
Further, prohibiting modifications doesn't stop anyone from deliberately
misrepresenting the author or the original work. For example, an original
document could be created, titled "RFC 959 - File Transfer Protocol",
with an inaccurate, misleading description of FTP. Restrictions on the
real RFC 959 don't help. The defense against a new work claiming to be
the opinion of somebody else is slander or libel laws[2]; adding copyright
restrictions to the person's real works doesn't help."
> 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.
Suggestions: "If the intent is to", "would not contravene", drop "completely".
> 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.
"One should be allowed to derive a document from RFC 2822 titled "New proposed
extensions to SMTP", or a document titled "A layperson's comments on the
GNU Manifesto" from 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.
>
> Anyway, remember that even if a particular document cannot be available in
> Debian because it is unmodifiable, it is not a tragedy: anyone who needs it
> can always download it from somewhere else (as an example, some of the
> authors of this FAQ never install manuals; they always read them off the
> Web).
This is true, but it takes a bit more to realize why this isn't such a big
deal: in general, integration of manuals is far less important than
integration of programs. This argument wouldn't make sense for programs
("you can just install Netscape yoursefl"), since that takes a lot more
work than pointing a web browser at the documentation. (I'm not sure
if it's worth trying to say that in some form.)
> 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 been considered non-free. For example, a license
> that says that a three-screen credits text must appear on startup would be
> unacceptable.
Well, specifying the exact text of a credit is considered obnoxious (can't
translate it, for example), but not non-free. Specifying where it must
go is a gray area (eg. the GPL's copyright notice, warranty and GPL
blurb requirement is permitted, and I think that pushes it as far as
it should go).
> 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?
"Q. I think that "Debian Free Documentation Guidelines" should be created
as an alternative to the DFSG for documentation. What should I do to
have them adopted?"
> 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: It is included because this text contains the terms under which many
> components of a Debian system are distributed. Debian is legally required,
> then, to inform of these terms to the receiver of the components ? the only
> way is including the text in the Debian system itself.
This "problem" isn't actually GPL-specific. Almost all Free licenses
require that the license text itself being included verbatim with the
work, not just the GPL.
"Q: Most software requires that their license text be included, prohibiting
its removal or modification. Why is this allowed in Debian?
A: Legal texts attached to software are an unavoidable special case, where
compromise is necessary to be able to distribute software at all.
This case is fundamental to copyrighted software, and this compromise
should not be extended to cases."
(The fact is, many people attempt to use licenses as a lever to claim
that more and more stuff should be allowed to be invariant, whether
they're aware of it or not. "Hey, license texts can't be modified, so
you should package my proprietary software, too!" I'm not sure how to
get this message across better, while remaining appropriate to a FAQ.)
> 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), Anthony DeRobertis, Raul Miller
> and Evan Prodromou.
I'd phrase this as an acknowledgement and not a Q/A.
[1] I don't use Java; I'm assuming Javadoc works like Doxygen, but I'm
not sure.
[2] I'm not sure if slander or libel are the relevant laws, here.
--
Glenn Maynard
Reply to: