Re: Why TPM+Parallel Distribution is non-free
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 evidence.
For the rest of this message, I concentrate on the argument that
prohibiting all TPM is fine under the DFSG. I think it is not because
it hinders free redistribution and discriminates against use of some
platforms.
> 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?;
2. the restrictions of a licence that permits parallel distribution
need not be non-copyleft;
3. Debian has not determined it - we are not at that late a stage yet;
4. Debian is a distribution - probably the above meant the debian project.
[...]
> 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. Both bad technology
and bad law are required. 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.
> 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 overgeneralisations:
1. one particular problem with TPMs overruling all other arguments;
2. assuming that everywhere has the bad TPM laws of the US and EU.
I do not understand why applying a TPM is necessarily illegal or
difficult.
> 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?
[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.
(I have experience of applying TPMs and of creating binaries from source.)
> [...] 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.
> 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? ;-)
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. Bob is still free to modify A and distribute A''
under the same licence. Bob can't distribute to Dave's platform,
but Dave has a platform monopoly whether or not d[A] exists. d[A]
cannot reverse that, but in the best case, the availability of A for
some d[A] may motivate Bob to escape Dave's control.
What would be the alternative situation? Sam releases A but forbids
creation of d[A], so steps 2-6 never happen, or Sam demands money before
d[A] is produced and there'll be no requirement to give A to Bob, so A''
will never be created. I don't see the upside for the free software
community in either of those. If Dave wants to highlight the problems
caused by his control and motivate people to escape, let's not stop him
doing that!
As clearly described above, d[] is the real problem, not A or d[A].
Attacking d[A] for all A is impossible, as there will always be some
A whose creator allows d[A]. So, the best tactic is to attack d[].
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.)
> 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.
[...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.
> 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 true?
> [...] 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?
[...]
> 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?
> [...] 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.
> 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.
> [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.
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.
In general, I feel that TPM should be addressed by requiring distributors
to meet requirements which exclude unreasonable negative acts.
The argument put forward by Terry Hancock seems to be dominated by
apparently-incorrect claims about DD past actions, one example which
involves an admittedly-disturbing compromise, and some claims that
certain things are not TPMs or are illegal. The lack of references for
the claims and assertions makes discussion rather difficult, which is
the same problem as on cc-licenses. I hope that some of the questions
above will be answered and discussion can start.
Hope that explains,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: