[cc-community] Strengthening the CC-BY-SA copyleft with respect to code

Christopher Allan Webber cwebber at creativecommons.org
Tue Dec 20 16:53:24 EST 2011

For all you people who use lame non-fixed-width clients like gmail:



Christopher Allan Webber <cwebber at creativecommons.org> writes:

> So I'm not sure this is the same thing... right now content and software
> are treated as separate layers, and I don't think adding compatibility
> will or *should* change that.  The bigger cases where I think we need
> the BY-SA->GPL compatibility is where there's a use case where content
> and code are intertwined and inseperable, and avoiding licensing
> incompatibilities.
> So there are really two conversations going on here:
>  1) A license which means that art *is* on the same layer/domain of
>     copyleft as code (this is what BartK is proposing, I'm sympathetic to
>     it but again think it's going to open up a worse can of worms than
>     it'll fix and is possibly even considered nonfree)
>  2) Accepting that code and content are generally separated as different
>     layers, like:
>     .----------.
>     | CONTENT  |
>     +----------+
>     |   CODE   |
>     '----------'
>     But that there may be some areas that end up having some inseperable
>     overlap, like:
>     .----------------.
>     |CONTENT.--------.|
>     |       |scripted||
>     +-------| level  |+
>     |CODE   '--------'|
>     |                 |
>     '-----------------'
>     In the scripted level scenario, this is a "level", maybe some level
>     created in a GUI that's just a bunch of tiles put together.  Sounds
>     like content, right?  But what happens if you have a box that lets
>     you type in some scripting, and the file that comes out of it is
>     *simultaneously code plus content*.  Even if we have separate
>     content and code layers, which is indeed how we currently treat
>     licensing, you could end up in trouble where you want to link to
>     GPL'ed code and want to mix in CC BY-SA assets, and suddenly you're
>     ending up with a copyleft conflict.
> So, at the moment, Bart is talking about scenario 1.  I don't see how
> scenario 1 really gets fixed by the BY-SA->GPL compatibility scenario,
> and it opens up a huge can of worms potentially if we do start
> considering things to be on the same layer... suddenly, you can't view
> my image inside a proprietary browser, etc.  Maybe you can write the
> license around it to something more sane, but it'll be hard.
> Meanwhile, I've been pushing the BY-SA -> GPL compatibility issue, as
> have some others, but that's more to address issue #2 to make sure we
> don't have specific types of works that combine both worlds which are
> blocked by conflicting copylefts (surely those of us in the copyleft
> world don't want to block the creation of cool things that themselves
> *want* to be able to comply with copyleft).
> Does that make sense?  There are really two issues here.
>  - Chris
> Maciej Pendolski <beholder0x100 at gmail.com> writes:
>> On Tue, Dec 20, 2011 at 10:01 PM, Bart Kelsey <elbarto at gmail.com> wrote:
>>> If an art license could specify a specific
>>> set of conditions for programs that make use of the art in a non-generic
>>> way, and the definition of free software could be expanded to understand
>>> these kinds of provisions, as opposed to just tossing them in with
>>> "bundling" (which is clearly different), then a license like this could be
>>> very useful.
>> Isn't this what a one-way opt-out CC-BY-SA -> GPL "compatibility"
>> proposal is roughly about?
>> _______________________________________________
>> List info and archives at http://lists.ibiblio.org/mailman/listinfo/cc-community
>> Unsubscribe at http://lists.ibiblio.org/mailman/options/cc-community
> _______________________________________________
> List info and archives at http://lists.ibiblio.org/mailman/listinfo/cc-community
> Unsubscribe at http://lists.ibiblio.org/mailman/options/cc-community

More information about the cc-community mailing list