Open Source application GPL legality

Björn Terelius bjorn.terelius at gmail.com
Wed Oct 14 15:42:43 UTC 2009


If I understand you correctly, you want to release your game as open  
source, but are at the same time worried that people will use your  
code to develop cheats. Unfortunately, there is no simple way around  
this problem; if you release how the client is supposed to work and  
interact with the server, then anyone can create modified client that  
gives the user an unfair advantage.

If you really are worried about people trying to cheat, your best  
option may be to keep the source closed. Notice that this does not  
completely solve the problem since a sufficiently determined attacker  
could reverse engineer the assembly code.

Your idea about dynamically merging the GPL'd client (whether this is  
allowed or not) with some non-free utility may not work as you indent  
it to. After all, I don't see how you could prevent a malicious user  
from creating a program which emulates a non-modified client when  
interacting with the security utility, but which acts as the cheating  
client when interacting with the user.

The only way I can see how to make the idea work would be to have the  
security utility scan the memory and check whether the client is  
unmodified or at least not known to cheat. Programs like Punkbuster  
does this, but the method is a threat to privacy. (The anti-cheat  
software could just as well be used to spy on the user.)

The specific problem for RPGs is probably a bit easier than for FPS  
etc because in an RPG you could conceivably let the server store and  
maintain all important data and check that each client request really  
is valid before processing it. Then the only thing to worry about seem  
to be players using bots instead of playing themselves, but the bots  
will still be forced to play according to the rules. I don't know how  
well this "solution" would scale though; perhaps it is necessary to  
delegate a lot of the work to untrusted servers or directly to the  
clients when building an MMORPG.

Best regards
-Bjorn

On Oct 14, 2009, at 2:02 AM, shd wrote:

> Hello,
> I'm Open Source initiative fan who's willing to manufacture MMORPG  
> computer game and share it's precious content with the humanity :).  
> Because of scarcity about repeated closing my application by money- 
> for-nothing+crap guys, one of GPL tree would be the best choose.  
> Blocking possibility thing is really important thing for me, without  
> it - I wouldn't share sources to mass-market. Keeping in mind  
> quality of gaming experience I encountered problem with player  
> protection. More specifically, absolutely opening application (in  
> this case client) means allowing to build automated cheating  
> utilities (such as computer bots and other 'hacks') which would  
> completely ruin fun for others. After considering many ideas of  
> restricting 'hack-programs' use... After exclusion of poor video  
> stream transmission (: I acknowledged it as impossible.
> To save possibility of making this kind of application open-sourced  
> I digested method which is making use of raw client data hashed with  
> server delivered seed as authentication token which can be used to  
> verify (surely open sourced) client integrity. Thanks to this idea  
> we can make client and server in Free Software way simultaneously  
> not breaking functionality (delivering fun in RPG way) and letting  
> to everyone open-up his own game realm. As someone of you probably  
> spotted, key of the whole concept is having concrete entity of  
> client (binary data) unknown for 'bad guys' whose aim is to destroy  
> game balance = fun = use of application.
> The question is - can I share my application released on GPL license  
> at the same time dynamically obfuscating and morphing an executable  
> file with *not shared* utility? Result would be - client + server  
> are both open source, but if someone wants to stay connected with  
> *my* server he has to use concrete (my) compilation from.
>
> Cheers,
> Mariusz Gliwiński




More information about the License-discuss mailing list