Re: Why TPM+Parallel Distribution is non-free
I spent far too long crafting a reply to this, then a pair of ISP/SMTP
errors sent it to /dev/null - this is a rushed rewrite. If you are in
a rush, points 17.1, 17.8, 17.13, 17.15 and 17.18 are most repeated
and you can get the gist from them.
Terry Hancock <hancock@anansispaceworks.com> wrote
> 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.
17.1 One cannot argue that allowing being non-copyleft is a problem
for CC-By.
> The terms in question ARE DFSG free, as they exist in CCPL3.0,
> for By and By-SA.
17.2 That seems circular reasoning: the terms follow DFSG, as they
exist in CCPL 3.0; and CCPL 3.0 follows DFSG, as the terms follow DFSG.
> 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".
17.3 That is a problem that I am working on, but as far as I can see
from the treaties, there's no assurance that "fair use" or "fair dealing"
exists in any meaningful form everywhere.
> 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.
17.4 Either it is a problem or it doesn't matter. Pick one.
> > > 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.
17.5 Only if one assumes that TPM must be such an obstruction.
That assumption may be wrong. The legislative definitions of TPM are
not great and there's not much case law yet.
> > >> 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").
17.6 The existance of some acceptable restrictions does not make all
restrictions acceptable. Some discriminate against fields or groups.
> 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.
17.7 I do not see how it is possible to twist my argument into that
conclusion. Has it been misunderstood?
[...]
> 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
17.8 I am not online, I do not have that URL cached and IIRC it doesn't
convert neatly anyway. As with other URLs, I neither accept nor reject
their arguments - it is merely citing inaccessible material. If it is
important, please quote relevant excerpts or summarise the substance, and
give an unambiguous reference. This isn't rocket science - it's research.
> > >> 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.
17.9 If the TPM field of endeavour were restricted, that might be fine.
It's not: any public use of TPM is prohibited, if I believe the claims.
> > > 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.
17.10 At least here, TPM is part of copyright.
17.11 Also, copyright is law creating a monopoly. Copyright is
fundamentally antithetical to free culture and software, but we can
still use it. Please leave the door open to doing the same with TPM.
BTW, please send personal messages to me directly. I think an "open
letter" style of debate usually indicates a desire to "win" the dispute
through confrontation rather than resolve it by explanation.
> > > 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.
17.12 What unalleviated restriction remains?
> 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.
17.13 Neither of the changes I suggested (import from CC-scotland or
reword current limitation to be TPM-agnostic) are particular fiddly.
> > >> 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?
17.14 So d[] is still a problem no matter what you do with A.
[...]
> > > 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.
17.15 So Tom, Dick and Harry could distribute d[A]?
> 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
See 17.8 (how to refer).
[...]
> > > 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.
17.16 That is what I mean too. He has a monopoly on d[A] for all A,
regardless of whether a particular A - or any A - is legally permitted
to be converted into d[A].
> 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.
17.17 Copyleft licences can follow DFSG, but being copyleft does not
prove it follows the DFSG. There have been copyleft licences which
have not followed the DFSG - not because of their copyleft, but
sometimes because of some overzealous discrimination...
> > > 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
See 17.8 (how to refer).
[...]
> 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.
17.18 Requiring it would easily be a discrimination. As a comparison,
free software does not require that users must have and be able to use
all the tools needed to compile the software for the platform they use
in exactly the same way. Is stuff with an awkward compile, such as
GHC (Glasgow Haskell Compiler IIRC), not free software?
> 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.
See 17.13 (not intricate).
> 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.
See 17.18 (may not require tool availability).
[...]
> > >>> 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.
See 17.18 (may not require tool availability).
> > >>> 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.
17.19 Are Mia Garlick's comments to the cc-licenses list approved by
the participants? Probably not, as there seems no strict representative
relationship anywhere in CC. If not, why do they hold any more weight
than comments from other participants? Actually, how can anyone tell
who the participants even were? No-one can tell who we should be
talking to and how.
17.20 Try assembling any sort of public record from the cc-licenses
list: it will take much time and still be incomplete. That is to say,
there is no public record worth the name. CC is less transparent than
a village girlguiding group, but so critical!
> 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.
17.21 If CC is in a marketplace of ideas, then having advocacy from as
much of the free software community as possible should be persuasive.
Having opposition in a place frequently asked to recommend licences
should be persuasive that it's a brain-fart, especially if some
suggested change seems inoffensive.
> 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.
See 17.1 (CC-By is not copyleft) and 17.13 (my proposals).
> > > 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.
See 17.15 (Tom, Dick and Harry).
> 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.
See 17.18 (may not require tool availability).
> 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)
17.22 How does CCPL3.0 guarantee that the available TPM conversion tool
produces a true equivalent?
> 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)
See 17.18 (may not require tool availability).
17.23 Does CCPL3.0 override all other agreements between the licensee
and licensor?
> > > 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".
17.24 So I think the suggested alternative seems misunderstood.
> But in being specific, we introduce the problem of loopholes being found.
See 17.1 (CC-By is not copyleft) and 17.13 (my proposals).
> 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.
See 17.18 (may not require tool availability).
> > > 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.
See 17.18 (may not require tool availability).
> > > 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.
See 17.8 (how to refer).
> and more clearly the "Opinion on Digital Restrictions Management":
> http://gplv3.fsf.org/drm-dd2.html
17.25 This one I did see, but I can't see how it justifies CCPL3.0draft.
[...]
> > - 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.
17.26 If I remember my logic classes correctly, even a logical argument
cannot reliably demonstrate anything if it is based on false assumptions.
So, the "nitpick" is relevant and the argument should be rebased on
sound assumptions to demonstrate that the idea itself is wrong, but I
doubt that's possible.
> The source/binary analogy clouded the issue for *me*, so I projected
> that experience onto other people, in what is, admittedly, speculation.
17.27 Other analagous situations may illustrate the evaluation, but the
evaluation should be done directly.
> Otherwise, it's difficult for me to understand why so many people should
> be so easily fooled into ignoring solid logical arguments.
See 17.26 (solid logic needs sound assumptions).
> 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.
See 17.27 (information).
> 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?
17.28 I don't object to that. I object to the suggestion that the
conclusion must be incorrect because something incorrectly identified
as an assumption is incorrect. I also object to people who make
strong claims without evidence when simple research suggests the
claim is false.
> > 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".
See 17.8 (how to refer).
> How terribly presumptious of me, to assume that the debian-legal readers
> objecting so vehemently to CCPL3.0 have actually *read* it, or that
17.30 I have read it, but it is large and complex, so hand-waving in
its general direction is uninformative.
> comparisons to the GPLv3 draft can be easily found, by going to
> http://gplv3.fsf.org.
See 17.8 (how to refer).
> > > 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?
17.31 "CC also has a bad obfuscation habit of posting text replies in
PDF files. Now we have the GPLv3 horror, where the Web2.0ish comments
system gives random answers to some browsers, stack traces to others
and has an email interface which rejects whatever comment I send it."
[...]
> > > 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.
See 17.15 (Tom, Dick and Harry).
> 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.
See 17.18 (may not require tool availability).
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: