What started as a simple question in an artwork comment evolved into a rather large set of thoughts. Sorry about that, I should have pulled back and posted in the forums here instead. :)

[Amendment to original post that I cannot edit in this forum because it was posted for me: "CC-BY-CA 3.0" was a typo that I pasted everywhere in order to avoid a typo. (That didn't work out very well for me, did it.) What I meant was "CC-BY-SA 3.0". And I don't care if periods are supposed to appear inside of quotations!]

Oh dear, my response is embarrassingly long. But I believe it is a worthwhile set of thought exercises on this matter. Herein you'll find a mix of precise arguments as well as arguments that are less clear, with the occasional redundant redundancy, but thought provoking nonetheless. I wrap up my response with some considerations that are important whether the rest of my thinking is right or wrong. So get yourself a coffee, sit back, and enjoy. :)

First of all, thank you for your thorough and thoughtful response. No worries about the uncertainty that you expressed, I'm figuring all this out as well. I believe you have substantiated my thoughts though with your two initial arguments when taking into consideration the hierarchy of the elements that have been presented in the diagram in my original post.

First and foremost, the art is always included in the game, whereas the creation software is not.

Perhaps a little misunderstanding. I didn't say anything about creation software, but rather a game engine. (ImpactJS is a great example of a game engine that requires a paid proprietary license in order to use it: http://impactjs.com) In fact, a licensed proprietary game engine will always be included in the game as an immutable element on top of which the game programming is based. This is in direct contrast to your assertion that the creation software is not included in the game. (Which is why I believe you misunderstood what I meant by game engine in what you said here. But later it seemed like you may have understood what I meant when you talked about software libraries.)

I'm going to walk through a thought exercise in order to create a clear perspective about a pattern of how the different elements interact with each other so that a more precise understanding can be established. Please note: Since the central question pertains to the source code of the Game Project, I want to basically equate my use of the word "Game Project" as the "project's source code" or "whatever technical mechanics used to create the game layer; source code basically" wherever you find the word Game Project used.

What we have in my diagram above are logically separate layers where items on top are fundamentally dependent upon the layers immediately below them. Without the existence of a compatible Operating System (imagine the required Operating System(s) mysteriously disappear from the universe), then the Game Engine has nothing on which to run, none of the low level commands that the Game Engine relies upon exist. The Game Engine becomes useless bits and bytes sitting on hard drive platters along with a whole lot of other useless bits and bytes. Without the Operating System, there can be no Game Engine in the first place. Instead of the Operating System disappearing, lets make the Game Engine disappear from the universe. Suddenly, your Game Project is completely crippled, unable to run, because your Game Project code relies on critical API calls to Game Engine mechanisms that render the game experience. Without the given Game Engine, you cannot even build the Game Project on top of that Game Engine in the first place. Now, instead of that, your Game Project code disappears from the universe. Without your Game Project code, the Artwork does not have a way to be displayed in your game. There is no delivery mechanism for the Artwork, which means that the Artwork is dependent upon the Game Project code. (Granted, the Artwork can still be used in someone else's game, but that argument doesn't contribute anything about the nature of how these hierarchical layers are applied to a given Game Project, which is what we're talking about here--thus mentioning other games in this context is a logical misdirection from the point being made. I just wanted to preempt this line of thought.) Without the Game Project, there is no need for Artwork in the first place. And finally, if the Artwork disappeared from the universe, than the Changes to Artwork that you made to the Artwork become a crazy display of irrelevant pixels with no overall image context. Without the Artwork, there can be no derivative Changes to Artwork in the first place.

Now, let's take the same approach in reverse. You will see that the exact opposite happens. If your Changes to Artwork disappear from the universe, the original Artwork is unaffected. The Game Project still works. Perhaps a little funky depending on how critical the Changes to Artwork were, but nothing actually affects the operation of the game. The Game Engine still works for people. The Operating System still works for people. Now, if the Artwork disappears from the universe, again the Game Project still works. You may need to probe the system's internal memory or read database variables directly in order to get user feedback for what is happening inside of the game while you are playing it, but the game is in fact operating and working. (Maybe the AI is playing against itself, you just can't see it easily, hah!) Now, if the Game Project disappears from the universe, the Game Engine isn't broken. Its APIs still have the ability to do what they are supposed to do, nothing is actually broken with the Game Engine. If the Game Engine disappears from the universe, the operating system continues to run just fine.

Ok, with all that understood, we should be able to understand the questions that come up about it. A good first question is, what does this understanding say about the definition of a derivative work? We know that a derivative work is something that changes the original, something that is built on top of it. What we see from the above thought exercise is, a primary characteristic of a derivative work is, if the original that the derivative is based upon does not exist, the derivative itself is impossible or broken in some completely fundamental way. Here you can see a pattern in the diagram that shows a series of derivative works all on top of one another. Derivatives happen as you go up the diagram, but not down. If there is any question about the derivative relationship between the game and its artwork, consider this: You are making a change to the composite whole of a game by changing the artwork (thus making a derivative of the game), but you are not changing individual pieces of artwork by putting a game underneath it. To derive the individual piece of artwork, you must make pixel changes to the artwork. Changing the game underneath the artwork does not create a derivative of the piece of artwork any more than transporting a famous painting from one museum to another creates a derivative of that painting.

It's a lot easier to make the argument that the game is a derivative work of the art than it is to say that the game is a derivative work of the creation software.

This is interesting because the game as a whole is a work of art. Any change that you make to one of the game's components creates a derivative of that game. If you change the source code to change the game's functionality, the game has become a derivation of its previous state. If you swap out a piece of artwork with another piece of artwork, the game is derived again. But here's the thing, the very nature of what makes a game manifest as "art" happens at a level above what makes its artwork "art". The artwork and source code within a game is analogous to the pigments chosen for a painting. The artwork is indeed "art", and so is the game, but what makes the artwork "art" is not the same thing that makes the game "art". From this I derive the following quotable quote: "By including the artwork in the game, you are changing the 'art' of the game, but you are not changing the 'art' of the artwork." To do that you must make pixel changes. Thinking of this in terms of art levels, pixel changes are at the "art" level of the artwork. The artwork itself is at the "art" level of the game. So then, while changing the artwork in a game changes the "art" of the game, what makes the artwork itself "art" is not what makes the game "art".

What strikes me at this moment as I write this is, just the fact that you are able to remove artwork and replace it with a completely different set of artwork in a game without any source code changes means that artwork is a completely logically separate layer in the game, and logically separate layers like this can be licensed separately. Nothing prevents a game maker from using different pieces of artwork from different licensed sources. One piece of art is licensed one way, another piece of art is licensed another way. Each piece of art can retain its own license without interference from any of the other pieces of art. Since every piece of artwork within the game is legally separate from one another, why wouldn't the "art" of the game itself (the "game art level") be considered its own separate piece of art just like all the other art?

You could look at a game as if it were a museum of art. If art in a museum has different contracts with different artists who have different requirements to display their art, those pieces of art are completely separate from one another. But the museum is ITSELF a work of art the same way that a game would be considered an art. (Museums are forms of art that contain art.) But all the art in question, including the museum itself, are separate from each other. Things that affect a given piece of art pertain only to that piece of art. Now, if the owner of the land that the museum is built on decides to evict everyone at the museum and tear the whole thing down, that affects the museum, but the artists with art on display inside of the museum do not have that same authority. This leads me to your next point.

Secondly, sometimes the license of the creation software can actually have an effect on the license of the game.  For instance, if I used GPLed game creation software that comes with a GPLed redistributable library to go along with the game executable, since my game is linking to that library, it triggers the GPL's linking requirement and my game legally has to be GPLed (interestingly enough, the FSF has clarified that art does not trigger the GPL's linking requirement, but the CC has made no such statements about any of their licenses to my knowledge).  As an aside, the linking requirement of the GPL gets violated all the time, but it is still technically there, and if someone wanted to enforce it, they could.

When the current operation of the game's state is dependent upon the library, the game is beholden to that library's requirements as long as it depends on it. The operation of the game's mechanical state is not dependent upon any artwork at all. The execution of game logic via the source (the source is what is in question here) continues to run just fine with black pixels instead of artwork. Like the museum's land owner, the library that the game's operation is utterly dependent upon has jurisdiction over the terms of its existence. Your game can be retooled to use a different library instead, but the museum can also move its marble walls to a different plot of land. (Note that the required retooling that makes it different from its current state of operation in order to function with a different library is not like artwork that doesn't require any code retooling when the artwork is swapped out.)

Yes, an artist can refuse to allow their art to be on display in the museum unless the museum pays them, but ultimate jurisdiction of the artist over the museum itself doesn't exist because the art is not what keeps the walls of the building standing. The land is. In the same way, the art in a game does not give the game its ability to function, so while the use of art in the game can require royalties to be paid, it cannot have jurisdiction to impose a license change to the whole game and all of its assets. OR MAYBE IT DOES?! Like an egregiously unreasonable artist, maybe it can try to make these kinds of demands?! But the question is, does CC-BY-SA 3.0 do this? I think that is the whole point that I am trying to get to. Maybe CC-BY-SA 3.0 does do this! But based on my arguments I think it would be egregiously unreasonable if it did. This means all the more that strong notice perhaps should be given to discourage the use of it. Unless your artists want to make these demands, which like I said, I really don't think that majority of your artists are intending this. Think about it, if CC-BY-SA 3.0 really does say this, that means your artists are telling everyone that they want everyone to open source their entire game, all of its other art assets and its source code, in order to use their art. Those are high demands that no museum would accept. Why should the game world be any different? Again, I really don't think this is what most who choose CC-BY-SA 3.0 are intending. Furthermore, this makes me increasingly skeptical that CC-BY-SA 3.0 is to be interpreted that way.

A game is still arguably art, although in a different medium, so it could easily be argued that your game that you make with a piece of art is a derivative of that art.

You might be able to argue that all the game's components and the way they are arranged together give rise to its own layer of art (as explained) that can be derived by changing the underlying components. But identifying the individual components and asking the question whether those individual components also instantly become derivatives when merely included in the whole is a different question. I would say that the source code is one such component. The source code is logically separated from the rest of the art just as the art pieces are separate from each other. (More so actually.) So that, if it were determined that other art components are immune from being re-casted as derivatives, the source code would have to be immune from this perception even more. So the question remains, when the whole game all-together is considered a derivative, must the other individual components be considered derivatives as well? I'm now remembering the form of art where you have tiny pictures that make up big pictures. (According to The Internet, it's called a "photo-mosaic".) What do licenses have to say about each and every one of those tiny photos in terms of how they affect one another once they appear together inside of a huge photo-mosaic? I'm guessing (hoping?) they don't affect one another, the same way that arrangements for art in a museum do not affect the legal arrangements made over other art in the same museum. The source code of a game is just another separate piece of art in the photo-mosaic of the game.

I just thought of a real scenario that puts a very substantial bind on the practicality of CC-BY-SA 3.0 if it is defined the way you have been thinking. It can make some artwork legally mutually exclusive from each other. Let's say I have an open source game that uses CC-BY-SA 3.0 artwork freely all over the place. But I have this one piece of artwork that is co-licensed to me such that I do not have the right to share the rights of that piece of artwork with others. (Interestingly, I personally possess the rights to a lot of artwork that matches this description. You might happen to be familiar with the IconBuffet license; something that was up and running several years ago.) If CC-BY-SA 3.0 forces all other artwork in a project to also become CC-BY-SA 3.0, that's a problem for the IconBuffet license that does not allow me to transfer that right to everyone else. But CC-BY-SA 3.0 forces me to? See, this is why these licenses just can't be written in a way to conflict with one another in a project. I mean, maybe they do, but they shouldn't. In any case, you know where I'm going with this. The source code is at the same level as "other artwork" as mutually separate components of the game project.

My thoughts congealed more as I wrote them. I think an important approach to understanding this can be summarized as follows. In a game project, every piece of artwork, including the source code, are all logically orthogonal toward each other. You can swap any of them out or make changes to them and it doesn't affect any of the other pieces in any way. However, any change to artwork or source code will cause the game itself to change or become a derivation of what it was before. The game itself behaves as a container for artwork and source code. The game itself is what gets derived by the selection of the artwork, not the source code, which is merely a separate piece of the game at the same hierarchical level as the artwork. So the question is, under CC-BY-SA 3.0, when the artwork is simply used INSIDE of artwork, does the outer artwork that contains it become a derivative/changed work of the artwork inside of it? And if so, does that cause all of the other separate inner artwork that happens to also live inside of the same outer artwork to instantly inherit the status of a "derived" work as a contiguous part of the whole, thus requiring every separate component to become licensed under CC-BY-SA 3.0? Does "use of the artwork within a context" equate to "changed or derived"? Does "use of the artwork within a context" cause the context itself to become transformed into a seamless part of the artwork? If so, is this true for websites? Like Google? Has a game ever been legally defined as "art"? Has a museum ever been legally defined as "art"? Have you ever met someone named Art? Can you think of any words in the English language that rhyme with "art"? Have you ever stubbed your toe and used "art" as a swear word? Can I license a black pixel #000000 under CC-BY-SA 3.0 like a legal virus and claim that all artwork and its software and associated business methods on the Internet are now licensed under CC-BY-SA 3.0 and must be opened so that I can use it in my similarly licensed works?

The rest of what you wrote about licensing being really hairy and a source of pain for you shows me that you might strongly consider making it really clear to artists what these issues are when they submit. Make sure they know that if they intend to have a maximum amount of adoption of their work and receive visible recognition for it in return, what licenses to use and what licenses to avoid. Let them know that some licenses are legally confusing and warn them about which ones, maybe even color coding legally confusing ones in red when they are prompted to make a selection. Some licenses will remain hairy. You can't change that. But you can get rid of much of the pain by letting artists know which ones are truly ambiguous and which ones clearly match the intentions that they have for their work.

Yes, an artist may choose to use an ambiguous license for some innocent purpose that we cannot think of, but warning artists about which licenses are ambiguous will provide developers like me with a more effective filter when we weigh the risk of using art from an artist that may actually intend to trap developers down the road and sue them.

It's a lot easier to make the argument that the game is a derivative work of the art than it is to say that the game is a derivative work of the creation software.

I should address this a little more. I'll assume by creation software you mean game engine like ImpactJS, since that is the sort of thing I was originally talking about. Going with that then, you implied that it is not as easy to argue that a game is a derivative work of its game engine. You said that it is more clear that a game is a derivative work of the art. Ok, let's run with that angle.

Artwork may derive the game, yes, but the artwork does not derive the source code, does it? I don't see where it does. Nothing about the source code changes when you swap out an image. Ok then. If artwork that derives the game requires that the source code become CC-BY-SA 3.0 just because the source code is required for the operation of the game, then the source code becoming CC-BY-SA 3.0 must also mean that the game engine become CC-BY-SA 3.0 since the game engine is required for the operation of the source code. And if the game engine becomes CC-BY-SA 3.0 because it is required for the operation of the source code, then operating systems must also become CC-BY-SA 3.0 because operating systems are required for the operation of the game engine. This rules out all projects from using CC-BY-SA 3.0 artwork for all time.

To understand this better, what if you created your own game engine in order to create the source code for your game? Your game engine would be a part of the game project and therefore forced into CC-BY-SA 3.0. Going the next step, what if you created your own operating system in order to support the game engine? Your operating system would be part of the game project and therefore forced into CC-BY-SA 3.0. All 3 of these things are merely layers of dependent software. In fact, your game source code may have its own separate layers of dependent software; are you familiar with MVC? Software in layers support the game and those layers start at the deepest levels, even to the operating system. So then, why would someone else's game engine layer (ImpactJS) and someone else's operating system layer (Windows) be immune to the CC-BY-SA 3.0 license creep when your own layers aren't? On which layer does the CC-BY-SA 3.0 creep end? I say that it ends at the artwork itself and before the source code because, as stated, the source code is not a derivative work of the selection of artwork.

this is why i have stuck to cc by

this started out as an explanation of why you believe I'm wrong about CC-BY-SA and then transitioned into an opinion piece about why you think it's unreasonable for artists to want their work to only be included in FOSS projects.  It's not my place (or yours) to tell artists whether the conditions they're putting on the use of their art are egregious or unreasonable in any way.

Ouch, it looks like what I wrote really did come across that way. I'm genuinely sorry about that. Sometimes I launch into a brainstorming mode of pontificating ideas in order to keep the thought stream going while clumsily not considering the social ramifications of some of the things that I write. I don't mean to insult anyone. I'm really just generating thoughts and ideas here. Please forgive me.

The important point to come out of that is, many artists aren't going to realize that they are imposing those kinds of restrictions when choosing that license (assuming we conclude the license is interpreted that way). I wholeheartedly agree that artists are not being unreasonable by contributing free art to us, regardless of the terms that they choose. But that's just it. Are they really choosing the license that they want when the license isn't clear? It is only fair to them that they are given the opportunity to understand what it is that the terms that they have chosen actually mean. And if that cannot be determined by us or even by lawyers until cases have been decided in court, then those licenses are truly ambigious and dangerous for all parties involved, including the artist who wants to know what terms they are intending to place on their artwork.

Still stinging from my mistake, I want to be clear. I really didn't want to say that the artists here are being egregious or unreasonable. Even those who intend to force projects to become open sourced by the inclusion of their work. It's no less fair for them to do that as it is fair for them to withhold the work entirely. So I definitely agree with you. I was just firing a loose cannon with my analogy of artists at an art gallery who would make those kinds of demands of the museum. I think a lot of artists on here don't actually intend to force legal restrictions on everyone when they provide their art, but I am very willing to learn the mind of those artists who do have that purpose and what makes that a good thing for them.

At this point given our current level of understanding about these matters, I completely agree with the rest of your response. Law is a very fuzzy thing, which drives programmers like us nuts! Thank you for bearing with me as I make mistakes and learn the culture of this environment. And thank you for giving my ideas thoughtful consideration.

On CC BY-SA:

"This license requires you to release the source your entire project under the same license or one with similar terms, such as the GNU GPL."

I think this is still incorrect - the licence can only be distributed under the same (or later version of the same) licence, i.e., CC BY-SA.

I think this misconception came about because the "human readable summary" contained the phrase "similar", but this was never in the licence itself. Instead it said you had to use one of the licences listed at https://creativecommons.org/compatiblelicenses ,but it says "Please note that to date, Creative Commons has not approved any licenses for compatibility". They've now updated the human readable summary to just say "same license", together with a link to the compatible licences URL.

Similarly for "This license requires you to release the any modifications to the art under the same license or one with similar terms, such as the GNU GPL." should just say "same license".

"Does using CC-BY-SA art require that an entire project be released as open source?"

I think the question of whether the SA requirement apples to the entire project is a red herring - even if it did apply to the entire game, it would mean that the game has to be released as CC BY-SA. Which is an Open/Free licence, but doesn't require that one must release the source code.

So I'd say that we can definitely say that there's no requirement to release source code - but it's unclear whether they would have to release the game as CC BY-SA.

If you don't mind, I'd like to use this thread to draft out changes to the faq.

Everything I have written in this thread I gladly release as CC0 for anyone to use and distribute and re-license however they please. ;D

If you've got time, I'd appreciate your input. :)

I'll have more time to look over all this later tonight and tomorrow morning and provide input.

I'll be back in a little bit. Thanks again for spearheading such a wonderful and gracious community. I really mean that. This is a rare gem on the Internet.

I think the question of whether the SA requirement apples to the entire project is a red herring - even if it did apply to the entire game, it would mean that the game has to be released as CC BY-SA. Which is an Open/Free licence, but doesn't require that one must release the source code.
-----
Ah, good point.  I'll update the question in a little while and post a new one.
...
Does using CC-BY-SA art require that an entire project be released as open source?
In brief: No, but it may or may not require that the whole project be released as CC-BY-SA.

Are we able to make that determination definitively? Do we know for sure that if the entire game becomes CC-BY-SA whether the source code becomes CC-BY-SA? If the source code is CC-BY-SA, doesn't that mean that "you must distribute your contributions under the same license as the original." Maybe if the game is compiled, it means that the binary becomes CC-BY-SA and only requires you to distribute the binary, since the source is merely a tool to build the game/binary and is not the game/binary itself. But are we saying we know this for sure? Can we really say "no" about the source code from this?

If the game is distributed in binary form, I don't see anything in the CC BY-SA licence that suggests one must release source code (either specifically source code, or in general, anything that was used to create the project)?

(I guess if we're uncertain, perhaps it's better to simply say nothing on the matter, which at least is much better than saying something incorrect.)

Who cares if you can or can't release the source code if the final product can still be freely distributed?  There is little commercial point in being closed-source if the end product is still not effectively monetizable.  (edit: and by "effectively monetizable" I mean effectively monetizable in traditional closed-source fashion, of course.  Even if your source is closed, if people are legally allowed to share the final product you're going to have some troubles).

Yeah, maybe I can buy into that. It would be kind of like being forced to distribute the Gimp XCF file or the Photoshop PSD file for all of the layers and such where the XCF or PSD is the "source" that "compiles" into the PNG that you distribute. CC-BY-SA only requires the PNG to be distributed.

@Redshrike - If it's for a web game that you monitize, providing the compiled form (.pyc for python for example) may indeed allow someone to host your game on some other domain and monitize it for themselves, but it's not going to be as easy for them to customize it to differentiate it from your original game to sway your audience away from you. It's still possible, just not as easy, just like handling the PNG is possible, just not as easy as the XCF or PSD file. For some, like a certain project I have in mind, that may be good enough.

Another question now.

If I use CC-BY-SA artwork in my game, does that mean that I am no longer allowed to also use artwork that I license from places like Icon Shock or Getty Images or iStockPhoto? Or even other licensed aspects of your game, maybe ImpactJS (that can't really be fully compiled by the way), that grants you rights to use it but does not allow you to share it for someone else to use? In other words, is CC-BY-SA mutually exclusive from using it alongside other artwork? CC-BY-SA forces you to choose to either go the CC-BY-SA route and use only CC-BY-SA compatible artwork, or abandon CC-BY-SA altogether and go the other route with a different set of artwork? That kind of makes CC-BY-SA artwork impossible for many projects that would have been willing to keep with CC-BY-SA. It's even ruled out by small CC-BY-SA projects that have the potential to grow and expand later on. Given this, it seems that artists who choose CC-BY-SA are not really interested in people using their artwork except for a small few that don't plan on having anything substantial going on (be it either open or closed source).

Can I distribute my project on the Apple App Store, or other distribution platforms that impose mandatory technical measures (DRM) to prevent redistribution?

Generally no, unless the art you're using is licensed CC0 or OGA-BY (note: I believe it's time to add the new license along with the changes to the FAQ.  It's clearly needed).  CC-BY, CC-BY-SA, LGPLv3 and GPLv3 all have clauses that explicitly prevent technical measures (DRM) that prevent redistribution of the work in question.  In addition, the Apple App Store terms of service conflict with the terms of the GPL, rendering the GPLv2 and LGPLv2 also incompatible with the app store.

The restriction on DRM in CC-BY was relatively unknown until recently, and has come as a surprise to many artists on OGA.  If you want to release a game on the App Store (or some other distribution platform with mandatory DRM), you can contact the artist directly and get their explicit permission.  Permission from the author of a work is in itself a license, and can override any other restrictions the license may place on redistribution.

@Bart could you elaborate about the 'The restriction on DRM in CC-BY was relatively unknown until recently, and has come as a surprise to many artists on OGA'  bit. Please share some info. or links which tell about the matter a bit more. - bart 

@shirish

'The restriction on DRM in CC-BY was relatively unknown until recently, and has come as a surprise to many artists on OGA'  bit. Please share some info. or links which tell about the matter a bit more. - bart

It was not shown on the deed until recently, so people would just read the deed and not know about the restriction.

@mdwh

Creative Commons interpurates the liscense in that way, thats part of the problem.

@Blender

according to the liscense, that is correct, sort of, its ambiguious...

I dont think thats what artists want but thats what they are doing, the ambiguity leaves it open to interpuration.

A GREAT example of the problem is this, the apple app store packages the art inside a .app file, IT DOES NOT CHANGE THE ART IN ANY WAY, an .app file is a zip with a changed extention, however because there is a text file inside the zip that the binary NOT the ART reads and uses as DRM you cant use CC art in the app store???

huh?

As such they interperate that if a binary uses or reads the art it must be covered under CC as well, that or there just crazy, i personally lean twords the latter...

Can I distribute my project on the Apple App Store, or other distribution platforms that impose mandatory technical measures (DRM) to prevent redistribution?

What if your Apple app is nothing more than a webkit wrapper around a web game? The graphics then aren't a part of the app at all, the app becomes just a specialized web browser that points to your game.

@Botanic - Yes, it's really ambiguous. Earlier, bart made a really good point: "Ambiguities in a license aren't always the end of the world, so long as the license clearly allows at least some things and clearly disallows others." Which is true even of CC-BY-SA to be useful for something. However, is it true enough of CC-BY-SA to be useful in games?

Can we enumerate a list of things that CC-BY-SA IS clear enough about to be useful in games?

If this is off-topic, just tell me to shut up:

So indicating (in the app) where the art can be accessed freely doesn't satisfy the anti-drm clause? I can't prevent the app store from DRMing the artwork, but I can provide an alterante avenue for the artwork to be obtained by anyone who wants it.

Kinda like saying "oh, it's DRMed here, sure. but right over here we un-DRMed it." If that isn't enough to satisfy the anti-drm clause, then does that mean I can't imbed pieces of the artwork in scripting data for quicker loading even though I also provide the same artwork un-obfuscated in the next folder over?

Ah. "parallel distribution". So my example of obfuscated art alongside unobfuscated art would probably work since it is the same distribution(?)

But the "see my website for artwork downloads!" example would clearly not work.

Thanks! That is excellent not-legal-advice.

While I'm a fan of FOSS ideas I don't see how cc-by-sa could force the source of a project to be released under the same license. Making a project so closely related to graphics/sound to become a derivative of that asset would be almost as absurt as making a program compiled for a particular OS an extension of that OS; it doesn't make sense, they are separate. A graphic can be used in any medium where graphics can be displayed on a screen. How does a graphic being included in a game make the game reliant on it so heavily that it becomes a derivative work of that graphic? Further still, if we did assume somehow magically this were true how could anyone make a game (or anything else for that matter) that used cc-by-sa assets along side anything else? Even further still, how would cc-by-sa make sense for code vs. creative content since it's a creative content license, not a code license?

I love the annual CC-By-SA discussion.  Same time next year, then?

Seriously, if Creative Commons would just officially clarify this stuff in the license text once and for all, we wouldn't need to endlessly speculate about it.  Until then, I'm personally sticking with CC0 and CC-By.

@William.Thompsonj - You put into a short paragraph what I spent pages and pages to explain in my follow-up posts. Gah, when will I ever learn?! :D

@MoikMellah: There may not be an annual discussion about this next year. It looks like Creative Commons did exactly that; it clarified this once and for all so that we don't need to endlessly speculate about it. bart posted the link right before your response: http://wiki.creativecommons.org/4.0/Games_3d_printing_and_functional_content . The page was last modified January of last year, before your previous annual discussion. But who has time to keep up with all this discussion and documentation, right?

New question, now about GPL!

I have no idea if the following reasoning is correct, please help me understand. (Please adjust my thinking accordingly.) But as I dig into all this, here is what I'm seeing at the moment for GPL.

Since GPL does not apply to art assets, only code, if an artist on here were to license their art under the GPL, then the result is, only the parts of their artwork that contain code (none of it has code usually) is what applies as I carry it into my game project.

So, under standard GPL, if I have a project with code and art assets in it that I license under GPL, the GPL license on that project only pertains to the source code. Nothing is imposed by the GPL onto the art assets in the project. (Another license is needed in addition to cover art assets.)

Follow my progression of reasoning real quick:

Ok, so what if my project had very very little code along with art assets. Again, just the very very little code is covered by GPL, the art assets still aren't touched by GPL in any way.

Ok, what if the very very little code shrinks until my project contains no code whatsoever. That means the GPL does not apply to any code, but it still does not apply to the art assets. The GPL doesn't suddenly apply to the art assets if the code in the project shrinks to zero. So adding GPL to artwork is like adding a GPL license to an empty set of non-existent code characters.

I don't think you can apply GPL to an empty set of code that has never been written. So you shouldn't be able to even apply GPL to artwork; the license would be instantly void.

So then, if you have artwork that you license under GPL, the GPL simply does not apply. Then when I bring the art into my project, the GPL simply falls right off (or wasn't even applied in the first place). Putting only GPL on your artwork causes it to have no license, making it undeclared, which is the same as public domain. (Unless you have additional licenses attached of course.)

Selecting GPL for artwork with no source code is equal to not selecting GPL for it at all. GPL may still be valuable to have on OGA because artists might release source code as part of their artwork, albeit rarely. Assuming GPL isn't removed as an option from OGA, at the very lease IMHO artists need to be strongly warned that GPL will not apply to their artwork in most cases unless it is made up of source code that basically renders that artwork. IMHO artists need to be informed of this at the time they are selecting GPL as their license. If they uploaded a PNG or something, GPL shouldn't even be provided as an option to them because it becomes a mismatch in its domain of applicability and leads to confusion.

To tie up the loose end in my reasoning above, I cannot apply GPL to the empty set of non-existent code. If I were allowed to do this, then everybody who applies the empty set of non-existent code inside of their source code would be forced to GPL their code. Since ALL source code both simultaneously includes and excludes the set of non-existent code as per set theory, ALL source code in the universe would be forced to be GPL. Therefore, the GPL necessarily falls right off the empty set of non-existent code, and as it falls of, it orthogonally passes right by the art assets that accompany it because the art assets aren't covered by the GPL.

That was a little complicated, but I think it is clear reasoning. The post made immediately before this may have some assumptions that I cannot see, thus my request for correction if I fail to understand this properly.

GPL is an option for artwork because it's a left-over from assets submitted under the LPC. The LPC assets and code were dual-licensed under GPL and CC-BY-SA. Your set theory idea about GPL not having an effect on art is correct. GPL art or music can only trigger attribution, not change the license of source code. GPL code cannot force art assets to become GPL licensed. DRM is not allowed by anything that includes GPL assets or code so still can't be used in the apple store or on steam without permission to waive this clause by the author/creator.

@Blender:

"But who has time to keep up with all this discussion and documentation, right?"

Who indeed?

Chris Webber's article on the CC Wiki does shed some light on the discussion, pretty much the same amount of light as it did when I linked to it last year (in the exact comment I linked to above).  Yet, the debate rages on.

More to the point, by my estimation BartK himself has had several changes of opinion on CC-By-SA:

- When he wrote the original FAQ, he was convinced that CC-By-SA covers code/binaries.

- When he wrote this quite insightful piece on FreeGamer, he was convinced that CC-By-SA does NOT cover code/binaries.  See also this discussion on the debian-legal mailing list, where he also advocates for an art license which covers entire projects (because as he stated, there wasn't one yet which does).

- Sometime before this discussion, he became convinced once again that CC-By-SA DOES cover code/binaries.

- As of reading Webber's article, he is now again convinced that CC-By-SA does NOT cover code/binaries.

I'm not faulting BartK for this - nobody here has put more thought into open asset licensing than he has, and he revises his stance when new facts come to light to ensure that his users have the most accurate information possible.  Again, this points to the fact that CC as an organization desperately needs to clarify the meaning of their legal terms - not just in a post on their wiki, but as I stated above, IN THE LEGAL TEXT OF THE LICENSE.

Regarding GPL and its application to art, that's a whole other can of worms - prepare to endlessy argue about the meaning of "preferred form of the work for making modifications to it".  I won't debate it here, because any point I could make on the subject has been made by countless others before - Google will point you to a thousand debates on the subject.

But who has time to keep up with all this discussion and documentation, right?

GNU clarified (very clearly) on their site that graphics, fonts, and geographic data are not considered software, they are static resources that are linked by software. GPL does not apply itself to graphics, font, or geographic data when included as part of a software package that is contained by GPL. GNU also recommends CC-BY-SA for non-software works that aren't attached to a project because GPL isn't suited for non-software. GPL is pretty cut and dry, there's not a lot of room for discussion on that one (anymore).

@William.Thompsonj:

Even that is muddled by the How to Choose a License section of their own site, which also states very clearly that you CAN apply it to "graphics, font, and geographic data", so long as it "is copyrightable and has a clear preferred form for modification" (opening the can of worms I mentioned earlier).  There is room for discussion, so long as GNU doesn't even have a clear consensus on their own site.

**Edit: For clarity, I absolutely agree with you that GPL'd code does not affect the licensing of other assets in the project.  My quibble is only over whether art can/should be released under a GPL license on its own, which has long been a fuzzy topic.

**Moar edit: ..which you have addressed already.  Disregard this entire comment, as I entirely missed your point (which I now see and agree with completely).

Lol, you're funny MoikMellah. I do that too. I'll read something and miss a major point, only to address some small bit that's an off-topic thought. Later, I'll go back to re-read the thread and realize I talked about something different or semi off-topic that was already addressed.

I agree that GPL *can* be applied to non-software, it just doesn't serve much functional purpose outside of requiring attribution and stopping DRM.

Is Public Domain incompatible with CC-BY-SA? Let's say I have a Public Domain icon in my game. Inside of the same game I have a CC-BY-SA icon in some other area of the game interface. Now, both icons exist as game content in the same game content layer, though separate in the interface. Since this one icon is CC-BY-SA, the entire game's content is forced to be licensed under CC-BY-SA, including the Public Domain icon. So doesn't that mean I am forcing the Public Domain icon to no longer be Public Domain and to now fall under CC-BY-SA? So, when I distribute all of my game's assets inside of a zip file under CC-BY-SA, the exact same icon file that was given to me under Public Domain I am redistributing as CC-BY-SA. Since it's impossible to have the authority to do that, it means I am not allowed to use Public Domain works inside of my game. All because I am using a CC-BY-SA icon.

Strictly speaking, it's starting to look again as though CC-BY-SA isn't of practical use to almost anyone.

The comment I just posted above jumped to a new question before resolving this final GPL question. You said something about "LPC" in regards to GPL. I have no idea what LPC is. I tried some Google searches and still am not sure. Any help with that? :D

Really thankful to you all for helping me understand all this!

This article gives me second thoughts about the legality of anything that we might do with Creative Commons (particularly SA), even if we're non-commercial and open source:

http://opencontent.org/blog/archives/347

Thinking through what I read there, it seems like in practice it's unlikely that someone can maneuver in this space without utilizing or combining something in a way that ends up being accidentally illegal. (Even if the project is non-commercial and open source.) It all comes down to hedging our bets about whether someone sensitive is going to blow a whistle about it. People like me who do want to stay completely within the law are going to feel better off staying away from all this and instead save up money to hire artists for commissioned work. (Which is a good thing! But there's a lot of good work out there that artists want to contribute freely to culture and I am more than happy to utilize what they've got.) I'm kind of sad about this, but life and development goes on.

At some point I need to make and stick to a decision about my protocols for artwork selection based on licenses. Can anyone give me a bottom line rule of thumb what course I should take if I'm wanting to stay within clear legal and ethical boundaries for a closed source commercial game? I'm guessing Public Domain is ok. How about CC-BY. How about GPL? What if someone adds "Public Domain" along with some other license? Is it the restrictive license that trumps the loose one? Or does the loose license downgrade the restrictive one? Etc.

Sorry Blender, hard habit to break. Here are some links to the LPC contest and the content submitted:

• http://lpc.opengameart.org/
• http://lpc.opengameart.org/static/lpc-style-guide/styleguide.html
• http://opengameart.org/lpc-art-entries
• http://opengameart.org/forums/liberated-pixel-cup
• http://opengameart.org/lpc-code-entries
• http://opengameart.org/content/liberated-pixel-cup-0

In response to your first comment about CC0 and CC-BY-SA: The creative commons licenses don't glom onto everything like GPL, they are specifically written to be self-contained. Having an asset that is CC-BY-SA does not cause anything else to change or gain that license, only that one specific asset and any derivatives will be forced to have that asset.

"Can anyone give me a bottom line rule of thumb what course I should take if I'm wanting to stay within clear legal and ethical boundaries for a closed source commercial game? I'm guessing Public Domain is ok. How about CC-BY. How about GPL? What if someone adds "Public Domain" along with some other license?"

I think I can give some answers:

- Closed Source project + GPL assets = usually no go (LGPL allows use in closed source)

- Public Domain is free in any case. You can always use that.

- If work is published under multiple licenses, you can choose the license that fits your needs best. You only have to meet one license' requirements, not all.

- "Commercial" ist not a problem with GPL, "closed" is.

But I'm not a lawyer, this is just my opnion.

First off, I am not a lawyer and nothing I write is legal advice.

I disagree about some of the comments regarding the GPL. At the bottom of this post I quote the relevant parts of the GPL.

It's all about whether art can be licensed under the GPL, how meaningful that is and what consequences the source requirement has. Speaking as one who has deliberately used the GPL for game art (independent from the LPC), I use one of mine as an example: http://opengameart.org/content/cuyo-levels-balls-at-easefrightened-balls... which is vector art produced by a program written in OCaml.

First, applicability of the GPL: Yes, the GPL is applicable to any copyrightable work. It prefers to call that work "program" throughout the license, but it makes it very clear that that is just a name.

Putting the work under the GPL triggers the famous consequences: Copyleft (derived works must be licensed the same way) and distribution in source form. Now what is the source form? By definition it is "the preferred form of the work for making modifications to it". If in doubt, the preferred form is the form that the author used for her own editing. In my example it would be the OCaml code. (Let me clarify: The program is not a general vector art editor. Its functionality consists only of rendering these specific images. To produce other images, I wrote different programs using the same libraries. And no, this has not been an exercise in creating GPL corner cases. This was the actual work flow that made sense for that particular project.) Other examples of source code for visual art are:
- layered images like Gimp's xcf format
- files in Blender's or Inkscape's format (whatever that is)
- Povray sources
- the images themselves. A png might very well be its own source.

Most importantly: It does make sense to license art under the GPL. As much as it does for programs. It's about letting others benefit from one's work under the condition that they return the favour (with respect to their derived works). And that only works as long as the source forms are commited.

As a side note, I am not a full fan of the GPL. I does have issues, its apparent inapplicablility to art being one of them. My personal response has been to switch to my own license.

bart:
> The GPL is a license that is intended for computer source code, and
> certain parts of the GPL (such as references to the source code of a work)
> have no legally consistent meaning with respect to art.

Yes, the GPL was created with only programs in mind, but I contest the second part of your statement.

Blender:
> Since GPL does not apply to art assets, only code, if an artist on here
> were to license their art under the GPL, then the result is, only the
> parts of their artwork that contain code (none of it has code usually)
> is what applies as I carry it into my game project.

I hope I managed to defeat that assumption. I agree about the no-impact-on-engine part.

William.Thompsonj:
> GNU clarified (very clearly) on their site that graphics, fonts, and
> geographic data are not considered software, they are static resources
> that are linked by software. GPL does not apply itself to graphics,
> font, or geographic data when included as part of a software package that
> is contained by GPL.

While I agree with the statement, I believe it is irrelevant how GNU interprets the GPL. What matters is what the GPL actually says. And maybe how the licensor interprets it.

William.Thompsonj:
> I agree that GPL *can* be applied to non-software, it just doesn't serve
> much functional purpose outside of requiring attribution and stopping DRM.

It provides copyleft and a source requirement.

As promised, here are the relevant parts of the GPL. First version 2:

| 0. This License applies to any program or other work which contains
| a notice placed by the copyright holder saying it may be distributed
| under the terms of this General Public License. The "Program", below,
| refers to any such program or work, [...]
| 3. [...]
| The source code for a work means the preferred form of the work for
| making modifications to it. [...]

Now version 3:

| 0. Definitions.
| [...]
| "The Program" refers to any copyrightable work licensed under this
| License. [...]
| 1. Source Code.
| The "source code" for a work means the preferred form of the work
| for making modifications to it. [...]