[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linux-aus] Fwd: Why TPM+Parallel Distribution is non-free
Below is Francesco Poli (a regular on debian-legal)'s reply to the mail.
On Fri, 06 Oct 2006 22:43:31 -0500 Terry Hancock wrote:
[...]
I apologize for the length of this
post, but it is summarizing the conclusions of quite a large
discussion (which I promised to the Debian folks who joined the
conversation there that I would provide here).
Thanks for the summary: I'm trying to catch up with cc-licenses web
archives, but it recently became very hard...
In the following I try to comment on your reasoning.
In a nutshell, I think that your analysis has some flaws and is based on
some misunderstandings.
I don't have a definite answer to the question about TPM'd/non-TPM'd
being more similar to object/source or rather (as has been claimed on
cc-licenses) to patented/unpatented: I think that it's closer to
object/source than you seem to think, but I acknowledge that the analogy
is not perfect (but which analogy is, after all?).
The usual disclaimers: IANAL, IANADD.
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, specifically item 3:
"""
*Derived Works*
The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software.
"""[1]
If you mean that allowing parallel distribution of TPM'd and non-TPM'd
versions fails to meet DFSG#3, then you're misreading the DFSG.
The DFSG constitute a set of minimum permissions that must be granted
for a work to be considered Free. Adding a permission cannot possibly
break DFSG-compliance. A license can be too restrictive and thus fail
to meet the DFSG, but no license can be too *permissive*.
On the other hand, if you instead mean that allowing parallel
distribution of TPM'd and non-TPM'd versions permits the creation (and
distribution) of non-free derived works, that could be true or untrue,
but that doesn't affect the DFSG-compliance of the license.
I interpret this to be an alternate wording of the same rule described
as "Freedom 1" of the Free Software Definition:
"""
The freedom to study how the program works, and adapt it to your needs
(freedom 1). Access to the source code is a precondition for this.
"""[2]
IMHO, DFSG#3 (maybe together with DFSG#2) is more equivalent to the
union of freedom 1 and freedom 3 of the FSD.
But we digress: this is irrelevant for the discussion at hand...
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.
This analogy has been cited multiple times in the discussion on
debian-legal, but I am not able to find much serious analysis of this
assumption. It is a seductive idea, and I have to admit that I was
sold on it myself for quite some time.
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". 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.
Please note that proprietary programs are often distributed in object
code form, under a contract (EULA) that forbids recipients to decompile,
disassembly, reverse engineer, ...
This is a legal barrier, as well as a technical impracticality (you
don't get the actual source code, when you decompile).
What I mean is that even the object to source reverse path is, in many
cases, legally forbidden, as well as technically difficult.
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).
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).
Are we sure?
The law speaks about TPM in order to specify what is illegal to
circumvent.
If the legal definition of TPM were "the measures that are illegal to
circumvent", we would have a circular (meaningless) definition.
We must have a different legal definition of TPM, before the law can say
that TPM cannot be circumvented...
For example, any "TPM" system licensed under the new GPLv3 (d2), will
not actually be a TPM in the legal sense, because the license
expressly declares that it is not.
I'm not convinced that something can magically become legally true, just
because a license expressly declares it.
Otherwise we could easily solve the software patent problem with a
single clause in Free Software licenses:
"No covered work infringes any patent under any patent law".
It would be great, but I don't think it would hold in court... :-(
[...]
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.
This is not always so true as you seem to think.
For instance, some systems are based on a high level of automation for
the compiling process (Gentoo Linux comes to mind).
TPM, however,
is always trivial to apply, provided the correct encryption keys are
available.
Always? I do not have experience in applying TPM, but I would be
surprised to learn that the process is *always* trivial.
What is trivial, anyway?
A single command? Two or three commands? Some ten commands to issue in
the correct order with appropriate text file editing?
Take into account that:
* downloading, compiling, and installing a package can be automated in
a single command (Gentoo Linux, again)
* for many people, even installing OpenOffice.org on their Windows box
is "too difficult" (try and tell them that applying TPM with these
encryption keys is trivial...)
It is only the secrecy of the keys and the laws protecting
their secrecy that interferes with the application of TPM to content.
Because of this, having to apply your own TPM is hardly a burden -- in
fact the process can be automated to the point where you would not
even realize that it is being done (e.g. it could be part of a
download client).
Once again, you could consider Gentoo's portage/emerge as a download
client with compiling functionality...
On the other hand, in a proprietary OS binaries could be required to be
signed by a vendor's secret key in order to be run. This could forbid
running your own modified version of a Free program on the same
platform. And the circumvention of this mechanism could be claimed to
be illegal (probably because of laws such as DMCA/EUCD/...).
Once again, the issue is *not* technical, but
legal: you may be required to agree to (non-free) terms to apply the
TPM to content. This effectively never happens with binaries: even
if sources are designed to be compiled with a proprietary compiler,
it is always legal to write a new compiler which does the same job.
As I said above, you can write a new compiler, but the platform could
still refuse to let you use the compiler's output, unless it's properly
signed...
But with a "TPM compiler", that compiler is illegal to write (it's a
"TPM circumvention device").
Now, having hopefully dispelled the myth that binary/source is
analogous to TPM/non-TPM,
I think that this analogy, though not perfect, still has some merits.
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).
OK, but, at that point, Dave must also provide A'.
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.
Wait, Bob can still create and distribute A'' and use it on other
platforms.
But I acknowledge that Bob is prevented from creating d[A''] in order to
make use of A'' on Dave's platform.
That could be seen as a weakening of the copyleft mechanism that
CC-by-sa aims to implement, but it's not a freeness issue, per se.
IMO, though, preventing any TPM to be applied to A is not the right
strategy to address this issue. It's like throwing away the baby along
with the bathwater.
Maybe a good strategy could be requiring the distribution of the
encryption keys that are needed to apply TPM to A'' (unless they are
already generally available).
That would be an approach similar to the GPLv3draft2 definition of
Source Code (see Section 1.).
That way, parallel distribution of TPM'd and non-TPM'd version could be
allowed, but only as long as any recipient is able to re-apply TPM to
his/her own modified version of the work.
So Dave has secured a platform monopoly on Alice's work. He is able to
charge for it under monopoly terms exactly as if he were the copyright
owner. He is not required to distribute the work in a form that allows
others to modify it and play it on his platform. He has managed to
effectively revoke the users' "freedom 1", making the work non-free.
Not exactly, he would become the only provider of versions of the work
that are usable on his platform, but any recipient could still modify
and distribute the enuncumbered versions.
Now, if you pay close attention, you can also see that this is
basically identical to the problem of "tivo-ization": we need a
special key, which has been withheld, in order to exercise our
freedom to modify and distribute.
Yes, it's seems to be quite similar to the "tivo-ization".
The GPLv3d2 attempts to rectify
this problem by defining that key as part of the "corresponding
source" for the work.
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'm surprised that nobody seems to have suggested this approach for
Creative Commons too, before.
But note that this is (from Dave's point of view) no
more difficult than making his platform run non-TPM'd works. In
fact, one way to implement that is to make a TPM-key-wrapper a part
of his platform.
This is not the same, IMHO.
At least from a technical point of view: a player that supports a single
format is simpler/lighter than a multiformat one.
It could also have different impact on what users can or cannot do with
"All Rights Reserved" works, even though I cannot focus this better,
right now...
So, if Dave wanted to create a TPM-only platform in the first place,
he's not going to release the encryption key. Requiring him to do so
is no less onerous than just asking him to let non-TPM works play on
his platform.
As I said, I'm not sure...
Furthermore, if such a key is published, Bob may use the published key
to TPM his own private copy of A'', and so may all users who receive
A''. 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.
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, in my opinion, the GPLv3d2 "Corresponding Source Key" clause is
roughly equivalent (at least in effect) to the CCPL3.0 "anti-TPM"
clause, because it is a key necessary to view the content on the
platform. IOW, if you were to release the same content under the
GPLv3d2, the same results would happen: Dave would be barred from
publishing the work on his TPM-only platform, unless he pubishes the
TPM key (which then makes it no longer a TPM-only platform).
IMHO, they are two very different clauses.
Now, of
course, Debian hasn't approved GPLv3d2 either, but I think it's
relevant that the Free Software Foundation and the Creative Commons
have both come to the same terms on this issue: TPM used to make it
impossible to play a derivative work on a platform is a violation of
users' freedom.
They are not the same terms.
The goals could be seen as similar (even though I cannot read minds, and
consequently cannot comment on unexplained goals: I'm still wondering
which are the actual goals of Creative Commons, and, to a lesser extent,
which are the ones of the FSF...), but the clauses are really different
and have different effects (remember that we must take collateral
damage, as well as primary effects, into account!).
In any case, it's pretty clear to me that it would be inconsistent to
recognize GPLv3, but not CCPL3 on this point, since they are actually
effectively making the same requirement.
They are not, IMO.
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. It was a nice thought that that
should be so -- but it doesn't hold up to close scrutiny. There
really is a difference, and for free-licensed cultural content, the
CCPL3.0's anti-TPM distribution clause is the only practical
solution.
IMO, it's not a solution. So, I hope there are other strategies,
because banning TPM causes collateral damage that makes the works
non-free.
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. There is a
strong feeling that fair use already permits this, and that the
existing wording already makes this true accross jurisdictions, but
that it should indeed be made more explicit (this is my understanding
from Mia Garlick's responses to the list commentary).
This would be an improvement, but I have yet to see the new clause
phrasing, before I can comment.
As a Debian user, I am furthermore concerned that continuing to push
for a TPM+parallel distribution clause will damage the freedom of the
Debian distribution and free software / free culture in general,
It cannot harm freedom.
Likewise, a non-copyleft license cannot harm freedom (as long as it
meets the DFSG).
Allowing parallel distribution could harm copyleft, or maybe not.
*Not* allowing parallel distribution could harm freedom, or maybe not.
These are the points to be discussed, really.
[...]
Anyway, that's my case both for accepting the CCPL3.0 w/o the parallel
distribution clause, and also for generally considering the parallel
distribution not to be required for "DFSG freedom". Thanks for
reading.
Thanks for writing.
On 10/8/06, Janet Hawtin <lucychili@gmail.com> wrote:
Hello folks
Karl sent me on this post on a debian list which I thought you might
be interested in as it has a good nuts and bolts look at TPM/DRM.
Thanks Terry and Karl
Janet
--
Andrew Donnellan
-- Email - ajdlinuxATgmailDOTcom (primary)
-- Email - ajdlinuxATexemailDOTcomDOTau (secure)
http://andrewdonnellan.com
http://ajdlinux.wordpress.com
Jabber - ajdlinux@jabber.org.au
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
-------------------------------
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net