[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why TPM+Parallel Distribution is non-free



MJ Ray wrote:
 Since when has CC-By been a copyleft anyway?

CC-By is a separate issue and whether it is or is not a "copyleft" isn't relevant. The terms in question ARE DFSG free, as they exist in CCPL3.0, for By and By-SA.

FWIW, Mia Garlick notes that, unlike copyright, TPMs are not limited by "fair use" or "fair dealing". Thus TPMs have the capacity to render a work even less free than "all rights reserved".

The platform monopoly issue creates a problem for the original work, as well as derivatives, so it is still a problem for CC-By licensors.

More importantly, from my PoV, the provision *is* DFSG free, so it doesn't matter.

> Not only is this untrue, but it is in fact reversed. Allowing TPM
> distribution allows a platform-owner to obstruct redistribution of
> the work.

 It is true. Also, allowing TPM distribution while prohibiting a
 platform-owner to obstruct redistribution of the work would not allow
 a platform-owner to obstruct redistribution of the work.

Now, who's using the confusing phrasing? ;-)

TPM is such an obstruction. Hence "allowing TPM distribution while prohibiting a platform-owner from obstructing redistribution of the work" is contradictory.

>> the restrictions of a licence that permits parallel distribution
>> need not be non-copyleft;
>
> The anti-TPM clause is part of the copyleft. It is essential to
> preserve the freedom of the work, hence it is essential to
> copyleft.

 However, blanket anti-TPM is not the only way to preserve that
 freedom and arguing about copyleft does little to argue for why it's
 in CC-By.

There is no "blanket anti-TPM". There is a requirement that distribution not occur in TPM'd form. All free licenses have some kind of distribution requirement. Many (including the GPL) make requirements about the form of distribution of derivatives (e.g. "you must include the license").

I've already pointed out that it is technically possible to design a TPM that triggers on the presence of GPL license statements, thus rendering the GPL non-free by your argument. But of course, that's only because your argument is wrong: both the GPL and the CC-By-SA are free because the user has the freedom to remove these obstructions in order to use the work.

BTW, this is NOT a new freedom of the CC-By-SA, as you keep suggesting. The wording has been improved, but CC-By-SA 2.5 provided this freedom as well (and it may go back further). Mia Garlick addresses this point in #6 of her "responses" document:

http://lists.ibiblio.org/pipermail/cc-licenses/attachments/20060908/da9db6a3/attachment-0001.pdf


>> 1. one particular problem with TPMs overruling all other
>> arguments;
>
> It's not so much "one particular problem" as it is "THE problem".

 Really? Fantastic! So prohibit "THE problem" instead of
 carpet-bombing whole fields of endeavour.

The only "field of endeavour" being restricted is the same one that ALL free licenses restrict: namely, the process of distribution. As with ALL free licenses, requirements are set on the form and methods of distribution.

> The entire purpose of TPMs is to preserve monopolies.

 I thought the entire purpose of copyright was to grant monopolies,
 even if that's not what we use it for today. I wonder whether TPMs
 will be subject to such legal judo in future.

No clue what you're getting at here, MJR. We both know that TPMs were invented because their users thought that copyrights were too difficult to enforce by legal means. They have since used them to extend their monopolies beyond what copyright allows.

That's why TPM is fundamentally antithetical to free culture and software.

> To be precise, of course, the CCPL makes it quite clear that it is
> solely restriction of the end user that is not allowed.

 So how does it not allow parallel distribution?

Because parallel distribution, by which I take you to mean "allowing TPM-locked distribution so long as an unlocked version is available" does not alleviate the restriction to the end-users freedom that the TPM-locked version applies. It's a "band-aid for a corpse", a solution that doesn't solve.

What you are trying to do seems all backwards to me -- trying to allow a particular kind of restriction of end-user freedoms, and then trying to patch it up afterwards by adding lots of fiddly clauses to the license.

>> Attacking d[A] for all A is impossible, as there will always be
>> some A whose creator allows d[A].
>
> That is still possible with the existing wording.

 It is possible that d[A] still exists for some A, which means that
 attacking d[A] for all A is impossible: agreed?

This is silly. There will always be works committed to the public domain, or licensed under BSD, or whatever. So what? We're interested in the fate of a particular work under a particular license. In that context, there is no question of the problem you're suggesting.

> In fact, it's possible that Dave may pay Sam for the right to
> distribute d[A]. He always has that option, no matter what the
> free license is.

 That is irrelevant here, as we consider licences not specific to
 debian. If Sam has granted a general public permission allowing d[A]
 for all d[], then we can put A in debian, but it sucks if no such
 permission is included in CC 3.0.

 If you're suggesting that we should pay for general public permission
 for d[A] for all A, then I disagree about that use of funds donated
 for debian.

No. In fact, this is an argument against a use case I have described elsewhere. The only reason I continue to bring it up, is that it's the only case where CCPL3.0 doesn't already provide you what you've asked for.

It was suggested that not allowing TPM distribution was a problem specifically in the case where TPM keys or tools are available, but only for a price, as argued by Philip Hands, here:

http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004218.html

It's easy to see from this example that a monopoly platform owner can easily use his control over the TPM tools and keys to control who has the ability to create packages for his platform. That, IMHO, is decidedly non-free.

However, I'm not religious about it. IMHO, Sam is entitled to *sell* that monopoly over d[A] to Dave, much as Troll Tech sells the right to link its GPL'd libraries to non-GPL'd works.

My point is that once you start talking about keys only available for sale, then you're out of the territory of free-licenses anyway. In Hands' example, the desired privilege can be purchased, no matter what the license is. There's no special reason why we should allow the (unfair) situation in which all of such funds go to the platform owner, and none to the creator (so long as funds are being paid anyway).

So far, though, this is the ONLY use case I've seen for which the existing CCPL3.0 doesn't work (and that's probably a good thing).

I'm happy to consider another example if you have one.

So far, however, all other cases work equally well whether the TPM is applied by a distributor or by the end user. Thus the CCPL3.0's insistence on it occuring at the end user is not a problem. The only case in which it restricts is a case in which the TPM key (or the tool to use it) is not available to the end user.

But a freely available key is precisely what you need to require for TPM parallel distribution, so there's no practical difference (except that the CCPL3.0 is more effective and simpler). This is why I say there's no material difference: from the position of end user freedoms and platform availability, both are the same.

> Parallel distribution gives DRM Dave the right to a platform
> monopoly on A without even paying the author for the privilege of
> doing so. Under normal copyright terms Dave would have to ask
> permission and pay for each work he wants to sell. Preserving this
> economic environment is what his use of TPM is all about.

 The platform monopoly is independent of the works on the platform.
 DRM Dave has a platform monopoly even with *no* works on it (and
 sometimes that can be commercially advantageous). This independent
 problem should be tackled independently of free software licensing.
 Donationware often tackles injustices, but usually does not follow
 DFSG either.

I'm not following you. When I say that Dave has a "platform monopoly", I don't mean he has a monopoly on selling the platform (though he has that too), I mean he has a monopoly on selling a work A in a form that is compatible for that platform. I.e., he has a monopoly on d[A], which is the only form in which users of his platform can use A. In other words, he maintains a monopoly over the market of users on that platform.

If that's not important for considering the freedom of the work, then we can go back one step, and remark that it isn't important to provide works to that platform in the first place. Either support for the free work A (and A') is important on the platform, or it isn't. If it's important for A to be free, then A' must be free too. That's a perfectly reasonable copyleft requirement, and the principle of copyleft is DFSG free.

> But if Dave wants to play the free content game, then he needs to
> make the content Free, by giving us the key needed to run non-TPM
> content on his platform. If he does that, users can run the free
> content, by applying the TPM encryption when they load the device.

 s/key/info/ ; s/encryption// ; # fine, but that isn't CC 3.0 draft
 AIUI

Yes it is.  Here is yet another link to the August 9 draft of the CCPL3.0:

Generic:
http://lists.ibiblio.org/pipermail/cc-licenses/attachments/20060809/24ad86fb/attachment-0004.pdf

US:
http://lists.ibiblio.org/pipermail/cc-licenses/attachments/20060809/24ad86fb/attachment-0003.pdf

You will note that the anti-TPM clause is in the section outlining *distribution* requirements. It does not address the issue of applying TPM to a work you already have in your possession. That would be a *use* restriction, but there is no such restriction in CCPL3.0.

It has been stated by Mia Garlick and others that in fact, the previous version allowed this as well, but it may not have been as clearly worded. The changes in the CCPL3.0 version are designed to make this point more obvious, but they don't actually make a change about this point -- end users are able to apply TPM.

I DO believe that this point is a requirement for DFSG freedom: the end user needs to have this freedom. Not having it would be a use restriction.

And it's all you need to ensure that the work is free. It's a better solution than expressly allowing an intricate exception that allows the work to be distributed under TPM-lock, then trying to squeeze out all the loopholes a platform owner could use to maintain his restictions on end user freedoms.

Also, by tying the ease of end user access to information on TPM platforms it produces two very important market forces for free culture/software: it makes it necessary for Dave to make his key and TPM tools easily available and it encourages users to see what the overhead cost of using a TPM-locked platform is. Nevertheless, it does this in a way that does not actually restrict the users freedoms at all.

IMHO, that is much superior to any of the proposed parallel distribution approaches.

>>> 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 feel I'd have no problem with that sort of requirement.
>
> So we're still discriminating against users of TPM platforms for
> which no such key is published.

 Rather, we should require monopoly distributors to platforms to
 perform certain tasks to enable non-termination, free redistribution,
 derived works and so on. We shouldn't care whether TPM is involved.

How about we require him to provide a means for users to load non-TPM material on the platform? Because that's all he needs to do with CCPL3.0.

>>> 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. [...]
>>
>> If that is true (and there seems to be no public record of CC
>> decisions), then it is welcome, but inadequate.

This is unfair and untrue. There is a public record. Mia Garlick publishes this on the cc-licenses list. That there are no meeting minutes or other evidences of a democratic process is a fair criticism of particular events such as the iCommons meeting, but responses to questions have been made. CC-licenses is the correct place to discuss this issue, and it is there that the responses have been published.

You have to appreciate that CC only produces licenses. They do this to meet licensor's demands. The cc-licenses list provides a channel for licensors to express what those demands are, and to reach a consensus about them. There is no strict representative relationship, because licensors are free to choose other licenses if they decide they don't like where CC is going.

One particular point about that is that CC has to be very careful about allowing a breakage of copyleft in a license to which existing licensors will automatically upgrade, due to the terms of the license. This means that adding a significant anti-copyleft loophole, as you propose, would be a major betrayal of existing licensors.

> It provides the same protections as the proposed alternative (with
> key provision), yet is much simpler to understand and implement.

 It has vital differences, due to its simplistic broad-brush approach.

No, it's "elegant, simple, and direct".  ;-)

The only substantive difference is where TPM must be applied.

Under the terms you've promoted, the TPM can be applied at a point of distribution, whereas CCPL3.0 requires it to happen at the end user. That's the only difference.

IMHO, the CCPL3.0 is preferable, because it provides a natural *guarantee* both that:

1) the TPM/non-TPM works are truly equivalent (because only the non-TPM is actually distributed, and the end-user controls the conversion)

2) the keys and tools really are available to the end user (so DRM Dave can't try something underhanded, like requiring NDAs, charging for the service, or otherwise interfering with the end users' freedom to modify, use, and distribute the work)

> The only alternative I've seen proposed is "parallel distribution
> permitted for platforms for which a public encryption key exists".
> This makes no material difference in which platforms are supported,
> and except for the trivial matter of whether the TPM is applied
> before or after the user receives the file, no difference in
> practice.

 s/for which a public encryption key exists/for which all users are
 permitted to add such restrictions/

That edit is not negligible: "permitted to add" does not imply "able to add". And since "able" is too broad (we could be talking about the user's skills), we need to be specific in what we mean by "able".

But in being specific, we introduce the problem of loopholes being found.

The CCPL3.0 wording is far safer and simpler. It provides, as I've already argued, a natural assurance that end-users retain their freedoms.

 If this "makes no material difference" to you, but would convince the
 objectors, why not support it?

 Maybe it looks identical to you because you are not looking at the
 differences, dismissing them as generally and practically immaterial.


> Furthermore, that small difference is sufficient to ensure that the
> key (and whatever means is needed to apply it) truly is publically
> available. If there's any problem with that, then it indicates a
> problem with the freeness of the content anyway.

 I'm not sure that general public disclosure is necessary, but I could
 be wrong.

Strictly speaking, the key must be available to all recipients of the work. CCPL3.0 provides this naturally, because the end user will use the key to load the material onto the device.

> What exactly is it you want references for?
 "TPM is no longer a TPM once the key has been published" - "TPM is a
 matter of intent"

Moglen expressed this in the GPLv3 draft 2's approach to defining GPLv3 systems as not being TPMs. The opinion regarding this approach is expressed further in:

http://gplv3.fsf.org/rationale

which addresses this point in footnote 39 on the relevant section of part 3 of the license.
and more clearly the "Opinion on Digital Restrictions Management":

http://gplv3.fsf.org/drm-dd2.html

(It does take some digging to find this, see also: http://gplv3.fsf.org/opinions-draft-2.html and http://gplv3.fsf.org/gpl3-dd2-guide.html for other documents about GPLv3).

 - That TPM-parallel meeting the DFSG "is based on the FALSE idea that
 binary/source distribution is analogous to TPM/non-TPM distribution".

As I've pointed out, this is an irrelevant nitpick. It actually doesn't matter *why* Debian project members acquiesced to such an idea, just that the idea itself is wrong, which I've already demonstrated through logical argument.

The source/binary analogy clouded the issue for *me*, so I projected that experience onto other people, in what is, admittedly, speculation. Otherwise, it's difficult for me to understand why so many people should be so easily fooled into ignoring solid logical arguments.

Also, your "refutation" of this suggests only that the source/binary analogy was not used to *form* the parallel distribution proposal (perhaps that's true). However, it was certainly used by adherents to *promote* the proposal, and that is where my experience comes from. IMHO, it is not a great leap of logic to suppose that what is offered in support is accepted as support.

It remains the most plausible explanation as to why so many people have acquiesced to the idea, and certainly if you object to the suggestion that this rationale was ever followed, you have no grounds for objecting to my stating that it is false and shouldn't be followed, for the benefit of those of us who were snowed by it?

 AFAICT, at best, the above have been supported by name-drop. At
 worst, not at all and research suggests the opposite.

Now you're just attacking. I don't think refering to CCPL3.0 or public statements by Moglen or Garlick constitutes a "name drop".

How terribly presumptious of me, to assume that the debian-legal readers objecting so vehemently to CCPL3.0 have actually *read* it, or that comparisons to the GPLv3 draft can be easily found, by going to http://gplv3.fsf.org.

> I presume people know how to find the CCPL3.0, the GPLv3, the DFSG
> and the other sources mentioned. I've already referenced the
> archive for Greg London's "DRM Dave" test case.


 As I note in
 http://mjr.towers.org.uk/blog/2006/debian.html#notconsult CCPL3.0

You don't actually.  Maybe the link is old?

 is buried in a PDF in a list archive, while GPLv3 is on a web site
 that doesn't follow the web content accessibility guidelines, so not
 all data about its current state is visible to all.

 The DFSG are at http://www.debian.org/social_contract#guidelines - if
 only everything was as easy to read.

> The logic is all pretty obvious.

 The only part of your logic I object to is when "TPM can cause
 problem X" leads to the conclusion "prohibit TPM" instead of
 "prohibit X".

Perhaps if that's what I had said, or rather what the CCPL3.0 says, but it doesn't. It says *distributing* in TPM-locked form is disallowed. The practical result is that TPM can be *used* whenever the ability to convert a non-TPM work to TPM form suitable for playback is available to the end user.

It does this in the simplest and most fool-proof way possible: it ensures the ability of the end user to apply TPM through the simple expedient of making that the way to access CC material on a TPM platform.

Cheers,
Terry


--
Terry Hancock (hancock@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com




Reply to: