[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Why TPM+Parallel Distribution is non-free

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.

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.

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.


[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

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

Reply to: