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

Re: A possible GFDL compromise: a proposal

Richard Stallman <rms@gnu.org> writes:

>     So your purpose is to spread GNU propaganda in invariant sections of GNU 
>     documentation, adding practical inconvenience where there shouldn't be.
> It adds some practical inconvenience, but practically speaking the
> magnitude is not great, so there's no reason not to do it.

Does this mean that you agree that if the magnitude of inconvenience
is below some threshhold, it's ok to add such a requirement, but if
the inconvenience is bigger, then there is?

> It's free because you can change the technical substance of the manual
> to say whatever you want it to say.  That is the standard we have always
> used in judging licenses.  I suggest it would be useful for Debian
> to follow the same standard.

Would you accept a similar restriction in a software license, and
still call the license free?  (Say, one which said "you must always
distribute this function as part of the system".)

> If the packaging requirements are prohibitive, so that it is
> impractical to publish the modified manual with the changed
> documentation, then it's not really permitted.  In that case, the
> license is not a free license.

Ah!  So I think we have made progress.  This is just what people have
said about why a practical inconvenience, sometimes, makes a thing
nonfree.  Now the question is: how impractical does it have to be?
Debian especially is concerned with the fact that we can't imagine all
the future ways of publishing.  How can we tell that it isn't a
prohibitive requirement?

I'd also like to understand better how you go about deciding whether a
given requirement is "prohibitive".  Can you explain why a small
monetary payment to the author of the manual would be non-free?  (We
all agree it's non-free, of course, but I suspect that we have rather
different reasons for that judgment, and I'd like to try and
understand yours.)

> Changing a program by studying and patching the binary is so different
> as to be prohibitive.  In effect, this restriction would say you
> cannot distributed a modified version (or determine what the program
> does).

Right, the point is that some practical inconveniences are so
incredibly serious that they amount to prohibitions.  


Reply to: