Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] PROCEDURAL SUGGESTION

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: Terry Hancock <hancock AT anansispaceworks.com>
  • To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: [cc-licenses] PROCEDURAL SUGGESTION
  • Date: Mon, 02 Oct 2006 22:13:02 -0500

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





Archive powered by MHonArc 2.6.24.

Top of Page