Development of Creative Commons licenses

[Terry Hancock <hancock AT anansispaceworks.com>]

drew Roberts wrote:
>Use of DRM on a redistributed CC work is okay ONLY IF:
>1) The work is also made available in an unDRMed parallel version,
> and
>2) Everyone is free to apply the DRM.

to which Greg London replied:
>I don't understand how this is any different than
>the current anti-tpm clause which allows local DRM.
>If folks are agreeable to the above then why are
>they in an uproar over the current anti-TPM clause.
>
>They are almost identical.

drew again:
>Do you need to understand it if it is acceptable to them?

Greg:
> I'd like to understand why folks object to
> Anti-TPM plus local DRM
> but would agree to
> parallel-distribution plus pre-authorization-to-apply-DRM
> 
> Because I see only a subtle difference between the two.
> And that means either I'm not understanding something
> or they're not understanding something
> or something more weird.

drew:
>Do you object?

Greg:
> Simply on the grounds that its near identical to the proposal
> but would require a full review cycle, again.

drew:
>Can it hurt?

Yes, it can. However, it's much less of a problem than other variants
mentioned. I know you have brought this up before, drew, and I really
should've made a more direct reply to you about it. I considered this
case, and found that it is almost exactly the same as the existing
anti-TPM language, but it has some undesireable second-order effects.

* It makes the license more complicated. This is not a question of mere
verbage, as TPM+PD proponents have suggested! It is a matter of being
understood. An unnecessarily circuitous clause will encourage
misinterpretation, while something plain won't. This is only a small
concern, though.

* It encourages anti-freedom behavior among the technically capable.
Essentially, it encourages them to "give fish instead of fishing
lessons". Instead of motivating free software developers to make TPM
application completely transparent so that the "end user freedom in
principle" becomes an "end user freedom in practice", it leaves them
with the crutch of simply applying the TPM themselves. This effectively
restricts the modify+distribute freedom to these same technically
literate people.

People coming from a programming/FLOSS background might be liable to
discount this because of their experience: the same technically literate
people are the only ones who can be expected to contribute significant
value to the work (because TPM application competence or compiler
competence is strongly correlated to programming competence). However,
with CC works we are interested in aesthetic value and these
correlations are practically non-existent: there is little correlation
between TPM application competence and musical or graphical competence.
IOW, the same user who's "afraid even to install software on their own
computer" and thus totally thumb-fingered with a complex TPM application
process may very well be a virtuoso musician with the capacity to rework
a mediocre CC ditty into a beautiful symphonic creation. The community
loses if he is artificially restricted from that.

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

None of these is a "showstopper", IMHO, but they are inferior to the
environment created by the existing plain anti-TPM language. Why go to
extra effort to make the license slightly (even if tolerably) worse?

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

There is, however, one really good reason to like your solution: it is
functionally *IDENTICAL* to the GPLv3 anti-Tivoization clause (the key
to apply TPM is identical to the signing key needed to run a re-compiled
Linux kernel on a platform with a boot key, which under GPLv3 is defined
as a part of the "Corresponding Source").

That would be politically useful, because the arguments raised against
the CCPLv3 anti-TPM clause are of the "freedom zealot" type, rather than
the "community benefit" type. And the GPL has *CLOUT*. No one is going
to declare GPLv3 "non-free" and make it stick. Hence, the CCPLv3 could
piggy-back.

However, while I agree that the GPLv3 approach is smarter for software,
 I think it doesn't work so well for creative content. I say this,
because, if you already have *source*, then adding the key to the source
is a simple change. OTOH, if "source" is not itself a natural concept,
then you have to erect the entire "source distribution" framework in
order to manage this one piece of information, and that's just awkward.

Meanwhile, Debian will most likely approve of the GFDL, which, as Mako
points out, is functionally equivalent (probably even more restrictive!)
to the CCPLv3 anti-TPM clause, in its requirement for "transparent" formats.

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.

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

Cheers,
Terry


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