Can license-incompatible program communicate with GPLv2 program via websocket?

Question

I'm writing a program for automation under a license that is incompatible with GPLv2 (it's dual-licensed: GPLv3/Proprietary). Let's call it my automation program.
And there is third party GPLv2 program that supports plugins.

I want to write and distribute a remote control plugin under GPLv2 license for GPLv2 program that adds ability to this program to be controlled via websocket protocol. It links as "*.dll" file with it. As I understand I'm allowed to do it.

But am I allowed then to make my automation program to control this GPLv2 program via websocket protocol (thanks to the plugin)?

Additional notes:

1. Both programs run separately and can do their jobs not relying on each other. For example, my automation program does many other things, but communicating with GPLv2 program gives it additional feature.
2. My automation program will be able to communicate with few other programs with functionality similar to GPLv2 program.
3. The plugin to the GPLv2 program will allow it to be remotely controlled with any other program using my API, not only with My automation program. And it will be useful for the user.
4. My automation program will most likely communicate with GPLv2 program not over the network, but on the same machine.

Answer 1

The method of communication is not relevant.

If you don't modify the GPLv2 program, and your proprietary program is developed independently from the GPLv2 program, there is no derivation work, so you can use the GPLv2 program without restrictions.

If you modify the GPLv2 program, things are grey. On both side you will have to code the communication part, and so on both side very probably you have derived code (I would side both side are derived with the other side). So linking one side will give problem with GPLv2.

To overcome to the problem, you can use a well know protocol to communicate both parts (but not only the outer layer), or you can create a very generic communication layer, which can be used for many other purpose. But I see that it is very difficult to have a non-grey area (e.g. to prove the no code linked on GPLv2 program is derived to the proprietary code, and the other way).

Answer 2

Disclaimer: I am not a lawyer

Since my automation program is communicating with the GPLv2 program via a socket, my automation program shouldn't need to link against the GPLv2 program. The fact that a GPLv2 program communicates with a another program does not necessarily make the other program GPLv2 as well.

I would attack this problem by creating a header file that defines the format of how the GPLv2 program and my automation program will communicate over the socket. Then both the GPLv2 program and my automation program can include the header file without affecting their licenses.

Richard Stallman, himself, said in the Linux Kernel Mailing List that including simple GPLv2 header files does not make a derivative work.

Someone recently made the claim that including a header file always makes a derivative work. That's not the FSF's view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work.

http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html