[jcelerier]

> It's totally legal.

If the IPC is here only for the sake of circumventing the GPL (e.g. there aren't any meaningful use of the "GPL plug-in" part through this IPC channel outside of communication with the non-GPL program), it's totally not. What are such plug-ins ?

[CyberDildonics]

Why would it be illegal to use IPC to communicate from one GPL executable to another non GPL executable?

Files are interprocess communication too. If files are fine and other forms are not, then it starts to get into an argument of speed making something illegal.

Not only that, but network communication is IPC and that would imply that it's fine to have a GPL program go to another computer holding a non GPL program, but not if they are on the same computer. There are a lot of holes in this argument.

Not only that, but any program that can't communicate with other programs (do drivers count?) through file formats, networks operations or anything else is probably limited anyway.

[nkallen]

Mr Dildonic it's definitely not illegal, the poster is a troll

[CyberDildonics]

I think so. I originally said there were a lot of holes in their argument, but I think they didn't actually make an argument in the first place, they just made a claim with no evidence behind it.

[jcelerier]

The GPL does not care about stuff such as libraries, executable, etc. The only relevant concern is whether your IPC-splitted thing is part of the program, or is a public API expected to be used by many unrelated other programs.

Quoting the GPL:

> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The relevant part is "intimate data communication": querying for instance some other program's publicly-advertised D-Bus API, such as a notification service expected to be used by the whole operating system wouldn't be "intimate data communication". However splitting a single executable into two parts which don't individually make sense are obviously "intimate data communication" - it may be two binaries, but it's still one single software from the point of view of the end-user.

If the GPL part of your plug-in cannot do meaningful things (basically still be useable for its original goal by the end user) without the other, proprietary, side of the IPC up and running, then they have "intimate data communication" and distributing it is breaching the GPL.

I have a hard time imagining how one would justify that a CAD plug-in split under two parts for IPC wouldn't constitute a single work for instance, with the following GPL paragraph in mind:

> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit.

You mentioned drivers: they are specifically denoted in the paragraph above ("it does not include the work's System Libraries").

[CyberDildonics]

There are a lot of things being conflated here.

First is a plugin that would be shared library loaded into the same virtual memory space as a running program.

The second is GPLed header files that define function signatures and data structures.

The third scenario would be passing already defined data formats like JSON or something serialized through the file system, shared memory, or the local network. In this situation, there would be separate processes, separate memory spaces and no interface definitions would need to be included into the non GPLed program. This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL.

[jcelerier]

> This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL.

any intimate communication would indeed. Any communication that goes through a standard (e.g. ISO-defined or industry standard, so not something specific to your company) would not.

Quoting the FSF:

> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

You can obviously extend "communicating complex data structures" to RPC through JSON & websockets for instance as it's this "exchange of complex data structures" which is the defining matter in what constitutes a single program from the point of view of the GPL.

[fsloth]

IPC is totally worthwhile for native applications in any case, when separate complex components are combined into a single user session. Running the code in separate heaps reduces the chances of bugs in one application code corrupting the entire application heap.

Very hard to argue that IPC would ever be just for avoiding license. It always increases total robustness.

[nkallen]

I agree with you -- it's hard to safely kill a runaway thread but it's not hard to kill a runaway process. But I think it's worth noting that the performance characteristics of IPC can be very bad