Re: Why TPM+Parallel Distribution is non-free
Terry Hancock wrote:
> I have been a Debian user for several years now, an occasional free
> software developer, and a user of the Creative Commons By-SA license, so
> I have been following the effort to make the CCPL3.0 comply with the
> Debian Free Software Guidelines with some interest. I used to post here
> on debian-legal occasionally, and I've rejoined to discuss this issue.
> I am not a lawyer. 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).
>
> 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]
>
> 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]
>
> 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.
The point here is that parallel distribution obviates any need for the
recipient to reverse the TPM. If parallel distribution does not do that,
then it is not the sort of parallel distribution we are trying to
allow. :-)
> 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).
That is an important point which has not been brought up before. I'm not
sure how relevant it is though.
*Prohibiting applying a TPM system to a work* is something which can be done
by someone controlling the rights to use the TPM system, regardless of the
work. Nothing in the work's license can prevent this, ever.
It's difficult to put a copy of my favorite perl one-liner on the side of a
blimp. However, under a free license I am allowed to do so.
The fact that it will be very difficult for anyone to put their modified
version on the side of the blimp is rather irrelevant. The fact that I,
or anyone else, need special permission from the blimp owner to do so is
also irrelevant. Even if the blimp owner is evil and using the blimp for
his own nefarious purposes, the license for my one-liner would be non-free
if it prohibited distribution by means of blimp.
> 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).
This is why we want to be very specific. If a system is genuinely being
used to restrict the rights given to work's recipient, we want that to be
disallowed. If it is not actually restricting rights, we want it to be
allowed.
The CC-Scotland licenses were written to allow exactly that. The actual
current text of the proposed CC license is likewise fine, provided it's
interpreted straightforwardly.
> 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. This *technically identical* software is
> nevertheless *legally distinct*. We might call this a "Non Legal
> Technological Protection Measure" or NL-TPM system.
OK. This is exactly what we're looking to allow. So this is just a matter
of terminology.
> For such an NL-TPM, Debian's parallel distribution idea *might* apply
> (there is still a subtle problem, but it is much less severe), but this
> is not what "TPM" is under law. TPM is something that has the force of
> law backing it up. In the United States, this means that circumventing
> the TPM is a violation of the DMCA. Other countries are adopting similar
> rules, which is, of course, the basis for so much concern over TPM.
Right. Now, if I distribute a TPMed copy and an identical unTPMed copy,
*nobody ever needs to circumvent the TPM* in order to get to my work.
Voila -- the anti-circumvention law is irrelevant.
> 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. TPM, however, is
> always trivial to apply, provided the correct encryption keys are
> available. 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, 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.
No, that's not true. What if the compiler uses patented techniques to do
the compilation? This is a real example. The 'free compiler' will almost
always generate a *different* binary, in fact, albeit hopefully one which
behaves the same way.
> But with a "TPM compiler", that
> compiler is illegal to write (it's a "TPM circumvention device").
Actually, no, I don't think *adding* TPM to something is
ever 'circumvention'. I think you're just wrong here.
Now, there is a point buried here.
I think the following is the essence of your point:
The *work plus TPM-wrapper* is a derived work -- it is non-free
because the TPM wrapper is non-free and can't be generated in a free
manner. You are correct.
As you say below, the TPM-wrapper, or the encryption key, could be
considered part of the source of the combined work, and perhaps should be.
It still seems entirely analogous to a binary generated with a non-free
compiler.
> Now, having hopefully dispelled the myth that binary/source is analogous
> to TPM/non-TPM, 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).
>
> 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.
*This is your fundamental mistake.* Bob is free to modify and distribute
A''. Perhaps Bob will suddenly realize that it's better not to use
Dave's "Tivo" platform. :-) But the actual works A, A', and
A'' are free, and can be used on a competing platform.
It seems desirable to let Bob understand this. He can keep using
A, A', and A'', and *get rid of Dave's platform*.
> So Dave has secured a platform monopoly
Stop right there. Yes, Dave has secured a platform monopoly.
There are any number of different ways Dave can do this. He can require
that any purchaser of his platform sign an agreement that they will only run
Dave-approved software. If Dave approves GPL-licensed software, then
the purchaser can use the GPL-licensed software on Dave's locked platorm,
and there's nothing the GPL licensor can do about it. Recipients are always
allowed to sign away their own rights (but not those of other people). :-/
> on Alice's work. He is able to
> charge for it under monopoly terms exactly as if he were the copyright
> owner.
No. Only for use on his platform.
For a similar non-TPM example, consider the Windows runtime libraries.
Microsoft could, if they wanted to, license those under very restrictive
terms, so that anyone linking to them had to pay Microsoft. Linking to
them is *absolutely necessary* to make a Windows program. Therefore,
Microsoft would have created a platform monopoly. They would be able to
charge under monopoly terms for the privilege of letting Alice's work run
on their platform.
Indeed, some rather stupid companies have licensed their operating systems
or compiler runtimes under extremely restrictive terms such as these. I
recall compilers from the 1980s where you had to get the compiler
publisher's explicit permission to distribute any work compiled with it (and
yes, they would charge you money).
Now, indeed, the GPL purports to prohibit combination of GPLed works
with such runtimes. It's unclear whether this is legally possible.
> He is not required to distribute the work in a form that allows
> others to modify it and play it on his platform.
Only *on his platform*. He can do this in any of a dozen other ways
which have nothing to do with TPM. It's a non-free platform. These can be
made with or without TPM, as noted above.
He is required to distribute it in a form that allows others to modify it
and play it, *off* his platform.
> He has managed to
> effectively revoke the users' "freedom 1", making the work non-free.
No, he hasn't.
> 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. The GPLv3d2 attempts to rectify this problem by defining
> that key as part of the "corresponding source" for the work.
So is that an acceptable restriction? I think so, but I'm not 100% sure.
> 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.
Equivalent, yes....
> 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.
>
> 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.
Actually, it *is* less onerous in some cases, where Dave is not a monolithic
entity, and where the Dave releasing [A] is not a programmer.
So why not require that?
Let me summarize a recurring theme here:
* Prohibiting distribution of binaries: bad.
* Requiring distribution of source along with binaries: good.
We make a distinction between the two, and it's a very important one.
> 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.
This is in fact the key point. We agree that if the anti-TPM clause *only
applies to things which actually restrict the recipient's rights*, then it's
fine and dandy. If it applies to more than that, then it's not.
> So, in my opinion, the GPLv3d2 "Corresponding Source Key" clause is
> roughly equivalent (at least in effect)
Never ever say "roughly equivalent" with regard to legal text. Either
it's equivalent or it's not. :-)
Specifically, GPLv3 draft 2 says
"A key need not be included in cases where use of the work normally implies
the user already has the key and can read and copy it"
This is in fact one of the scenarios we are thinking of. The Playstation
and Xbox hackers are working in this situtation: they have keys to encrypt
the content for their own boxes. We want it to be possible to distribute
Playstation-encoded material to those people who could encode it themselves,
but might find it very tedious. How's that for a subtle point?
Now, reading the CCPL3.0, it appears to allow this. Reading the commentary
by the people who wrote CCPL3.0, it's not so clear, which is the problem.
> 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). 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.
>
> 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.
>
> 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.
*The clause as currently written is fine.* It *permits* parallel
distribution of the sort we want. The problem is quite explicitly
whether they really mean what they say or whether they don't.
Unfortunately, CC's mailing list doesn't accept posts from non-subscribers,
so I have been unable to tell them this. (I am not about to subscribe to
another mailing list -- I don't subscribe to any mailing lists, I only read
web archives or news gateways.)
> 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).
Nice.
> 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, because it
> will encourage exactly the kind of exploitation that Dave exhibits in
> the example above: it provides an incentive to exploit existing works
> commercially while removing any incentive to create (and for many, even
> the ability). It's a very wicked poison to the free/copyleft
> development community, and all the more deadly for its relative
> invisibility. Please don't let this happen over a such a basic
> misunderstanding!
>
> Anyway, that's my case both for accepting the CCPL3.0 w/o the parallel
> distribution clause,
If the CCPL3.0 is *read literally* to mean *exactly what it says*, I think
we should accept it. The crucial point really is that some things may
look like TPM, smell like TPM, quack like TPM, but not actually restrict the
recipient's rights. And those must be allowed.
More subtly, a free license should not and can not prohibit the user from
signing away *his own* rights (as opposed to the rights of third parties) by
using an evil platform. There's really no way we can prohibit all the ways
a user can sign away his own rights anyway. The best we can do is to
guarantee that when the user sees the light and leaves the cave of
proprietary platforms, the free software is there waiting for him to modify
it. :-)
The equivalent of prohibiting parallel distribution is requiring that a
source file *only* be compiled with a free compiler and *only* be linked
to free system libraries. Now, perhaps these would be free restrictions --
thinking about it, I can see that they might be, though I'm not sure. They
would be *stupid* restrictions, however. They would prevent the
people "inside the wall" from even having a glimpse of the free world
outside the wall.
> and also for generally considering the parallel
> distribution not to be required for "DFSG freedom". Thanks for reading.
And for the 'last word', I have to repeat that the clause in CCPL3 is *fine
as written*. If we have some assurance that it *means what it says
literally*, and that use of any system which *doesn't* restrict the rights
of the recipient is *not* affected by the clause no matter what it looks
like, then we're happy.
--
Nathanael Nerode <neroden@fastmail.fm>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
Reply to: