GPL in a runtime environment

Question

I'm making a runtime environment for Squirrel that includes embedded functions for basic I/O needed in games. The idea is that it would just run Squirrel files (.nut or .sq) or its own format for multiple packed scripts. Basically, the RE contains all the functions for drawing, getting input, handling sound, loading resources, etc., but doesn't actually do anything on its own. The Squirrel scripts have all the game logic and tell the RE what to do.

So far, the code is available under GPL3, but someone who recently got interested in the project tells me that GPL3 is a bad idea because it'll force anyone who makes a game with it to open source their game as well. This confuses me, because unless they're actually modifying the runtime itself to make a game out of it, why would this happen? The scripts it runs aren't actually part of the runtime, so shouldn't whoever writes them be able to determine their own license for it?

The way I see it, since the Squirrel scripts aren't actually part of the runtime, and could possibly even be run by another program altogether, assuming they used the same names in their embedded functions, then the license of the runtime shouldn't apply to the programs it's being used to run. Of course, I don't know if this is right or not, which is why I'm here.

If I make a runtime with a GPL license, does that license apply to programs that are intended to be run in it but not actually a part of it? Or are they separate and people making games with it shouldn't worry?

Also, in case anyone is wondering, the libraries I'm building it with are all either X11/MIT or ZLib licensed.

Squirrel is a scripting language. It's been used in games like Portal 2, Left 4 Dead, GTA 4 and 5, and a few others I can't remember off the top of my head. Someone else made a game development kit for it, too, but it's specifically designed for Android/iOS. I want to make one that's for PC.

Answer 1

Generally speaking, the GPL license does not necessarily apply to the input of a program. For example, the GNU bash interpreter is GPLv3 licensed, but bash scripts are not all GPLv3 licensed, and some people make proprietary scripts.

However, it could be a gray area if your program and its input are intimately coupled (and that notion is not easy to define). You might need to ask a lawyer (which I am not).

Look at the GPL FAQ question :

If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?

And the same FAQ tells

When the interpreter just interprets a language, the answer is no.

But read more about that issue. If there are several interpreters of Squirrel you are on the safe side.

PS. I have absolutely no idea about what Squirrel is.

Answer 2

The problem is this: is the runtime environment a separate program that processes the scripts, or is it a a library that is linked with the scripts? Or perhaps a combination of both?

The input and output of a program are not subject to the GPL license of the program. It isn't important whether the input or output is another program. For example, the GPL'ed GCC can be used to compile non-GPL'ed programs, and the GPL'ed OpenJDK/HotSpot JVM can be used to run non-GPL'ed programs.

Linking a program to a library means that the program makes function calls into the library and shares data structures with it. The program and library then form a combined work. If one part of this work is subject to the GPL, then the combined work may only be published under the GPL license. It is irrelevant how the library is linked, or whether non-GPLed alternatives to the library are available. This combination can happen very late when you replace a library with a GPL'ed library at runtime via dynamic linking. It can also happen very early when the code is being written to take advantage of a GPL'ed library, i.e. when you write function calls into the GPL'ed library.

But a software is not subject to the GPL just because it could be linked with a GPL library. If the scripts are fully functional on a non-GPLed runtime, then running them with a GPL'ed runtime will not taint them. They are still linked, but this linking is is done by the user at run time, and the result of the linkage is not published. But if the script depends on features only provided by the GPL'ed runtime or makes special arrangements for being linked with the GPL runtime, then they clearly are linked.

The separation between compiler/interpreter and a runtime library is not always simple since they can only offer a complete runtime environment in tandem. Compilers like GCC do insert code fragments and the resulting programs depend on a runtime library (usually glibc), programs running on a JVM do need a Java standard library implementation. To allow themselves to be used with non-GPLed programs, the glibc (for GCC) and OpenJDK (for HotSpot) runtime libraries contain an exception to the GPL. Without this exception, the programs would be subject to the GPL because they are linked with the runtime libraries.

So for your scenario, a GPL'ed interpreter would not be a problem, but a GPL'ed runtime library is more difficult. Users of your runtime library do run the risk of making their scripts subject to the GPL unless the users take care to not use any unique or incompatible features of your runtime library, or unless you can offer an GPL exception for the runtime library (which requires the explicit consent of all copyright holders of the runtime library). Additionally, embedding the GPL'ed runtime into a game would make the whole game subject to the GPL.