16 ms·

That's a nitpick. Within this discussion if you take a GPL'd piece of software, a "program", and interface to it via pipe/exec you're just using an external pr

That's a nitpick. Within this discussion if you take a GPL'd piece of software, a "program", and interface to it via pipe/exec you're just using an external program, you're not linking to it and are 'immune' from GPL 'contamination'. If not it would effectively not be possible, or very difficult, to run commercial license programs on Linux, for instance.

Nursie 3y ago
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.
- EnigmaFlare 3y ago
  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.
  - Nursie 3y ago
    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.
actionfromafar 3y ago
It would not, however, Linux has: "GPL-2.0, with an explicit syscall exception"
- mytailorisrich 3y ago
  Deleted/Edited (sorry...): That's for the kernel, right? My comment was general and about all the interactions betweem programs.
  - actionfromafar 3y ago
    How else do you run programs on Linux? Edit: yes! And it in the general case it get really twisty and interesting. The classic example is a GPL cloning the functionality of a closed source program, down to arguments and options. Now, if you made some sort of closed source plugin for the GPL program, that's OK, if the plugin API was part of the originally cloned program. However, if the plugin API was an innovation in the GPL program, then a proprietary plugin the can easily be infringing. (And as always with GPL, only on distribution.)
EnigmaFlare 3y ago
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.
- mytailorisrich 3y ago
  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.
  - EnigmaFlare 3y ago
    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.

Nursie 3y ago

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.

EnigmaFlare 3y ago
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.
- Nursie 3y ago
  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.

actionfromafar 3y ago

It would not, however, Linux has: "GPL-2.0, with an explicit syscall exception"

mytailorisrich 3y ago
Deleted/Edited (sorry...): That's for the kernel, right? My comment was general and about all the interactions betweem programs.
- actionfromafar 3y ago
  How else do you run programs on Linux? Edit: yes! And it in the general case it get really twisty and interesting. The classic example is a GPL cloning the functionality of a closed source program, down to arguments and options. Now, if you made some sort of closed source plugin for the GPL program, that's OK, if the plugin API was part of the originally cloned program. However, if the plugin API was an innovation in the GPL program, then a proprietary plugin the can easily be infringing. (And as always with GPL, only on distribution.)

EnigmaFlare 3y ago

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.

mytailorisrich 3y ago
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.
- EnigmaFlare 3y ago
  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.