The GPL is not specific to any technology like Java vs Lua, Windows vs Linux. To determine the scope of the GPL, we have but one question to consider: does this form a single program?
This question is not for the GPL to answer, it is a question for copyright law. However, the GPL authors have opinions on this question, which I regard as sufficiently authoritative in this matter.
To determine whether something forms a single copyright-covered work, the GPL authors suggest that a program forms a single work, including any files or libraries. Whether two processes that communicate with each other form a single program would depend on what/how they communicate. If they have deeply intertwined shared state, then that would point towards being a single program. An interpreter or compiler is a program that processes another program as data. The compiler and the program being compiled clearly do not form a single program. In the case of an interpreter, things can be more tricky since the interpreter may offer various libraries to the interpreted program.
In the following, I provide a brief analysis of your two scenarios. TL;DR:
- You will not find a GPL loophole. The idea “user clicks a button to load GPL-covered Lua code” will not work.
- You can use GPL software in a proprietary system if the two are clearly separate programs (think microservices).
- You can run GPL-covered software on Windows. A Linux VM likely just complicates compliance.
Scenario 1: Using GPL-covered plugins in a proprietary application.
In your first scenario, you are proposing that a proprietary software adds a Lua-based plugin system, which would then be used to load GPL-covered plugins. Since the GPL is technology-neutral, it doesn't matter which language or system is used to load the plugins: Lua scripts, JAR files, or DLL files will all lead to the same conclusion. The GPL FAQ contains multiple entries relating to plugins:
When is a program and its plug-ins considered a single combined program?
This would depend on how the plugin and the main program communicate. It is likely that the plugin and the host program would form a single program in your case, since your Lua runtime environment would likely allow the Lua code to call into your application and/or your application to call into the Lua code. In contrast, they would likely be separate programs if the Lua code is executed in a standalone process.
Can I apply the GPL when writing a plug-in for a nonfree program?
If they would form a single program, then no. Slightly simplifying: The GPL requires that you make all dependencies of the GPL-covered program available. You are proposing to rewrite the GPL-covered code to fit your application's plugin system, which would make your application a dependency of the plugin.
If you were the sole copyright holder of the plugin, you could add a GPL exception to allow this case. However, you are not the sole copyright holder since you are using existing GPL code, and therefore cannot grant such an exception.
Can I release a nonfree program that's designed to load a GPL-covered plug-in?
This is not really different from the above cases. If your proprietary application is specifically designed to load a GPL-covered plugin, there's a good argument that it's derivative of this GPL-covered code.
However, if your application merely has the ability to load plugins which could be GPL-covered, then the user would be able to create (but not necessarily distribute) a GPL-covered plugin.
You propose that the user could trigger the loading of the plugin. I don't think this will change anything: if you provide an application with a plugin system, a matching GPL-covered plugin, and offer instructions for the user to load this plugin, there's a pretty good argument that your application would have to be available under GPL.
Scenario 2: Using GPL-covered software on Windows.
In your second scenario, you are concerned about running GPL-covered software on Windows. You are proposing to run this software in a Linux virtual machine, and then have your proprietary application communicate with the virtualized GPL-covered software.
First, it's perfectly acceptable to distribute proprietary and GPL-covered software side by side. This is sometimes called mere aggregation. You just have to make sure to comply with the GPL license for the GPL-covered parts, e.g. you must not make the use of the GPL parts conditional on accepting an EULA, and you must not prevent modifications to the GPL-covered components, and you must provide the corresponding source code.
Here, it seems that your proprietary software and the GPL-covered software may be communicating “at arms length” and therefore are two separate programs (compare the GPL FAQ). The GPL is technology neutral, so running the two programs in different processes vs running them in different virtual machines makes no difference.
Note that you are allowed to run GPL-covered software directly on Windows. While the GPL generally requires you to make all dependencies available under the GPL, the GPL-3.0 exempts “System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work”. For example, a GPL-covered program can use Windows System Libraries like the Win32 API. The GPL-covered software could also require gratis but generally available tools such as the proprietary Visual C++ compiler.
If you do distribute a virtual machine image, note that you must comply with the licenses for all of the software contained in that image. This can be rather tedious, as you'd have to consider all software including the Linux kernel and programs in the userland. Busybox provides a minimal userland which can simplify compliance, alternatively you might want to use a BSD userland instead of using GNU tools. Certain Linux distributions such as Debian are very good at managing licenses for software installed through Debian's main packages.
