Development of Creative Commons licenses

[Terry Hancock <hancock AT anansispaceworks.com>]

drew Roberts wrote:
>>* It reduces the pressure on DRM Dave to release the TPM encryption keys
>> from "the number of people who want to play TPM works on the platform"
>>to "the number of people who want to modify and distribute TPM works for
>>the platform". IOW, instead of the entire population of *potential*
>>remixers, we have only the population of self-consciously intentional
>>remixers.
> 
> Here I think you misunderstand my proposal or I do. In my proposal, the PD 
> clause would never kick in unless everyone had the keys you mention in the 
> first place.

I don't think so. The point is, how does Dave's platform get to the
point where you can apply this clause? Presumeably it's because Dave
caves into the pressure from people who need the key.

In the anti-TPM scenario, *everyone* who wants to play free content on
Dave's platform needs the key (although 1-they may need to be told this,
and 2-it will probably be embedded in a library. Think of the libdvdcss
library: everybody knows you need that to watch region-coded DVDs).

In the keyhole TPM+PD scenario, only the "developers" who want to
package free content for Dave's platform need the key to be published.

Note that I am not talking about who has the key once it is published (I
think this is where you're misunderstanding me). I'm talking about how
many people are going to write petition letters to Dave to get the key
published.

>>In the same spirit of tolerance that Mako and James have graciously
>>acknowledged that the existing anti-TPM language is "free", however, I
>>would say that the above scenario is also "free". However, once again to
>>borrow from their lexicon, I believe it is a "tactical" error. :-)
> 
> Indeed it may be. Allowing local application where not everyone has keysmay 
> also be a "tactical" error to my way of thinking. If we do that, Dave can 
> just charge a monthly fee for the right to apply DRM on the platofrm. No? 
> Now 
> he has si revenue from my works via a back door...

That would be an error, but I didn't think you were advocating it (or
even tolerating it).

For the record, I categorically reject TPM+PD if there is no public
availability of the encryption key!

TPM+PD if there is a publically available public key and no restrictions
on using it is in the same gray zone as anti-TPM which allows TPM
application at the end user, but not TPM distribution. It's a
compromise. I think it's a worse compromise than we currently have, but
it is tolerable (I also think it may be possible to interpret the
existing wording as permitting this case, but that's a weaker argument).

TPM+PD without such a requirement is, IMHO, clearly hostile to the
commons and inconsistent with free culture. It simply shouldn't be on
the table.

>>Which raises another point: Why do we need to compromise? If Debian will
>>take the better license (the existing one), then we should stick to our
>>guns. If not, then we should cross that bridge when we come to it.
> 
> The biggest point in favour from my point of view would be the possibility 
> of 
> lessening unintended consequences,

That's a danger either way, and for my money, the more complex a clause
is, the more unintended consequences are possible. For example, it's
quite possible to imagine that there are technical loopholes in which
Dave could technically meet your requirements, but still have an
effective monopoly.

For example, he could publish the keys themselves, but not the TPM
application tool, which might be extraordinarily complex, simply to make
 it difficult for free software to use it. This would lift the legal
barrier, but still leave a significant technical barrier in place.

TPM+PD proponents suggest that this is an inevitable and negligible
consequence that we can't avoid. But of course, we can avoid it -- the
existing language does so.

Now, of course, there are devices which merely *can't* copy, download,
or communicate electronically at all. But that's not TPM. Such devices
are under the same terms as any other offline work and anti-TPM or
TPM+PD choices have no bearing on that (no parallel distribution
requirement would be triggered in the TPM+PD case).

Now, of course, you *could* require a PD for offline works, where there
*is* a readable version. But of course, that would have wide-ranging
consequences for other types of offline works.

>>Mako is asking us to re-evaluate our ideals, not our minimum tolerance.
>>So far, though, I still see plain anti-TPM as "more ideal".
> 
> I am not sure about that. I think they may not have picked up on how much 
> people like you were willing to permit in the TPM realm. Perhaps I am 
> reading 
> that completely wrong though.

I think they're not realizing that TPM really is fundamentally more than
just "something which makes it difficult for me to exercise my rights in
the work". So, for example, the snowglobe/greeting card example, which
is not TPM at all.

I find I'm actually making the same argument as Eben Moglen did about
the anti-Tivoization clause in the GPLv3. If you load a Linux kernel
onto a *ROM* device (which has no intrinsic ability to be reprogrammed)
that is legally distinct from loading it into a flash memory device with
a ROM private key, requiring a public key to allow the kernel to boot.

In other words, Tivo can get around anti-Tivoization if they just burn
Linux into a ROM, and GPLv3 won't stop them. Moglen defends this line,
suggesting that the fact that there is parity between all users of the
device is the important thing to maintain.

Ironically, I've actually argued against Moglen's interpretation there,
but I think I'm starting to see things his way. ;-)

Of course, none of us can really be sure if that's how a court would
rule. AFAIK, there's no precedent to tell is if "printing words on
paper" instead of an electronic medium is a "TPM" and an OCR is
therefore a "TPM circumvention device". God help us if such a precedent
is set, though.

Anyway, the point is that neither a ROM, which simply can't be
re-written, nor an undocumented chip, which *can* be read, but there's
no documentation for doing it, is a "TPM", so neither anti-TPM nor
TPM+PD clauses would be triggered by either circumstance.

Like the hypothetical "ROM Tivo" that situation is "just too bad", but
it's not something we need fight for (because there would be far too
many bad consequences). Pro TPM+PD folks want to push that line to the
other side of TPM, making it okay to treat TPM devices as if they were
ROM devices.

However, that's problematic because of two things:

1) Special treatment of TPM under law makes it not only difficult, but
illegal to capture content from such a platform (with a ROM or no-I/O
device, it's difficult but legal).

2) TPM devices create a significant disparity between platform owners
and content creators. In particular, it allows platform owners to use
content creators' works against them. The appalling case is the one
where the platform owner charges the original author a monopoly-based
price for the right to play his work on a device which he owns!

Cheers,
Terry

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