Development of Creative Commons licenses

[Gunnar Wolf <gwolf AT gwolf.org>]

Anthony dijo [Mon, Jan 02, 2012 at 05:13:56PM -0500]:
> >> I don't want to force people to do anything. If people want
> >> derivatives of their work to be used in GPL software, they should
> >> license their work under GPL.
> >
> > The implication of this is that if the author of a graphic image or
> > audio file or text document does *not* license their work under GPL, it
> > is because they don't want recipients to combine the work into GPL
> > programs.
> 
> No, that's not the implication.  The implication is that *some* people
> licensed their work under CC-BY-SA, and not GPL, because they want
> their work under CC-BY-SA, and not GPL.
> (...)
> > If the original licensors of each work wanted a sharealike, but one of
> > them made a program and another made a graphic image and another made an
> > audio file – it *is* a bug that a recipient does not have the freedom to
> > combine them into a single derived work and redistribute under free
> > license terms.
> >
> > So what can be done to address that bug?
> 
> There's nothing that can be done if the two forms of sharealike are
> incompatible.
> 
> You can't combine CC-BY-NC-SA with CC-BY-SA, even though both are
> sharealike.  Should we put a clause in CC-BY-NC-SA allowing people to
> relicense the work under CC-BY-SA?  Surely it is more likely that the
> licensor would have no objection to having his image used in
> Wikipedia, but didn't think about the incompatibility between
> CC-BY-NC-SA and CC-BY-SA.

What I see here is a clash that comes from our (programmers)
side. What is combine? What is the work?

It is common to have a software package having many different licenses
for its different components, as programs are usually structureed as a
set of related but independent files — Sometimes it happens because a
program wholly includes another one, and sometimes because simply the
author decides some files should be treated differently – One of the
most common examples for this would be (and brings me back to the
CreativeCommons-related discussion) that documentation cannot be
(often) seen as code.

To illustrate this, please look at the following copyright file I
wrote for a package I maintain in Debian:

  http://packages.debian.org/changelogs/pool/main/c/cherokee/current/copyright

While the format is not precisely human-friendly¹, you can see I am
quoting nine different licenses, plus a licensing exception
(OpenSSL+GPL). Some of the licenses are applied exclusively, some
allow the user to choose which terms to abide by. And no, this is not
a very complex software package. By the way, one of the licenses is a
CC one: All of the icons are CC-BY-3.0.

Here, there is not one single license that applies to the whole
package. Many of the components are "linked" together when the package
is built (that is, they become part of one undistinguishable binary
object), some are just bundled together (i.e. the icons will stay as
icons accompanying the program). Some components are not even part of
this source, but are required to be present in the build environment
and taken into account when licensing.

And what has been argued here can be perfectly exemplified by the
OpenSSL+GPL exception: Both licenses are free (or, put it in this
list's words, both clearly contribute to the commons). But they do it
in an incompatible way: OpenSSL requires all derived works to mention
OpenSSL in "advertising materials", and the GPL forbids any such
restriction.

Without digging too deep into the question unless requested², that's
what we want to avoid in the CC4 process: We want to ensure we can
still build bundles where some bits are GPL, some bits are under some
forms of the CC licenses, and we don't need to present those obnoxious
and hard to explain conditions. Currently, CC-BY and CC-SA-BY are
GPL-compatible (and in general, Free Software-compatible). I do not
expect it to change, but subtle details can lead to this kind of
incompatibility. There are probably hundreds of works which combine
GPL and CC components, and it would be a pain if we would have to hunt
for incompatibilities and convince authors to grant the relevant
exceptions, as was done with OpenSSL.

¹ It is made so it can be parsed by a computer

² Go to http://people.gnome.org/~markmc/openssl-and-the-gpl.html for
  further details