Development of Creative Commons licenses

["Luis Villa" <luis AT tieguy.org>]

On 8/11/06, Rob Myers <rob AT robmyers.org> wrote:
> > But I don't understand DRM enough to know
> > if a "FLOSS-to-DRM" converter is like a compiler
> > or not. I.E. is it hard to implement or reverse engineer?
>
> You may be able to reverse engineer some current DRM. iTunes DRM is
> typically cracked as soon as it is upgraded. But to do so is illegal
> because of the DMCA, and when Trusted Computing comes in you won't be
> physically able to analyse it.

This is a pretty good summary of the compiler/DRM comparison.

In comparison, the GPL *assumes* that code is available (because of
other clauses in the license). GPL v3 adds additional
tool-related/DRM-related clauses which primarily focus on making sure
the available code is useful and unrestricted.

What CC seems to be doing is the reverse- assume that the 'source'
might not be available, and then use some language to force
availability. So maybe that suggests a strategy to make the parallel
distribution clause more clear: phrase the license such that an
unencumbered/unDRM'd copy of the 'source' (i.e., the music/video/what
have you) must always be available, and then allow the distributor to
post-process the file into whatever DRM-ish formats they so choose.

It could look like this:

"You must always distribute the Work/Adaptation in a format which does
not restrict the ability of a recipient of the Work to exercise the
rights granted to them under the license ("Unrestricted Format"). You
may, in addition, distribute the Work/Adaptation in a format which
restricts the ability of a recipient to exercise the rights granted to
them under the license ("Restricted Format"), provided that the
Unrestricted Format is at least as accessible to the recipient as a
practical matter as the Restricted Format."

That approach feels much more readable to me, and makes it clear that
the organization's focus is on unrestricted formats, and DRM'd formats
are only an afterthought. If that is insufficient, perhaps something
like 'and provided that the Restricted Format is an unavoidable
requirement of the targeted software platform' (to make it clear that
DRM can be used only in the PS2/PSP/etc. case) could be added at the
end.

[Tangentially, having just read Evan's summary:

http://evan.prodromou.name/Debian_Creative_Commons_Workgroup_report

I'm frankly shocked that iCommons would allow an in-person vote in a
country that was very expensive to get to determine policy for the
organization. Is that really what happened?]

> What I'm yet not clear on is whether the DRM clause protects
> against [proprietary forks] or not. No one has yet answered that question.
> ANd I still ahven't had time to comb the license wording myself.

The relevant clause is pretty short if you want to read it, Greg- it
will take a lot less time to read it than it has taken you to write
about it without reading it, I guarantee :) And to answer your
question, yes, assuming the parallel distribution language is
included, then proprietary forks are effectively prohibited.

"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 ("Restricted Format")
unless You also make a copy or phonorecord of the Work available to
the recipient, without additional fee, in at least one medium that
does not restrict the ability of a recipient of that copy or
phonorecord of the Work to exercise the rights granted to them under
the License, provided that that copy or phonorecord of the Work is at
least as accessible to the recipient as a practical matter as the
Restricted Format."

There is a similar clause with Work replaced by Adaptation.

HTH-
Luis