2

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) ?

migrated from law.stackexchange.com May 5 '17 at 16:34

This question came from our site for legal professionals, students, and others with experience or interest in law.

  • At any rate, to me it looks as if you must indeed provide source for everything under the GPL if you do what you describe. The only loophole I see would be the rule that software is exempt if it is not "combined with it such as to form a larger program" - but in your case the whole setup would probably be considered a "larger program", since it is built to work together. But I am not a lawyer... – sleske May 5 '17 at 13:53
  • 2
    If the only GPL code is the for the VM emulator then it is probably fine. But it's hard to tell when you're using nonstandard terms like "OS simulator", "partition". Please edit this to use clearer language like "application/executable", "library", "VM". It would also help to give clear labels to all the parts. If you can't reveal the actual names then call them "library A", "application B" etc. – curiousdannii May 6 '17 at 0:28
  • @curiousdannii I have edited the question. – JOTD May 6 '17 at 10:18
  • There is no such thing as 'contaminate'. The GPL is NOT a virus. This is FUD. It has conditions and you either meet these or not. It would be great if you could update your question – Philippe Ombredanne May 8 '17 at 12:08
  • @PhilippeOmbredanne I have updated my question. Most important information added: the OS we're simulating complies to a norm which is public (not proprietary). – JOTD May 8 '17 at 14:26
5

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.

  • 1
    this is very helpful. If I can run F through the CPU emulator, which communicates with I only using API calls to the simulated OS, then I guess it complies with the GPL. Don't worry, we have an IP/legal department, but the more advice/arguments I can get for my solution the better. Thanks. – JOTD May 9 '17 at 11:32
1

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

  • 1
    That's not how it works. "Scratching your own itch" is perfectly normal for Open Source projects. Intel makes Linux drivers for Intel hardware, because that's Intel's interest. That doesn't cause the kernel to become less GPL, or the Intel firmware to be more GPL. Similarly, enhancing QEMU to serve your RTOS is just scratching that particular itch, but doesn't affect the GPL status of either side. – MSalters May 8 '17 at 14:06
  • @MSalters we are not talking itches here, but rather what could be the possible impact of the GPL conditions in a very specific and rare case combining a CPU emulator and its modifications, a proprietary RTOS and a third-party proprietary application on top of this RTOS. – Philippe Ombredanne May 8 '17 at 19:36
  • @JOTD let me think a bit more overnight and eventually update my answer tomorrow – Philippe Ombredanne May 8 '17 at 20:20
  • This SE site is very helpful. Thanks, I'd appreciate that. – JOTD May 9 '17 at 11:33
0

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.

  • thanks for your reply, but maybe you didn't fully understand my question (maybe a graphic would be helpful, and it's my fault). The OS simulator is ours. The CPU emulator is GPL. And I don't see any conclusion on whether the CPU emulator would contaminate the entire system, not only the application being emulated. – JOTD May 8 '17 at 9:30
  • @JOTD: Details. The core logic remains the same; you improve the CPU simulator, in isolation, based on non-protected observations. This act is fully allowed within the GPL. You then bundle it, also allowed by the GPL. – MSalters May 8 '17 at 10:35
  • I have fixed a couple of bugs in the core emulation, true, and I also connected it but not specifically to our proprietary OS but to any OS following the A653 norm. Reading your answer, it seems that I'm off the hook for the rest of the applications & the simulated OS, as long as I distribute the modified emulator sources to our clients. – JOTD May 8 '17 at 14:28
  • @MSalters I don't understand the second paragraph. Are you saying you can create patches for a GPL program that are not bound by the GPL? That would be an innovative (i.e., probably wrong) legal theory. You also do not explain under which circumstances the GPL software may be used together with the rest of the system. Bundling GPL with non-GPL software is OK, but integrating it into the system is not. Given that the question explicitly mentions DLLs, this answer seems misleading. – amon May 9 '17 at 11:26
  • @amon: Patches for the GPL programs are also GPL, but the inspiration for the patches need not be GPL. And it's a well-accepted legal theory that run-time environments do not affect the license of the things run inside them, c.f. Linux running non-GPL programs and Windows running GPL programs. – MSalters May 9 '17 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.