Creative Commons - User contributions [en]

4.0/Games 3d printing and functional content

2012-12-13T09:40:27Z

LindaL: /* Background */

= Background =

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap [http://www.telsgroup.com.de/services/groupage_cargo_transportation_services/ Spedition Sammelgut]

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

== Background on separation of functional/software and cultural layers ==

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. (The FSF has held this position or something like it
for a long time; alluded to slightly on their
[http://www.gnu.org/philosophy/free-system-distribution-guidelines.html#non-functional-data distribution guidelines about non-functional data].)

It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code].
<ref>Technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else.</ref> If for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.
<ref>In fact, this issue comes up with Blender all the time, which
*does* have a backend which is scriptable with Python; see Blender's
[http://www.blender.org/education-help/faq/gpl-for-artists/ GPL for
artists page]... although I'm somewhat unconvinced that all of the
statements on that page make sense, it does demonstrate the complexity
of things.</ref>

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have been released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.

Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right when we try to create a new project that combines
cultural and functional works.

(One could possibly ask
[http://www.publicknowledge.org/blog/3d-printing-settlers-catan-probably-not-illeg how far copyright applies to functional 3d printed works]
(and therefore, how far copyleft applies), and there's not much
background to show how it applies at all yet. I'm writing this
assuming it does apply.)

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part?

But most complicated of all, what if you wanted to make a walking
cat-robot that uses a BY-SA cat design (maybe the head of the octocat)
and combines it with the robot chassis and some bears and the bead
belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

= Possible actions =
== GPL compatibility ==

Probably the most actionable and most urgently raised amongst issues
when discussing with relevant community members is that of a one-way
compatibility between CC BY-SA (and probably also CC BY) and the GPL.
It's almost certainly not possible at this point (and probably
undesirable) that GPL->BY-SA compatibility is possible, but if we
choose to do it BY-SA->GPL (and probably BY->GPL) should be.

The benefits of this is that it will resolve the tricky issues with
"interwoven" content and cultural works. Clashes in copyleft licenses
which share the same goals are unfortunate if they block useful things
from being created. As
[https://creativecommons.org/weblog/entry/30676#comment-356183 Arne Babenhauserheide said],

<blockquote>... the case of cc-by-sa not being comptible with the GPL is very sad,
because they share exactly the same goals: Copyleft. Thus their
incompatibility creates a real split in cultural works. If the 4.0
licenses could make it possible to combine cc works under licenses
with compatible concepts (cc by, cc by-sa) with the GPL, that would be
a huge step towards a unified free culture.</blockquote>

So what are potential downsides? The main downside is that
[http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F Creative Commons licenses are not acceptable for software]
and we don't want to spread a misconception that they are. If we go
forward with this, we should develop strong messaging that makes clear
that software should still not be released as BY-SA and that this is
for avoiding conflicts in complicated areas of interwoven cultural and
functional/software works.

The other possible downside is whether or not source requirements for
art might make incorporating BY-SA works with the GPL difficult. Ie,
there is no source requirement for BY-SA, and there is one for the
GPL. The GPL says:

The “source code” for a work means the preferred form of the work
for making modifications to it. “Object code” means any non-source
form of a work.

See also the "source release" section of this document for detailing
on the complexities of source code requirements in BY-SA. But as for
fulfilling the requirements of the GPL, what about the following:

* In programming, the division of what source and object code is well understood. In content it's more of a gradient
* For example, the Blender Foundation releases all the "source code" of its films such as Big Buck Bunny and etc by releasing the .blend files (though it is not a requirement of the license).
* However, what if someone made a remix of Big Buck Bunny where they changed the order of scenes, added a psychadelic overlay, and added new music. But the "source" they worked with was not on the .blend file level, but by remixing the rendered film itself. If incorporated with a GPL'ed work, would the source requirement apply, and would it in fact require sharing the source all the way down to the original .blend files?
* What about a film like Sita Sings the Blues, which is BY-SA but from which the source files were never redistributed at all? It's unlikely the content/code layers would be intertwined if combined with software, but let's pretend for a moment that it was. Would "combining" with a GPL'ed work mean requiring distribution of the original files from which the film was made? What if those were lost? What if there's still a lot you can do without the "original source files", although admittedly not as much as if you had them?
* In other words, just how far does "preferred form of the work for making modifications to it" go down? What if people are remixing it on different layers, and the artists themselves prefer separate layers? Does the GPL give flexibility here?

There is additional discussion about GPL/CC compatibility [[4.0/ShareAlike#Considerations_regarding_compatibility_of_other_licenses| here]].

== Scoping copyleft across and code ==

Bart Kelsey has written an excellent article,
"[http://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html Why we need a stronger copyleft for artists, and how this might be accomplished]".

It's best just to read that article, but the crux of the argument is
that artists who contribute artwork to free software games often worry
that their artwork will be "lifted" and dropped into some proprietary
game. In other words, something along the lines of this:

,---------YOINK----------,
| V
.---------------. .---------------.
| FaiF CONTENT | | FaiF CONTENT |
+---------------+ +---------------+
| FaiF CODE | | CLOSED CODE |
'---------------' '---------------'

Where FaiF stands for "Free as in Freedom". The argument is that if
you're producing free-as-in-freedom content, you won't want your
content being lifted and dropped into a proprietary codebase (ie, my
dragon creature which is BY-SA could still be used with a game with a
proprietary engine). Bart has pointed out that if the artwork were
done in something like the GIMP, it would be considered on a separate
layer, so even if copyleft like CC BY-SA were used, it could still be
compromised by being lifted and dropped into a proprietary
codebase... but if the artwork were instead done embedded into the
codebase itself like so:

/* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var smiley = [
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,0,0,0,0,0,0,0,0,1,0,0,1,
0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,
0,1,0,0,0,1,1,1,1,1,1,0,0,0,1,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
];

So, why should artists who use normal, real graphical tools not get
the same copyleft benefit of keeping their stuff protected with the
rest of the program under the GPL as do coders or artists who would
use a text-editor to hardcode their assets into their work? Are
artists being treated as if they are using some sort of second class
citizen copyleft then? Some artists in the FOSS gaming area feel that
they would be. (Some have even expressed interest in preventing
proprietization by using an -NC license, but there's an irony there in
that an NC license is proprietary anyway.)

The proposal then is for a copyleft license whose requirements reach
across the content layer over into the software layer, requiring a
free software licensed engine or etc. Complexities quickly arise as
in terms of "what about viewing the image in a proprietary browser or
other viewer, etc" and Bart has proposed trying to seperate terms out
for that, particularly by doing packaging-based copyleft.

It's easy to be sympathetic about why artists don't want their work
used in a proprietary engine. The issue is complex, and Bart has
tried to weigh out some pros and cons of this in his blogpost above.
There's also some risk in that some authors have expressed interest in
making a separate copyleft license. This could be very unfortunate
for license proliferation reasons, and especially because copyleft
does best when there's a
[http://gondwanaland.com/mlog/2007/12/01/copyleft-pd/ single copyleft license per domain].

But here's another set of likely complexities with this:

'''Number one:''' In the example shown above, in a sense it's not true
that artists get a second class copyleft. The reverse also applies:

.---------------. .----------------.
| FaiF CONTENT | | CLOSED CONTENT |
+---------------+ +----------------+
| FaiF CODE | | FaiF CODE |
'---------------' '----------------'
| ^
'-----------YOINK---------------'

So while it's true that in the dual-layer system, copylefted
free-as-in-freedom content can be "yoinked" and dumped into a
proprietary game or game engine. But the reverse is also true;
copylefted game engine code can also be yoinked and used with to power
a free-engine-yet-proprietary game using proprietary assets. So
second class citizenship is not true; both sides are cat risk of
having their separate layer yoinked and used in something proprietary.

'''Number two:''' Getting the copyleft-works-across-layers bit to work
right without restricting mere viewer programs could be very hard to
write the correct way, could be excessively complex, and could even
end up in a license that's deemed nonfree if done wrong.

'''Number three:''' The current "separate layers" distinction between
code and content may result in some un-ideal circumstances, but people
have come to rely on it, and it's probably significantly easier to
manage things preserving these layers than to change them.

'''Number four:''' There's still a significant amount of copyleft
protection being done on the content layer even if the culture layer
is dropped onto a proprietary software layer. To put it this way: Say
Zynga or Nintendo were to take your CC BY-SA licensed 3d model and
were to drop it into their proprietary game with their proprietary
engine. If the copyleft layer really does span the whole content
layer, then that means that they also have to release all the rest of
their content to stay in compliance, and that's potentially a
tremendous payback on its own in a way.

That said, it's very reasonable that some artists are frustrated with
this copyleft divide and we should take this into careful consideration.

== Increasing/clarifying scope of what's a derivative ==

The 3.0 Creative Commons licenses provide clarification on what is and
isn't an adaptation/derivative as opposed to a mere collection:

For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered
an Adaptation for the purpose of this License.

Various people in the free software gaming community have commented on
the fact that it would be good to get more clarifications in the
license about what's an adaptation, making it clear that combining
works in a game ''is'' a derivative. For example, this "syncing"
example probably intends to cover works such as multiple character
models that are BY-SA all placed together and interacting in the same
file, but it doesn't explicitly say so.

One concern that has been raised is that the part that "binds"
together various assets in a game is the engine itself, and that if
the copyleft doesn't extend to the engine layer, maybe it doesn't
properly encompass all assets:

[asset] [asset] [asset]
\ | /
\ | /
[engine]
|
V
Player experience

There's a good chance this isn't a concern however, as there's plenty
of things that aren't game engines that also load a bunch of separate
components and combine them into a single media experience.

Even so, it would be helpful to make clear that something along the
lines of loading several pieces of media together, for example in a
game, was a clear adaptation.

For specific proposals for 4.0 relating to the scope of SA, visit the [[4.0/ShareAlike#ShareAlike_scope|ShareAlike page]].

== Source release? ==

Right now, unlike the GPL, BY-SA does not have a requirement for
source release. It's been proposed that this could possibly become a
requirement in CC BY-SA 4.0, but this seems unlikely:

* This could mean plenty of works never released with sources before will suddenly become out of compliance
* Unlike with software, where there's a clear binary of source or no source, in other forms of content it's often a gradient. See Big Buck Bunny/Sita Sings the Blues examples described the GPL compatibility section of this document.

It's likely we can't or shouldn't make this a requirement for CC BY-SA
4.0, but perhaps we could improve messaging generally to encourage
more community sharing of sources.

== DRM in BY-SA but not BY ==

In talking to some OpenGameArt members about licensing issues, several
expressed interest in keeping anti-DRM provisions in BY-SA as it's a
copyleft license, but remove them from CC BY (under the rationale the
CC BY approximately the equivalent of MIT/BSD licenses and CC BY-SA
approximately the equivalent of the GPL).

There are specific proposals about addressing DRM in Version 4.0 on the [[4.0/Technical_protection_measures|TPM page]].

<references/>

4.0/Games 3d printing and functional content

2012-12-10T15:10:29Z

LindaL: /* Source release? */

= Background =

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

== Background on separation of functional/software and cultural layers ==

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. (The FSF has held this position or something like it
for a long time; alluded to slightly on their
[http://www.gnu.org/philosophy/free-system-distribution-guidelines.html#non-functional-data distribution guidelines about non-functional data].)

It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code].
<ref>Technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else.</ref> If for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.
<ref>In fact, this issue comes up with Blender all the time, which
*does* have a backend which is scriptable with Python; see Blender's
[http://www.blender.org/education-help/faq/gpl-for-artists/ GPL for
artists page]... although I'm somewhat unconvinced that all of the
statements on that page make sense, it does demonstrate the complexity
of things.</ref>

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have been released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.

Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right when we try to create a new project that combines
cultural and functional works.

(One could possibly ask
[http://www.publicknowledge.org/blog/3d-printing-settlers-catan-probably-not-illeg how far copyright applies to functional 3d printed works]
(and therefore, how far copyleft applies), and there's not much
background to show how it applies at all yet. I'm writing this
assuming it does apply.)

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part?

But most complicated of all, what if you wanted to make a walking
cat-robot that uses a BY-SA cat design (maybe the head of the octocat)
and combines it with the robot chassis and some bears and the bead
belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

= Possible actions =
== GPL compatibility ==

Probably the most actionable and most urgently raised amongst issues
when discussing with relevant community members is that of a one-way
compatibility between CC BY-SA (and probably also CC BY) and the GPL.
It's almost certainly not possible at this point (and probably
undesirable) that GPL->BY-SA compatibility is possible, but if we
choose to do it BY-SA->GPL (and probably BY->GPL) should be.

The benefits of this is that it will resolve the tricky issues with
"interwoven" content and cultural works. Clashes in copyleft licenses
which share the same goals are unfortunate if they block useful things
from being created. As
[https://creativecommons.org/weblog/entry/30676#comment-356183 Arne Babenhauserheide said],

<blockquote>... the case of cc-by-sa not being comptible with the GPL is very sad,
because they share exactly the same goals: Copyleft. Thus their
incompatibility creates a real split in cultural works. If the 4.0
licenses could make it possible to combine cc works under licenses
with compatible concepts (cc by, cc by-sa) with the GPL, that would be
a huge step towards a unified free culture.</blockquote>

So what are potential downsides? The main downside is that
[http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F Creative Commons licenses are not acceptable for software]
and we don't want to spread a misconception that they are. If we go
forward with this, we should develop strong messaging that makes clear
that software should still not be released as BY-SA and that this is
for avoiding conflicts in complicated areas of interwoven cultural and
functional/software works.

The other possible downside is whether or not source requirements for
art might make incorporating BY-SA works with the GPL difficult. Ie,
there is no source requirement for BY-SA, and there is one for the
GPL. The GPL says:

The “source code” for a work means the preferred form of the work
for making modifications to it. “Object code” means any non-source
form of a work.

See also the "source release" section of this document for detailing
on the complexities of source code requirements in BY-SA. But as for
fulfilling the requirements of the GPL, what about the following:

* In programming, the division of what source and object code is well understood. In content it's more of a gradient
* For example, the Blender Foundation releases all the "source code" of its films such as Big Buck Bunny and etc by releasing the .blend files (though it is not a requirement of the license).
* However, what if someone made a remix of Big Buck Bunny where they changed the order of scenes, added a psychadelic overlay, and added new music. But the "source" they worked with was not on the .blend file level, but by remixing the rendered film itself. If incorporated with a GPL'ed work, would the source requirement apply, and would it in fact require sharing the source all the way down to the original .blend files?
* What about a film like Sita Sings the Blues, which is BY-SA but from which the source files were never redistributed at all? It's unlikely the content/code layers would be intertwined if combined with software, but let's pretend for a moment that it was. Would "combining" with a GPL'ed work mean requiring distribution of the original files from which the film was made? What if those were lost? What if there's still a lot you can do without the "original source files", although admittedly not as much as if you had them?
* In other words, just how far does "preferred form of the work for making modifications to it" go down? What if people are remixing it on different layers, and the artists themselves prefer separate layers? Does the GPL give flexibility here?

There is additional discussion about GPL/CC compatibility [[4.0/ShareAlike#Considerations_regarding_compatibility_of_other_licenses| here]].

== Scoping copyleft across and code ==

Bart Kelsey has written an excellent article,
"[http://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html Why we need a stronger copyleft for artists, and how this might be accomplished]".

It's best just to read that article, but the crux of the argument is
that artists who contribute artwork to free software games often worry
that their artwork will be "lifted" and dropped into some proprietary
game. In other words, something along the lines of this:

,---------YOINK----------,
| V
.---------------. .---------------.
| FaiF CONTENT | | FaiF CONTENT |
+---------------+ +---------------+
| FaiF CODE | | CLOSED CODE |
'---------------' '---------------'

Where FaiF stands for "Free as in Freedom". The argument is that if
you're producing free-as-in-freedom content, you won't want your
content being lifted and dropped into a proprietary codebase (ie, my
dragon creature which is BY-SA could still be used with a game with a
proprietary engine). Bart has pointed out that if the artwork were
done in something like the GIMP, it would be considered on a separate
layer, so even if copyleft like CC BY-SA were used, it could still be
compromised by being lifted and dropped into a proprietary
codebase... but if the artwork were instead done embedded into the
codebase itself like so:

/* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var smiley = [
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,0,0,0,0,0,0,0,0,1,0,0,1,
0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,
0,1,0,0,0,1,1,1,1,1,1,0,0,0,1,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
];

So, why should artists who use normal, real graphical tools not get
the same copyleft benefit of keeping their stuff protected with the
rest of the program under the GPL as do coders or artists who would
use a text-editor to hardcode their assets into their work? Are
artists being treated as if they are using some sort of second class
citizen copyleft then? Some artists in the FOSS gaming area feel that
they would be. (Some have even expressed interest in preventing
proprietization by using an -NC license, but there's an irony there in
that an NC license is proprietary anyway.)

The proposal then is for a copyleft license whose requirements reach
across the content layer over into the software layer, requiring a
free software licensed engine or etc. Complexities quickly arise as
in terms of "what about viewing the image in a proprietary browser or
other viewer, etc" and Bart has proposed trying to seperate terms out
for that, particularly by doing packaging-based copyleft.

It's easy to be sympathetic about why artists don't want their work
used in a proprietary engine. The issue is complex, and Bart has
tried to weigh out some pros and cons of this in his blogpost above.
There's also some risk in that some authors have expressed interest in
making a separate copyleft license. This could be very unfortunate
for license proliferation reasons, and especially because copyleft
does best when there's a
[http://gondwanaland.com/mlog/2007/12/01/copyleft-pd/ single copyleft license per domain].

But here's another set of likely complexities with this:

'''Number one:''' In the example shown above, in a sense it's not true
that artists get a second class copyleft. The reverse also applies:

.---------------. .----------------.
| FaiF CONTENT | | CLOSED CONTENT |
+---------------+ +----------------+
| FaiF CODE | | FaiF CODE |
'---------------' '----------------'
| ^
'-----------YOINK---------------'

So while it's true that in the dual-layer system, copylefted
free-as-in-freedom content can be "yoinked" and dumped into a
proprietary game or game engine. But the reverse is also true;
copylefted game engine code can also be yoinked and used with to power
a free-engine-yet-proprietary game using proprietary assets. So
second class citizenship is not true; both sides are cat risk of
having their separate layer yoinked and used in something proprietary.

'''Number two:''' Getting the copyleft-works-across-layers bit to work
right without restricting mere viewer programs could be very hard to
write the correct way, could be excessively complex, and could even
end up in a license that's deemed nonfree if done wrong.

'''Number three:''' The current "separate layers" distinction between
code and content may result in some un-ideal circumstances, but people
have come to rely on it, and it's probably significantly easier to
manage things preserving these layers than to change them.

'''Number four:''' There's still a significant amount of copyleft
protection being done on the content layer even if the culture layer
is dropped onto a proprietary software layer. To put it this way: Say
Zynga or Nintendo were to take your CC BY-SA licensed 3d model and
were to drop it into their proprietary game with their proprietary
engine. If the copyleft layer really does span the whole content
layer, then that means that they also have to release all the rest of
their content to stay in compliance, and that's potentially a
tremendous payback on its own in a way.

That said, it's very reasonable that some artists are frustrated with
this copyleft divide and we should take this into careful consideration.

== Increasing/clarifying scope of what's a derivative ==

The 3.0 Creative Commons licenses provide clarification on what is and
isn't an adaptation/derivative as opposed to a mere collection:

For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered
an Adaptation for the purpose of this License.

Various people in the free software gaming community have commented on
the fact that it would be good to get more clarifications in the
license about what's an adaptation, making it clear that combining
works in a game ''is'' a derivative. For example, this "syncing"
example probably intends to cover works such as multiple character
models that are BY-SA all placed together and interacting in the same
file, but it doesn't explicitly say so.

One concern that has been raised is that the part that "binds"
together various assets in a game is the engine itself, and that if
the copyleft doesn't extend to the engine layer, maybe it doesn't
properly encompass all assets:

[asset] [asset] [asset]
\ | /
\ | /
[engine]
|
V
Player experience

There's a good chance this isn't a concern however, as there's plenty
of things that aren't game engines that also load a bunch of separate
components and combine them into a single media experience.

Even so, it would be helpful to make clear that something along the
lines of loading several pieces of media together, for example in a
game, was a clear adaptation.

For specific proposals for 4.0 relating to the scope of SA, visit the [[4.0/ShareAlike#ShareAlike_scope|ShareAlike page]].

== Source release? ==

Right now, unlike the GPL, BY-SA does not have a requirement for
source release. It's been proposed that this could possibly become a
requirement in CC BY-SA 4.0, but this seems unlikely:

* This could mean plenty of works never released with sources before will suddenly become out of compliance
* Unlike with software, where there's a clear binary of source or no source, in other forms of content it's often a gradient.[http://www.telsgroup.com.de/services/groupage_cargo_transportation_services/ Spedition Sammelgut] See Big Buck Bunny/Sita Sings the Blues examples described the GPL compatibility section of this document.

It's likely we can't or shouldn't make this a requirement for CC BY-SA
4.0, but perhaps we could improve messaging generally to encourage
more community sharing of sources.

== DRM in BY-SA but not BY ==

In talking to some OpenGameArt members about licensing issues, several
expressed interest in keeping anti-DRM provisions in BY-SA as it's a
copyleft license, but remove them from CC BY (under the rationale the
CC BY approximately the equivalent of MIT/BSD licenses and CC BY-SA
approximately the equivalent of the GPL).

There are specific proposals about addressing DRM in Version 4.0 on the [[4.0/Technical_protection_measures|TPM page]].

<references/>