Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] Founders as a module? was Re: Getting to Version 3.0

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: drew Roberts <zotz AT 100jamz.com>
  • To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: [cc-licenses] Founders as a module? was Re: Getting to Version 3.0
  • Date: Thu, 18 May 2006 22:58:33 -0400

On Thursday 18 May 2006 09:36 pm, Terry Hancock wrote:
> drew Roberts wrote:
> > A couple of thoughts, while a units sold sounds simpler, it does
> > nothing for someone who lives in a high cost of living country and is
> > popular in a low cost of living country.
>
> I don't really see this. The author sets the prices N and the
> amount of units M, so the monetary limit is just N*M. I thinking
> it might be a bit much to ask to have different quantities for
> different countries. I never much liked region-coding, actually.

You may be right and I may not be thinking clearly there and it is too late
and I am too tired to think clearly now.
>
> > So you we need three. Time, Units, Money. Pick any one, two, or three
> > and when either is satisfied, the work moves on to the next license.
> > No real reason, other than simplicity, that there could not be more
> > than one hop between the license a work starts with and where it ends
> > up.
>
> Well, okay, for the sake of argument, anyway.
>
> But I dislike this semantics, because it implements an AND between
> the conditions (work is freed once all conditions are met). I prefer OR
> semantics (work is freed once any condition is met).

I think you must have misread me there. "when either is satisfied" is a call
for and OR and not an AND.
>
> The reason is simple -- many works simply won't achieve the target
> sales (the artist may have been unreasonable in their estimates). Should
> they never expire, then?

I am with you on the OR so long as there is more than one element in play. If
you are pusing this as a way of ensuring that CC works all end up at some
point as either a BY or a BY-SA then you would want to mandate a time
element. (Right?)
>
> Of course, this also makes me realize another reason I don't like the
> earnings
> target or the units-sold targets -- both rely on accounting information
> only known to the artist. Hence, these make better sense to be implemented
> by a distributor or by the artist themself (they require a central
> authority to be contacted to determine license status -- hence they don't
> really achieve any free-licensing mileage).

Not really, we would just need the cooperation of someone like LULU to have
the option of showing sales for items chosen to have them made public by the
seller. It may not be as clean as a simple time delay, but I think it is more
than do-able. (So, if you have unit or dollar + mandatory time, then people
can wait, or purchase the "freedom" sooner.)
>
> Not so for a time-delay: As long as the work provides its licensing
> date, you
> know when the sunset clause will expire.
>
> This is an important property of free licenses: they avoid forcing you to
> ask permission every time you want to use something. A time-delay system
> can do that, but not a units-sold or money-earned system.
>
> And since both can be acheived through use of a repository authority or
> the artist as authority, nothing would be gained by putting those
> constraints
> in the licenses themselves (IMHO).

Except the possibility of an earlier freedom for the work.
>
> So, okay, now that I've thought about it some more, I don't like the
> idea of sunset modules based on money or number of sales (but they
> might be good strategies for publishing, nevertheless). Sunset based
> on timed release though, still seems practicable.

See above, and let's discuss some more.
>
> Cheers,
> Terry

all the best,

drew
--
http://www.ourmedia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedia.org/user/17145





Archive powered by MHonArc 2.6.24.

Top of Page