To which extent GPL license contaminates my project?

Question

We're planning to develop an Windows application which simulates an embedded system containing 2 applications (that communicate through OS messages) and sell it as a whole package

• appication "F": we are provided with a non-intel/Windows binary, we don't have the source code (but we pay royalties to the company who does for using it)
• application "I": we develop that, and have the source code

Both applications are co-existing in real-time OS engine (that we developped) to run both. Both applications must be provided to the engine (windows executable) as DLLs, dynamically loaded by the OS simulator.

The real-time OS engine complies to the ARINC 653 norm.

We don't have the source code for partition "F", only the executable (using a different CPU than the host), but we found an emulator/VM that seems to fit our needs, provided we trim it down (a lot) and add features so it connects to the OS engine, also creating a DLL embedding the emulator/VM & some "glue" code.

Our modifications to emulator/VM would allow anyone using a A653-compliant OS and the same CPU architecture to run their programs (maybe with some further adaptations)

The CPU emulator/VM is GPL, and we're planning to distribute the simulated system to clients as a whole (both applications). I'm aware that- according to the GPL V2 terms - we'll have to provide source code for the tweaked emulator/VM part (and that's not an issue), but does that extend to:

• the simulated OS engine (our IP) which implements ARINC 653
• application "I" (our IP, which we rebuilt for the host from its sources)
• application "F" (a third party delivery, no source code, and we have to emulate the machine code instructions)

Can we still use & distribute the modified GPL emulator/VM in the DLL without having to provide source code for the OS simulator and application "I"? (the emulator doesn't link to the simulated OS or application "I": those are separate DLLs)

And in the case the whole project would have to comply to GPL V2, is there a way to get an agreement with the author(s) of the emulator to get a different license for us (like Qt paying licence) ?

Answer 1

When a GPL program processes some data, the output of the GPL program is not bound by the GPL. This is particularly important when the data is another program. You may execute non-GPL programs with a GPL emulator, virtual machine, or programming language implementation.

You can therefore execute program F in the GPL emulator without any problems, as long as this is permitted by the license of F.

A more difficult question is whether you can integrate the GPL emulator into your system. Any changes you make to the emulator also fall under the GPL. It does not matter whether these modifications are for compatibility with proprietary systems or whether these changes would also be useful for other people. If you distribute binaries of the patched emulator, you also have to offer the source code of the patched emulator under the GPL.

But can you integrate your application I with the emulator, whether you applied any changes or not? This is the subject of some debate.

The position of the GPL is that generally, using GPL code in a work makes the whole work subject to the GPL. The LGPL variant provides an explicit exception to this, where you can use LGPL code in a proprietary application. But that doesn't apply here.

If the GPL work and the proprietary work communicate “at arms length”, they can be considered separate works and the GPL does not affect the proprietary program. What that precisely means is again the subject of some debate. At a minimum, the two programs should run in separate processes. They can then communicate over an IPC mechanism like pipes. Two programs do not communicate at arms length if they share any data structures. This means that directly using a GPL library (e.g. loading the emulator as a DLL) does not provide sufficient separation between the library and your application I.

There is an opposing view that argues that the GPL license cannot apply to code that you wrote, because the authors of the GPL licensed program do not own the copyright over your code – your code is not derivative of the GPL code. If this argument is correct, this would mean that the GPL and the LGPL licenses are effectively equivalent. I understand this line of thought, but think it is a flawed argument because the authors of the GPL software are not required to allow you to use their software unless you abide by the license. Any work that is “based on” the GPL work is considered a covered work by the terms of the GPL. This also depends on the precise version of the GPL we are talking about. I'm assuming the GPLv3 here. Since this legal theory is untested and contradicts the spirit of the GPL, I would be very wary of building a business on a probable GPL violation.

To conclude: It is unlikely that you can use the emulator directly in your application I. This might become possible if you re-architect your system so that application I and the emulator communicate only at arms length.

Instead of listening to random people on the internet, this is probably important enough to your business that you should draw up a clear schema illustrating the communication of the GPL part with the rest of the system, including clear boundaries between subsystems. The better isolated the GPL part is, the better. You can then consult a lawyer with experience in open-source license compliance to give you an informed opinion. We can't do this since we are neither lawyers, nor do you have explained the communication between the various systems very well.

Answer 2

Say that has an hypothetical example that you use QEMU for CPU emulation which is overall under a GPL 2 license.

The key question is whether or not your own code and the product as a whole is a derivative work of the emulator or not.

The way I would think of a vanilla QEMU is as if it were a CPU. It you use it without modification, then its license should have no impact on the OS that runs on top of it and any embedded application in the RTOS itself.

The thing becomes more complicated if you start to make modifications and enhancements to QEMU itself.

First, you are unlikely to be able to secure an alternative commercial license for QEMU: they use a shared DCO-style copyright approach like the Linux Kernel. So no single person may be able to grant such an alternative license.

Then if your modification to the emulator seems is specific to your RTOS, rather than generic for some emulated hardware, then it could be that you are making the modified emulator dependent on your proprietary RTOS and this may subject the RTOS to the GPL. And so on, eventually, depending how things interact (linking static or dynamic has no bearing here, the way things interact is what matters).

Instead, if your modification to QEMU are not dependent at all on your RTOS, but are emulating some new piece of embedded hardware, my suggestion would be to contribute these to QEMU such that they become part of the standard.

If you reach that, then you would be using QEMU as-is, and running a proprietary RTOS on top that executes some other proprietary application alright which would put back in my QEMU-is-like-a-CPU analogy above.

/HTH

Answer 3

A common goal of OS emulators is to run as many programs as possible, with no or only minor changes to such programs. This requires that the emulator is similar to the real thing.

By observing your two apps, you can find omissions, mistakes, etcetera in the emulator. The legal status of the two apps which leads to such observations is completely irrelevant to these observations. And if you develop patches from these observations, they too would not depend on the legal status of the two apps. Copyright simply does not make these patches "derived works", and Open Source is still based on Copyright law.