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
