[cc-community] CC-BY-SA 4.0 (and other CC-*** 4.0 licences) vs. computer game content
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."
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.
>> 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
> 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
> 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
More information about the cc-community