Development of Creative Commons licenses

[Terry Hancock <hancock AT anansispaceworks.com>]

Patrick Peiffer wrote:
>  i too totally lost track of what the actual points are, that are
>  being discussed here at extreme frequency by very few people lately.
>  Please, make one short, to the point wrap-up of what you has been
>  contributed to the public discussion so we can understand and
>  continue.

Okay, here's a summary:

(Please note that we are using TPM="Technological Protection Measures" 
and DRM="Digital Rights/Restrictions Management" interchangeably -- the 
preferred term depends on jurisdiction, but they are equivalent ideas).

After reading Greg's "DRM Dave" scenario I am convinced that he's right 
after all and parallel distribution does not solve the question of 
"platform lock-in". In this scenario, the freedom of Dave to distribute 
DRM-locked versions of content, regardless of whether he also 
distributes unlocked versions results in a monopoly position.  It turns 
out that this isn't really because downstreams users can't *remove* the 
DRM, but rather because they can't *apply* the DRM to their modified 
versions:

1) "ShareAlike Sam" releases a package A, under CC-By-SA+parallel-dist

2) "DRM Dave" wraps this package for his DRM-Only-Platform (DOP), 
creating package [A]

3) "Alice" acquires [A] and wants to make a modified version. So she 
downloads package  A (which Dave must provide under the parallel-dist 
model), makes her modifications, and produces package A'

4) OOPS!  Alice cannot wrap package A' to package [A'] without acquiring 
DRM Dave's permission to use the DRM wrapping software (which he may 
either not give, or charge an exhorbitant amount for). Doing so without 
his permission is a violation of the DMCA, for which Alice would go to 
jail.  Hence, she cannot compete with DRM Dave's versions. Hence, Dave 
has effectively squashed Alice's right to modify and use (let alone 
modify and distribute) the work.

5) OOPS! What's more, even ShareAlike Sam, cannot wrap his package A to 
make [A] so that it can be played on the DOP, leaving DRM Dave with an 
effective copyright monopoly over Sam's work, without having contributed 
*anything* (except the DRM wrapper). This is very similar to the 
infamous WIPO "broadcasters' right" which would allow channel 
distributors to acquire effective copyright monopoly even to free works 
which pass through their channel.  This is like hijacking a 
non-copylefted free software by making trivial changes and closing the 
source.

IMHO, either of these problem is singly sufficient to kill the idea of 
parallel distribution.

This points out two major ways in which the analogy between TPM/non-TPM 
and binary/source distribution is broken. Since the parallel 
distribution model is based on the assumption that they are essentially 
the same, it too must be considered suspect.

Specifically, the analogy breaks because:

1) DRM/TPM measures, unlike binaries, do not merely present a technical 
obstacle to creation or understanding, but rather a legal obstacle. Most 
importantly, it is illegal circumvention even to *apply* DRM, just as 
much as it is to *remove* it. This means that new versions, created from 
the non-TPM content cannot be signed to work on a DRM-only platform. 
That means that the platform owner ("DRM Dave") is the only one who can 
make them.  This is exactly equivalent to the "tivo-ization" threat that 
GPLv3 is supposed to address for free software: it removes "freedom 1" 
-- the right to modify a work and use it on the platform.

One can argue that the modified work can be played on another (free) 
platform, but this is exactly equivalent to the argument that an 
unsigned Tivo-based kernel can be run on alternate hardware, provided 
you have some.

This is the breakage that, IMHO, provides the argument in *principle* 
against allowing DRM distribution.

2) DRM application, unlike binary compilation is a technically trivial 
process. This means that there is no significant burden on the end user 
if he has to convert files to DRM format to play/view them.  The binary 
distribution of free software, including entire Linux distributions is 
seen as a necessity because compilation is a complex, error-prone 
process which is difficult for end users to acheive without special 
skills. In general, attempts to automate it are fraught with problems 
due to a maze of package and library dependencies, and a myriad 
assumptions about the underlying hardware platform that are required to 
be correctly handled in order to correctly compile binaries. 

DRM application, however, is a highly self-contained encryption process 
which can be automated to the point of invisibility.  With appropriate 
design of client software, the end user never even need know that the 
original file was not DRM'd.

Unfortunately, this introduces another possible threat that I don't 
think we can do anything about.  DRM Dave (if he's very, very evil) can 
create a signed free content registry site which actually sells signing 
keys for free content. The user pays for the signing key to the song 
(though he thinks he's paying for the song itself, and he really is), 
and then he actually downloads the song in clear format from a free 
content site. The custom DRM Dave Download Utility automatically applies 
the purchased key to the content and DRM wraps it for playback on the 
DRM Dave DRM-Only Platform.

This was suggested to me by a recent blog by Edward McNaughton ( 
http://www.freesoftwaremagazine.com/node/1777 ) in regards to the GPLv3, 
and also by the way Debian used to handle some high-profile non-free 
packages. What they would do is provide an "installer" package that did 
not actually contain the non-free package (which it would've been 
illegal for Debian to distribute), but rather contained an automated 
script to download and install the package from the original site.  But 
of course, what Debian can use to make non-free content look free, DRM 
Dave can use to make free content look non-free!

Nevertheless, I think that the freedom to apply DRM yourself, in order 
to play/view content is an essential freedom, and I applaud CC's 
decision to improve the language so that this is more clearly provided 
(arguably it was already provided by the fair use clause, but clearer is 
better).

Note also, that since this problem is exactly equivalent to the 
"tivo-ization" issue, the GPL version 3 will have exactly the same 
prohibition in practice.  If the DRM is regarded as source, then the DRM 
private key needed to encrypt a file to make it play on the DRM-only 
platform will be defined as part of the "Corresponding Source". Thus, if 
a content producer were to decide to use the GPLv3 to license his 
content instead of the CC-By-SA 3.0 (without parallel dist), DRM 
distribution will *still* be prohibited (because the distributor cannot 
legally give out the DRM private key in order to conform to the 
"Corresponding Source Key" provision of the GPLv3). 

So, it turns out that the Free Software Foundation and Creative Commons 
are united against Debian on this issue!  Conventional wisdom has had it 
that FSF and Debian were united against CC, but this is not true on the 
DRM issue.

Finally, I have suggested that this is more than just a Creative Commons 
or Free Culture issue. Debian is making a mistake by claiming that 
parallel distribution meets the Debian Free Software Guidelines (DFSG).  
IMHO, the problems above render the work *non-free* under the Free 
Software Definition and in violation of the Debian Free Software 
Guidelines.  I suggest that Greg's "DRM Dave" example is just as 
important a lithmus test as the existing "Desert Island", "Dissident", 
and "Tentacles of Evil" tests which Debian Legal uses to examine new 
license terms that are in question (I'm a Debian user myself, and have 
spent some time reading Debian Legal in the past, though I did not 
participate in the discussion leading to the parallel distribution 
proposal. I must say though, that until I read Greg's example case, I 
supported that parallel distribution idea).

I suggest that the reason that there is this big disconnect is that the 
binary/source to TPM/non-TPM analogy was fairly compelling from a 
technical point of view, and that it was pushed too far by people who 
did not notice the two fundamental inconsistencies I mentioned above, or 
did not think through to their consequences.

Well, I *think* that sums it all up. ;-)

Cheers,
Terry

--
Terry Hancock (hancock AT AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com