try another color:
try another fontsize: 60% 70% 80% 90%
Institute for Legal Questions on Free and Open Source Software

Is a program that forks a GPL-licensed program via a system or vice versa call derivative work?

Example
 
An application runs a GPL-licensed program via a system call (system(), popen() or fork()/execvp() and friends). The GPL program is generating data that the application is reading and processing or, alternatively, that are made available when the application is exiting. Is this system call of a GPL-licensed program sufficient to assume derivative work of the application and must the application, therefore, also be licensed under the GPL?
 
Answer
 
Normally not.
 
Explanation
 
Starting an application from another application and exchanging data between the calling and the called program via command line, files or pipes is a normal and established procedure. This happens, for example, nearly every time a program is started from the shell. If this procedure implied that the called program is assumed a derivative work of the calling program and the shell in use is licensed under the GPL such as the standard shell bash, it would no longer be possible to run a non-GPL application from shell level. This would not reflect the intention of the GPL and would contradict common practice accepted from the authors of the GPL over many years.
 
This said, there are some restrictions to this general assumption:
 
1. The calling and the called program must not be packed into a single executable (which normally is not the case).
 
2. If the called program is continuing to run in the same memory space as the called program, i.e. fork() is not followed by execvp() or friends, and the calling program and the called program share common data structures and protocols, derivative work may be assumed. Similarly, if the called and the calling program are further connected using other communication mechanism such as sockets, shared memory, driver calls etc., derivative work may also be assumed. This is most notably the case, if the system call mechanism is primarily implemented to circumvent a situation that normally would lead to derivative work. Example: A special library that is licensed under the GPL and not under the LGPL shall be used. The author of a program that is intended to use this library is not willing to license his program under the GPL; therefore, the program cannot be linked together with the GPL-licensed library. In the hope to circumvent GPL licensing of his program, the author writes a server program that is linked to the library and listens to a local UNIX socket, and the application uses a socket connection to this server instead of library calls to use the functionality of the library. The server is, of course, licensed under the GPL. However, this will probably still lead to derivative work of the program and force its GPL licensing, although a connection via a UNIX socket would normally not. In conclusion, it is not the technical mechanism of the link between two works per se which defines whether the work is derivative or not. It is rather the character of interaction, the exclusivity of the connection and other conditions that define derivative work.
 
3. To exclude derivative work in a special and individual situation, it may be advisable to consult a lawyer.


Back to the overview of all FAQs