It would not, however, Linux has:

"GPL-2.0, with an explicit syscall exception"

Deleted/Edited (sorry...):

That's for the kernel, right?

My comment was general and about all the interactions betweem programs.

How else do you run programs on Linux?

I think that's probably an interesting case, and whether it's a valid defence is going to depend on what you're doing.

If you are (for example) shipping a product which is effectively a thin wrapper around a GPL 'd component, but instead of linking to a GPL'd library you've written and dutifully GPL'd a small shim program that turns the library into an executable and reads function arguments over a pipe, then you call that from your 'non-GPL' code... I don't think you'll find the process boundary is some sort of absolute defence in law.

In fact you may be looked upon unkindly in court for having knowingly attempted a license circumvention mechanism.

The law is not necessarily sensitive to the exact inner workings of a turing machine, and the definition of a derivative work may or may not be affected by such shenanigans.

If the whole product you're selling is just a thin wrapper around GPL code, why not simply sell the GPL code or GPL the wrapper? Surely the wrapper would be trivial for a competitor to replicate so the reason you're able to make money from it must be something else like other services you provide with it, or just the value of you having chosen and distributed that particular GPL program.

It was more of a thought experiment to show that a process boundary isn’t likely to be some sort of perfect defence, than a real example of how someone might operate.

GPL v2.0 is pretty vague on that:

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

I use the pipe/exec loophole to include a GPL program in a proprietary one. I personally decided that the proprietary code can be considered an independent and separate work because it's still does something useful without the GPL component. Also, you could swap the GPL component for a 3rd party proprietary one, which actually exists and uses the same interface for communicating via files. So to me, it's just a generic interface and I'm distributing the GPL program together as "aggregation" of separate works. For the sake of human relations, I also got approval from the GPL program's author to do this but he admitted he wasn't sure, and neither am I.

That quote is part of section 2, I believe. That section states "You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program...", so if my program uses a GPL'd program via pipe/exec I am not modifying the GPL's program at all, just using it, and so my interpretation is that section 2 (and in fact the whole GPL license), and therefore your quote, does not apply at all.

An example of what I have in mind: Let's say that you write a program and for some functionality it needs to grep files. Now, instead of programming this from scratch you just exec/pipe grep and grab its output. That's does not make your program GPL'd although grep is.

Packaging grep with your program to make distribution easier (if needed) does not, either.

I assume it never matters if you modify it or not since you're fully allowed to fork and redistribute GPL code. It doesn't even prohibit modifications that enable compatibility with proprietary software.

The ambiguity is in whether the two programs (proprietary and GPL) together count as a "work based on the program". Your grep example seems to support the idea that they don't, and it wouldn't fall under the operating system components exemption because it "accompanies the executable". But then where is the boundary? Others have said you can't make a GPL shim to convert a library to an executable then use it in this way.

Well, in the beginning of section 2, which I quoted, a "work based on the program" is defined as a modification of the program. If you use the program as is then you do not modify it and therefore your own program is not a "work based on the program".

A GPL library is a trickier case because it's all about linking to it and potentially how that is done.

My guess is that if the shim converts the library into an executable that is usable in itself generically then you're fine (e.g. you turn some 'libgrep' into grep then uses grep). But if it only implements something like RPC through pipes specifically for use with your own program then someone might decide that this is just convoluted 'linking' and falls within the licence.

I see. It almost seems to be starting to make sense. That even brings clarity to:

"But when you distribute the same sections as part of a whole which is a work based on the Program..."

No matter how you distribute them, they never formed a "work based on the Program" anyway so the GPL doesn't spread.

If all that's correct, it seems to leave a loophole that I mentioned where you can fork the original program to make it specially compatible with your proprietary program and redistribute it under the GPL. Now when you combine them you're not modifying it because you (or your friend if need be) did that before you obtained it and the modification is none of your business.