Re: Why TPM+Parallel Distribution is non-free
Hi. Not that I'm necessarily conceding other points, but the one below
is the most interesting one...
Francesco Poli wrote:
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, are you asserting that if the CCPL3.0 included an allowance to
distribute TPM'd files, so long as the key necessary to apply TPM to
modified works based on the non-TPM'd version were publically available
(or always available as part of the non-TPM'd distribution)?
If so, I'm not sure you're wrong, but you are being inconsistent.
What is the basis for Debian's objection to the anti-TPM clause? Isn't
it that it is considered to be "discriminatory" against "person or
fields of use" because it (supposedly [1]) discriminates against users
of TPM systems?
But if that's true, then your modification doesn't change things. It
still restricts distribution in TPM form for platforms for which the TPM
encryption key is *not* publically available.
And of course, as we've shown, the TPM-only platform owner *does* have
motivation to keep this key secret, because doing so protects his monopoly.
You see, I think the thing you might be missing here is that the creator
of the work has no control over whether the TPM key might or might not
be available: it is a property of the platform, just like the platform
being TPM-only. Only the TPM-only platform owner has this right or
ability. And he therefore has the ability to make non-TPM works work on
his platform (at worst, he must provide the ability to apply the TPM in
the download process to the platform).
The key freedom that we need here is NOT the freedom to distribute TPM'd
files, but the ability for the user to apply TPM to his own files in the
process of loading them (CC believes this has always been the case due
to 'fair use'/'fair dealing', but is planning to clarify the point in
the next draft). This gives him the freedom to play free content on a
TPM platform -- so long as the TPM encryption software and key are made
available. And if they're not, then the platform has expressly made
itself non-free, and there's nothing we can do about that.[2]
So the point is, no end-user freedom is gained by your proposal: either
proposal allows the end user to install content on TPM-only platforms
for which a TPM encryption key is publically available and denies it on
platforms for which it is not. In fact, the only thing it gains is
increased complexity of the license.
Cheers,
Terry
[1] I say "supposedly" because the CCPL3.0 anti-TPM requirement is a
*distribution requirement*, it's not a use restriction.
[2] We can't escape this possibility in general: Consider a platform
that scans for GPL license notices in code and refuses to run them if
they are found. Retaining the notices is a requirement of the GPL, but
doing so would render the programs unrunnable on this hypothetical
platform. In a sense, this is exactly what a TPM-only platform is doing
(except that it's easier to implement). A platform designer can always
find a way to restrict use based on form of distribution, and the only
defense we have on that is the defense used in the GPLv2: if you can't
meet the distribution requirements, you just can't distribute it.
--
Terry Hancock (hancock@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
Reply to: