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 this out; MedicineStorm is right and I have clarified as such in the attribution instructions. Let me know if this is still unclear.
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!
I re-drew (traced really) the windmill blades at 2x resolution and added intermediate frames (so 8 instead of 4). I also recolored the water wheels into the LPC palette (I might make larger versions of them at some point too). My edits are CC0, just credit Ivan if you use.
Also, would you be willing to license this set under the OGA-BY 3.0+ license (in addition to CC-BY)? https://opengameart.org/content/oga-by-30-faq . I would like to incorporate this into another set of assets that will be OGA-BY.
Yes, when you are ready to share, click the "Submit Art" button and upload your new image; for each image you used, you need to provide credit (list the URL, name of the artist, what license(s) the art was provided under---you can find this on the left-hand side of the submission page, and the title of the artwork). You can provide credit as a .txt file (this is what I usually do), or you can provide this information in the "Copyright/Attribution Notice" section. You can see some examples on my profile of how I credit different works that went into my submissions. See https://opengameart.org/content/faq#q-how-to-credit for more details about crediting, and feel free to ask here if you have more specific questions.
As for your pixel art, you're off to a nice start---I like the latticework!
I'd suggest you check out the LPC style guide if you haven't already---there are some good tips in there on perspective and light source that will be helpful to you: https://lpc.opengameart.org/static/LPC-Style-Guide/build/styleguide.html . There are also some general purpose pixel art tutorials linked at the bottom there that you might review.
The two things that stand out stylistically to me: 1) the roof and the stone quoins from Roots' submission have much thicker outlines and more noise than the other tiles. I would suggest reducing the width of the black outlines until they are closer to 1px. Also get rid of some of the "noise"---try to make the blocks of the quoins each a solid color, then add more detail bit-by-bit. 2) the light source, which should be above, in front, and slightly to the left, is not consistent. The right side of the gable roof should be slightly darker. I also would expect the front-facing roof to be somewhat lighter, or at least not much darker than the left-side of the gable.
Additionally, I notice if you zoom in, that the timber-framing of the front of the house is blurry. This is usually caused by scaling or rotating pixel art using a tool like GIMP, which will use bilinear filtering or similar method to interpolate images. For pixel art, you don't want this---if you must scale, always use "nearest neighbor" interpolation or similar, then manually clean up the results.
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 pointing this out; MedicineStorm is right and I have clarified as such in the attribution instructions. Let me know if this is still unclear.
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!
What a weird and neat submission!
The floor is by SpiderDave, CC0 https://opengameart.org/content/wallpaper-pattern-tiles-0 so you can just credit them (or not).
Hi, could you bump this asset? I added an animated cannon (thanks castelonia!): https://opengameart.org/content/lpc-siege-weapons
11:56 UTC for me!
I re-drew (traced really) the windmill blades at 2x resolution and added intermediate frames (so 8 instead of 4). I also recolored the water wheels into the LPC palette (I might make larger versions of them at some point too). My edits are CC0, just credit Ivan if you use.
Also, would you be willing to license this set under the OGA-BY 3.0+ license (in addition to CC-BY)? https://opengameart.org/content/oga-by-30-faq . I would like to incorporate this into another set of assets that will be OGA-BY.
Thanks again for the beautiful assets!
Welcome and thanks for contributing!
Yes, when you are ready to share, click the "Submit Art" button and upload your new image; for each image you used, you need to provide credit (list the URL, name of the artist, what license(s) the art was provided under---you can find this on the left-hand side of the submission page, and the title of the artwork). You can provide credit as a .txt file (this is what I usually do), or you can provide this information in the "Copyright/Attribution Notice" section. You can see some examples on my profile of how I credit different works that went into my submissions. See https://opengameart.org/content/faq#q-how-to-credit for more details about crediting, and feel free to ask here if you have more specific questions.
As for your pixel art, you're off to a nice start---I like the latticework!
I'd suggest you check out the LPC style guide if you haven't already---there are some good tips in there on perspective and light source that will be helpful to you: https://lpc.opengameart.org/static/LPC-Style-Guide/build/styleguide.html . There are also some general purpose pixel art tutorials linked at the bottom there that you might review.
The two things that stand out stylistically to me: 1) the roof and the stone quoins from Roots' submission have much thicker outlines and more noise than the other tiles. I would suggest reducing the width of the black outlines until they are closer to 1px. Also get rid of some of the "noise"---try to make the blocks of the quoins each a solid color, then add more detail bit-by-bit. 2) the light source, which should be above, in front, and slightly to the left, is not consistent. The right side of the gable roof should be slightly darker. I also would expect the front-facing roof to be somewhat lighter, or at least not much darker than the left-side of the gable.
Additionally, I notice if you zoom in, that the timber-framing of the front of the house is blurry. This is usually caused by scaling or rotating pixel art using a tool like GIMP, which will use bilinear filtering or similar method to interpolate images. For pixel art, you don't want this---if you must scale, always use "nearest neighbor" interpolation or similar, then manually clean up the results.
Good luck!
Pages