[Linux-aus] Fwd: Why TPM+Parallel Distribution is non-free

["Janet Hawtin" <lucychili@gmail.com>]

Hello folks

Karl sent me on this post on a debian list which I thought you might
be interested in as it has a good nuts and bolts look at TPM/DRM.

Thanks Terry and Karl

Janet

Terry Hancock wrote:

I have been a Debian user for several years now, an occasional free
software developer, and a user of the Creative Commons By-SA license,
so I have been following the effort to make the CCPL3.0 comply with
the Debian Free Software Guidelines with some interest. I used to post
here on debian-legal occasionally, and I've rejoined to discuss this
issue. I am not a lawyer.  I apologize for the length of this post,
but it is summarizing the conclusions of quite a large discussion
(which I promised to the Debian folks who joined the conversation
there that I would provide here).

The case has been made that CCPL3.0 is DFSG-non-free because it does
not allow the distribution of content in TPM'd format[0].  I assert
that not only is this argument false, it is actually reversed:
allowing TPM distribution, even with parallel distribution of non-TPM
versions of the same content actually permits a violation of the DFSG,
specifically item 3:

"""
*Derived Works*

The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software.
"""[1]

I interpret this to be an alternate wording of the same rule described
as "Freedom 1" of the Free Software Definition:

"""
The freedom to study how the program works, and adapt it to your needs
(freedom 1). Access to the source code is a precondition for this.
"""[2]

Debian's determination that parallel distribution of non-TPM files
alongside TPM files will solve this problem is based on the FALSE idea
that binary/source distribution is analogous to TPM/non-TPM
distribution.

This analogy has been cited multiple times in the discussion on
debian-legal, but I am not able to find much serious analysis of this
assumption.  It is a seductive idea, and I have to admit that I was
sold on it myself for quite some time.

However it misses the most critical point about TPM systems, which is
that they acquire their force not from "technology" (despite the
name), but from "law".  It is not truly the fact that TPM is difficult
to reverse that is the problem, but rather that it is ILLEGAL to do
so. Moreover, it turns out that the most serious problem occurs not
because it is difficult/illegal to *remove* TPM, but because it is
difficult/illegal to *apply* TPM (counter-intuitive as that may seem).

A system which applies encryption, but is not enforced under law is
NOT a "TPM" in the legal sense of the word, and is therefore not
"being used to restrict" a work (legally).

For example, any "TPM" system licensed under the new GPLv3 (d2), will
not actually be a TPM in the legal sense, because the license
expressly declares that it is not. This *technically identical*
software is nevertheless *legally distinct*. We might call this a "Non
Legal Technological Protection Measure" or NL-TPM system.

For such an NL-TPM, Debian's parallel distribution idea *might* apply
(there is still a subtle problem, but it is much less severe), but
this is not what "TPM" is under law.  TPM is something that has the
force of law backing it up.  In the United States, this means that
circumventing the TPM is a violation of the DMCA. Other countries are
adopting similar rules, which is, of course, the basis for so much
concern over TPM.

Another assumption that is typically made about binaries is that
creating them from source is a complex, error-prone process that
requires expert skill. This is what drives the practical necessity of
distributing binary versions of free software packages. TPM, however,
is always trivial to apply, provided the correct encryption keys are
available. It is only the secrecy of the keys and the laws protecting
their secrecy that interferes with the application of TPM to content.
Because of this, having to apply your own TPM is hardly a burden -- in
fact the process can be automated to the point where you would not
even realize that it is being done (e.g. it could be part of a
download client). Once again, the issue is *not* technical, but legal:
you may be required to agree to (non-free) terms to apply the TPM to
content.  This effectively never happens with binaries: even if
sources are designed to be compiled with a proprietary compiler, it is
always legal to write a new compiler which does the same job.  But
with a "TPM compiler", that compiler is illegal to write (it's a "TPM
circumvention device").

Now, having hopefully dispelled the myth that binary/source is
analogous to TPM/non-TPM, I will relate the problem case (originally
presented by Greg London on the cc-licenses list [3], I'm just
outlining it here):

1) Sam releases a work A under By-SA w/ parallel-distribution allowance.

2) Dave, owner of a TPM-only platform, wraps work A in his TPM wrapper
to create d[A].

3) Under "parallel distribution" rule, Dave can now sell d[A] through
his channel, so long as he also provides A.

4) Dave may choose to alter the work to create A', and wrap that to
create d[A'] which he may also sell (Dave has the right to modify and
distribute).

5) Bob downloads work d[A] and likes it.  He decides that he wants to
create a modified version, A'' which he will (due to the platform's
TPM-only nature) need to wrap to create d[A''] so that he can play on
the platform Dave owns.

6) Bob can download the non-TPM work, A.  He can modify it to create
A''.  But he has no key to create d[A''].  Nor does anything we've
done require Dave to give him that key!  Bob's freedom to modify and
distribute has been eliminated by Dave, in a clear breakage of
copyleft.

So Dave has secured a platform monopoly on Alice's work. He is able to
charge for it under monopoly terms exactly as if he were the copyright
owner. He is not required to distribute the work in a form that allows
others to modify it and play it on his platform. He has managed to
effectively revoke the users' "freedom 1", making the work non-free.

Now, if you pay close attention, you can also see that this is
basically identical to the problem of "tivo-ization": we need a
special key, which has been withheld, in order to exercise our freedom
to modify and distribute.  The GPLv3d2 attempts to rectify this
problem by defining that key as part of the "corresponding source" for
the work.

This is equivalent to demanding that Dave release his encryption key
(or provide an alternate key) to be used to encode works to play on
his platform. But note that this is (from Dave's point of view) no
more difficult than making his platform run non-TPM'd works.  In fact,
one way to implement that is to make a TPM-key-wrapper a part of his
platform.

So, if Dave wanted to create a TPM-only platform in the first place,
he's not going to release the encryption key.  Requiring him to do so
is no less onerous than just asking him to let non-TPM works play on
his platform.

Furthermore, if such a key is published, Bob may use the published key
to TPM his own private copy of A'', and so may all users who receive
A''.  IOW, having the key allows the platform to be freed to allow
content to play on it, so it is not effectively TPM'd any more (or, in
fact the TPM is no longer a TPM once the key has been published).  In
any case, it is no longer being used to restrict the content, so the
anti-TPM clause in CCPL3.0 no longer applies to it.

So, in my opinion, the GPLv3d2 "Corresponding Source Key" clause is
roughly equivalent (at least in effect) to the CCPL3.0 "anti-TPM"
clause, because it is a key necessary to view the content on the
platform.  IOW, if you were to release the same content under the
GPLv3d2, the same results would happen: Dave would be barred from
publishing the work on his TPM-only platform, unless he pubishes the
TPM key (which then makes it no longer a TPM-only platform).  Now, of
course, Debian hasn't approved GPLv3d2 either, but I think it's
relevant that the Free Software Foundation and the Creative Commons
have both come to the same terms on this issue: TPM used to make it
impossible to play a derivative work on a platform is a violation of
users' freedom.

In any case, it's pretty clear to me that it would be inconsistent to
recognize GPLv3, but not CCPL3 on this point, since they are actually
effectively making the same requirement.

In my opinion, Debian has reasoned incorrectly about this issue, based
on a compelling, but false assumption that the 15+ years experience
with binary/source parallel distribution can be applied to TPM/non-TPM
parallel distribution.  It was a nice thought that that should be so
-- but it doesn't hold up to close scrutiny. There really is a
difference, and for free-licensed cultural content, the CCPL3.0's
anti-TPM
distribution clause is the only practical solution.

On a related note, I should mention that CC has decided to clarify the
language to make it more obvious that it is only the *distribution* of
TPM'd files (not private copying) that is forbidden.  There is a
strong feeling that fair use already permits this, and that the
existing wording already makes this true accross jurisdictions, but
that it should indeed be made more explicit (this is my understanding
from Mia Garlick's responses to the list commentary).

As a Debian user, I am furthermore concerned that continuing to push
for a TPM+parallel distribution clause will damage the freedom of the
Debian distribution and free software / free culture in general,
because it will encourage exactly the kind of exploitation that Dave
exhibits in the example above: it provides an incentive to exploit
existing works commercially while removing any incentive to create
(and for many, even the ability).  It's a very wicked poison to the
free/copyleft development community, and all the more deadly for its
relative invisibility.  Please don't let this happen over a such a
basic misunderstanding!

Anyway, that's my case both for accepting the CCPL3.0 w/o the parallel
distribution clause, and also for generally considering the parallel
distribution not to be required for "DFSG freedom".  Thanks for
reading.

Cheers,
Terry

[0] TPM="technological protection measures" it's synonymous with DRM
in a legal context (There was a bit of red-herring awhile back in
which it was suggested that "digital rights management" would refer to
the management of metadata about the rights on a file. In a sane world
perhaps, but this is not what it means in licenses)

[1] http://www.debian.org/social_contract

[2] http://www.gnu.org/philosophy/free-sw.html

[3] http://lists.ibiblio.org/pipermail/cc-licenses/2006-September/004130.html