RMS wrote:
1. It prevents you from making the program into a 'grep' or 'ls'-like program with specified machine-readable output, unless the requirement is *very* narrowly tailored to exempt all programs designed to produce machine-readable output. (The GPL requirement appears to be sufficiently narrowly tailored.)By contrast, a requirement that the program must print a copyright notice and permission notice does not stop you from changing the program to do, substantially, what you want it to do. Some people might dislike that requirement, they might say it stops them from doing what they want to do with the program (such as, "I'm not allowed to make it not print a message). Nonetheless, this requirement doesn't stop you from making the program do substantially whatever you want.
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. This is a *real* use, and I have many *real* examples of cases where I and others want to do precisely this. This clearly prevents me from using the manual for "substantially" what I want.
(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 LGPL. This could simply allow the "Invariant Sections" to become GPLed material, or it could require that they be removed. It is quite unlikely, incidentally, that a traditional print publisher would prefer to distribute under the GPL rather than the GFDL.)
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". (On machine where the machine code is invalid, this will presumably crash when invoked.) If not executable, the work must include a way to display the unmodifiable machine code. (In addition, any creator of a derived work can add new unmodifiable chunks with the same requirements.)
Your derivative program can still do "substantially" whatever you want; it just has to *also* do this. This can be done in pretty much any program without difficulty, so it's certainly not a prohibitive packaging requirement.
Is the license free in your opinion? What you've said so far seems to imply that it is. If you believe that it is, I commend you for your consistency. If not, why not?
I and most of the people on this list think that it's *not* a free license, because although your derivative program may do "substantially" whatever you want, it can't actually do certain important things which you want it to: notably, be small, elegant, and free of cruft.
I consider non-removable "Invariant Sections" in manuals to pose the same problem, in that they prevent me from writing *elegant* derivative manuals. I can't even fix typos in the Invariant Sections. (Sure, I could create a fixed clone Invariant Section, but then I'd have the horrible inelegance of two similar Invariant Sections, one wrong...)
4. Even if something can be "free" while encumbered with the requirement of being ugly and messy, it seems to be a *very* bad idea to encourage such licenses. We want to encourage *good* programming and documentation writing, not *bad* programming and documentation writing, don't we? GNU FDL Invariant Sections are at least as bad as the proliferation of lots of subtly different licenses which must be carried along in works derived from multiple sources. In fact, they're worse, because they affect the actual produced work directly, not just the attached license information.
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.