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 ?
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.
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.
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").
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.
> 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.
I gave specific examples and you keep using an abstract label.
> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
These are two separate things unless they are talking about shared memory meaning sharing the same memory space as another process, which is what dynamic linking does.
Communicating through complex data structures can describe files too. If you save a file from one GPLed program and open it in a non GPLed program, that is interprocess communication. If both programs are using mmap on the files instead of writes, does that change things? If files are being sent over local loop back does that change things?
Are there any examples of any of these ideas being tested? I've never heard of anyone except for you asserting that two processes communicating without including GPLed source code was somehow a GPL violation.
> I gave specific examples and you keep using an abstract label.
I am quoting the license text.
> Communicating through complex data structures can describe files too. If you save a file from one GPLed program and open it in a non GPLed program, that is interprocess communication. If both programs are using mmap on the files instead of writes, does that change things? If files are being sent over local loop back does that change things?
I don't thinkg it would at all - it would still breach the license if e.g. you are dumping raw struct contents in your files that are only meaningful for the proprietary side of things.
The part you are quoting is still an abstract label. You can't take specific common scenarios and say 'intimate communication is banned' when 'intimate communication' is not defined well.
you are dumping raw struct contents in your files that are only meaningful for the proprietary side of things.
What does that even mean? You could work with the bmp file format internally as a frame buffer in a program because it is uncompressed. Does that mean if you write a bmp file out of gimp and open it in photoshop you are violating the GPL? If so, why has that never been brought up or asserted by any person or company ever?
The things you are saying don't seem to line up with what anyone else thinks. When has anyone else tried to claim that you can't send files from one GPL program to another non GPL program?
I think you should consider whether you are trying to claiming something is true because you want it to be true, not because it makes sense.
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.
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
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 ?