7

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:

However, 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.

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?

Steven Williams
  • 73

4 Answers4

10

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.

sylvanaar
  • 2,305
4

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.

David Schwartz
  • 4,704
1

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.

Sean McMillan
  • 5,064
0

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!

ThomasX
  • 19
  • 2