[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
software license.

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.

Reply to: