Development of Creative Commons licenses

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

On Monday 12 February 2007 11:45 am, Terry Hancock wrote:
> Gregory Maxwell wrote:
> > On 2/12/07, Terry Hancock <hancock AT anansispaceworks.com> wrote:
> > They would likely be concerned if the different but still free license
> > was a weaker copyleft than the license they used. There is no point in
> > having a strong license if by some license slight of hand a downstream
> > user can switch to a weaker license, since downstream folks who want
> > to circumvent the stronger terms will do exactly that if the option
> > exists.
>
> ISTM you're missing a subtley in this particular thread. The idea is
> that there is a third state, between "mere aggregation" and
> "derivation", which involves "semantically linked" works.

Right.

Question: For each of these cases, let us know if you consider it a case of 
mere aggregation or not.

1. Popular Hits CD. This is just a random collection of hit songs. Original 
artists and recordings.
2. Popular Hits of the 90s CD. This is a collection of random hits of the 
90s. 
Original artists and recordings.
3. Popular Love Songs CD. This is a CD of hits specifically chosen and 
ordered. Original artists and recordings.
4. Same as 1 but covered by one new artist.
5. Same as 2 but covered by one new artist.
6. Same as 3 but covered by one new artist.

In all cases, one variety has all songs under s free license but not 
compatible ones. Another variety mixes songs with free and non-free licenses.

Should I give some other examples?
>
> I still don't know if that can be written in a legally-binding way, but
> it would be useful.

It might be worth looking into. Does anyone see any roadblocks to crafting 
such a clause / license? (Other than politics?)
>
> In the case of music for a movie soundtrack, the music's license *would
> not change* just because it is synched with a movie under a different
> license. But the movie wouldn't otherwise be required to use the same
> license.
>
> The closest extent analogy would be to the LGPL which allows a specific
> kind of linking (dynamic or static linking of a software library to a
> package). The Library remains under the LGPL, and any changes to it must
> be treated in the same way as the GPL, but this specific type of
> distribution may be used with proprietary works.
>
> In the case we are envisioning, the requirement is slightly different:
> the linking may occur outside of the object's own license, but it must
> still be under an "approved" free license.
>
> IOW, you can imagine a variant of the LGPL which allows linking of
> libraries to *ANY* free software license (say, "Any OSI Approved
> License"), but NOT to proprietary licenses. This would be more
> restrictive than the existing LGPL, but still not as restrictive as the
> GPL.

I am sure it would be an FSF approved, but this is a somewhat interesting 
thought.

Just a quick thought on that:

Basically, I can't see them ever suggesting use of that license where they 
suggest use of the lgpl. They pretty much only recommend the lgpl where there 
are decent non-free laternatives in existance and putting the work under the 
gpl will cause it not to be widely adopted.

Would they ever use it where they would normally use the gpl? It would have 
no 
practical benefit in the case of gpl compatible free licenses. Would it?

So, the benefit would be to allow linking of non-gpl compatible free code 
with 
gpl compatible code. ???

Comments / the poking of holes greatly appreciated.
>
> This would allow, for example, a GPL-like library to be linked to MPL
> code (which is otherwise incompatible), but not to be appropriated by
> Microsoft into a commercial/proprietary product.
>
> Note that GPLv3 makes it easy to declare such a license using the same
> Section 7 provisions that are used for the new LGPL.
>
> > This is the conceptual flaw in the compatibility approach currently
> > taken in the cc-by-sa-3.0 draft:  any work protected by a license in
> > the pool of licenses compatible with cc-by-sa-3.0 receives protection
> > only as strong as the weakest license in the pool.
>
> Yes. That's a problem. I think certain steps can be taken to mitigate
> this risk, though. One is this idea of keeping separate components under
> their separate licenses, but allowing them to be linked together.
>
> > This might be acceptable if the most interesting failure mode of a
> > free content license was to be too restrictive. But because license
> > restrictions can be fixed after the fact (by issuing new licenses)
> > while excessive permission can not be fixed except for new
> > works/derivatives, the too restrictive case is not the one we should
> > be solving.
>
> Yes, the insufficiently restricted case is more of a hazard.
>
> I think automatic upgrade clauses are the real kicker. If a license
> containing such a clause is declared "compatible", then the way is
> opened for a bad license steward to essentially leak the whole commons
> out of copyleft entirely. Which would be *BAD*.

This could indeed be bad. Could this be side stepped by having the automatic 
upgrade be conditional on converted works some how? A converted work can be 
upgraded but only after approval of the new version? This might get hairy 
really fast.
>
> Cheers,
> Terry

all the best,

drew
-- 
(da idea man)