Development of Creative Commons licenses

[drew Roberts <zotz AT 100jamz.com>]

On Monday 04 December 2006 07:47 am, Terry Hancock wrote:
> 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.

I think it could be re-worded to make the language simpler. It is the basic 
concept I was floating to see if it could help resolve the differences here.
>
> * 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.

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

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

The biggest point in favour from my point of view would be the possibility of 
lessening unintended consequences, but, I am not for this proposal. I do feel 
that it needed more discussion than it got and I do think when that 
discussion finally happened, it lead to more understamding of the various 
objections the parties had, so I am glad I brought it up again.
>
> 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.
>
> Cheers,
> Terry

all the best,

drew
-- 
(da idea man)
National Novel Writing Month
Sayings (Winner 2006)
http://www.ourmedia.org/node/262954