Comments on GFDL, may be useful for statement
I've collected some thoughts on the GFDL, mainly the results in my head
of having read (and participated in) the discussions on the GFDL for
over a year now. I'm sure I've forgotten a bunch of good points to
bring up, but I've been working on this for several days now and I
really need to get some real work done now, so I thought I'd throw this
out; feel free to use it, either in its entirety or any part thereof,
for any purpose whatsoever. I just can't see writing a critique of the
GFDL and then asserting that only verbatim copying of the critique was
permitted :-) Comments, criticisms, corrections welcomed. It is my
hope that this will be useful in putting together a FAQ, but I had some
difficulty phrasing everything in terms of questions and answers,
although I did put a few of those in at the end. This is a lower-level
look at the problems of the GFDL; for a higher-level view, see Anthony
Towns' "Proposed statement wrt the GFDL".
Practical problems
------------------
* Invariant sections
Invariant sections are certain secondary sections of the work which
may not be modified or removed from the document. Additionally, these
secondary sections must not pertain to the main subject of the work.
Works which are composed by combining two works under the GFDL must
include the union of the sets of Invariant Sections of the component
parts, but need not include any such section more than once.
The problems with invariant sections are numerous.
- Anybody may add one, for any reason; nobody may remove one. Not
everyone thinks carefully about adding one, and so they add invariant
sections casually, because they can. Does anybody else see a problem
here?
- Invariant Sections are off-topic by definition. Any good editor
will tell you that too much off-topic material *will* detract from the
piece as a whole. An editor's job is to remove such material and
generally to improve the impact of the work overall. Is it that we
don't like editors, think we don't need them, or just don't want them
improving Free content? In any case, I think that Free documentation
suffers by not allowing editors to do their jobs well.
- While the fact that only off-topic sections are allowed to be
invariant is a wall against making any of the important parts
non-modifiable, walls block in two directions. Any work which contains
Invariant Sections may not be combined with another work which
addresses the topics of any of the subjects from the Invariant
Sections as part of the main subject matter, even though both works
may be licensed under the GFDL. This is in direct contrast with the
GPL, where any two works licensed under the GPL may be combined into a
single work (whether that makes sense technically is a different
question entirely). This is of particular concern for works like the
Wikipedia, which covers a wide variety of subjects.
- Invariant sections are incompatible with the GPL, in that one may
not combine a work under the GPL with a work under the GFDL[0]; this
prevents documentation under the GFDL from being combined with
software under the GPL. As a practical consequence, we are in
technical violation of the licenses if we redistribute a copy of
Emacs, unchanged, exactly as we got it from the FSF, with the
documentation integrated as a help text. Now I'm sure that the FSF
doesn't think so, since they distribute the documentation and the code
together, but I would guess that a careful lawyer with a good
background in Free software would advise against doing so. As Free
software progresses toward the late 20th century as regards help
systems and documentation[1], there will be an ever-increasing need to
integrate the documentation with programs. From the reverse vantage
point, literate programming languages blur the line between software
and documentation even further. We don't need licenses that make this
difficult; proprietary software already offers that particular
feature, and I'm not interested in competing with them on that part.
- Invariant sections sometimes become outdated. At that point, they
still cannot be modified or removed; the false statement must remain
there forever. Clearly, this does not contribute to the credibility of
Free Software or Free Documentation in any way. This has already
happened, in that Joey Hess found a statement in the "Free Software
Needs Free Documentation" about the copyright status of Perl
documentation, which happens to be false[2].
- Invariant sections may contain illegal or offensive material.
Furthermore, material which is legal in one country may be illegal in
another. Material which is offensive to me may be something you enjoy
very much, and vice versa. If a community finds some portion of the
work to be offensive and is unable to remove it for the benefit of the
members of their community, the work is not Free for them.
* Cover Texts
Cover Texts are small pieces of text which must be affixed to the
covers of any printed form of the covered work.
The rationale for the GFDL is to provide a license for Free
documentation which will be appealing to authors and publishers, so as
to encourage more Free documentation to be written and
published. Cover Texts are fine when there are one or two of
them. When there are a hundred authors collaborating on a large work
(say, like the Wikipedia or a compilation like the Linux Documentation
Project or a magazine with many contributors), then having a hundred
authors all saying "Hi, Mom!" on the cover becomes obnoxious. [Gee, I
think I've heard this argument before, published at
http://www.gnu.org/philosophy/bsd.html. FWIW, I pointed this out
during the comment period; the FSF basically called me a troll and
said that I didn't understand what I was talking about for pointing it
out, so I doubt they're going to move on it.]
The really stupid thing is that this license is supposed to make it
more appealing to authors and publishers. Now I can see how Dr. Hook &
the Medicine Show[3] would appreciate this, but I fail to see how any
publisher is going to appreciate being told to fill the cover with all
sorts of little bits of graffiti from all the different authors. After
all, a publisher is trying to sell books, and generally they need the
cover to be some kind of a hook to attract a reader. In a bookstore,
the cover of the book is all the advertising they get -- but when
using GFDL material, they have to print Hans Reiser's ego trip on the
cover instead[4]. Show me a publisher who doesn't care about the
aesthetics of their book covers, and I'll show you a publisher with a
captive audience - a certain publisher of advanced mathematics texts
"springs" to mind here.
Cover texts are even less restricted than invariant sections are -
they can say anything. It's bad enough having an obnoxious invariant
section buried in the back of the book where the reader might not
discover it until after the book was purchased, but a book in which
the reader was invited to perform certain anatomically impossible acts
upon himself, printed clearly and legibly and of equal prominence with
all other cover texts might not sell very well. Henning Makholm
recently pointed out [5] that even the Cover Texts might become
obsoleted; in this case, a publisher would be *required* to print
material that is just plain wrong - not buried in the back of the
book, in an appendix, but *on the cover*!
Idealogical problems
--------------------
The GFDL is presented because we supposedly can't get anyone to write
free documentation to go with free software otherwise. Supposedly,
nobody will be motivated to write free documentation if they don't
have the possibility to add invariant sections. Oddly enough, though,
these same arguments hold no weight when it comes to software authors
writing software -- and is clearly false, given the vast amounts of
Free software now available, and the rapid growth in the quantity and
quality of Free software. This disconnect between software authors and
documentation authors leaves us confused and (those of us who are
programmers) insulted, because it implies that writing documentation
entitles one to a permanent soapbox, whereas writing software entitles
one only to a line in the copyright file.
Q&A
---
Q. Why doesn't Debian change to match the new reality rather than
asking everyone else to change?
A. Because our principles are important to us. Freedom is the key,
underlying point, and it upholds everything else in the
project. Having a technically superior operating system is nice, high
levels of integration, security, and large amounts of software are
nice, but the fact is that without Freedom, none of this would be
possible. We've learned that the Freedom to adapt the software to suit
our needs is critical. We're puzzled to find out that the same Freedom
does not apply to the documentation that goes with it. We're extra
puzzled to find out that it is the Free Software Foundation promoting
this, *especially* when the FSF expends so much time and energy
distancing themselves from the "Open Source movement" because it is
insufficiently focused on freedom.
Q. Why now?
A. We've been talking about it for a while, but nothing has changed
elsewhere, and isn't likely to change without a coherent explanation
of what's wrong. A number of us submitted objections during the FSF's
comment period, and we were uniformly ignored, since the only changes
between the draft release of GFDL 1.2 and the final release were to
fix technicalities, not the . Also, we just now got around to
collecting all of the objections together.
Q. What do you suggest as an alternative?
A. Remove the concept of invariant sections entirely. (Software
licensed under the GPL only requires that the legal statements remain
unchanged; everything else may be modified. This would be a good state
for the documentation, as well.) Or permit invariant sections to be
removed. This would overcome the major technical objections, since
such sections could at least be removed rather than continuing to
disseminate incorrect information.
Q. But doesn't this mean that the original author will no longer be
able to protect his/her views from being misrepresented?
A. No worse than the ability to *add* additional things that the
original author doesn't agree with causes the original author to be
misrepresented. Invariant sections cut both ways, remember; not only
are the original author's views cast in stone forever, so are the
views of any other person who cares to add them and make them
invariant. In any case, one may only assume that the document reflects
at most the views of the last author to modify the document.
Q. But the GPL itself is marked "Verbatim copying only" and you
distribute that. Aren't you hypocrites?
A. First of all, only the preamble of the GPL is so marked; the FSF has
stated that you may take the actual content of the GPL and modify it to
produce another license, although they strongly recommend against it, in
that the modified license *will* be confusing. Additionally, in many
jurisdictions, legal texts such as software licenses may not be
copyrighted, so as to prevent private monopolies on the law. Finally,
as regards the effect of the license, the license must be preserved
intact in order for it to have any legal standing.
Footnotes
---------
[0] This point is a little tricky; I think that it is clear that if a
GFDL document were included into the source code of a GPL application
in the form
const char * help = "<<GFDL doc with invariant sections>>";
then that would constitute a violation of at least the GPL. Further,
when talking about code, the FSF considers dynamic linking of a
library to be equivalent to static linking; that is, whether the
library is loaded at run-time or included as part of the binary on
disk is irrelevant, and the two parts cannot be distributed that way
unless the licenses are compatible. Given that precedent, I think
it's a stretch to say that an application could load the document as
help text dynamically from a file, at run-time, but could not include
it as part of the binary, statically linked in. Additionally,
context-sensitive help requires that the code know enough about the
documentation to know which part to display; this is *not* the same as
simply loading a document as raw data, because the application must
know about the meaning of the document in order to load the
appropriate parts, and furthermore depends on its existence.
[1] Yes, that's an insult; Free software is behind the times when it
comes to pervasive, integrated online help. Many command line
applications are nicely documented by the man pages, but programs with
GUI interfaces could benefit greatly from the context-sensitive help
facilities which are standard features of commercial proprietary
software. It is *not* a beneficial thing to discourage the
development of this, either. Being able to point the mouse at
something on the screen and ask "What is this?" is a tremendous help
to people unfamiliar with the program.
[2]
http://lists.debian.org/debian-legal/2002/debian-legal-200212/msg00058.html
The error may or may not have been fixed in later releases of that
document. That point is irrelevant -- the fact that we have to sit
around and wait for the original author to update something wrong is
something that we have to do with proprietary software, not with Free
software. If I really wanted that, I'd run Windows.
[3] Dr. Hook and the Medicine Show did the song "Cover of the Rolling
Stone", which includes the lines
Wanna see my picture on the cover
Wanna buy five copies for my mother
and
We keep getting richer but we can't get our picture
On the cover of the Rolling Stone
It seemed apropos to me as I was writing this out. Okay, so I'm weird.
[4] Yes, I know that the GFDL limits Cover Texts to some small amount,
significantly less than the 24 line spew from mkreiserfs, but I bet he
could get the whole thing in by having each contributor add a few
words from that spew as a cover text. Besides that, I don't intend to
pick on him particularly - anybody else's ego trip would be just as
ugly.
[5]
http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00455.html
--
Stephen Ryan Debian Linux 3.0
Technology Coordinator
Center for Educational Outcomes
at Dartmouth College
Reply to: