Re: Why TPM+Parallel Distribution is non-free
Don Armstrong wrote:
NB: please avoid needlessly embolding words: it only heatens
discussions that are better discussed calmly.[1]
I've emboldened key words that are important not to misunderstand. This
seems to be very important as responses to several of my posts indicate
that these words were overlooked. It's very frustrating to have to
repeat the same points over and over again, because some people don't
apparently read them before replying.
I can appreciate of course, that Debian legal folk, having discussed
this already, and having amongst themselves already reached a consensus,
find it difficult to have to revisit the same question. But that's
something that will naturally happen when you bring in new people with a
fresh point of view on the problem.
Heat is not intended, however.
At least not usually. Nobody's perfect. ;-)
On the other hand, some of the responses on this list have been very
rude, which does make it difficult to have an intelligent conversation.
I don't find that hurling insults or airing conspiracy theories is
particularly helpful.
However, in respect for your request, I've eliminated all stylistic
emphasis from this post. IMHO, this makes it harder to read, but I
trust you are prepared to make the extra effort.
On Wed, 11 Oct 2006, Terry Hancock wrote:
> Don Armstrong wrote:
>> On Tue, 10 Oct 2006, Terry Hancock wrote:
>>
>>> Prohibiting TPM *distribution* is fine under DFSG.
>>
>> No, it's not. Prohibiting TPM distribution is quite clearly a
>> restriction on a field of endeavor.
>
> Since distribution is always a use, then *any* distribution
> requirement is a use restriction in the broadest sense of the term.
>
>
> Thus, by this logic, GPL, LGPL, and even BSD are "restrictions on a
> field of endeavor".
This is a classical misunderstanding, unfortunatly. What the GPL does
(and other similar copyleft licenses do) is make requirements on
what you must distribute (or otherwise provide). This may indirectly
restrict fields of endeavor because they are no longer profitable or
useful, but it doesn't directly restrict them. [It may seem like
splitting hairs, but it's an important distinction.]
Which was the point of what I just said.
Both GPL and CCPL make distribution requirements. There are no use
requirements in either. Yet it is repeated over and over again that the
anti-TPM distribution rule in CCPL3 is a use restriction.
CCPL3 makes this point more clear, although I have it on authority from
official CC folks that this was true before. I admit I have not
carefully re-read v2.5 to check this claim. But I have very carefully
read the 8/9 draft of v3 to make sure that it is currently true, and it is.
Hence if GPL is free, CCPL should be also. The "use" restrictions being
objected to are in fact distribution requirements.
> 1) TPM-distribution is allowed, so long as there is a parallel
> distribution of an equal or better version of the work without TPM,
> and there is a publically available key and encryption tool for
> converting the non-TPM work to TPM in order to play on the platform
If I'm parsing you correctly, this would be appropriate; it's
basically what the GPLv3 is trying to go for.
I can understand that this kind of arrangement might be accepted as DFSG
free, but not that it should be required for it. It has a fundamental
flaw, as I have already shown:
http://lists.debian.org/debian-legal/2006/10/msg00113.html
In brief: A hard to apply TPM is a barrier to end user freedoms, just as
is one without a publically available key or a tool to apply it.
> If it's #1, then there is only one practical concern, which is
> where the application of TPM occurs.
>
> In that case, I would argue that it needs to happen at the
> end-user, because that's the only way to truly prove both that the
> non-TPM work is "equal or better" than the TPM work, AND it's the
> only way to prove that the keys and encryption tools are available.
This is the very same reasoning could be applied to compiled works;
the counter arguments are the same reasons why important that we be
able to distribute binary works. It may not be practicable for every
end user to have the equipment to apply the TPM, or it may not be
legal for them to posses the TPM circumventing devices.
(Once again, here's the binary/source to TPM/non-TPM analogy that MJ Ray
insists isn't being used to support parallel distribution... being used
to support parallel distribution!)
The reason why it's so crucial to release binary distributions of
programs is simply that binary compilation is an intrinsically complex
process. Because there are multiple variables (differing hardware,
differing operating systems, differing drivers, etc), it is impossible
to make compilation completely foolproof. In fact, to be precise, it
isn't really "compilation" that is a problem, but rather "linking".
Compiling "bytecode" for Perl or Python, for example, is routinely done
on the users' machine, even in so-called binary installations.
This is why it's a problem to leave it to end users.
This is simply not the case for TPM. TPM is an encryption. A mapping
from data to data, that includes no special dependencies other than on
keys. The TPM provider could, in principle, make TPM depend on hardware
characteristics of the device, or involve some other complexity simply
to make the process difficult, but there is no intrinsic reason for it.
If he's made it hard, it's because it is his objective to make it hard.
This can be viewed as another kind of TPM -- one designed specifically
to block competition from free software, and deny end users their rights
of modification, use, and redistribution. Such a TPM barrier should be
regarded as rendering the work non-free.
To use a better analogy...
Binary compilation is like building a door, TPM is like locking it. A
locksmith could, in principle, make a lock hard to use, but it's
pointless and unnecessary to do so. More to the point, doing so is
malicious. Not so, with regard to building a door: there are many
engineering constraints -- it may not be possible to make the door easy
to make without interfering with its function.
or another analogy...
Building a software distribution from source is analogous to building a
car from a kit (very few people are willing to do that). Applying TPM
during the loading process of a piece of content is like being expected
to be able to unlock and turn the ignition on a car after buying it.
Of course, it may happen that the process of applying the TPM has been
obfuscated on purpose. Or it might even be an accident. But this is
equivalent to hiding or obfuscating source code, or to having a binary
package that has not yet been successfully built from the provided
source. Either condition is considered DFSG non-free.
Thus, I would assert that a work which has these obstacles interfering
with the end user's freedoms to modify, use, and redistribute the
modified work, has had its copyleft effectively nullified. Since
retaining copyleft is considered a "free" practice, then this
distribution constraint should be a completely reasonable requirement.
>> The critical aspect here is that parallel distribution does not
>> cause the rights of a recipient of the work to be restricted;
>> they retain all abilities that they had originally and gain
>> additional ones (namely, being able to run the work on a
>> TPM-inflicted device.)
>
> No. They already have that freedom in CCPL3.0. Problem solved.
I'm unable to follow this line of reasoning.
Okay, but what part did you not understand? The objection was that the
user must have the right to play a work on a TPM-only platform. Clearly
CCPL3.0 gives him that right: he may apply TPM to the work to play it.
>> There are two choices: You either 1) allow parallel distribution
>> 2) require distribution of keys or information needed to deploy
>> modified versions to the device.
>
> CCPL3.0 chooses #2. The end user loads the TPM'd content onto the
> device, applying the TPM at that point.
You appear to be arguing that it requires a third state, that DRMed
content cannot be distributed, and that the transformation to a TPM
format must occur in by action of the end user.
No, that's #2. The user must have access to the keys and tools to apply
TPM to the work.
It has been objected that the user may not be capable of applying the
TPM, even given these tools. This seems ludicrous to me, because the
act of downloading the file to the device is surely just as difficult if
not more so.
If the TPM is harder than that to apply, then it is a barrier to the
end-user's freedoms. Hence the TPM renders the work non-free anyway (the
user's rights to modify and use have been abrogated by technological
measures). So, the "freedom or death" rule applies: the work can't be
distributed if it can't be distributed with freedoms intact.
The rule of applying TPM at the end user solves this nicely, because if
the TPM application process is simple enough for the end user to play
the content, it's simple enough to protect his freedoms in the work.
The freedom or death principle is applied automatically, with no need to
enforce fuzzy "ease of use" rules regarding the TPM application.
This is more important for content than for programs, because while it
can be accepted that a programmer is a "computer expert", and therefore
won't be effectively restrained by difficult build or TPM processes, the
would-be content re-mixer is very likely not a "computer expert" (she
might be an "art expert" or a "literature expert" or some other kind of
expert, but computer science may be very difficult for her). Thus even a
TPM that a Debian developer would not consider difficult might be enough
to be considered an effective restraint on this user, and therefore be
considered to violate the copyleft on the work.
Thus, tying the ease of use for distribution to the ease of use for
modification and redistribution is a much more elegant solution. I
admit this may be more important for content than for programs. But
then, content is what the CCPL3 is specifically designed for.
>> If you're seriously interested in discussing how to do copylefted
>> TPM and DRM properly, I strongly suggest reading my position
>> statement from committee D on the first discussion draft of the
>> GPL
>
> URL please?
http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/drm_allowing_authentication/
! LaTeX Error: File `../gplv3_latex_functions.tex' not found.
;-)
What I get from reading the source, however, is that this document shows
in great detail why the kind of exception that parallel distribution
would require is far too complicated, and riddled with loopholes. Most
of the issues you are dealing with in that document are completely
sidestepped by requiring TPM to occur with the end user. All that
business about who gets keys, etc, just evaporates.
Now, of course, that does raise some good objections to using CC-By-SA
for programs. But it is expressly not intended for programs, so that's
not a problem.
Cheers,
Terry
--
Terry Hancock (hancock@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
Reply to: