I guess we just disagree, because I still think my approach is clearer :p Just to emphasize a few points:
- Separating into different questions per-audience makes it easier to answer the specific questions people actually ask (on the forum, on discord, etc.), namely "can I use this art in my game?" or "what license should I choose?". If I imagine answering such a question with the current text, I'm basically telling someone "look, just go understand the licenses," which feels less helpful to me than "you can use the art if you think about/address the following issues: A, B, C, D"
- Organizing by audience rather than by license means there is less duplicated information when talking about different licenses (e.g. the issue of credit is discussed once, the issue of share-alike/copyleft is discussed once, etc.). I don't really feel there is much duplication between the "can I use this art?" and the "what license should I choose" questions that I posted above, and together they are about the same length as the new/current "What do the licenses mean?" question
- Finally, my descriptions are more conceptual, introducing the reader to the issues at play (attribution, copyleft, open source, DRM), then explaining how they apply to the different licenses in the hypothetical question-asker's position (e.g. as an artist or as a dev).
Anyway, I'm not going to write much more on this; if you haven't been persuaded by my arguments so far, then we probably just have a different perspective and that's fine :) I'll allow others to weigh in, and/or MedicineStorm to decide; if the consensus is that withthelove's combined approach is clearer, that's fine.
Finally, I want to express again my gratitude to withthelove for working on this, years before I even thought about it!
Is my game a "derivative work" (also known as an "adaptation") of the artwork?
I prefer my approach (from the final section of my last post) here as well.
I think this approach is better because it:
1) clearly enumerates the known and agreed up cases where a work is a derivative
2) stops there with minimal speculation as to what else might or might not be a derivative.
Again, I prefer what I wrote :p I tried to achieve those same two goals, but with a few differences:
This "what is a derivative work" issue applies to both GPL and CC-BY-SA, so I tried to write an answer that applied to both
My answer makes clear at the beginning that this issue depends on copyright law and thus can't be answered except by a court. Your answer gets around to this point but, IMO, gives the misleading impression that CC (or the FSF, in the case of the GPL) could just give clearer guidance about games but refuse to do so for some reason.
Similarly, saying things like "CC has clarified..." doesn't feel quite right to me, because ultimately it's not CC who decides how the license is interpreted, but the courts. The person you spoke with at CC spoke with some authority because she was a copyright lawyer who had studied the relevant legal cases, not because she worked at CC per se. So I tried to speak more generically, rather than being like "CC says this." Maybe that's splitting hairs. (By the way, I found both that email exchange you reproduced and the conversation you had with the lawyer very helpful!)
I agree there probably should be a section that talks about the license version numbers. How about somethig simpler and more to the point, ie adding the question:
I agree with adding a separate question about this (it was on my list under "Why should I always choose "Allow later versions of the same license" when submitting to this site?"); I think what you have written is good for that. One thing I would add is that "Allow later versions" also allows your art to more easily be combined with art under later versions. There is some slight complication with combining CC-BY 3.0 and CC-BY 4.0, for instance, which would be resolved by licensing work A under "CC-BY 3.0 and later".
@medicinestorm: I see the proposed changes have made it up onto the site. Excelsior!! I guess we can now start calling it the 'current site text' instead of the 'proposed text' :)
I have some minor comments about the current text, if that is what we end up keeping, but I'll save those for later.
I'm submitting art/music to the site. What license should I choose?
First, if you are modifying an existing work, see #q-modified-work-licenses, as the license of the existing work will constrain your choices.
The license you choose depends on what you want to require of someone (e.g. a game developer) who uses your work; viewed another way, some licenses (e.g. the GPL and CC-BY-SA) attempt to preserve the rights of others to use and modify your work. Therefore the best license for your work depends on your values.
If you want anyone to use your work for any purpose, perpetually, worldwide, without any restrictions whatsoever, choose CC0. This releases your work into the "public domain" and allows anyone to use it, modify it, and distribute it without crediting you.
If you want to be credited for your work...
...but otherwise want to place no other restrictions on its use, choose OGA-BY 3.0 (or later). This license allows anyone to use your work (including [in a game that uses DRM](#q-drm)), provided they credit you.
...but don't want your art used in programs that use DRM, choose CC-BY 4.0 (or later).
...and want to make sure that any derivatives of your artwork can also be freely used by others, choose CC-BY-SA 4.0 (or later).
If you want to be sure your art can be used in larger projects that are licensed under the GPL v3, choose CC-BY-SA 4.0; CC-BY-SA 4.0 is compatible with the GPL v3 (link) but also has terms that are more clearly applicable to art than GPL v3.
We do not recommend you use CC-BY 3.0, CC-BY-SA 3.0, or GPL 2.0 unless you have no other choice because you are creating a derivative. Those licenses have all been improved upon by later versions, so if you have the choice, you should use the latest version. For the same reason, we recommend always checking "Allow later license versions," because there may well be improvements to these licenses in the future; see {#q-allow-later-versions}.
I have used artwork from this site in my game. Is my game a "derivative work" (also known as an "adaptation") of the artwork?
Short answer: probably yes, but it depends.
Applicable copyright law determines whether one work is a "derivative" of another. (CC licenses call this an "adaptation"). That means the answer to this question depends on the specific facts of your game, the jurisdiction, and ultimately how a court of law interprets those facts, the license, and the law. Therefore the only person who can definitively answer this question is a judge ruling on a case. For a more informed answer to this question, you should seek legal advice.
That said, here is some general guidance and some resources to better understand this issue:
A "derivative work" (or "adaptation") must "add original expression to [a] pre-existing work," although the standard for originality differs by jurisdication <https://creativecommons.org/faq/#what-is-an-adaptation>. Therefore, merely reproducing one work within another doesn't necessarily make the second work a derivative. For example, CC has advised that reproducing an image in a book or blog post is not sufficient to make the blog post itself a derivative of the image. By this logic, including an unmodified spritesheet in a game may not make the game a derivative work.
On the other hand, if a graphic comes with a developed character or story line then a game using those character or story elements may be considered a derivative work.
The CC-BY-SA license specifically states that syncronizing a CC-BY-SA licensed sound or music work to a moving image as creating a derivative work.
For the GPL, the question of whether an asset is functional or "merely aesthetic" may have some bearing on whether the program is a derivative of an asset.
I'm a commercial (closed-source) game developer. Can I use this art?
Short answer: Yes, you can use this art, even in commercial projects, as long as your follow the terms of the license. You cannot use the GPL for closed-source projects that you intend to distribute.
All of the licenses on this site allow use in commercial products. However, you still need to comply with the terms of the specific license. See #q-licenses for a brief description of the licenses on this site. If an asset is released under multiple licenses (#q-multilicense), you can choose any one of them and follow the terms of that license; for example, if an asset is available under both CC-BY 3.0 and GPL 3.0, you don't need to worry about the terms of the GPL---you can just follow the term of the more lax CC-BY 3.0.
In general, there are four issues your need to consider as a developer:
1) Attribution (credits): all licenses here except CC0/public domain require you to provide proper credit to the author (see #q-how-to-credit).
2) "Copyleft"/"Share-alike": the GPL and CC-BY-SA licenses require that "adaptations" (CC-BY-SA calls them "adaptations") be made available under the same license as the original work (i.e. the artwork you are using from this site); this is known as a "copyleft" or "share-alike" provision. What constitutes a "derivative work" is not determined by the license, but rather by applicable copyright law; therefore it is hard to say, in every case, whether using artwork in your game makes your game a derivative work. (see #q-why-conflicting-advice) The best way to be sure is to seek legal advice about your specific situation. The most conservative approach is to assume that your game is a derivative of any artwork/assets you use, that the copyleft provisions of the license apply, and thus if you distribute you game you need to do so under the same license as the artwork/assets.
3) Open source: The GPL requires that, if any GPL-licensed material is incorporated into a program, the source code for the entire program must be made available under the GPL; for example, copying GPL-licensed code into your game means the game code must be available under the GPL. Does using GPL-licensed art in your game impose the same requirement? It probably depends on how the art is technically incorporated into your game, whether the art serves a functional or purely aesthetic purpose, and perhaps other factors. (We say "probably", because this issue has not been tested in the courts (#q-why-conflicting-advice)). The safest option, and the one recommended by the Free Software Foundation, is to release your source code under the GPL when using GPL-licensed artwork.
Note that while CC-BY-SA is a copyleft license, it is not an open-source license; that is, unless the source code for your game is somehow derived from the artwork, merely using the artwork in your game does not require you to release the source code.
4) Additional restrictions (e.g. DRM): The GPL, CC-BY, and CC-BY-SA licenses all prohibit you from applying additional restrictions that interfere with the ability of other users to exercise their rights---namely to use, modify, and distribute the artwork under those licenses. In practice, this means that you cannot incorporate DRM into your game or distribute it on a platform that requires DRM. See {#q-drm} for details.
May I suggest that we move forward with getting the updated license descriptions posted to the site and then work on any other questions/answers we want to update/add/tweak on the FAQ pages?
Certainly! Sorry for introducing all the other questions; I agree that the "what do the licenses mean" and "I'm a commercial (closed-source) game developer. Can I use this art?" should be addressed first. However, I'll suggest a slightly different way of looking at this issue. Overall, I pretty much agree with everything withthelove says in the post above. Thanks by the way for all your work on this so far.
I agree that "what do the licenses mean" and "I'm a commercial/closed source developer; can I use this?" should be two different questions, because even though they'll contain overlapping information, they can be written with different (specific) audiences in mind. Sure, if someone perfectly understood what the licenses meant, they wouldn't need this FAQ. At some point, anyone using these assets for a big project will probably need to read the license text, but we can help them by providing some general information. Further, there are good resources (like the CC license summaries or the FSF's extensive FAQ page about the GPL) that describe the features of the licenses in general. We don't need to reproduce that guidance in its entirety here, but we can point people towards it. What we can do here is provide context and guidance that might help people who are specifically interested in creating and/or using the art here for games.
To that end, it might even make sense to have four questions:
"What are the different licenses on this site, and what do they mean?" (general information).
"I'm submitting art/music to the site. What license should I choose?" (information for artists).
"I'm developing a closed-source game using art from this site. What do I need to know?".
I have used artwork from this site in my game. Is my game a "derivative work" (also known as an "adaptation") of the artwork?
Separating the answers to these different audiences would mean we could keep the descriptions of each license shorter, more like the current FAQ, while providing clearer guidance in each scenario that is more conceptual and less of a laundry list.
MedicineStorm probably won't like question #4, but I think it's helpful. Even though we seem to agree its impossible to provide hard-and-fast advice on this, I think it would be worth giving some general guidance/resources about this issue, as withthelove has proposed. We don't have to account for every possible scenario or answer questions that are unsettled copyright case law (like, "what is a derivative work").
With all that in mind, in subsequent posts I'll propose answers to these questions. I find myself most interested in #3, #4, and #2, and I think after those are written, it will be easier to trim down the answer to #1.
Final thought, should add a blurb in there somewhere about being careful about mixing CC-BY-SA and non-CC-BY-SA assets? Maybe that's a separate question, since it could be a problem more generally (eg mixing assets of different licenses).
I think this is a separate question; I've drafted an answer to "I want to combine two assets under different licenses; is this allowed?" but per your request I'll save that for now to stay on topic.
Just finished reading over this very long thread. I had started a separate draft of answers to several questions, but it will take me some time to edit those. Here are the questions I was working on:
Can I use the art I find here? How should I credit the artist?
I'm a commercial (closed-source) game developer. Can I use this art?
What do the licenses mean?
My game is distributed with DRM. Can I use artwork from this site in my game?
Are CC-BY and CC-BY-SA incompatible with the GPL?
I want to combine two assets under different licenses; is this allowed?
I want to modify an asset; what license(s) can I use for the modified asset?
I want to combine two assets, one that is CC-BY 3.0 and one that is CC-BY 4.0; is this allowed?
Why should I always choose "Allow later versions of the same license" when submitting to this site?
What is "copyleft trolling" and how can I protect myself against it?
I asked about the same licensing issue in two places and got two different answers. Why am I getting conflicting advice?
For now, let me contribute the email exchange I had with the FSF's GPL compliance lab (my message in blockquotes, their response set to the left)
***
Subject: Incorporating GPL-licensed data into a non-free program
Hello and thank you for writing in.
I am helping to update the FAQ page for the website OpenGameArt.org, which allows users to share and download artwork and music for video games under various free/libre licenses, including the GPL v2 andv3. I am looking for clearer guidance to this common question:
A piece of artwork is licensed under the GPL v3. I want to use it in my game. Does including the GPL-covered artwork in my game require me to release the source code to my game under the GPL v3?
Let's assume that the artwork (images, music, etc.) is not linked into the executable, but loaded by the program at runtime; assume therefore that the artwork can be replaced with a similar file (for example, an image file with the same dimensions in the same format) and the program will still run. Finally, assume that all other requirements to use the artwork under the GPL are met (e.g. license is specified, attribution is provided, source, e.g. .xcf files are made available where relevant).
On the one hand, I could read section 5(c) to mean that the entire work (e.g. the game) must be GPL-licensed because the Program (e.g. the artwork) is GPL-covered, and therefore the game source must be distributed. On the other hand, it seems that reading the artwork as data, as I have described, might be the type of "arms-length" communication described here <https://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem>. At issue seems to be whether the type of interaction I've described constitutes *incorporating* the GPL-covered artwork into the larger work (the game). For instance, if the artwork were baked into the executable, it would seem clear that the GPL-covered art is part of the game... although maybe that distinction is irrelevant, much like static vs. dynamic linking.
I have found oblique references on OpenGameArt.org and other sites to guidance the FSF may have issued in the past about this issue, but never anything concrete, so I apologize if this question has been answered before.
First, this applies not only to non-free licenses (as written in the subject of your email) but to any GPL-incompatible license. A license can be a free software license and at the same time be GPL-incompatible (for a conspicuous example: "GPLv2-only" is a free software license, yet incompatible with GPLv3.)
Therefore, I'll avoid talking about proprietary licenses. Those should those be discouraged because they are an injustice. But there are practical issues as well. A proprietary license can have any terms at all, including terms which make combining with free software of any kind impossible. For instance, a proprietary license can explicitly prohibit any work licensed under the GPL in any form (there are organizations, such as Apple, who have certain platforms carrying such prohibitions: https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforce...). Therefore, you may do well to remind people that compatibility is a two-way street.
So instead I'll address the issue of free software licenses which are nevertheless GPL-incompatible.
The terms of the GPL apply if and when the work would be considered a derivative under copyright law. So that is the crux of the matter. There isn't a lot of useful case law in this area (assets vs. software), so it has been hard to develop any hard-and-fast guidance. If a program expects to use a particular resource, a "foo001.png", so that it can be displayed as an integral part of the interface (or similar), then the FSF recommends that "foo001.png" would be licensed in a compatible manner. This is also a practical recommendation since the functionality of the software would be hurt by needing to replace "foo001.png" with an equivalent image. This is not to say that "foo001.png" is definitely a derivative (this is something that only a court of law can ultimately decide) but nevertheless the FSF would like to see compatibility in this area in order to steer people away from trouble.
The proverbial waters get murkier when we are dealing with graphics engines, API, fetching remote resources, using system fonts, etc. At one point it becomes hard to differentiate those from a general-purpose image viewing program, which is generally understood to have no mutual licensing obligations in regards to the work it is displaying (similar to GCC and the code it compiles: http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF)
I hope this is of help.
***
For me, the takeaways from this message and from withthelove's conversation with CC is very similar: the key issue is whether the game is a derivative work of the art---this determines whether copyleft/share-alike provisions apply. Unfortunately this is not settled case law and therefore pretty much impossible to give definitive guidance about. The most conservative advice would probably be "assume your game is a derivative of the artwork and thus copyleft/share-alike rules apply; if you think that might not be the case, get legal advice." That still seems like a pretty good answer to me.
(Edit 2023-01-21: slight formatting change to more clearly separate the beginning/end of the FSF email from my commentary)
Thanks for pointing out; the inverted female halberd seems like a mistake. Also we will probably be able to adapt this to use the same sprite for both male and female bodies now.
Yes, I will address the other issues, thanks! (Might take a few days).
Please share any other suggestions or issues you encounter!
I actually missed that Sara has a unique tunic; I'll adapt that to the updated bodies and add to the generator. Everything else is due to simple mistakes with file names and such; should also be easy to fix.
Please let us know if you notice any other issues!
Hello! Would you consider licensing this armor set under the OGA-BY 3.0 (and later) license?
OGA-BY has the same rules as CC-BY, but it also allows works to be used in games that contain DRM, such as on the iOS app store.
Thanks for your thoughtful reply, withthelove.
I guess we just disagree, because I still think my approach is clearer :p Just to emphasize a few points:
- Separating into different questions per-audience makes it easier to answer the specific questions people actually ask (on the forum, on discord, etc.), namely "can I use this art in my game?" or "what license should I choose?". If I imagine answering such a question with the current text, I'm basically telling someone "look, just go understand the licenses," which feels less helpful to me than "you can use the art if you think about/address the following issues: A, B, C, D"
- Organizing by audience rather than by license means there is less duplicated information when talking about different licenses (e.g. the issue of credit is discussed once, the issue of share-alike/copyleft is discussed once, etc.). I don't really feel there is much duplication between the "can I use this art?" and the "what license should I choose" questions that I posted above, and together they are about the same length as the new/current "What do the licenses mean?" question
- Finally, my descriptions are more conceptual, introducing the reader to the issues at play (attribution, copyleft, open source, DRM), then explaining how they apply to the different licenses in the hypothetical question-asker's position (e.g. as an artist or as a dev).
Anyway, I'm not going to write much more on this; if you haven't been persuaded by my arguments so far, then we probably just have a different perspective and that's fine :) I'll allow others to weigh in, and/or MedicineStorm to decide; if the consensus is that withthelove's combined approach is clearer, that's fine.
Finally, I want to express again my gratitude to withthelove for working on this, years before I even thought about it!
Again, I prefer what I wrote :p I tried to achieve those same two goals, but with a few differences:
I agree with adding a separate question about this (it was on my list under "Why should I always choose "Allow later versions of the same license" when submitting to this site?"); I think what you have written is good for that. One thing I would add is that "Allow later versions" also allows your art to more easily be combined with art under later versions. There is some slight complication with combining CC-BY 3.0 and CC-BY 4.0, for instance, which would be resolved by licensing work A under "CC-BY 3.0 and later".
I have some minor comments about the current text, if that is what we end up keeping, but I'll save those for later.
I'm submitting art/music to the site. What license should I choose?
First, if you are modifying an existing work, see #q-modified-work-licenses, as the license of the existing work will constrain your choices.
The license you choose depends on what you want to require of someone (e.g. a game developer) who uses your work; viewed another way, some licenses (e.g. the GPL and CC-BY-SA) attempt to preserve the rights of others to use and modify your work. Therefore the best license for your work depends on your values.
We do not recommend you use CC-BY 3.0, CC-BY-SA 3.0, or GPL 2.0 unless you have no other choice because you are creating a derivative. Those licenses have all been improved upon by later versions, so if you have the choice, you should use the latest version. For the same reason, we recommend always checking "Allow later license versions," because there may well be improvements to these licenses in the future; see {#q-allow-later-versions}.
I have used artwork from this site in my game. Is my game a "derivative work" (also known as an "adaptation") of the artwork?
Short answer: probably yes, but it depends.
Applicable copyright law determines whether one work is a "derivative" of another. (CC licenses call this an "adaptation"). That means the answer to this question depends on the specific facts of your game, the jurisdiction, and ultimately how a court of law interprets those facts, the license, and the law. Therefore the only person who can definitively answer this question is a judge ruling on a case. For a more informed answer to this question, you should seek legal advice.
That said, here is some general guidance and some resources to better understand this issue:
Some additional resources about this topic:
I'm a commercial (closed-source) game developer. Can I use this art?
Short answer: Yes, you can use this art, even in commercial projects, as long as your follow the terms of the license. You cannot use the GPL for closed-source projects that you intend to distribute.
All of the licenses on this site allow use in commercial products. However, you still need to comply with the terms of the specific license. See #q-licenses for a brief description of the licenses on this site. If an asset is released under multiple licenses (#q-multilicense), you can choose any one of them and follow the terms of that license; for example, if an asset is available under both CC-BY 3.0 and GPL 3.0, you don't need to worry about the terms of the GPL---you can just follow the term of the more lax CC-BY 3.0.
In general, there are four issues your need to consider as a developer:
1) Attribution (credits): all licenses here except CC0/public domain require you to provide proper credit to the author (see #q-how-to-credit).
2) "Copyleft"/"Share-alike": the GPL and CC-BY-SA licenses require that "adaptations" (CC-BY-SA calls them "adaptations") be made available under the same license as the original work (i.e. the artwork you are using from this site); this is known as a "copyleft" or "share-alike" provision. What constitutes a "derivative work" is not determined by the license, but rather by applicable copyright law; therefore it is hard to say, in every case, whether using artwork in your game makes your game a derivative work. (see #q-why-conflicting-advice) The best way to be sure is to seek legal advice about your specific situation. The most conservative approach is to assume that your game is a derivative of any artwork/assets you use, that the copyleft provisions of the license apply, and thus if you distribute you game you need to do so under the same license as the artwork/assets.
3) Open source: The GPL requires that, if any GPL-licensed material is incorporated into a program, the source code for the entire program must be made available under the GPL; for example, copying GPL-licensed code into your game means the game code must be available under the GPL. Does using GPL-licensed art in your game impose the same requirement? It probably depends on how the art is technically incorporated into your game, whether the art serves a functional or purely aesthetic purpose, and perhaps other factors. (We say "probably", because this issue has not been tested in the courts (#q-why-conflicting-advice)). The safest option, and the one recommended by the Free Software Foundation, is to release your source code under the GPL when using GPL-licensed artwork.
Note that while CC-BY-SA is a copyleft license, it is not an open-source license; that is, unless the source code for your game is somehow derived from the artwork, merely using the artwork in your game does not require you to release the source code.
4) Additional restrictions (e.g. DRM): The GPL, CC-BY, and CC-BY-SA licenses all prohibit you from applying additional restrictions that interfere with the ability of other users to exercise their rights---namely to use, modify, and distribute the artwork under those licenses. In practice, this means that you cannot incorporate DRM into your game or distribute it on a platform that requires DRM. See {#q-drm} for details.
Certainly! Sorry for introducing all the other questions; I agree that the "what do the licenses mean" and "I'm a commercial (closed-source) game developer. Can I use this art?" should be addressed first. However, I'll suggest a slightly different way of looking at this issue. Overall, I pretty much agree with everything withthelove says in the post above. Thanks by the way for all your work on this so far.
I agree that "what do the licenses mean" and "I'm a commercial/closed source developer; can I use this?" should be two different questions, because even though they'll contain overlapping information, they can be written with different (specific) audiences in mind. Sure, if someone perfectly understood what the licenses meant, they wouldn't need this FAQ. At some point, anyone using these assets for a big project will probably need to read the license text, but we can help them by providing some general information. Further, there are good resources (like the CC license summaries or the FSF's extensive FAQ page about the GPL) that describe the features of the licenses in general. We don't need to reproduce that guidance in its entirety here, but we can point people towards it. What we can do here is provide context and guidance that might help people who are specifically interested in creating and/or using the art here for games.
To that end, it might even make sense to have four questions:
Separating the answers to these different audiences would mean we could keep the descriptions of each license shorter, more like the current FAQ, while providing clearer guidance in each scenario that is more conceptual and less of a laundry list.
MedicineStorm probably won't like question #4, but I think it's helpful. Even though we seem to agree its impossible to provide hard-and-fast advice on this, I think it would be worth giving some general guidance/resources about this issue, as withthelove has proposed. We don't have to account for every possible scenario or answer questions that are unsettled copyright case law (like, "what is a derivative work").
With all that in mind, in subsequent posts I'll propose answers to these questions. I find myself most interested in #3, #4, and #2, and I think after those are written, it will be easier to trim down the answer to #1.
I think this is a separate question; I've drafted an answer to "I want to combine two assets under different licenses; is this allowed?" but per your request I'll save that for now to stay on topic.
Hi all,
Just finished reading over this very long thread. I had started a separate draft of answers to several questions, but it will take me some time to edit those. Here are the questions I was working on:
For now, let me contribute the email exchange I had with the FSF's GPL compliance lab (my message in blockquotes, their response set to the left)
***
Subject: Incorporating GPL-licensed data into a non-free program
Hello and thank you for writing in.
First, this applies not only to non-free licenses (as written in the subject of your email) but to any GPL-incompatible license. A license can be a free software license and at the same time be GPL-incompatible (for a conspicuous example: "GPLv2-only" is a free software license, yet incompatible with GPLv3.)
Therefore, I'll avoid talking about proprietary licenses. Those should those be discouraged because they are an injustice. But there are practical issues as well. A proprietary license can have any terms at all, including terms which make combining with free software of any kind impossible. For instance, a proprietary license can explicitly prohibit any work licensed under the GPL in any form (there are organizations, such as Apple, who have certain platforms carrying such prohibitions: https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforce...). Therefore, you may do well to remind people that compatibility is a two-way street.
So instead I'll address the issue of free software licenses which are nevertheless GPL-incompatible.
The terms of the GPL apply if and when the work would be considered a derivative under copyright law. So that is the crux of the matter. There isn't a lot of useful case law in this area (assets vs. software), so it has been hard to develop any hard-and-fast guidance. If a program expects to use a particular resource, a "foo001.png", so that it can be displayed as an integral part of the interface (or similar), then the FSF recommends that "foo001.png" would be licensed in a compatible manner. This is also a practical recommendation since the functionality of the software would be hurt by needing to replace "foo001.png" with an equivalent image. This is not to say that "foo001.png" is definitely a derivative (this is something that only a court of law can ultimately decide) but nevertheless the FSF would like to see compatibility in this area in order to steer people away from trouble.
The proverbial waters get murkier when we are dealing with graphics engines, API, fetching remote resources, using system fonts, etc. At one point it becomes hard to differentiate those from a general-purpose image viewing program, which is generally understood to have no mutual licensing obligations in regards to the work it is displaying (similar to GCC and the code it compiles: http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF)
I hope this is of help.
***
For me, the takeaways from this message and from withthelove's conversation with CC is very similar: the key issue is whether the game is a derivative work of the art---this determines whether copyleft/share-alike provisions apply. Unfortunately this is not settled case law and therefore pretty much impossible to give definitive guidance about. The most conservative advice would probably be "assume your game is a derivative of the artwork and thus copyleft/share-alike rules apply; if you think that might not be the case, get legal advice." That still seems like a pretty good answer to me.
(Edit 2023-01-21: slight formatting change to more clearly separate the beginning/end of the FSF email from my commentary)
Thanks for the report! We are aware of this problem and will fix it shortly, along with a few other kinks that came up in the recent giant refactor.
Feel free to post any future bug reports here https://opengameart.org/forumtopic/lpc-updated-spritesheet-generator?page=2 or open an issue on Github https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen... .
Let us know if you discover any other issues or have other feeback!
Thanks for pointing out; the inverted female halberd seems like a mistake. Also we will probably be able to adapt this to use the same sprite for both male and female bodies now.
Yes, I will address the other issues, thanks! (Might take a few days).
Please share any other suggestions or issues you encounter!
Hey, thanks for pointing out these issues. We missed some of these in the process of the recent massive clothing refactoring https://opengameart.org/content/lpc-clothing-updates .
I actually missed that Sara has a unique tunic; I'll adapt that to the updated bodies and add to the generator. Everything else is due to simple mistakes with file names and such; should also be easy to fix.
Please let us know if you notice any other issues!
Pages