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.

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.

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.

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