Rather than guessing what a judge may deicdedecide, you should first think about how the copyright holder of the GPL program you are redistributing willis likely to interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
Rather than guessing what a judge may deicde, you should first think about how the copyright holder of the GPL program you are redistributing will interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
Rather than guessing what a judge may decide, you should first think about how the copyright holder of the GPL program you are redistributing is likely to interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what actually will actually be considered a combined work.
From your description, it sounds like you already suspect that combining your closed source program with the GPL program that you want to usemay not be legally possible in the 'conventional' way (via static or dynamic linking) may not be legally possible, so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. The reason itWhy is it a disadvantage to the GPL program's copyright holder is because? Because many software authors license their programs under the GPL specifically to getencourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what actually will be considered a combined work.
From your description, it sounds like you already suspect that combining your closed source program with the GPL program that you want to use in the 'conventional' way (via static or dynamic linking) may not be legally possible, so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. The reason it is a disadvantage to the GPL program's copyright holder is because many software authors license their programs under the GPL specifically to get companies to do the same. I.e. "You may copy our code as long as you release yours as well."
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what will actually be considered a combined work.
From your description, it sounds like you already suspect that combining your closed source program with the GPL program may not be legally possible in the 'conventional' way (via static or dynamic linking), so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. Why is it a disadvantage to the GPL program's copyright holder? Because many software authors license their programs under the GPL specifically to encourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."
So the real question is whether what your finishedfinal product will ultimately be considered as one work or separate works. This is true whether it your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way of combining the parts. The FSF tried to answer this in their FAQ:
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source user programsprogram is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.
So the real question is whether what your finished product will ultimately be considered as one work or separate works. This is true whether it your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or some other way of combining the parts. The FSF tried to answer this in their FAQ:
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source user programs is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.
So the real question is whether your final product will ultimately be considered as one work or separate works. This is true whether your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way. The FSF tried to answer this in their FAQ:
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source program is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.