I want to write a closed-source desktop application that uses a piece of GPL software in the background.

I know that I can't link to a GPL library (libgit.a). But if I embed a GPL application (git.exe) into a closed source application, unzip the GPL app to a temporary location, and then make calls to it using some form of IPC (e.g. command line arguments), is that legal?

  • non-GPL application calls a GPL application at the command line -> definitely legal
  • non-GPL application links to a GPL application using function calls -> definitely illegal
  • non-GPL application bundles, distributes, and calls a GPL application at the command line -> ?

Distributing a GPL application and making silent IPC calls is functionally identical to linking, as far as the end-user is concerned. Does GPL care about whether I'm linking inside of one process, or using IPC to do the linking? It seems like closed source applications like GitHub's desktop clients do this, but maybe I'm misunderstanding how they work.

NOTE: This is different than the other GPL questions on this site, because it asks about embedding a GPL application, not linking to a library in the traditional sense. The answers have been specific to this case and very helpful to me.

NOTE2: Mods found a new duplicate, and this time they are right - it is actually asking the same question as this (although the details are a little more jumbled). The best answer has been modded into oblivion though. Key points are copied here:

  • VMWare Server's example shows that it's okay to include the object code into your distribution and
    • install it alongside your program
    • pack it into a compound file within its footage if it's clearly a compound file and can be taken apart with widely available tools (an ISO image)
  • 1
    As soon as you embed the GPL application into your code, it becomes a derivative work of theirs, and you fall foul of copyright law. It doesn't matter how you subsequently use the executable.
    – Simon B
    Jul 15, 2015 at 8:27
  • 2
    By the way, this question would probably fit nicely into the new Beta OpenSource.SE, in fact, I wouldn't be surprised to learn that it has already been asked and answered there. Jul 15, 2015 at 11:04
  • 2
    Even better: it turns out, it hasn't been asked there! Jul 15, 2015 at 11:10
  • 1
    Thanks for the OpenSource reference @Jorg. If this question were languishing I would definitely repost, but as it has gotten some useful answers, it seems spammy for me to double-post.
    – Ned Twigg
    Jul 15, 2015 at 12:27
  • 1
    I got downvoted because that answer was not for that question! That question is much more general, it asks about GPL+LGPL+MPL(+other similar licenses implied), all versions, which all say different things! While I focused on GPLv2 specifically! It's impossible to address them all at once in this level of detail, complete with references! Jul 17, 2015 at 19:14

2 Answers 2


Short answer: you're not forced to release your software under GPL; you can do it because you're making interoperability with GPL software and this doesn't make your software a derivative work (but if you want to feel more safe then don't distribute Git inside your application package, a dependency is OK).

Dirty workaround to avoid licensing headaches: note that if you make your package independent from Git and you have a separated Source Control Integration Layer then you may want to release under GPL (with source code on GitHub?!) only your Git integration module (not whole software which, in theory, is abstracted and compatible with any SCM).

Note that this question has been asked before: Can I use GPL software in a commercial application? but I completely disagree with given accepted answer and I'll try to explain why. GPL needs to overprotect itself to avoid abuses and misuses but its bounds are set by law and it can't prevaricate them.

Long answer: it's a common debate about GPL, you'll find both point of views (it's derivative work or it's not). I'm not a lawyer (and this issue has been disccused in a court too few times to have a well-known universally accepted answer) but let's try to summarize.

GPL ties you to distribute your source code if you deploy any derivative work based on GPL. First of all check if Git has a GPL linking exception (in that case you can freely use it). Main point is then to define derivative work. What they say about this (quotation from FAQ)?

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

For US law derivative work is:

“derivative work” is a work based upon one or more pre-existing works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.

How you define transformed and adapted from copyright point of view (in US law)?

This previously published material makes the work a derivative work under the copyright law. To be copyrightable, a derivative work must be different enough from the original to be regarded as a “new work” or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes.

You have to incorporate GPL material in your own application. To use it is not enough to define your work as derivative. If you think about it then this is pretty obvious (and important!) because if you use Git to manage your source code you don't need to release your application under GPL!

Moreover they also says that:

Titles, short phrases, and format, for example, are not copyrightable

Then now you also know that you have to include enough GPL material in your own work. A code snippet copied & pasted in your own code doesn't make it tied to GPL.

It seems that US law and GPL agree about derivative work but note that GPL is much more specific: they explicitly say they make functions calls [...] and share data structures. If you include git.exe in your program then you're not making any function call. It's (in theory) perfectly allowed by GPL license.

In fact they later explicitly says that:

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Also note that they generically speak about plugin so it may be applied also to dynamic linked libraries where you invoke just one function (although IMO it should also be the only exported function).

Dependent code is not derivative code, interoperability doesn't make your code a derivative work. There is even sentence from an US court for a similar issue: Lewis Galoob Toys, Inc. v. Nintendo of America, Inc..

Note that they also say:

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.

There is no mention about deployment method (one single package or a dependency).

According to GPL license you're in doubt but according to US law you have to incorporate GPL material to be tied to GPL license. You can do it without any problem but if you want to feel more safe then make it a dependency (installed together with your package or a mandatory prerequisite),

Given all these hard reasoning then:

non-GPL application calls a GPL application at the command line -> definitely legal

Yes, if connection between your code and Git takes place at user's computer then you're not restricted by GPL in any way.

non-GPL application links to a GPL application using function calls -> definitely illegal

Maybe not. If you invoke just one main plugin function then it may be a borderline case which IMO should be avoided because contrary to GPL spirit. If you don't like just don't use it.

non-GPL application bundles, distributes, and calls a GPL application at the command line -> ?

Legal, dependent code is not derivative code and interoperability doesn't make your code a derivative work. Moreover they explicitly states that if you use fork/exec then it's not derivative or combined work (no mention about deployment).

From Scott's link a lawyer explains this issue with much deeper knowledge and better wording, I'd like to highlight one passage from that article (emphasis is mine):

The phrase, "This General Public License does not permit incorporating your program into proprietary programs", comes after the "END OF TERMS AND CONDITIONS" statement. It is not part of the license itself. In any case, the statement is not supported by the text of the license. The GPL does not prohibit incorporating proprietary programs; at best, it requires that proprietary programs be subject to the GPL's inheritance obligations.

Also re-read dirty workaround I suggested at beginning if you want to feel safe.

  • This answer has the potential to be dangerously inaccurate. As far as I'm aware, what the OP wants to do would normally be done by saying "here's my software, it needs git, but I can't bundle it with my software, so go download and install it yourself." Even then I'm not 100% sure, and I'm pretty sure it's hard to prove what you're saying too. I'm pretty sure this'll get closed because it requires legal advice. Jul 15, 2015 at 12:19
  • 1
    @No, they (who wrote GPL license) explicitly handle this cases.It's not such inaccurate at least because it's not based on personal opinion. Jul 15, 2015 at 12:27
  • Here is an interesting discussion of this issue written by a lawyer (apparently). Jul 15, 2015 at 12:28
  • @ScottWhitlock yes, it's a reasonable (!) position of course (but IMO too few cases to have a solid background). However we're discussing about deployment. If you call an executable then your application is not derivative work nor combined work. Even for GPL itself if you simply invoke a function you're in a bordercase. Jul 15, 2015 at 12:33
  • @AdrianoRepetti: "If you call an executable then your application is not derivative work nor combined work" Then it is not neccessarily a derivative work. Look on the FSF site, or read the license, for the details. Jul 17, 2015 at 10:27

The answer by Andriano Repetti is perhaps correct but you should ask a lawyer (and I am not a lawyer neither), or perhaps the FSF or the copyright owners of the gitsoftware.

Be aware that some people think (and I believe that) if you adapt some GPL software (even if you publish your adapted source code under GPL!) to communicate with your own proprietary product by using a specific, ad-hoc, protocol (e.g. your JSONRPC on pipes) it is not legal (AFAIU) since your code is in that case a derivative work. Things are often different if the same protocol is used by several applications, including a free software one.

The point is that linking or derivative work has a different meaning to lawyers and judges that for developers. In some countries, the intent you have also matters!

But I am not a lawyer, and you really should ask one. You could also as a courtesy ask the authors of the free software, or even ask the FSF (or the FSFE in Europe, or APRIL or AFUL in France).

BTW, embedding in a compressed file the executable of git inside your application is certainly against the spirit of GPL, since your user is not able to easily replace your git by his own updated or improved version of git. However, you could package git.exe (probably with the source tar ball of that git) and tell your user that he/she needs to install it (and where, and how). If he wanted to upgrade git he should be able to do that easily (so please tell him how to do that). Even if such an executable embedding is legal (and I wish it is not), doing that is certainly user unfriendly. If using git you should at least explain your users which version ranges of git you want, and how to upgrade the git binary.

(Explanations around GCC plugins such as MELT and GCC runtime license exception and discussions around it might be relevant)

You might consider publishing your software with a free software license. It might be wiser and costs less to you. And you could then get external contributions and feedback.

  • I agree with "ask a layer" (absolutely!) but can you please explain better why you think if you make a communication plugin (released under GPL) you also should release under GPL the target application? They're separate works, I'm interested in that position! Jul 15, 2015 at 12:40
  • Because it is considered as derivative work and/or linking. IIRC, there have been some lawsuite somewhere in Europe about that. This is why you should ask a lawyer. And Sun did that in the past on GCC, and that was part of the motivation for the FSF to go from GPLv2 to GPLv3. See also the GCC runtime exception Jul 15, 2015 at 12:41
  • If there is a modification on the original GPLed code to actively support this bridge then I'd tend to agree too but if it's a merely an interface then GPL can't apply (IMO). GPL may be inherited but it's not transitive (friends of friends...) Jul 15, 2015 at 12:53
  • I don't know laws, and I am a free software enthusiast and contributor to GCC. So I am very biased. Also, I live in France and know nothing about US laws. Jul 15, 2015 at 12:55
  • 2
    It depends if I am using a well known and documented format, or if I had to patch the GPL software to suite the needs of that bank application. But you really should ask the FSF (or some other free software organization: FSFE in Europe, or APRIL or AFUL in France). I am not the right person to discuss that. AFAIK this is one of the motivations of the GPLv2 -> GPLv3 transition (in addition of TIVOization) Jul 15, 2015 at 12:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.