[cc-licenses] PROCEDURAL SUGGESTION
hancock at anansispaceworks.com
Tue Oct 3 18:07:41 EDT 2006
Greg London wrote:
> On 10/3/06, MJ Ray <mjr at phonecoop.coop> wrote:
> > 4. I don't see why the last anti-TPM language I saw would mean "You
> > can apply DRM to your local copy and play it on your own hardware
> > player" [Greg London]
> I can't find the wording at the moment to quote. But I believe the
> wording was something to teh effect of: "You cannot apply TPM to
> restrict the rights to a work you distribute."
> Can the generic licence safely rely on fair use, which seems to vary
> wildly around the world? I thought I'd seen it defined in the Berne
> treaty as essentially whatever the local laws say. Reliance on 'fair
> use' to make a licence free is something I see as a big warning sign.
Yes. This is apparently already agreed.
According to the response paper posted earlier by Mia Garlick, Creative
Commons has already agreed that the license should be re-worded to
emphasize that it is only distribution that is affected by the anti-TPM
language (although it's apparently the case that the "fair use" language
does already make this so in the 2.5 licenses).
> I also believe the wording of the anti-TPM clause was such that you
> may even be able to distribute content that has transparent TPM
> applied to it. The requirement being that TPM is allowed so long as
> it does not restrict the rights to the work.
Other than the fact that "transparent TPM" would seem to be an oxymoron,
I think this is correct (I presume that by "transparent TPM" you mean
"encryption which would be called 'TPM' if it were used to protect a
monopoly on a work, but which isn't because no such intent has been
> > Further, using it to argue that even the CC-By licence should
> > contain anti-TPM would mean that CC-By would prevent such lock-in
> > while not doing anything to stop other copyright-based lock-ins.
> > That would be bizarre.
It's quite possibly true that CC-By should not worry about this kind of
restriction. I've probably contributed to confusing this issue, so I
should try to clarify. I disagree politically with the idea that Debian
should take a position of allowing CC-By (but not CC-By-SA) on the basis
of such anti-TPM language. That's a little off-topic on this list,
because my reason for my wanting that is that I'm a Debian user, and I
(now) think the position is inconsistent with the DFSG.
So rather than see Debian try to "fence off the damage", I would prefer
that they fundamentally re-examine the issues. But it's fair to say I
should take that up on Debian Legal rather than here.
> > DRM Dave is not a tenable argument for an anti-TPM CC-By.
No, but there are reasons a creator would fear TPM on CC-By, but not
other forms of "lock-in" as you put it. It's important to remember that
we are talking about artistic, directly-observable value when we talk
about "free culture" licenses like the CC licenses.
One consequence of this is that the value of these works is not
intrinsically hidden, as it is for utilitarian works like free software.
What I mean by this, is that if a piece of software is BSD licensed, the
author has done that with full knowledge that their work can be sucked
into the bowels of some corporate proprietary product. So they've
obviously reconciled themselves with this possibility.
A work of art or music, however, will be directly accessible if it is
incorporated. So, for example, if you wrote and recorded a nice little
jingle, and Microsoft decides to use it as their new default start-up
sound, then you will hear your work clearly everytime someone logs into
a Windows machine near you. That means your music will be accessible to
everyone around the world. CC-By (and BSD) assure you will get
credited. But the *nature of the work* assures that the work will be
separable from the proprietary context (you will be able to extract the
sound file from Windows, and it's still yours). An artistic creator may
well be releasing their work with the expectation that this will remain so.
The only thing that can change this dynamic is if Microsoft deliberately
applies some kind of TPM to prevent it. In that context, the anti-TPM
language in CC-By makes sense, because it preserves the social contract
the creator felt they were making when they released the work.
Admittedly, this is not nearly so strong an argument as in the case of
CC-By-SA, and I don't plan to fight for it, but it's a plausible
> > Personally, I think ShareAlike could deal with DRM Dave by
> > requiring him to ShareAlike, including permission to use his DRM
> > encoder for all derived works.
> One of my earlier suggested alternatives to anti-TPM was to authorize
> circumvention of any DRM applied to the work or any alternative.
> Apparently that won't work due to the way the DMCA works.
Mia Garlick is so sure that the DMCA language won't permit this kind of
requirement, that she says further discussion of it is "not
productive". I hate declarations from on-high like that, but she's
apparently got a point.
Yes, of course this just underscores the stupidity of the DMCA, but we
have to remember that much of the point of the existence of CC licenses
(and all free licenses) at all is to correct what we see as stupid laws
(for example, inadequate scope of fair use and too long a duration of
If we had the power to just rewrite the copyright laws to suit us, we
wouldn't need all this legal jiu jitsu in the first place. ;-)
> >> Dave has a platform monopoly that would be similar to Microsoft
> >> distributing Linux/Microsoft executables, distributing some of
> >> their source code, and then using DRM and DMCA to PREVENT ALICE
> >> AND BOB FROM EVER COMPILING THAT SOURCE CODE ON A MICROSOFT
> >> SYSTEM.
> > Hello! Cross-compilers! I have had GPL'd apps on a Palm computer,
> > but I can't compile them on it.
Greg could/should have said "...COMPILING THAT SOURCE CODE *FOR* A
MICROSOFT SYSTEM" and it would make the same point. The point is not
that such a compiler is difficult to write or that Dave's particular
compiler is non-free, the point is that *it is illegal to implement such
a compiler* (DMCA anti-circumvention clause).
Again, this is stupid law. We should probably (continue to) lobby to
change it. But as things stand, we have to tolerate the existing law.
However, what this is effectively arguing is that we can't allow the
work to be TPM'd unless the key to TPM a modified work is available.
This would be exactly like the GPLv3 anti-tivo-ization language (the
corresponding source key requirement).
In principle allowing the TPM, but requiring the key to be published is
not an unreasonabkle idea, but....
1) this would make the TPM "transparent", thus meaning it is not being
used to restrict, hence the CC language already allows it
2) it requires the authorization of the owner of the TPM technology to
make the key legally publishable. Encouraging anyone else to release the
key without such authorization could be interpreted as incitement to
break the law
> Terry Hancock wrote:
> >> 2) DRM application, unlike binary compilation is a technically
> >> trivial process. This means that there is no significant burden
> >> on the end user
> I saw this repeated several times, but I think it's obviously not
> true. A binary compilation:
> cc -ofoo foo.c can be as technically
> trivial a process as a DRM application:
> tp -ofoo.tpm foo.ogg but many
> people still won't want to do it themselves. I've yet to see
> anything to suggest that TPM is inherently not a translation.
This is totally missing the point. Yes, a compilation *can* be trivial,
but it almost never *is* trivial in practice. The technical reason for
this (e.g. library and hardware dependencies), isn't important here. The
important thing is that it biases your perception of the obstacle that
compilation represents, and therefore the importance of binary
distribution (very important for unskilled users!).
And while it might be technically possible for a TPM program to
introduce all kinds of weird dependencies and obstacles for the express
purpose of making it hard to apply, there is no *natural* reason for it
to be hard. And there is no *motivation* for it to be made artificially
difficult. Hence, it's perfectly reasonable to expect that in
*practice* TPM will *always* be trivial to apply (assume you know the
The difference is not unlike comparing the construction of a pressure
hatch to the use of a lock. The pressure hatch is complex and possibly
prone to error because it is constrained by its application to have a
certain amount of complexity, plus a dependence on the environment in
which it will be used. You can't avoid that complexity.
A lock could, in principle, be designed to be that difficult (think Rube
Goldberg!), but in practice, locks are designed to be simple to operate
devices requiring only the insertion of the right key.
Thus, if for example, you were sold a submarine, it's one thing to turn
it over locked and just give the user the key, and quite another to hand
them a bag of parts and say, "here's the door, just put it together, and
you're set to go"!
Debian has been arguing that it's important to be able to distribute the
TPM copy based on experience from managing binary and source
distributions of software. But that experience teaches the wrong
lesson, because the TPM is in a very different complexity regime than
binaries are. In fact, it's really no trouble at all for the end user
to apply their own TPM, provided the keys to do so are made available.
I admit this isn't much of an argument on principle, it's more about the
pragmatics. But let's not forget that the "pragmatics" of getting people
on TPM-only platforms to use free content is part of the sales-pitch
Debian has made against the anti-TPM language. Here we see that the
pragmatic assumption (it's hard to apply TPM yourself) is not really
true, so long as the keys are available.
Now, in practice, the real obstacle is not *difficulty*, but *expense*.
The argument that has been made is more typically that access to the
secret key costs some exhorbitant amount of money that might be paid
once for the whole community if one community member agrees to apply TPM
as a service. However, that puts us in the position of having to pay a
per-seat license fee for everyone who wants to retain their "freedom 1"
(the freedom to modify) in the work. This is getting into "free as in
beer" territory (much as I hate that expression, it sort of fits here).
Also, there is nothing in the law that forces the TPM provider to sell
its keys *at all*, so it may be that there is no benevolent TPM-keeper
in the picture, but only a hostile TPM-keeper whose actions are designed
to undermine the community.
This seems completely plausible to me, in terms of where DRM/TPM is
going in the marketplace.
In fairness, I should suggest this point: if there's room to budge on
this issue, it might be that we could somehow require the TPM-keeper to
provide fair conversion service (in a way that is similar in spirit to
parallel distribution or source distribution requirements). This would
be pretty unattractive from the TPM-keeper's point of view (committing
to a free service), but not entirely unfeasible, if the keeper were to
provide a TPM-conversion web application, for example, that would
convert any content into the TPM'd format.
However, our hypothetical 'benevolent community-based' TPM-keeper
probably can't do this within the terms of his contract to acquire the
key, and the more probable 'evil corporate stooge' TPM-keeper has a
strong profit motive not to provide this service (easier to open his
platform up to play un-TPM'd material). So I can't see that it would
help in any practical way.
> Terry Hancock wrote:
> >> After reading Greg's "DRM Dave" scenario I am convinced that he's
> >> right after all and parallel distribution does not solve the
> >> question of "platform lock-in". [...]
> For all its cute names, the DRM Dave story seems to make several
> assumptions, including my points A (everyone is a clone of me) and B
> (overgeneralisation and buggy examples) above.
These are unfair and unsupported claims about the case. Which bit was
"overgeneralized" or "buggy", and at which point does it make any
assumptions about "clones"? If you want to find a fault with the
example, fine, but this kind of arm-waving doesn't make any kind of case
against it. Be specific.
> > Terry Hancock wrote:
> >> Finally, I have suggested that this is more than just a Creative
> >> Commons or Free Culture issue. Debian is making a mistake by
> >> claiming that parallel distribution meets the Debian Free
> >> Software Guidelines (DFSG).
> > There are some who hold that opinion, but it has not been explained
> > on debian-legal in any understandable way yet.
Fair point. I've already said I'm willing to bring it up myself, but
I'll need to re-join Debian Legal (haven't been on the list in over a
year), and so I'm not doing it right away.
> >> IMHO, the problems above render the work *non-free* under the
> >> Free Software Definition and in violation of the Debian Free Software
> >> Guidelines.
> Some parts of some derived works may be non-free, yes. However, one
> must consider the whole work, else you'll find several of the DFSG
> violated by every package in the archive, which is clearly absurd.
Again, this is isn't argued clearly, but it sounds like sophistry. It's
sounding very much anti-copyleft (a position which clearly must be
contrary to Debian's historical policy and Social Contract).
> >> [seen several times:] I suggest that Greg's "DRM Dave" example is
> >> just as important a lithmus test as the existing "Desert Island",
> >> "Dissident", and "Tentacles of Evil" tests which Debian Legal
> >> uses to examine new license terms that are in question [...]
> Whoa! Anyone who has experience on debian-legal should know that
> those tests are merely indicators - like the litmus test - and not
> definitive proofs of DFSG failure. A litmus test can give screwy
> indications, just like DRM Dave gives some screwy indications of some
> of the anti-TPM suggestions. Of course, it's better not to give the
> wrong indications, but sometimes it is simpler.
And your point is? ;-)
I used the expression "litmus test" myself.
Surely the point of these examples is to expose questionable cases that
ought to be considered. I think "DRM Dave" (though you're welcome to
suggest a better name) is just as important a test case as these other
three tests. It certainly opened my eyes to the problem.
There *are* no "definitive proofs of DFSG failure", because (as the
litany goes) the DFSG are *guidelines*. Duh. Yes, I know this.
Your assessment of the DRM Dave example of giving "screwy indications"
is still completely unsupported. All this means is you didn't like the
answer you got (and we already knew you wouldn't). But a "test" is
worthless if you only pay attention to the answer if it happens to come
up with the answer you wanted. If you don't like the outcome, you need
to explain *why* you think it's "not typical" or "not accurate" or "not
applicable" or "not important" or whatever your reason for rejecting it
is. "Not the answer I wanted" isn't enough.
Now please realize that I gave Greg a pretty direct challenge to show me
what was wrong about the binary/source to TPM/non-TPM analogy. He
responded fairly and persuasively.
If you want to sway the argument back the other way, you need to find an
actual hole in the test case, or make an effective counter-argument.
Just pounding the old argument without addressing the counter-example
that Greg has provided is not persuasive. You can't just dismiss this
("it gives a screwy indication"), you have to refute it ("the indication
it gives is screwy because ...").
As I told Greg, I'm all ears. Convince me. :-)
Terry Hancock (hancock at AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
More information about the cc-licenses