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

Re: A possible GFDL compromise



Disclaimer: I'm not a debian-developer, and consequently I have no
official standing in the Debian community.  But I have been
participating on debian-legal for some time (at least since the
beginning of the GFDL discussion here a few years back), and am at
least somewhat familiar with the issues we're discussing.  I have no
doubt that I'll be vigorously corrected if I err.  ;)

Richard Stallman <rms@gnu.org> writes:

> Those words are simply an indirect way of declining to recognize the
> difference between loss of freedom and practical inconvenience.

That's not entirely true; I believe that debian-legal generally makes
this distinction based on the severity of the inconvenience (i.e., we
make allowances for "insignificant" inconveniences).  I think this is
the point that Joe Wreschnig was trying to make.  Generally, though,
an inconvenience must be quite insignificant indeed in order to
warrant this free pass.

This is an essential point -- possibly even the source of our
disagreement on this issue.  I believe (and I suspect that much of
debian-legal agrees with me) that there is no good way to distinguish
between a barrier that is an inconvenience and a barrier that is a
loss of freedom.  Any attempt to do so will inevitably be
context-dependant.

One of the core principles of the Free Software community, IMHO, is
that the end user is king; the person with a problem to solve should
not have his or her options curtailed any more than absolutely
necessary by the distributor or the copyright holder.  Thus a useful
heuristic (and I realize it is nothing more) is to be very, very
suspect of context-dependant judgements enforced in licenses.

I say the above simply to point out that, in my opinion, any effort to
distinguish between freedom and practical inconvenience must meet a
very high burden of proof.

> Where we draw the line, when judging licenses as free or not, is
> whether you can practically speaking make the code or the manual do
> the substantive job you want.  If license restrictions make it
> impossible to make the technical changes you want, then the license
> is non-free.  If they make it possible, but with conditions you
> might not necessarily like, it is free but with a practical
> inconvenience.

The nature of a "substantive" and/or "technical" change is what
attracts my attention here.  Though, to my knowledge, you have not
attempted to describe what those two words mean in this context, I
very much doubt that it is possible to do so in a way that is both
universal (i.e., applying in all possible contexts) and objective.
Yet I believe that this must be done in order for this distinction to
be useful.  If you are willing, I'd very much appreciate it if you
could try to expand on your position here.

>> So what divides "egregious practical inconveniences" and
>> "non-free"?
>
> The practical inconveniences of the GFDL are similar to those Debian
> accepts from other licenses that we agree are free.  They are not
> egregious.

Occasionally debian-legal does make mistakes.  Could you point out
some examples of licenses that you feel have similar inconveniences to
those of the GFDL?  In addition to pointing out possible errors on our
part it might help to provide a more concrete grounding for our
discussion.

-- 
Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03



Reply to: