Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: Mia Garlick <mia AT creativecommons.org>
  • To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: [cc-licenses] Subject: Re: Version 3.0 - List Discussion Responses
  • Date: Sat, 23 Sep 2006 17:25:59 -0700

comments below.

On Sep 23, 2006, at 4:39 PM, Terry Hancock wrote:

Mia Garlick wrote:
the substantive one is that, on taking the temperature of the "CC
community" it, for the most part, seems to agree that putting
restrictions on the ability of downstream licenses to place TPM on
content in such a way as to thwart the intent and effect of the
licenses is a bad thing.
(there appears to be an error here, but I think you are claiming there
to be a consensus that using TPM to "thwart the intent and effect
of the licenses" is a bad thing, not the restriction against imposing it).

yes, sorry.

Technically, that may be true -- but it doesn't lead to a consensus
on what to do about it.

I've seen at least four positions championed:

1) parallel distribution (i.e. accept the Debian recommendation)
2) leave it like it is in CC 2.5 licenses
3) allow DRM/TPM, but explicitly grant permission to crack it

as i indicated in the table circulated on the list earlier, this is not imo, a viable option.

4) make the DRM/TPM restriction a separate license module

IMHO, all have merits, all have problems, and there's a sizeable
group of somebodies who doesn't like each one of them.

I personally think that #1 and #3 are compatible, and if both were
applied, the original intent would be sufficiently safe-guarded while
permitting the edge cases that Debian is interested in. The most
important point is that this approach destroys most of the advantage
of using DRM, so there's little reason why anyone would attempt
it -- *except* for those specific "DRM platform" applications that
Debian wants to avoid restricting.

the practical consideration is that allowing people to mix and match
their license terms would add more complexity to the license
selection process.

This has always been true, and yet it is the fundamental raison d'etre
of the Creative Commons to allow precisely this mix-and-match
freedom. This stance is contrary to the whole CC concept, so I find
it a bit bizarre.

no, the CC concept is based on a simple license generator is designed to ask three basic questions that focus on types of use that the licensor wishes to authorize: do you want to allow commercial uses? yes/no; do you want to allow derivatives? yes/no; if yes to derivatives do you want to require sharealike? yes.no.

if we start to open the can of worms as to additional, highly specific legal conditions people would also like to add to those permitted use...then we make it becomes mix and match license conditions (not a simplified list of authorized uses) and it becomes must more complex than the basic standardized, simplified license selection process upon which CC has traditionally been based.

other candidates for specific add-on conditions historically have included: making commercial use more nuanced and adding the ability to include IP warranties...if we are going allow people to checklist legal terminology, then we have to open it up to much more than TPM and i don't think we're in a position to do that yet; particularly not to solve "edge cases" as you refer to them above, that have not yet been shown to be tangible as opposed to hypothetical and particularly not given another license which has the same if not a broader TPM restriction (the FDL) has been declared Debian-free...


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

_______________________________________________
cc-licenses mailing list
cc-licenses AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses





Archive powered by MHonArc 2.6.24.

Top of Page