Hi Evan,

Sorry for being late to the party, but I thought I'd chime in anyway with
my 2ยข on the question.

On Thu, Aug 10, 2006 at 11:26:13AM -0400, Evan Prodromou wrote:
> The main question I want to ask debian-legal is this:

>         Does the anti-DRM requirement in the CCPL 3.0 draft, without a
>         parallel distribution proviso, make it incompatible with the
>         DFSG?


> We'd originally negotiated a parallel distribution proviso, but the
> extra clause was later removed. So, the CCPL 3.0 license draft has this
> language for DRM restrictions:

>         You may not impose any technological measures on the Work that
>         restrict the ability of a recipient of the Work from You to
>         exercise the rights granted to them under the License.

So the language being replaced seems to be:

  "You [being the licensee, not the licensor] may not distribute,  
  publicly display, publicly perform, or publicly digitally perform the  
  Work with any technological measures that control access or use of  
  the Work in a manner inconsistent with the terms of this License  

That's clearly non-free, as it says you can't ever distribute the work by
TPM-encumbered means.  But the new draft language doesn't say that: it says
you can't impose any technological measures on the Work *that restrict the
ability of the recipient to exercise their rights*.  If I take care to
ensure that the recipient has access to an unencumbered copy, in addition to
the encumbered copy, then to the extent I have imposed technological
measures at all, they don't seem to actually restrict the recipient's
exercise of rights under the license.

Is this interpretation in keeping with how the CC folks understand the
license?  If so, I agree with Marco d'Itri's comments in
<[EMAIL PROTECTED]>: there seems to be no need at all for a
parallel distribution clause.

OTOH, if CC intends that this clause prevents ever making the Work available
on TPM-encumbered media (which I don't think is the plain-text reading of
this clause), I don't believe it's DFSG-compliant.

> Since we negotiated the license changes, Debian has had a GR to allow
> works licensed under the GFDL into main. The GFDL has the following
> anti-DRM clause:

>         You may not use technical measures to obstruct or control the
>         reading or further copying of the copies you make or distribute.

> GR 2006-01 says, in part,

>         Similarly, we do not think that GFDL covered documentation is
>         non-free because of the measures taken in the license against
>         misuse of DRM-protected media.

As you yourself noted later, this isn't part of the text of the GR that
passed.  The actual resolution doesn't address the DRM question at all; the
only way I can personally understand the claim that the GFDL does not
conflict with the DFSG is that we believe the *intent* of the GFDL is to
prevent using DRM to limit users' rights rather than to prevent distributing
on DRM-encumbered media per se, and therefore the license's ambiguity on
this point is a blemish that can be overlooked.

> In my personal opinion, the question boils down to these points:

>      1. Was GR 2006-01 an exception to the DFSG, or a clarification of
>         our principles?

Neither; it is a position statement that the GFDL should be read in a way
that is compatible with the DFSG.  Since the GR does not *say* it's an
exception, it's not an exception; and it's not a clarification of principles
because it hasn't attempted to clarify anything.

>      3. If so, is the anti-DRM clause in the CCPL 3.0 draft similar
>         enough to the FDL's anti-DRM clause for us to consider it
>         compatible with the DFSG?

I consider it compatible with the DFSG because it's sufficiently
*dissimilar* to the FDL's clause.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
[EMAIL PROTECTED]                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply via email to