# can a closed source commercial software make system(3) calls to GPL applications (not libraries)?

The closed source commercial software (CSCS), will just make system(3) calls to GPL applications.

The user machine will run CSCS and it will call these GPL applications, in realtime, in the very same way a user could use the command line and call the very same applications. Even a log of such actions could be provided, and user could replicate these actions manually.

In Java it would be like: Runtime.getRuntime().exec("echo Hello");
In C it would be like: system("echo Hello");

The point is, the CSCS is calling a GPL application to just generate realtime output, and in a predetermined way and hard coded on it, so CSCS depends on GPL app to work.

The GPL application is NOT a library. Is a regular command line application.

And, I am NOT going to distribute any GPL application (neither its sources) packaged together with CSCS. It will just depend that the OS have such GPL apps already installed. Also, CSCS can run with at least the version of the GPL application that was used in the development time (or newer), so it will NOT depend on a specific GPL app version to run.

1) Can the CSCS remain closed source on this sole specific situation?

2) Or should CSCS only use statically generated output from GPL applications, being prevented to use them in realtime, if it wants to remain closed source?

3) Alternatively could be created a LGPL software composed by scripts like ls -l \$1 whose parameters would be dynamic data provided by any application including this CSCS. In this case, all the logic of these scripts would be exposed and reusable by anyone, therefore not proprietary. So, such "protocols" would all be LGPL. Can that be done? Or this would simply fall under something like indirect use of GPL sofware, and so GPL would infect every application using it (including this very LGPL software, forcing it to become GPL)?

I would appreciate also excerpts confirming the answer, thanks!

PS.: I have read this Can I use GPL software in a commercial application, and it doesnt seem to answer my specific question.
And, I need to know this before I can consider any kind of realtime GPL application usage on my software.

I was unable to avoid linking this: https://meta.stackexchange.com/a/91116/222324

Obs.: (2 days after, considering all commented tips and answers) These may contain the answer:
A) I think this very question could actually be "What is a GPL derived work?" considering the "Networked Systems" section.
B) See "Mere Aggregation" in the GPL FAQ "pipes, sockets and command-line arguments are communication mechanisms".

PS.2: just as a final disclaimer, we all here seem to not be lawyers, and even if you do it all correct in this line, and even if you are sure of your license interpretations, something you do not expect may happen, https://softwareengineering.stackexchange.com/a/158925/112610

• Ask your lawyer, or perhaps the author of the GPL application. And define what you mean by "system calls": syscalls(2) or system(3) ? Also, what exact GPL applications are you using and how? What is your CSCS? So please edit your question (which is off-topic or borderline here) to improve it – Basile Starynkevitch Dec 14 '14 at 19:08
• Be aware that in Linux e.g. the system-call-interface is a public API and a licence-barrier. – Deduplicator Dec 14 '14 at 19:11
• @Deduplicator are you speaking about system(3) ? or both? – Aquarius Power Dec 14 '14 at 19:22
• Even after the edit, you don't explain what GPL software is invoked with system(3) and what is your program doing. Is the "protocol" between them specific to your application or not? – Basile Starynkevitch Dec 14 '14 at 19:24
• And if only using ls, just use stat & readdir syscalls instead. Or consider making all your application as GPLv3 free software – Basile Starynkevitch Dec 14 '14 at 19:34

This situation is covered in the GNU GPL FAQ, in the section "I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?"

in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

• [bash here is just to exemplify, it could be any other GPL application] that means that, for ex.: as bash is GPL, any bash script (that depends 100% on bash to run), must be released as GPL? also, /bin/bash application is and will continue being a single application on itself that can run independently of myApplication, I did not modify bash to depend on myApplication to run; but.. myApplication, will only be a runnable application if bash is present, that makes bash+myApplication a single application? or just makes myApplication a broken one? because bash could not be present? – Aquarius Power Dec 15 '14 at 0:36
• so in short: by depending on bash to run, myApplication must be GPL too? – Aquarius Power Dec 15 '14 at 0:38
• "if the two programs are combined so that they become effectively two parts of one program", well, myApplication will do the combining step, making myApplication+bash one application, and so myApplication must be GPL, or am I wrong? – Aquarius Power Dec 15 '14 at 0:43
• In theory, one could write a bash clone under a different license, so it isn't strictly speaking true that bash scripts depend 100% on bash to run. – Steven Burnap Dec 15 '14 at 0:46
• @StevenBurnap, I just found this that says exactly what you said. So, I would be coding in a language, but the interpreter license would not affect the code made in that language, as another equivalent interpreter could have other license. – Aquarius Power Dec 15 '14 at 0:53

And, I am NOT going to distribute any GPL application (neither its sources) packaged together with CSCS.

Copyright controls who is allowed to distribute something, not who is allowed to use it. If you don't distribute the GPL application, you can't infringe copyright, even if you depend strongly on it.

Your user could infringe the conditions on which they got the application you use, but GPL does not include such clauses.

• also, as an example, I just found this bash guide, there it says "When not to use shell scripts" -> "Proprietary, closed-source applications (Shell scripts put the source code right out in the open for all the world to see.)". So it basically says we should not create proprietary bash scripts for our algorithm safety, but it does NOT say that we cannot do it, that we are forbidden from doing it. – Aquarius Power Dec 15 '14 at 18:22
• Copyright does not just protect distribution; making derivative works is one of the exclusive rights a copyright holder has. Whether this is a derivative work is a legal question (though the FSF doesn't seem to think so, and they're the ones most likely to want to enforce the GPL). – cpast Dec 16 '14 at 8:56
• @cpast I found something that may be worth reading: en.wikibooks.org/wiki/FOSS_Licensing/…, look for "proprietary": "..and has source code from all three programs.", so what in case it has NOT source code from the GPL program? – Aquarius Power Dec 16 '14 at 20:03
• I just thought also that, if a GPL program is prefered over a proprietary one to perform the same task (output), like I suggest in the question, that puts that GPL application above the proprietary one, what is actually good. But that is just a thought... – Aquarius Power Dec 16 '14 at 20:05
• @AquariusPower Something could potentially be a derivative without including any source code whatsoever. Derivatives include copyrightable elements of the original work; everything hinges on what about software is copyrightable. There is an active court case in the US where a federal appeals court has ruled that APIs are copyrightable, for instance (the case is still ongoing, but the point is it's a question for lawyers). – cpast Dec 16 '14 at 20:16