Perhaps we have hit the key parts of the disagreement, finally. I would
love to get some further clarification from RMS on his views, so I have
asked a few questions below. I have made 4 points in response to this
one paragraph, but the questions are in points 3 and 4.
RMS wrote:
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.
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.)
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.
