A number of people have said some intemperate things in this thread, but I really think that this comes down to a matter of 90% miscommunication, and 10% differences in circumstances. I believe that a meeting of minds should be possible, since we share the exact same goal here: WHAT IS BEST FOR FREE SOFTWARE.
> Debian insists that all which it distributes be free, under a single > definition which does not require asking whether a given bit of text > is "technical" or "political". Can you help us find a suitable > definition for that? > >It makes no sense to apply the same standards to political and legal >text as to technical material. Ethically they are different >situations. This issue is, I believe, a red herring. To my mind the question we ask should not be concerning the existence of political essays, or the inappropriateness of people revising them without permission, or even their being carried along in the free software distribution chain. The issue here is subtly different - it is that (as I hope is explained below) in the particular case of the GFDL such invariant essays interfere with the functional freedom of the documentation they accompany. > I put my political essays under a license that permits only verbatim > copying because in my view that's proper for for political essays. That seems entirely reasonable. (One danger is that essays can become outdated. That is not so bad in a magazine, but is a bit of a PR problem when they enjoy distribution along with source code, eg in the GNU Emacs sources. So---just a suggestion---it might be a good idea to regularly re-evaluate the rhetorical effictiveness and timeliness of such materials.) > It was clear from an early stage that companies might package parts > of GNU with non-free software and would present the non-free > software to the users as something legitimate and desirable. (This > problem is getting bigger, not smaller: today, nearly all packagers > of GNU/Linux distribute non-free software with it and try to argue > it is a good thing.) So we had to search for ways to make sure that > our message saying non-free software is wrong would at least be > present in the GNU packages that they redistribute. We did this by > putting invariant political statements into programs and manuals. > In programs, these statements are included in the license text, in > the preamble to the GPL. In manuals, they are separate sections. > When we make decisions in the GNU Project about what counts as free > software, or free documentation, they are based looking at freedom > as a practical question, not as an abstract mathematical one. That seems like a good way of looking at these issues. You are trying to make the best possible copyleft for these things. I don't think there's any real disagreement about that goal. There is instead a tactical question, of how free software can be best supported via a copyleft on its free documentation. There are also some practical questions about how documentation can best be copylefted. > These sections are consistent with freedom because practically > speaking they don't stop people from making the software do what > they want it to do, or the making the manual the manual teach what > they want it to teach. This is the heart of the matter. They don't stop the FSF in such endeavors, because the FSF holds copyright to the whole ball of wax. So you probably have not encountered, or even thought of, the problems I'm about to describe. After all, they do not affect you. But *as treated by the GFDL* these invariant section do, as a practical matter, dramatically interfere with the freedom of others to utilize the covered materials as free documentation for free software. Here are some "xerox printer control software" kinds of scenarios that I hope will make the issues explicit. (For each there is an implicit "and share the result with my friends", of course.) I wanted to add online help to a GPLed program using text from the GFDLed manual that came with the program ... but I *couldn't* because of the *license*! (Of course *you* can, RMS. But only because you hold the copyright, so you're not bound by the letter of the license. This simple act is forbidden by the GFDL.) I wanted to combine materials from two GNU manuals into a single manual, but it *wasn't allowed* (incompatible cover texts, or the union of the two sets of invariant sections was too burdensome.) I wanted to make a BSD DIFF manual by editing the GNU DIFF manual, but I *couldn't* (cover texts say "GNU" which wouldn't be accurate). An invariant section was outdated/inappropriate/incorrect but could not be removed. I wanted to snip a long section from a GFDLed manual into my GPLed program debian-bug.el, but I couldn't. (This one actually happened.) I modified the texinfo documentation for GNU Emacs, and now I'm not sure if I can distribute them together (because the info pages and the executable make a single coherent work but the licenses are incompatible.) I know you want the documents under the GFDL to constitute an "information commons" for documentation, and perhaps for other sorts of material as well. As written this is impossible: you can't take a section describing the --baz switch from the FOO manual and copy it into the BAR manual ... because you'd have to carry along the FOO manual cover text which would be inappropriate for the BAR manual! And maybe the invariant section describing why we need a free FOO wouldn't make sense in the context of a manual about BAR. Here is a non-hypothetical exvent that should really concern you: Wikipedia almost got seriously harmed by using the GFDL. They used the GFDL in a reasonable way, with a "cover text" being a pointer to the wikipedia web site. As people tried to share the information this became an unacceptable burden. In that case the GFDL served to discourage sharing. (It nearly prevented it entirely, had remedial measures of dubious legality not been taken.) (Wikipedia problem docs: http://www.wikipedia.org/pipermail/wikipedia-l/2001-October/000624.html http://www.wikipedia.org/pipermail/wikipedia-l/2002-June/002238.html ) The Wikipedia used the GFDL because it was recommended by the FSF. They used it in its natural way. And then they got burnt. Another practical problem with the GFDL is that new and contributing authors can add their own invariant sections and cover texts. There's nothing to prevent a manual from becoming rapidly covered with a hundred little impassioned pleas. Once there are two, adding a third is irresistible. And each one would be considered by its author using a "marginal cost/benefit" analysis. That is, the same analysis you use when you say the benefit is worth the cost in your own email! Each one would be little extra cost, so the benefit of added meat for the document itself that comes along with each extra invariant blurb could actually be pretty small. And the author of the extra invariant section of cover text naturally has a tendency to overestimte its value. Pretty soon we have a big mess, with all kinds of "don't invade Iraq" and "GM food can help feed Africa" things attached. This would be a bad result. SUMMARY Here are the cases against the GFDL as written: - it is obviously inappropriate for software - the line between documentation and software is very blurry - eg in the debian-bug.el example, if the FDL were in use it would be to the detriment of free software another case: - it is not GPL compatible (!) another case: - it fails to support a usable information commons, due to license incompatibilities between GFDLed documents with different invariant sections and/or cover texts another case: - used in the recommended fashion, by innocent people trying to build a common free encyclopedia, it has *already* caused serious problems These are telling: the GFDL, if used for documentation of free software, can damage the cause of free software; and when used for non-documentation documents like an encyclopedia has already damaged the cause of free documents. Conclusion: the GFDL as written is not a good copyleft license. POSSIBLE SOLUTION All that said, let me suggest a simple resolution which I believe would make everyone happy. Simply make the GFDL be GPL compatible, the same way the LGPL was. Add a clause saying that the covered materials can be construed as source code and used under the GPL; and that the invariant sections should, under such circumstances, be regarded as materials simply accompanying the GPLed technical materials but not themselves covered by the GPL, like the essays that accompany the GNU Emacs source code. That's it - just use the GFDL+GPL instead - that would solve all these problems! Dead tree publishers could print the invariant sections as required by the GFDL. Or they could use the GPL, and accompany their manuals with transferable written offers to send the source text. They'll opt for the former. Programmers could snip documentation from GFDL+GPL documents and pop it right into their online help systems, and their debian-debug.el help strings. The body of documentation would become an information commons not just for documents, but also for use in GPLed programs. That is a big win! Please consider it. ---------------------------------------------------------------- Thanks for reading my long-winded discourse, --Barak. PS If you're ever in town (Dublin Ireland now, no longer Albuquerque) we should have sushi again. But we cannot because there's none here. Instead we will have dim sum!
