Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] PROCEDURAL SUGGESTION

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: Terry Hancock <hancock AT anansispaceworks.com>
  • To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: [cc-licenses] PROCEDURAL SUGGESTION
  • Date: Tue, 03 Oct 2006 17:07:41 -0500

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






Archive powered by MHonArc 2.6.24.

Top of Page