Re: Why TPM+Parallel Distribution is non-free
Terry Hancock <hancock@anansispaceworks.com> wrote:
> 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.
Apologies for misreading that. Please try to keep phrases simple,
to help people with language troubles.
Why is it a problem to permit violation of the DFSG? Some licences that
follow the DFSG also permit other violations, but works which actually
violate them are not welcome.
> 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.
Since when has CC-By been a copyleft anyway?
[...]
> Prohibiting TPM *distribution* is fine under DFSG. [...]
No, prohibiting *all* TPM distribution is still not fine.
> > 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.
It is true. Also, allowing TPM distribution while prohibiting a
platform-owner to obstruct redistribution of the work would not
allow 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. [...]
Prove it. Claiming telepathy is not credible. I was active on this
list in 2003 and I'm pretty sure I wasn't thinking of it then.
> > 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.
However, blanket anti-TPM is not the only way to preserve that freedom
and arguing about copyleft does little to argue for why it's in CC-By.
> 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).
I don't see why you not having the tools to target platform A stops the
work being considered as free software. Free software licences don't
stop you targetting platform A - CC 3.0draft would.
What is the definition of "real copyleft"? Is it different from the
"fake" copyleft described in http://www.gnu.org/licenses/licenses.html
which apparently doesn't insist you can do that?
[...]
> > 1. one particular problem with TPMs overruling all other arguments;
>
> It's not so much "one particular problem" as it is "THE problem".
Really? Fantastic! So prohibit "THE problem" instead of
carpet-bombing whole fields of endeavour.
> The entire purpose of TPMs is to preserve monopolies.
I thought the entire purpose of copyright was to grant monopolies,
even if that's not what we use it for today. I wonder whether
TPMs will be subject to such legal judo in future.
> This case merely
> exposes how parallel distribution is inadequate to preserve end-user
> freedoms.
The case looks at it backwards: we need terms which are *adequate*
to *ensure* end-user freedoms. In the example, the freedom is
restricted by monopoly control of d[], not the licence of any A.
[...]
> > > 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.
What is this based on? When I suggested adding "effect or intent" to
the prohibition, I was told that it was a peculiarity of UK TPM law.
> To be precise, of course, the CCPL makes it quite clear that it is
> solely restriction of the end user that is not allowed.
So how does it not allow parallel distribution?
[...]
> > 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.
It is possible that d[A] still exists for some A, which means that
attacking d[A] for all A is impossible: agreed?
> 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.
That is irrelevant here, as we consider licences not specific to
debian. If Sam has granted a general public permission allowing
d[A] for all d[], then we can put A in debian, but it sucks if
no such permission is included in CC 3.0.
If you're suggesting that we should pay for general public
permission for d[A] for all A, then I disagree about that use of
funds donated for debian.
> 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.
The platform monopoly is independent of the works on the platform.
DRM Dave has a platform monopoly even with *no* works on it (and
sometimes that can be commercially advantageous). This independent
problem should be tackled independently of free software licensing.
Donationware often tackles injustices, but usually does not follow
DFSG either.
> 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.
s/key/info/ ; s/encryption// ; # fine, but that isn't CC 3.0 draft AIUI
[...]
> > > 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.
Rather, we should require monopoly distributors to platforms to perform
certain tasks to enable non-termination, free redistribution, derived
works and so on. We shouldn't care whether TPM is involved.
> 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?
They may or may not be and even if they are generally practically the
same today, it might not always be so.
> > > [...] 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.
Sorry for the misphrasing, but can you answer the question? If "in fact
the TPM is no longer a TPM once the key has been published" then why is
DVD-CSS still considered a TPM, AFAICT? Or can Debian distribute the
DeCSS library legally?
> [...] 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.
I don't think it's any more polite to use an unsupported claim to assert
they applied insufficient critical thinking and accepted a wrong idea.
It would be more polite to show errors in the stated reasons, rather than
making insulting suggestions about what you claim were their thoughts.
> > > 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.
It has vital differences, due to its simplistic broad-brush approach.
Sadly, the treaty-based language of the generic CC is never going to
be the simplest to understand.
[...]
> > 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.
s/for which a public encryption key exists/for which all users are
permitted to add such restrictions/
If this "makes no material difference" to you, but would convince the
objectors, why not support it?
Maybe it looks identical to you because you are not looking at the
differences, dismissing them as generally and practically immaterial.
> 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.
I'm not sure that general public disclosure is necessary, but I could be
wrong.
[...]
> > 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?
I'm saying the argument cannot show the conclusion to be correct,
because it seems to be based on a false assumption.
[...]
> > 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?
Primarily:
- "TPM is no longer a TPM once the key has been published"
- "TPM is a matter of intent"
- That TPM-parallel meeting the DFSG "is based on the FALSE
idea that binary/source distribution is analogous to TPM/non-TPM
distribution".
AFAICT, at best, the above have been supported by name-drop. At
worst, not at all and research suggests the opposite.
> 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.
As I note in http://mjr.towers.org.uk/blog/2006/debian.html#notconsult
CCPL3.0 is buried in a PDF in a list archive, while GPLv3 is on a web
site that doesn't follow the web content accessibility guidelines,
so not all data about its current state is visible to all.
The DFSG are at http://www.debian.org/social_contract#guidelines - if
only everything was as easy to read.
> The logic is all pretty obvious.
The only part of your logic I object to is when "TPM can cause problem
X" leads to the conclusion "prohibit TPM" instead of "prohibit X".
--*--
Minor points moved from above:
[...]
> > 4. Debian is a distribution - probably the above
> > meant the debian project.
>
> That's called "synecdoche".
Not in my dictionary, so I looked it up in WordNet:
synecdoche
n : substituting a more inclusive term for a less inclusive one
or vice versa
Neither the project nor debian includes the other...
[...]
> > > 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. [...]
I welcome this acknowledgement that it requires both.
> Consider DeCSS. The technology was overcome quickly, but Debian still
> can't distribute the resulting library for legal reasons.
I know the project chooses not to, but why can't we?
> > 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. [...]
Thank you. I think it is significant and should be addressed.
> > [...] 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.
TPMs can be such a pain to apply, because the application tool is
necessarily a closed unit and so there is a combinatorial explosion
of dependencies on other pieces of software and the hardware used to
apply them. As a result, the environment the applier has is almost never
exactly the one the platform owner uses, and the application process
is stressed by all of the changes. (Ever rewired your hardware so an
application tool can read its key generator?)
[...]
> > (I have experience of applying TPMs and of creating binaries from
> > source.)
>
> Please demonstrate a case of TPM which is necessarily complex to apply.
Why should I do that? I claim that both can be as simple! Neither
are necessarily complex, but often are.
[...]
> > 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.
Users can't obtain copies of A for use on the platform in many cases,
as A does not allow distributors to supply such copies.
[...]
> > 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.
ACK. Sorry for discussing ancient history. The alternative situation
remains unchanged.
[...]
> > > 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.
Not all devices can be patched after release. I feel that wasting
such a lot of electronic equipment is unethical.
Regards,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: