4

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.
6
  • Can you elaborate on which one of these programs is yours vs. which one is third party and if any of the third party programs is modified or not, in particular if it is modified to add a socket interface? Nov 27, 2016 at 9:29
  • Yes, I have edited the question to make it more clear: the automation program is mine, the GPLv2 program is third party. The GPLv2 program can be concidered as modified by dinamically-linked plugin ("*.dll"). The plugin for the GPLv2 program will be under GPLv2 license.
    – Liito
    Nov 27, 2016 at 15:16
  • Does the unmodified "GPLv2 program" have built in support for plugins extensibility? Do you ever intend to have the "My automation program" contraption being used under a proprietary license as you mention some dual licensing? Nov 28, 2016 at 9:30
  • And is any of this technical architecture something you need or something you are considering to work around some GPL compatibility issues? Nov 28, 2016 at 9:31
  • 1. Yes, the GPLv2 program has built in support for plugins extensibility.
    – Liito
    Nov 28, 2016 at 15:03

2 Answers 2

2

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

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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