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

Rob Myers rob at robmyers.org
Tue Dec 20 17:30:10 EST 2011

On 19/12/11 20:22, Mike Linksvayer wrote:
> On Mon, Dec 19, 2011 at 11:51 AM, Rob Myers <rob at robmyers.org> wrote:
>> 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.

If it's the case that BY-SA would say effectively:

"You can use this work with any game engine, as explained by the FSF
FAQ. If you choose to distribute this work with an AGPL-licensed game
engine you *may* declare it to be covered by the AGPL. If you do,
downstream users must honor this."

that's OK.

If BY-SA would say effectively:

"If you use this work as part of a computer game, that computer game
must be licensed under the AGPL. Distributing this work with the game
makes this work covered by the AGPL. Downstream users must honor this."

Then ಠ_ಠ .

> 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.

Oh cool.

>> 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.

It depends how the MPL 2 B2 mechanism is mapped onto BY-SA, as above.

>> 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.

I mean the FSF FAQ distinction between game engine and game asset.

>> 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

Yes I mean "donor compatible". I don't know how I've done without that
term. :-)

> it just isn't possible in all cases without either bilateral
> compatibility (BY-SA<->GPL) which I consider beyond the pale, or some

Why would this be beyond the pale? And why is not BY-SA->GPL not simply
half as bad?

> new mechanism allowing a sort of
> work-type-based-compatibility-sorta-like-bilateral-sorta-like-multilicensing,
> which would be pretty darn interesting, but is totally speculative
> (someone suggested to me offlist; feel free to claim :-)).

BY-SA as the ODbL with the (A)GPL-covered work being the "Produced
Work"? :-)

- Rob.

More information about the cc-community mailing list