[cc-community] CC-BY-SA 4.0 (and other CC-*** 4.0 licences) vs. computer game content

Mike Linksvayer ml at creativecommons.org
Mon Dec 19 15:22:07 EST 2011

On 19/12/11 19:03, drew Roberts wrote:
> On Monday 19 December 2011 12:54:31 Mike Linksvayer wrote:
>> Am I
>> still missing something?
> Perhaps. Since one of the things being considered for BY-SA this round is to
> make its copyleft provisions stronger, we may not want to let it go into the
> GPL where those copyleft provisions are currently being worked around in a
> way that the AGPL does not allow.

That's at best an in-theory concern. To make it real, BY-SA copyleft
would have to be extended in the one dimension in which AGPL extends
GPL, and that seems doubly (source requirement is the first) beyond
the pale for BY-SA's baseline. But of course any change in BY-SA (in
particular, but really any license) needs to consider alignment with
whatever other licenses may be of interest for compatibility one way
or another.

On Mon, Dec 19, 2011 at 11:51 AM, Rob Myers <rob at robmyers.org> wrote:
> The Mozilla Public Licence 2-B2, which I believe is being used as one
> example of compatibility, defines a "Secondary Licence" as either the
> GPL, LGPL or AGPL. I'd be against insisting on the AGPL, as desktop
> software doesn't need to be AGPL and the source provision requirements
> would be burdensome in that context.
> I can see the value of AGPL-style disclosure requirements for meshes in
> MMORPGs that don't send all the assets they render to the client, but
> *forcing* this by BY-SA requiring that the AGPL be used would be
> different to the MPL's allowing it. Depending on how it's formulated,
> this could easily make BY-SA 4.0 nonfree.

I don't understand how one would force it, unless you're arguing
against turning BY-SA into AGPL. In which case I agree, that's doubly
beyond the pale.

> There isn't a need for compatibility between BY-SA and the GPL in the
> same way that there is between the MPL and the GPL. The MPL and GPL are
> mutually exclusive code copylefts, so the MPL has to explicitly allow
> including of MPL code in GPL works. In contrast, the GPL doesn't care
> about BY-SA game assets (and I'm sorry but that includes level designs
> and any other data that isn't expressed as executable code). This means
> that there's no need for compatibility *as an end in itself*.

Yes, the onus is on people (including me) interested in some form of
BY-SA->GPL compatibility to demonstrate consequential use cases for
such. I know this is being worked on, and encourage maximum criticism
when posted.

> So my concerns are:
> 1. That BY-SA not end up nonfree by trying to dictate the free software
> that it can be used with.

That's a good concern, but I don't understand by what mechanism it
could do this.

> 2. That BY-SA not confuse code and assets, as this *will* have
> unintended consequences.

It does not distinguish between code and assets, and I don't expect
that it would. If you mean CC not confuse matters by recommending
BY-SA for software, I consider that also beyond the pale.

> and additionally:
> 3. That "compatibility" not lead to derivatives of BY-SA work becoming
> incompatible with their parents.

I'm assuming you mean donor compatible, ie a derivative can always be
incorporated into a new derivative of the parent, under the parent's
license. The MPL2 mechanism keeps this open a bit longer, but AFAICT
it just isn't possible in all cases without either bilateral
compatibility (BY-SA<->GPL) which I consider beyond the pale, or some
new mechanism allowing a sort of
which would be pretty darn interesting, but is totally speculative
(someone suggested to me offlist; feel free to claim :-)).


More information about the cc-community mailing list