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

Re: Results for Debian's Position on the GFDL



On Sat, Mar 11, 2006 at 11:01:19PM -0500, Anthony DeRobertis wrote:
> However, Option 1 was the consensus of this list, and thus we've been
> overridden[0]. I feel that we now need to figure out why the project as
> a whole has rejected the draft position statement [2] and render our

The GFDL has more serious problems than most licenses, and Debian has stuck
its rubber stamp on them; we're stuck with them, probably for good.  I'm
sure any pretense from the FSF of trying to fix these problems will be
dropped entirely now, since Debian has said they're OK.  The project has
asserted that onerous practical problems are acceptable.

Message-Id: <20060218003617.GA29670@zewt.org> lists some other problems found
on a quick reading, not all mentioned in the old position statement.  Also,
any other problems found in the license can no longer be considered DFSG-
unfree, no matter how bad they are; this GR forces any such problems to be
contrived as free.

> "You may not use technical measures to obstruct or control the reading
> or further copying of the copies you make or distribute" has been
> mis-read. I don't think there is any way the Project would consider "you
> must make all your files a+r, etc." a free license. I propose that the
> Project is telling us that something along the following is the true
> reading:
>
>     "You may not use technical measures to obstruct or control the
>     reading or further copying [by the intended recipient] of [all] the
>     copies you make or distribute [to him]"

The Project can't say what the "true reading" is.  Only the license and
the copyright holder can determine that.  The Project has no power, by GR or
otherwise, to define the interpretation of someone else's license.  This
GR also did not say "the GFDL is free, as long as this and that
interpretation of the license are held"; it makes no such qualification.

The Project is telling us that it's Free to prohibit encrypting a document,
since that's what a straightforward reading of the GFDL does.  Even if the
FSF has clarified that it's not *their* intention, that's only partially
waiving the clause for only the FSF's works.

I can put a document under the GFDL, and say "the 'technical measures'
clause is, in fact, intended to prohibit encrypting the document".
That's not bending or twisting the license; it's merely confirming a
straightforward interpretation.  This GR says that it's free to prohibit
you from sending the document over https, or to attach it to a message
GPG-encrypted.

(The silly thing is just how worthless this clause really is.  Merely
requiring source be available--you know, the preferred form for
modification--prevents any effective DRM.  This ill-conceived clause
didn't even need to be there, and now Debian has to consider it free.)

-- 
Glenn Maynard



Reply to: