Re: A possible GFDL compromise: a proposal

[Richard Stallman <rms@gnu.org>]

    > It has to be prohibitively impractical in real cases.  The
    > inconveniences that occur in some cases with the GFDL are not
    > prohibitive.

    I'm a little sure what is "prohibitive".  Can you flesh it out?

If you are asking for a bright line as to what is or isn't
prohibitive, I don't think that is possible.  When you let other
people write detailed rules, but insist these rules substantively
permit certain things, you invariably face the question of whether
the requirements are tantamount to a prohibition in disguise.

When I judge this question for a packaging requirement, I try to be
tolerant.  Any packaging requirement that doesn't generally prevent
users from publishing versions with the technical behavior they like
is ok.

    Importantly, what must the impracticality prohibit to count?

The question is whether you the user are free to publish a modified
version with the technical behavior you like.  If the requirements for
publishing a modified version cannot be met, then you really can't
publish a modified version with the technical behavior you like.

    The DFSG says that we must have the right to modify everything, at
    least by the use of patch files.

I cannot find that in the DFSG.  If you are talking about this part,

     <P>The license may restrict source-code from being distributed
     in modified form _<strong>only</strong>_ if the license allows
     the distribution of "<tt>patch files</tt>" with the source
     code for the purpose of modifying the program at build
     time.

then I don't think it says that.  This text is specifically about
source code for programs, and specifically about licenses that
entirely forbid modified versions of the source code.  It is extremely
specific and narrow.

I think Debian developers have come to feel that the literal
interpretation of these words is too weak a criterion.  I too think it
is too weak: a software license that passes this criterion but allows
only some kinds of modification can be non-free.  And documentation
should also be free in its appropriate way, though it is not software
and not a program.

It looks like Debian developers, rather than changing the criterion,
have decided to reinterpret it by discarding some aspects of the
actual words.  I'm not sure that is the best way to solve the problem,
but never mind that.  My point is that once you decide to do that,
there is more than one way to do it.  To take the most strict possible
interpretation of what the words don't say is not necessarily right.