Didn't know where to put this post...

I would like to put all of my games under the GNU General Public License, but how do I safeguard online games from cheating?  Anyone will be able to see the username and password for accessing the server along with the password to encrypt my packets.  Is it allowed to just leave those fields blank?  What do other GNU GPL games do?

I thought about creating a separate Jar executable that would not be under the GNU GPL that would send the info along with an md5sum of the calling Jar executable (to check no code was tampered with), but...then I can't truly say it is under the GNU license and won't be acceptable for the FSF directory, etc.

Should I just trust the users?        

I remember sending an email a long time ago to GNU asking about this (I believe), and I think that they said I couldn't leave the password/username blank, and most be able to build and run exactly like I am able too....but perhaps, my memory is mistaken.  I don't really want to email GNU again because they never offer me alternatives/suggestions to my questions, annoying.

Please help, thanx.

With Obfuscation, it would at least be a little better.  I know that nothing is unhackable, just wanting to make it harder to be hacked.

What would you suggest then in order to prevent cheating in online games?  How do other Java games (both open source and not) prevent cheating?

What would you suggest I do please?

So you're saying...I'm screwed? 

Can you explain more about what your online game does; is it highscores or multiplayer? If it's multiplayer then what sort of multiplayer games?

I partly agree with cas, but it depends on context. Some games like WoW you'd expect the system to be able to prevent cheating, but I've played FPS games online where people have cheated and I just move to a different match (it's less of an issue).

Well, I went to the GNU IRC channel to ask about this...

GNU GPLv2, you don't have to provide passwords (for server virtual host, encryption, etc.). in source code
GNU GPLv3, you have too (I would like to use this one).

At least, that's what they said, just community users.

But, they gave me some good suggestions.

For submitting a highscore, I will track all keystrokes/etc.  Send this to the server which will then play the game using those keystrokes/etc. and compare the highscore submitted by the player to the one my server program creates (and have like a 1% tolerance or something).  I could probably make it where it isn't the actual game, just a simulation stepping through the keystrokes one frame at a time with the level loaded (no drawing obviously).  To try and prevent submission overload, I could log IP/macaddress and stuff to prevent how many times you can submit a highscore in a day (this is weak security as people can use proxies, etc., but still there).  Also, I could provide some type of randomness in points so that you can't get the exact same score as someone else, could be hard on server side.  Anyway, I think that the first 2 sentences will be sufficient.

For games that play online, if a bullet is shot for example, on the server side there is a limit to number of bullets shots, and it would record the player's position at all time so can make sure it doesn't change wildy from 0,0 to 180,180.  I will figure out other stuff for everything somehow

Thanx guys for the replies; if you have any good ideas about preventing cheating, please let me know here

NEVER TRUST THE CLIENT NEVER EVER NEVER

I feel like we've had a bazillion posts of this related question in the past couple of weeks. The fact of the matter is, you can't trust the client. Assume anything coming from a client is hacked. Assume everyone is out to break your game. How do you fix that? Everything important happens on the server, or the server verifies everything that's important. That's it. GPL v1, v2 or v3.

RAR *froth* GR GR BABFKJAKGFJL!!!!!!!!11!!!one!!!

But yes, Cas is actually right. I'd say design smart from the beginning but don't waste time over it. The odds that it will really matter are so very small.