Take the 2-minute tour ×

I'm planning on running an executable as a child process in my program (e.g. using Ruby's popen or C's exec() family of functions). However, the executable I'm planning on running is licensed through the GPL.

The GPL, as I understand it, requires that all linked code to GPL licensed code needs to also be GPL.

But there's also an "arm's length" exception, discussed in the FAQ:


Would runnning an executable as a child process be part of this exception, or would it still be considered "linking" for the purposes of the license?

If it is considered "linking", how does it differ from running program, like Nmap, from the a command line?

share|improve this question
think this covers it programmers.stackexchange.com/questions/50118/… –  jk. Aug 22 '11 at 10:56
It doesn't seem to cover my question, which is someone trying to get around the GPL by not linking, but using a server. In my case, I can't link(AFAIK) because Nmap is a program not a library, and using popen is like using C's exec functions. It spawns a new process, but is a child process of my program that uses pipes for IO between parent and child. I would ship my program without Nmap, and the end-user would have to install it himself. I haven't decided on what license, but am leaning towards a open license of some sort, but if legally permissible I might need to dual-license. –  Steven Williams Aug 22 '11 at 18:00
@Steven thanks for clarifying your question. I've revised it a little more to focus on the specific use-case rather than a blind reading of the license, to try to keep it on-topic for Programmers. –  user8 Aug 22 '11 at 18:42
add comment

4 Answers

up vote 6 down vote accepted

I think this quote from the section on plugins might lead you in the right direction.

If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.

share|improve this answer
add comment

Lets compare the strings "running an executable as a child process" and "linking a library". One starts with the letter "r" the other with the letter "l". Therefore it is not the same!

share|improve this answer
What about "running some code as a child process" and "running some code as a linked library"? –  mouviciel Aug 23 '11 at 7:54
add comment

This is generally considered to be okay, as long as the child process is a sensible program in its own right.

Ultimately, the question is, is the owner of the GPL'd code going to sue you, and can he convince a judge that the processes are "combined in a way that would make them effectively a single program." If the child process is a tool that can be used on its own, and you are invoking that tool, you should be fine.

share|improve this answer
add comment

You are going to have a hard time getting a good answer to this question. The issue is that the correct answer to your question relies on a complicated legal question for which there is as yet no answer.

I am not a lawyer, but I'll tell you my own position, for what that's worth. Linking, because it does not involve a creative process, cannot create a new work for copyright purposes. Linking is legally like stapling. Linking two works together is just like stapling two DVDs together. The output is, legally, the same as the input. It is the two works.

So if your work was not a derivative work before you linked it, it is not a derivative work after you linked it. The GPL requires source code of distributed works be distributed. So the question is whether the work whose source code you don't want to distribute is a derivative work. Since linking can't change this, the question comes down to whether the work was a derivative work before you linked it.

Legally, with only a few exceptions by statute that don't apply here, a work is a derivative work if it contains significant protectable expression taken from the other work. Note that functional elements are not protectable expression, only creative elements are.

So the answer to your question is: If your code contains sufficient protecable expression taken from a work covered by the GPL to make it a derivative work of that work, then yes. Otherwise, no.

share|improve this answer
After linking, the executable is a derivative work (same as translating a book to another language). GPL requires all source code to derivative works be made available. This is not ambiguous. There is also more to linking that your stapling analogy suggests, but that doesn't matter unless we get into dynamic linking. –  phkahler Aug 22 '11 at 14:37
I don't think that in this case, any linking occurs. –  Steven Williams Aug 22 '11 at 17:31
@phkahler: Not true about dynamic linking. Right, you mention that. But it isn't clear if David meant static or dynamic linking either. –  Zan Lynx Aug 22 '11 at 18:45
Linking cannot make a derivative work. Under copyright law, a derivative work is a type of new work, and a new work can only be produced by a creative process. If linking could make a derivative work, then the linker would be entitled to copyright, since it had made the work. That's absurd. Linking is legally equivalent to stapling -- it's a non-creative process that simply aggregates two works. If your work wasn't derivative before you linked it, it can't be derivative after. Only a creative process can create a new work, derivative or not. –  David Schwartz Aug 22 '11 at 18:53
@David Schwartz: Repeating your idiosyncratic view in a comment doesn't make it mainstream. I've read a good deal about software and copyrights, and your opinion took me totally by surprise. You're welcome to your own opinion, of course, but from about the middle of your second paragraph on you were giving what looks awfully like legal advice, speaking very definitely about the law. Since you are not a lawyer, you're almost certainly not qualified to establish novel legal theories and rely on them. –  David Thornley Aug 22 '11 at 19:36
show 19 more comments

Your Answer


