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
evidence.
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
License
"""
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
overgeneralisations:
>
> 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
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?
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
source.)
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
true?
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.
Cheers,
Terry
--
Terry Hancock (hancock@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
Reply to: