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

[Andrew Donnellan]

Below is Francesco Poli (a regular on debian-legal)'s reply to the mail.

 On Fri, 06 Oct 2006 22:43:31 -0500 Terry Hancock wrote:

[...]
> 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).

Thanks for the summary: I'm trying to catch up with cc-licenses web
archives, but it recently became very hard...

In the following I try to comment on your reasoning.
In a nutshell, I think that your analysis has some flaws and is based on
some misunderstandings.
I don't have a definite answer to the question about TPM'd/non-TPM'd
being more similar to object/source or rather (as has been claimed on
cc-licenses) to patented/unpatented: I think that it's closer to
object/source than you seem to think, but I acknowledge that the analogy
is not perfect (but which analogy is, after all?).

The usual disclaimers: IANAL, IANADD.

>
> 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]

If you mean that allowing parallel distribution of TPM'd and non-TPM'd
versions fails to meet DFSG#3, then you're misreading the DFSG.
The DFSG constitute a set of minimum permissions that must be granted
for a work to be considered Free.  Adding a permission cannot possibly
break DFSG-compliance.  A license can be too restrictive and thus fail
to meet the DFSG, but no license can be too *permissive*.

On the other hand, if you instead mean that allowing parallel
distribution of TPM'd and non-TPM'd versions permits the creation (and
distribution) of non-free derived works, that could be true or untrue,
but that doesn't affect the DFSG-compliance of the license.

>
> 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]

IMHO, DFSG#3 (maybe together with DFSG#2) is more equivalent to the
union of freedom 1 and freedom 3 of the FSD.
But we digress: this is irrelevant for the discussion at hand...

>
> 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.

Please note that proprietary programs are often distributed in object
code form, under a contract (EULA) that forbids recipients to decompile,
disassembly, reverse engineer, ...
This is a legal barrier, as well as a technical impracticality (you
don't get the actual source code, when you decompile).

What I mean is that even the object to source reverse path is, in many
cases, legally forbidden, as well as technically difficult.

> 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).

Are we sure?
The law speaks about TPM in order to specify what is illegal to
circumvent.
If the legal definition of TPM were "the measures that are illegal to
circumvent", we would have a circular (meaningless) definition.
We must have a different legal definition of TPM, before the law can say
that TPM cannot be circumvented...

>
> 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.

I'm not convinced that something can magically become legally true, just
because a license expressly declares it.
Otherwise we could easily solve the software patent problem with a
single clause in Free Software licenses:
"No covered work infringes any patent under any patent law".
It would be great, but I don't think it would hold in court...  :-(

[...]
> 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.

This is not always so true as you seem to think.
For instance, some systems are based on a high level of automation for
the compiling process (Gentoo Linux comes to mind).

> TPM, however,
> is  always trivial to apply, provided the correct encryption keys are
> available.

Always?  I do not have experience in applying TPM, but I would be
surprised to learn that the process is *always* trivial.
What is trivial, anyway?
A single command?  Two or three commands?  Some ten commands to issue in
the correct order with appropriate text file editing?

Take into account that:
 * downloading, compiling, and installing a package can be automated in
   a single command (Gentoo Linux, again)
 * for many people, even installing OpenOffice.org on their Windows box
   is "too difficult" (try and tell them that applying TPM with these
   encryption keys is trivial...)

> 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, you could consider Gentoo's portage/emerge as a download
client with compiling functionality...

On the other hand, in a proprietary OS binaries could be required to be
signed by a vendor's secret key in order to be run.  This could forbid
running your own modified version of a Free program on the same
platform.  And the circumvention of this mechanism could be claimed to
be illegal (probably because of laws such as DMCA/EUCD/...).

> 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.

As I said above, you can write a new compiler, but the platform could
still refuse to let you use the compiler's output, unless it's properly
signed...

> 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 think that this analogy, though not perfect, still has some merits.

> 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).

OK, but, at that point, Dave must also provide A'.

>
> 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.

Wait, Bob can still create and distribute A'' and use it on other
platforms.

But I acknowledge that Bob is prevented from creating d[A''] in order to
make use of A'' on Dave's platform.
That could be seen as a weakening of the copyleft mechanism that
CC-by-sa aims to implement, but it's not a freeness issue, per se.
IMO, though, preventing any TPM to be applied to A is not the right
strategy to address this issue.  It's like throwing away the baby along
with the bathwater.

Maybe a good strategy could be requiring the distribution of the
encryption keys that are needed to apply TPM to A'' (unless they are
already generally available).
That would be an approach similar to the GPLv3draft2 definition of
Source Code (see Section 1.).
That way, parallel distribution of TPM'd and non-TPM'd version could be
allowed, but only as long as any recipient is able to re-apply TPM to
his/her own modified version of the work.

>
> 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.

Not exactly, he would become the only provider of versions of the work
that are usable on his platform, but any recipient could still modify
and distribute the enuncumbered versions.

>
>
> 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.

Yes, it's seems to be quite similar to the "tivo-ization".

> 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.

I'm surprised that nobody seems to have suggested this approach for
Creative Commons too, before.

> 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.

This is not the same, IMHO.
At least from a technical point of view: a player that supports a single
format is simpler/lighter than a multiformat one.
It could also have different impact on what users can or cannot do with
"All Rights Reserved" works, even though I cannot focus this better,
right now...

>
> 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.

As I said, I'm not sure...

>
> 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.

Wait, wait: if the TPM are based on public key cryptography, you could
have the necessary key for applying them, but not the key that's needed
to pull them off.
In that case, when you receive an "All Rights Reserved" work with TPM,
d[R], you cannot get R back and share it with your friends or modify it
in any way.  You can only use d[R] on Dave's platform (perhaps for a
limited number of times or for a limited timeframe).
On the other hand, when you receive d[A] along with A (parallel
distribution) under the CC-by-sa-v3.x, you can exercise all the rights
granted by the license on A and re-apply the TPM to A (or A') in order
to use it on Dave's platform.

I think that TPM with a published encoding key are still effective TPM
(as long as the decoding key are held secret).

>
>
> 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).

IMHO, they are two very different clauses.

> 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.

They are not the same terms.
The goals could be seen as similar (even though I cannot read minds, and
consequently cannot comment on unexplained goals: I'm still wondering
which are the actual goals of Creative Commons, and, to a lesser extent,
which are the ones of the FSF...), but the clauses are really different
and have different effects (remember that we must take collateral
damage, as well as primary effects, into account!).

>
> 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.

They are not, IMO.

>
>
> 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.

IMO, it's not a solution.  So, I hope there are other strategies,
because banning TPM causes collateral damage that makes the works
non-free.

>
> 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).

This would be an improvement, but I have yet to see the new clause
phrasing, before I can comment.

>
> 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,

It cannot harm freedom.
Likewise, a non-copyleft license cannot harm freedom (as long as it
meets the DFSG).

Allowing parallel distribution could harm copyleft, or maybe not.
*Not* allowing parallel distribution could harm freedom, or maybe not.
These are the points to be discussed, really.

[...]
> 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.

Thanks for writing.


On 10/8/06, Janet Hawtin <lucychili at gmail.com> wrote:
> 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


--
Andrew Donnellan
-- Email - ajdlinuxATgmailDOTcom (primary)
-- Email - ajdlinuxATexemailDOTcomDOTau (secure)
http://andrewdonnellan.com
http://ajdlinux.wordpress.com
Jabber - ajdlinux at jabber.org.au
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
-------------------------------
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net