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 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 this wesnoth level file which looks like mostly data and this boss file from Frogatto that looks like code. ^[1] 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. ^[2]

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 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 MakerBot Thing-O-Matic. But here's an iteration of the 3d printer called the 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 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 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:

• RepRap 3d printer (on which most modern 3d printers are based)
• Bead belt gear

BY-SA things:

• Motorized functional differential gear system
• Robot chassis
• Octocat

BY things:

• 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 Arne Babenhauserheide said,

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

So what are potential downsides? The main downside is that 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 here.

Scoping copyleft across and code

Bart Kelsey has written an excellent article, "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 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 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 TPM page.