Re: Why TPM+Parallel Distribution is non-free
Francesco Poli wrote:
On Sun, 08 Oct 2006 21:45:46 -0500 Terry Hancock wrote:
> 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)?
Am I asserting that if $LONG_SENTENCE, then what? I'm not sure I
understand your question, since something seems to be missing in
it... :-/
Yes, you're right. Obviously, I was asking that if this were true, "...
you would claim the license were DFSG free".
I would agree with you in that case, but I would also claim that such
agreement implies the existing license is DFSG free (because there is no
difference in principle between them. Both restrict certain platforms in
exactly the same way -- they do not allow distribution of works already
encrypted to work only on that platform).
> 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?
AFAICT, the objection is that an anti-TPM clause (such that it
forbids any TPM in any case) forbids porting to some platforms.
I would agree with you in the case that all application of TPM is
forbidden, but as I've mentioned, that change is already conceded. The
end user can apply TPM if needed. In the case of interest (the TPM key
is publically available), this already provides the user with the
freedoms you ask for (he is certainly able to use the content on that
platform).
In the case that the key is not available, your alternative wording
continues to restrict the users ability to use the platform.
But of course, that is not the license, the license-writer, or the
licensor's fault. It is a decision made by the owner of the platform.
> I
think that no such porting should be disallowed, as long as it can be
done without denying recipients the ability to exercise the rights
granted by the license.
But one of the rights granted by the license is to produce modified
works that can also be used by the user on ANY platform, including the
one he's currently using. Certainly if the platform is common enough
for it to matter that use on it is unrestricted, then it's common enough
for a restriction against making works for it to also matter?
It seems paradoxical to me that Debian should take such pains to allow
free works to be ported to restricted platforms, "because of freedom",
but then to dismiss the loss of freedom that results from doing so.
Likewise, a clause that forbade porting the work to Windows systems
would be considered non-free.
Then the GPL is "non-free" if Microsoft decides to implement a system to
scan the package file and refuse to unpack, install, or run the file if
it finds a copy of the GPL license in it. (Strictly speaking, I think
it would have to look for the GPL notices that must be retained in the
binary -- harder to implement, but the same in principle).
> 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.
I am well aware of this. Just as the presence of a third-party
software patent that covers a piece of software is not under control
of its author.
Again, you are inconsistent.
If *this* is not non-free, then neither is the existing anti-TPM
distribution clause. Both restrict distribution of files in a format
that can only be read on a certain platform.
If the key is publically available, then in practice, the user will have
exactly the same freedoms, because it's possible to encrypt files after
receiving them.
Note that in the "anti-GPL platform" example above, the end user can
remove the GPL license for the purpose of running a program (*use*).
But he still has to include it when distributing the package
(*distribution*). Likewise, the existing CCPL3.0 terms require the file
to be distributed in a non-TPM'd format, but the end user may apply TPM
in order to play the content.
The anti-TPM clause in CCPL3.0 is a *distribution* requirement. It
places NO *use* requirements whatsoever. If a platform uses TPM to
prevent the work from running on it, and provides no means (e.g. a
publically available encryption key) to allow the work to be run on it,
there's nothing we should be required to do about it.
> 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.
The end-user freedom that is added (with respect to the no-TPM-ever
clause) is the ability of having the TPM applied by someone else (in
the cases where anybody can do that), rather than being compelled to
do it yourself.
Again, this argument can be used to defeat *any* distribution
requirement, including the ones in the GPL and BSD. You can always, in
principle, design a platform to discriminate against packages following
any distribution requirement you choose.
So long as the user is free to alter the package (possibly in a
completely automated way) and play on the platform, they have what I
would consider complete freedom of use. Likewise, one of the essential
freedoms: the ability to modify and use the work, is assured this way.
In a world where many users are scared to death at
the sole idea of installing a software package (that doesn't come
preinstalled with the computer they bought), I think that the
above-mentioned end-user freedom should not be seen as negligible...
Again, this is the false impression that is created by regarding the
application of TPM as something difficult, like compiling a binary. If
the end-user is so terrified that they won't even *install* software,
they aren't going to be using Debian, period.
Cheers,
Terry
--
Terry Hancock (hancock@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
Reply to: