undefined | Better HN

0 pointspeterkelly7y ago0 comments

It depends on how the game engine works. If your game code is directly linked with the engine in the same executable (or a shared library) it would fall under GPL. If the game engine provides a virtual machine that executes bytecode compiled from game scripts I don't believe that would count.

0 comments

3 comments · 1 top-level

klodolph7y ago· 2 in thread

That's an argument, but I belive it wouldn't stand up in court.

If you have something like the JVM, you can make a case that the program and the JVM are separate works. If you have something like Quake, I don't think that would hold up, I would consider the bytecode and Quake to form a combined work.

At best, I think you would be testing in-court what a "derived work" is or what it means for a work to be "based on" a program. The legal risk is not only the fact that your game might be considered in violation of GPL (and therefore copyright infringement), but that the case might be difficult and involve sophisticated legal arguments (which would make it expensive) and you might also experience adverse effects before successfully arguing your case (DMCA takedown notices, etc).

ascagnel_7y ago

FWIW, the source to Quake's bytecode (progs.dat, written in QuakeC) is available under the GPL. I think, since the bytecode source was distributed separately from the engine source, you could get away without distributing later bytecode source as long as you start from scratch.

klodolph7y ago

The key difference about the bytecode is that the sources are available under terms other than the GPL, but the SDK license they use does not permit commercial exploitation. I think you could distribute an open source Quake + open source progs.dat, but I don’t think you could really mix and match (distribute open-source Quake + your own closed-source progs.dat, as one product).

j / k navigate · click thread line to collapse