GPL Application <-> LGPL Plugin <-> Properietary code

Question

I would like to explicitly consider possibility of having either of

Fig.1:

1. (1-A) A GPL application with dlopen-based plugin system.
2. (1-B) LGPL plugin for application (1-A), that is linked to (1-C)
3. (1-C) Proprietary non-GPL compatible library.

or

Fig.2:

1. (2-A) A GPL application with dlopen-based plugin system.
2. (2-B) LGPL plugin for application (2-A), that is making own dlopen-based plugin system for (2-C)
3. (2-C) LGPL plugin for a plugin (2-B), that is linked to (2-D)
4. (2-D) Proprietary non-GPL compatible library.

or

Fig.3:

1. (3-A) A GPL application with dlopen-based plugin system.
2. (3-B) LGPL plugin for application (3-A), that is making use of any network/IPC/shared memory communication to (3-C)
3. (3-C) An application linked to (3-D) and receiving commands from (3-B) over communication channel.
4. (3-D) Proprietary non-GPL compatible library.

as GPL-compatible way to allow GPL application utilize proprietary library.

As per https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins quote

If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

The Fig.1 apparently ruled out (not sure about Fig.2 completely though), however, where does make function calls to each other and share data structures part ends anyway?

1. (Q-1) Is Fig.2 the same as Fig.1 in this respect after all?
2. (Q-2) Is IPC/shared memory page to purely exchange data counts? It lacks one of function calls AND share data structures, only sharing data structures that may themselves be under LGPL, dual-licensed or public domain.
3. (Q-3) Is network-based RPC falls into same category as shared memory? What if RPC implementation (e.g. zeromq) can be configured to use shared memory as a transport as well as some TCP/UDP/Unix socket?

Answer 1

(Q-1) Is Fig.2 the same as Fig.1 in this respect after all?

Yes. There is no significant difference between Fig.2 and Fig.1 with regards to determining if they are considered a single combined program or not.

(Q-2) Is IPC/shared memory page to purely exchange data counts? It lacks one of function calls AND share data structures, only sharing data structures that may themselves be under LGPL, dual-licensed or public domain.

This depends on the data structures that are being shared and the kind of calls made over the IPC connection. GPL code can interact with proprietary code if this interaction happens "at arm's length". This effectively means that the side that falls under the GPL regime can be written without having knowledge of how the proprietary code is implemented and that it is possible to replace the proprietary code with an open-source alternative (where the feasibility of writing the alternative is not considered).

(Q-3) Is network-based RPC falls into same category as shared memory? What if RPC implementation (e.g. zeromq) can be configured to use shared memory as a transport as well as some TCP/UDP/Unix socket?

Network based communications fall in the same category as the on-machine IPC/shared memory. With network based communications, it is usually easier to keep the two parts "at arm's length," because the network protocols make it harder to accidentally share implementation details.