Re: The debate on Invariant sections (long)
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!
Reply to: