[cc-licenses] PROCEDURAL SUGGESTION
Terry Hancock
hancock at anansispaceworks.com
Mon Oct 2 23:13:02 EDT 2006
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
More information about the cc-licenses
mailing list