Propietary software + GPL source code modified to work with my propietary software

Question

1) I find the source code for a program that is GPL licenced (ie, a video player, which supports playing videos at 16k resolution! [joke]).

2) I wanna play a video on it, but it doesn't offer an interface to receive requests from external programs (like listening on a port, and the executable doesn't accept passing arguments on creation).

So I go on and modify the source code, add an interface so that I can connect my propietary software to that program.

I'm a safe with this approach?

Am I correct in that:

1. My program remains proprietary (I don't need to share the source code with anyone).

2. I know I need to make available the source code of the modified "GPL" program, and it must remain in GPL.

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html

If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

The FAQ on GNU.org doesn't make things clear, at least for me.

Answer 1

Your second point is entirely correct: The modifications you make to the GPL program must also be released under the GPL.

Your first point (my other program can remain proprietary) is where stuff gets muddled a bit. This entirely depends on how intimate the communication between the two programs is.

On the one hand, if you design the communication such that your proprietary program (P) can only communicate with the modified GPL program (M) and it is very hard to impossible for other programs than P to use the modifications you made to M, then it can be argued that even when they execute on separate machines, they are really parts of the same work. In that case, the GPL would also apply to P.

On the other hand, if you designed the interface such that P can use any back-end player that can be invoked with "<program> <file>" (or some equally simple network command) and any program can easily use the new capabilities of M (without even knowing of the existence of P), then the two programs are separated enough that they are clearly separate works for copyright and program P can be/remain proprietary.

In the middle ground between these two is where the lawyers get fat paychecks to argue whether the GPL applies to P or not.

Answer 2

The key thing here is that in order to ensure that the two parts of the solution are to be considered separate, that they should be distinguishable separate. In this case if you created an JSON/REST interface in the GPL code and your Proprietary application exchanges messages with the GPL application then this is clearly considered two distinct applications in the meaning of GPL.

How about a GPL class in a proprietary application. Does it 'poison' the commercial code? No, it doesn't need to, as even a class has a clear internal interface and if kept in a separate file in it's own directory it can be clearly distinguished as well, even it the communication channel may be more obscure. However, any change to GPL Source means that it can only be released under GPL.

That being said, if you plan your future on the commercialization of your application that uses Open Source licensed code, please involve a specialist so that the foundation of your venture is solid.