The only acceptable answer is "asking every artist for there license and waiting for their response" as you say.

Licensing your game as CC-BY-SA would also work, but may defeat the purpose of having a commercial game.

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.

uhm.. So I looked up "mere aggregation" to see what it meant..

http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation

"Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them."

Dissapointing.. I've been working on a commercial game using the LPC graphics.. but I might just end up dropping it now and making something else.. Does this apply to them?

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:

Can I release a non-free program that's designed to load a GPL-covered plug-in?

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.

I think the tentative consensus is that art and code can be treated separately for this--all that needs to be released under -SA are direct derivaties of the graphics.  That hasn't been tested in court, but as far as I am concerned it satisfies the license requirements for anything I release under the license.

Note also that most (or all?) of the LPC base assets (at least those made by me, Sharm and Charles Gabriel--I don't know for sure about those done by Beast or Daniel Armstrong (Hughspectrum)) are dual-licensed to CC-By.  Of course that does not apply to any derivatives made by others, though they are free to dual-license as well if they please.

All that to say: you can absolutely pay me if you want.  I accept large wads of cash, precious metals or gemstones.

Andrettin -

Well even reading the full answer, it seemed to me that the spirit of "mere aggregation" is to not fault programs that can be used in conjunction with each other that get packaged together..

Even if I don't embed the graphics in my exe file, the coding and graphics are still pretty "intimate" together.. They combine to form an experience that couldn't exist without each other.. And it can be argued that games are an artistic endeavor that can be defined by the experience they present to players..

The fact that people are already licensing code and art seperatly in their games doesn't mean anything until they get sued for it..

It should be noted though that the cc-by-sa is not as strongly copyleft as the GPL. Its more like the LGPL as far as I can tell (IANAL). As the lpc assets can be used both under the GPL or the CC-by-SA, the "mere aggregation" definition from the GPL does not necessarily apply.

I certainly have the impression that art from OGA is generally intended to be freely used in commercial and/or closed-source games. In the FAQ (http://opengameart.org/content/faq#q-proprietary) section they have a (non-legally binding) description of all of the licenses, and none of them suggest a limitation on commercial applications. The only case I am aware of a probelm is CC-BY-SA in iOS games, as CC-BY-SA has an "anti-DRM" clause which is incompatible with the Apple store. I don't know if there is a handy way around this other than asking each author for an excemption.

If your goal is to couple the character generator code into your own project, then you would have to release your source code under GPL, since Guarov0 has released the original under GPL.