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

Re: Why TPM+Parallel Distribution is non-free

MJ Ray wrote:
 Terry Hancock <hancock@anansispaceworks.com> wrote:
> 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, [...]

 I agree that Terry Hancock asserts allowing TPM-parallel licences is
 "a violation of the DFSG" but does not support that with any

No. I said it permits a violation. What a platform owner may do, is take an otherwise free+copyleft work and release it under non-free terms. He may do so in a way that obstructs competition from free+copyleft works. It is essentially the removal of the copyleft on the work.

You are of course right that effective copyleft is not required by the DFSG.

However, I find it highly disturbing to imagine that the Debian Project is taking a position against the support of copyleft to retain future freedoms for users. So is finding

 For the rest of this message, I concentrate on the argument
 that prohibiting all TPM is fine under the DFSG.

Prohibiting TPM *distribution* is fine under DFSG. This is exactly what the Aug 9 draft of CCPL3.0 says:

You may not impose any technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise their rights granted under the

The entire section refers to *distribution*, not *use* (this should be obvious from the wording -- if we aren't talking about distribution, then who is the "recipient"?).

The requirement is needed to ensure that copyleft preserves the freedoms granted by the content's author.

Note that it occurs in parallel with the standard copyleft statements which make it clear that no further restrictions may be imposed. TPM is merely being included as one such means of applying restrictions against users' freedoms.

> I think it is not
 because it hinders free redistribution and discriminates against use
 of some platforms.

Not only is this untrue, but it is in fact reversed. Allowing TPM distribution allows a platform-owner to obstruct redistribution of the work.

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

 Problems I see with this argument so far:

> 1. AFAICT, parallel
 distribution was first suggested as a TPM-countermeasure [in 2003 at
 least] long before the binary/source analogue was first used in
 explanation [in 2005] so how can it be based on it?;

Oh give me a break. Like they weren't thinking of that in 2003. The analogy is obvious. That it is incorrect is less so.

This has little to do with my argument, though. It just shows a plausible explanation for a mistaken consensus. But explanable or not, the consensus is mistaken.

> 2. the
 restrictions of a licence that permits parallel distribution need not
 be non-copyleft;

The anti-TPM clause is part of the copyleft. It is essential to preserve the freedom of the work, hence it is essential to copyleft.

Saying that a work distributed for platform A is "free" because you can play derivatives on platform B, even though you can't play them on A, is just double-speak. Obviously, a real copyleft insists that you can modify a work and play it back on the platform the work was designed for (that you can do so on other platforms is also required).

> 3. Debian has not determined it - we are not at that
 late a stage yet;

Good.  Let's *not* determine it, because it's wrong.

> 4. Debian is a distribution - probably the above
 meant the debian project.

That's called "synecdoche".

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

 As I mentioned on cc-licenses, this is incorrect.

The technology is potentially problematic. But it is only when the law is coupled to it that it becomes a serious impediment. A purely technologic obstacle can always be overcome (and once the solution is available, then it can be shared legally if the solution is not itself illegal).

Consider DeCSS. The technology was overcome quickly, but Debian still can't distribute the resulting library for legal reasons.

> Also, CC3.0draft appears to
 prohibit use of that technology, regardless of whether or not a bad
 law is active - it appears to export the DMCA to everywhere.

Actually, that's a valid point. I'd be happier if it made it clear that "TPM" means only legally-backed TPM. I can't see that it makes any real difference with the current wording, though.

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

 This line of argument seems based on two mistaken
> 1. one particular problem with TPMs overruling all other arguments;

It's not so much "one particular problem" as it is "THE problem". The entire purpose of TPMs is to preserve monopolies. This case merely exposes how parallel distribution is inadequate to preserve end-user freedoms.

> 2. assuming that everywhere has the bad TPM laws of the US and EU.

Regrettably, these laws are spreading by treaty agreements and very quickly. A license that can't preserve freedom in such jurisdictions has a problem everywhere else.

 I do not understand why applying a TPM is necessarily illegal or

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

 Adding the adverb "legally" does not change the meaning of words on
 its own. Are there any cases showing any technological measure used
 to restrict anyone as being not enforced under law now?

It's only a "TPM" if it is being used to protect. That is a matter of *intent*, not technology. That's why "TPM" is a *legal* term, not a technological one.

To be precise, of course, the CCPL makes it quite clear that it is solely restriction of the end user that is not allowed.

 [skipping GPLv3 draft discussion]

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

 I claim this is nonsense, based on more overgeneralised assumptions.
 Binaries can be easy to create from source (apt-get source --compile)
 and TPMs can be awkward to apply. There is nothing inherent in
 either process in general that makes them unautomatable.

Yes, there is. A TPM is just a form of encryption. It has no complex dependencies. Either you have the keys to encrypt or decrypt it, or you don't. The hardware and software environment doesn't affect it. It's an independent problem.

Binaries are (usually) such a pain to compile, because there is a combinatorial explosion of dependencies on other pieces of software and on the hardware it's to run on. As a result, the environment the user has is almost never exactly like the one the developer used, and the build process is stressed by all of the changes (usually including many untested combinations).

 (I have experience of applying TPMs and of creating binaries from

Please demonstrate a case of TPM which is necessarily complex to apply.

You've demonstrated a trivial binary compilation, but I think we all have enough experience to know how false an impression that is of the general case.

> [...] But with a "TPM compiler", that compiler is illegal to write
> (it's a "TPM circumvention device").

 Surely it's the decompiler which would be a circumvention device? At
 worse, your compiler may be education in how to circumvent, which is
 itself illegal, but maybe it wouldn't.

I don't know that this distinction has ever been tested in court. I'm reasonably sure that it *would* be considered a circumvention device. After all, you are circumventing the technology used to protect the platform owner's monopoly on his platform. This materially damages his profitability. I'm not sure whether that is sufficient to invoke the anti-circumvention laws or not.

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

 Alice? Who the f'k is Alice? ;-)

Should read "Sam". Sorry, I used "Alice" in the first draft to follow an ABC scheme, then changed to be consistent with Greg's alliterative players, "Sharealike Sam" and "DRM Dave". Maybe "Bob" should be "Conducer Carla". ;-)

 The above is a convincing example showing the bad effects of platform
 monopolies, but it does not justify Sam discriminating against users
 of that platform.

And there is no discrimination. The license is completely indiscriminate in it's anti-TPM clause. Furthermore, *users* can do what they like. It's only *distributors* who must conform to the license terms.

 What would be the alternative situation? Sam releases A but forbids
 creation of d[A],

The creation of d[A] is not forbidden. Just its distribution.

 As clearly described above, d[] is the real problem, not A or d[A].

Yes it is.  That's why we don't like d[].

 Attacking d[A] for all A is impossible, as there will always be some
 A whose creator allows d[A].

That is still possible with the existing wording. In fact, it's possible that Dave may pay Sam for the right to distribute d[A]. He always has that option, no matter what the free license is.

Parallel distribution gives DRM Dave the right to a platform monopoly on A without even paying the author for the privilege of doing so. Under normal copyright terms Dave would have to ask permission and pay for each work he wants to sell. Preserving this economic environment is what his use of TPM is all about.

But if Dave wants to play the free content game, then he needs to make the content Free, by giving us the key needed to run non-TPM content on his platform. If he does that, users can run the free content, by applying the TPM encryption when they load the device.

> So, the best tactic is to attack d[].

Yes.  Parallel distribution fails to do that.

 Letting Dave show that A exists for some d[A] is part of that.

 (Note that in step 4, Dave must be distributing A' too and in step 6,
 Bob maybe should have the non-TPM work A already.)

Yes, of course Bob has A already, so he can make A''. But he can't run it on Dave's platform nor can any other users of Dave's platform. In short, A'' is unusable to the people whose freedom we are concerned about. That means that A (or rather d[A]) is non-free: users do not have the freedom to modify and use the work, much less modify and distribute.

For that matter, they may have to pay a single supplier monopoly (Dave) in order to access the original work (because Dave can sell d[A], A won't play, and Sam can't make a d[A] to compete with it.

> He is able to charge for it under monopoly terms exactly as if he
> were the copyright owner.

 No, he is not. He does not have a global monopoly, so there is
 always A out there as a comparison. A difference in price between A
 and d[A] shows how he is abusing his dominant market position.

Either the TPM platform is important or it isn't.

If it *is* important, then the monopoly doesn't have to be global to matter.

If it *isn't* important, then the whole argument has little significance. We should instead be encouraging users not to choose such non-free platforms.

 [...more gplv3 draft discussion removed...]

> 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 feel I'd have no problem with that sort of requirement.

So we're still discriminating against users of TPM platforms for which no such key is published.

You do realize, that, given the obvious monopoly advantage of NOT publishing such a key, these are generally going to be practically the same platforms and the same users, right?

> But note that this is (from Dave's point of view) no more difficult
> than making his platform run non-TPM'd works.

 That's only true if Dave made the correct decision at platform design
 time. Platform ownership is bought and sold, so why must it be

Because all he needs is a patch that applies the TPM as it loads or plays the material.

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

 As far as I can tell, it is still restricting the content as much as
 it was before. Also, if a TPM with a known key is not an effective
 TPM, why is DVD-CSS still considered a TPM, AFAICT?

The question is not whether it is an "effective TPM", but whether it is being used to "restrict" the end users' rights.

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

 That opinion is flawed, partly because it seems to be based on an
 assumption that the parallel distribution suggestion was based on
 binary/source distribution, contrary to the evidence in the list
 archives. Why make that assumption?

The only value in this obvious assumption is that it offers a way for Debian Project folks to save face. It makes no difference to the argument. I think it's more polite to assume that there is a plausibly logical reason why otherwise intelligent people would accept a wrong idea without applying sufficient critical thinking to it to see what's wrong with it.

> [...] There really is a difference, and for free-licensed cultural
> content, the CCPL3.0's anti-TPM distribution clause is the only
> practical solution.

 I suggest that this is an attempt at proof by assertion. As has been
 outlined above, with key provision, there are other practical
 anti-TPM distribution clauses.

Well, "practical" is a matter of opinion, I suppose.

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

 If that is true (and there seems to be no public record of CC
 decisions), then it is welcome, but inadequate.

It provides the same protections as the proposed alternative (with key provision), yet is much simpler to understand and implement.

> [0] TPM="technological protection measures" it's synonymous with
> DRM in a legal context [...]

 This is not true in England at least, as far as I've seen, where
 technological measures are named as such in law.

The words "technological protection measures" are used in some jurisdictions, while "digital rights management" is primarily US usage (AFAIK). TPM is probably a more precise and correct name, since DRM could logically mean just associating rights-based meta-data with a file (i.e. Creative Commons RDF would be a "DRM" if name were interpreted logically).

If you know of a difference in meaning which matters here, please explain.

 In summary, CC3.0draft's anti-TPM is not the only practical solution.
 There are alternative approaches suggested (in this thread for
 example) which may be acceptable and avoid discriminating against
 other fields.

The only alternative I've seen proposed is "parallel distribution permitted for platforms for which a public encryption key exists". This makes no material difference in which platforms are supported, and except for the trivial matter of whether the TPM is applied before or after the user receives the file, no difference in practice.

Furthermore, that small difference is sufficient to ensure that the key (and whatever means is needed to apply it) truly is publically available. If there's any problem with that, then it indicates a problem with the freeness of the content anyway.

> In general, I feel that TPM should be addressed by
 requiring distributors to meet requirements which exclude
 unreasonable negative acts.

Like applying TPM to "restrict the ability of a recipient of the Work from You to exercise their rights granted under the License"?

I agree.

 The argument put forward by Terry Hancock seems to be dominated by
 apparently-incorrect claims about DD past actions,

Wow. That is a major twist of wording. You're saying that my argument is wrong because I offered a plausible explanation of why Debian might have gotten it wrong?

> one example which involves an admittedly-disturbing compromise,

It only takes one.

> and some claims that
 certain things are not TPMs or are illegal.

That TPM is a matter of intent is a legal interpretation favored by two lawyers, Eben Moglen and Mia Garlick, for both of whom I have a fair amount of respect. It's the basis for the wording in the current GPLv3 draft, which, while still controversial, has not been seriously challenged on this matter of interpretation.

The CCPL3.0 goes further than this though, by being specific about the way the TPM can't be used.

> The lack of references
 for the claims and assertions makes discussion rather difficult,
 which is the same problem as on cc-licenses.

What exactly is it you want references for? I presume people know how to find the CCPL3.0, the GPLv3, the DFSG and the other sources mentioned. I've already referenced the archive for Greg London's "DRM Dave" test case.

The logic is all pretty obvious.


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

Reply to: