I don't think it applies to them. The rest of that answer reads:
"What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
Graphics would generally be used in forms similar to command-line arguments, and as such seemingly would be "mere aggregation". This answer in that FAQ is also relevant for this issue:
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
"If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program." If this is the case for plug-ins, then graphics and other sorts of content would be fine too. Furthermore, as I said previously, a lot of projects use different licenses for code and artwork - meaning that there is a general understanding that they are in mere aggregation. There are also commercial games that have code under the GPLv2, while keeping the artwork proprietary (an example: Frogatto) - if they can do this, then you can also the reverse, and have proprietary code and open-source artwork.
Using the LPC graphics for your game would AFAIK constitute "mere aggregation" (otherwise games like 0 AD wouldn't be able to have one license for code, and one for content), meaning that you don't need to license your game under the CC-BY-SA even if you use graphics licensed under that license, you would only need to allow free redistribution of the CC-BY-SA content.
I think it would be good if you tagged the art with "Frogatto" and put a link to the game's website in the artwork's description too, to get some more exposure for the game.
I am also working on a strategy game, perhaps some of the graphics from the game will be of use to you. Here is the link to the graphics which I posted on this site:
I don't think it applies to them. The rest of that answer reads:
"What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
Graphics would generally be used in forms similar to command-line arguments, and as such seemingly would be "mere aggregation". This answer in that FAQ is also relevant for this issue:
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
"If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program." If this is the case for plug-ins, then graphics and other sorts of content would be fine too. Furthermore, as I said previously, a lot of projects use different licenses for code and artwork - meaning that there is a general understanding that they are in mere aggregation. There are also commercial games that have code under the GPLv2, while keeping the artwork proprietary (an example: Frogatto) - if they can do this, then you can also the reverse, and have proprietary code and open-source artwork.
AFAIK you can also still trademark your game even if it's open source, so if someone forks it they have to call themselves something else.
Using the LPC graphics for your game would AFAIK constitute "mere aggregation" (otherwise games like 0 AD wouldn't be able to have one license for code, and one for content), meaning that you don't need to license your game under the CC-BY-SA even if you use graphics licensed under that license, you would only need to allow free redistribution of the CC-BY-SA content.
Nice! Any chance of releasing this under the GPLv2 as well? :)
Quite nice, I like your work very much!
Thanks for posting this :)
I think it would be good if you tagged the art with "Frogatto" and put a link to the game's website in the artwork's description too, to get some more exposure for the game.
Hey mainsworthy,
I am also working on a strategy game, perhaps some of the graphics from the game will be of use to you. Here is the link to the graphics which I posted on this site:
http://opengameart.org/users/andrettin
There are also a few new graphics which I haven't posted here yet, but which can be found in the game's GitHub:
https://github.com/Andrettin/Wyrmsun/tree/master/graphics
All of these were released under the GPL 2.0 license. You can see who did each of the graphics here:
https://github.com/Andrettin/Wyrmsun/blob/master/graphics/credits.txt
Nice to hear about the cursor being used, DatapawWolf!
This is awesome! Any chance of releasing it under the GPLv2 license as well?
Any chance of hill/mountain tiles being made to accompany these? :)
Pages