Development of Creative Commons licenses

[Terry Hancock <hancock AT anansispaceworks.com>]

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."

[and elsewhere...]

>  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 
expressed").

> > 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 
interpretation, IMHO.

> > 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 
copyright terms).

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 
encryption key).

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. :-)

Cheers,
Terry

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