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

Re: Results for Debian's Position on the GFDL



On Tue, Mar 14, 2006 at 03:06:58PM -0500, Raul Miller wrote:
> For the DRM issue to be significant, we'd have to have reason to
> believe that a judge would not be familiar with the legal meaning of
> the phrase "technical measures" in the context of copyright law.
> Other meanings of "technical measures" would lead to ludicrous
> conclusions (for example: once we've started giving someone a copy we
> must keep spamming copies, never being allowed to stop).

Encrypting a document (whether via GPG or HTTPS) sure seems like a technical
measure to obstruct the reading of copies.

> And the Opaque issue only applies when the transparent copies are not
> distributed.  It's simple enough to include the transparent copies in
> any .deb, and it's simple enough to file an RC bug report against any
> package with GFDL'd content which doesn't include the transparent
> copies.

Maybe I'm misunderstanding the issue you're referring to.  My issue with
the "transparent copies" bit is that it prohibits converting the document
to, say, a Word document.  The GPL allows it: I can convert it to Word,
and make that my source form (using it for all future modifications,
throwing away the original HTML and all that).  The GFDL prohibits this.
The "Transparent copies" definition is being used like "source" in the
GPL, but narrowed to exclude source forms that the FSF doesn't like (even
entirely open formats, if they can't be edited with "generic text editors".)

> As for the other issues you call out, I don't think this GR really
> says much about them:  Where these elements are invariant, the
> GR doesn't say anything about GFDL licensed documents which
> contain them.  Where they're not invariant, the restrictions
> imposed are not any more obnoxious than practical restrictions
> on software for non-legal reasons, or practical restrictions on
> patch clause dfsg software.

I think that, prior to this, the patch clause exception was the biggest
blunder in the history of the DFSG: calling software which you're never
allowed to reuse code from Free.  Code reuse is one of the basic goals
of free software.  It's the biggest error not so much because of the
software under these licenses (which are few), but because it's been used
to argue as you have: "patch clauses even prohibit putting code in version
control; since we allow that, we should allow all kinds of other onerous
restrictions, too."

I had hoped that this might be fixed some day, but this GR moves things
a couple miles in the other direction and I no longer retain any such hope.

> It's never been clear to me that the Dissident test is a accurate
> reflection of the DFSG.  I can think of many ways for a dissident to

If a dissident is placed in serious danger if his identity is revealed,
I can't think of any way he could work around a license that requires
revealing his identity.

> work around such problems (except for dissidents who more slavishly
> follow their government's suggestions than most non-dissidents -- but
> I don't think that's a serious issue).

I'm not sure what you mean by "follow their government's suggestions".
If the license says "identify yourself", and identifying myself working
on cryptography software will get me thrown in a dark cell, what
"government suggestion" am I slavishly following?  Copyright law itself?

"The government" isn't the operating force in the dissident test, anyhow.
The dissident test is not simply about dissidents and governments; that's
the case used as a test, and for explaining the problem, but the test is
applicable much more generally.  That's why it's a test.

I might work for a company that feels threatened by Free Software, and
doesn't want its employees contributing to it.  (I don't, to be clear; we
actively contribute to free software.)  If I was to spread Free Software,
and was discovered, I might find myself without a job, so I'd do so
anonymously.  The Dissident test deals with the many reasons one might
need to remain anonymous in order to exercise DFSG freedoms.

(If you're thinking about "you've probably signed over your copyright
already", then use "future employers won't hire you".  Free licenses
shouldn't prohibit anonymity.)

> Maybe none of this is new, but aside from the Opaque and DRM issues,
> none of the proposals or supporting material on vote.debian.org
> indicate that any of these issues are to be taken seriously.

That's the problem: license problems are not being taken seriously.  The
GR casually (and, without another GR, permanently) ignores all of these
issues, saying "from now on, every issue you find in the GFDL is to be
ignored, preemptively labelled free", and probably also "any freeness
issues are automatically OK if you can find them in the GFDL".  The DFSG
must now be read to allow mandating identifying yourself, making random
section headers invariant, prohibiting converting to formats the author
doesn't like, and so on.

-- 
Glenn Maynard



Reply to: