Re: A possible GFDL compromise: a proposal
2. The GFDL prevents you from using the technical material in the manual
in nearly any program, because most programs don't have a lot of the
specific things the GFDL refers to ("section titles", etc.), so there's
no legally clear way to satisfy its requirements.
I don't think that section titles are a problem--it would not be
hard to put them in a program. But it is true that you cannot take
text from a GFDL-covered manual and put it into most free programs.
This is because the GFDL is incompatible with the normal free
This is equally true of other free documentation licenses, including
the Open Publication License version 1, and the simple license we used
in the past for GNU manuals without invariant sections.
(It is trivial to fix this, if you are not obsessed with unremovable
"Invariant Sections" to the exclusion of all other goals. Add a clause
to the GFDL allowing GPL-conversion, exactly like the clause in the
This is simple, but it might effectively nullify all the other special
features of the GFDL. That is something we want to avoid.
3. Consider the following. (For future reference, this is called the
"ls --hangman" example.) I am designing a license (the "hangman
license") for a new version of "ls" which requires that any derivative
work (if executable) provide a documented way, preferably a command line
option, to invoke a particular piece of unmodifiable machine code,
designed to play a game of "hangman".
I think I have never considered whether such a license is non-free,
and since the question has not arisen in reality, I don't need to
answer it. (Where there is a gray area, it is often possible to
construct artificial questions of any desired degree of difficulty,
and often the best response is not to worry about them.) But I think
that would not be free, because this behavior is substantive, not mere
packaging. It's not the same as just printing an informative message
about something nontechnical.
So even if you feel that you really, really, need these Invariant
Sections for a few special cases to promote the FSF's work, why is the
FSF *promoting* the broad and general use of Invariant Sections by all
and sundry? It should be actively *discouraging* them.
I don't agree that we ought particularly to discourage them, but we
are not actively urging others to use them. I wrote the GFDL to allow
anyone to add invariant sections so that it would be possible to merge
manuals with different invariant sections.