Can I (legally) use a program that is released under GPL from another program that I'm writing and not have to respect the GPL (for the program I'm writing)?

For example, I have a GUI that uses a program (which is under GPL), can I hide the code in the GUI and even sell it?

4 Answers 4


You can use a GPLed program from your own program without your program being affected by the GPL, but you cannot link the GPLed code into your own program without your program becoming subject to the GPL's terms.

In the example provided in the question, in which you have written a GUI wrapper around an existing command-line program, your GUI is not bound by the terms of the GPL, provided that it is a separate program which runs the GPLed program in a separate process and communicates with it only via the existing interface(s) - e.g., over the command line and/or via stdin/stdout.

Some relevant bits from GPL FAQ:

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Can I release a non-free program that's designed to load a GPL-covered plug-in?

It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

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. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

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.

Note that the GPL applies in full to the underlying command-line program in any case - if you distribute it (as opposed to having users obtain it from another source), you are responsible for providing a copy of the GPL to users, making it clear to them that the command-line program is under the GPL (even if the GUI wrapper isn't), and making the command-line program's source code available to them on request. From the GPL FAQ again:

If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.

Standard disclaimer: I am not a lawyer and, even if I were a lawyer, I'm not your lawyer. If you need a definitive answer, consult an appropriate legal professional who is licensed to practice in your jurisdiction.

  • 1
    It should be noted that the FSF's position on linking is the minority position. (And, IMO, it makes no sense whatsoever. An automated process cannot create a new work.) Sep 24, 2011 at 18:32
  • 3
    However, the FSF did write the GPL. This makes their opinion far more relevant. "When we say X, we mean { ... }" is generally accepted in court. "When you said X, you meant {...}", not so.
    – MSalters
    Sep 27, 2011 at 11:30
  • What does it mean by "uses only simple fork and exec to invoke" - can someone clarify this?
    – Krunal
    Sep 12, 2013 at 6:46
  • 1
    So then the GPL can be easily bypassed by simply writing a pipe wrapper to run GPLed code in a separate process? That would seem to make the GPL irrelevant and impossible to enforce. What if I write my own library and link to it along with a GPLed library. Does my separate standalone library then become GPLed too? What if I link to someone else's library while using GPLed code? Does their library become GPLed? If you answer no to any of these questions, it opens a massive loophole to easily bypass the GPL. If you answer yes, then you're violating copyright law.
    – Cerin
    May 3, 2015 at 18:00
  • @Cerin - The GPL only really applies to code which you distribute. So, while you can write a program which links to both GPLed and non-GPL-compatible licenses, you cannot then distribute that program to third parties, as it would run GPLed and non-GPL-compatible code in the same process. ("Use without redistribution" is seen by many as a loophole in the GPL, since it means web services and the like can sidestep the GPL entirely because they run the software themselves instead of giving it to users to run. The GNU AGPL is an attempt to address this issue.) May 4, 2015 at 7:23

Depends what you mean by use it?

  • compile it into your code
  • use a shared library
  • run an executable

It also depends exactly which version/variant of the GPL the other code is under.

  • GPL
  • LGPL
  • AGPL
  • Probably others

Legal disclaimer: I am not a lawyer.



GPL code can only be used by other GPL code.

Citing the first line of wikipedia's GPL article:

The GPL is the first copyleft license for general use, which means that derived works can only be distributed under the same license terms.

Bsides of that, the GPL is several pages long and exists in several versions.

Warning, personal rant ahead!

I personally dislike the GPL license a lot because of it's very restrictive and virus-like nature. They call it "free" but it is actually quite the opposite, GPL code cannot be used by anything except other GPL code. Thus forcing other projects into GPL or being forced to rewrite whole libraries, whether your current project is open source or not. There were huge open-source projects, like freeBSD for instance which were forced to rewrite hundreds of thousands of lines of linux code because their license was incompatible, it was too "free" in the sense "do whatever you want", which is obviously not compatible with GPL.

If you want a truly "free" license in the sense "do whatever you want", I recommend BSD or MIT license ...actually, most of the other licenses are OK. It's only GPL which is really problematic because how restrictive it is and how it forces others into it. Lastly, it is overly complicated.

Ah, yeah, it's also a one-way ticket. GPL can use code/libraries licensed from most licenses, but these libraries/code cannot use GPL code in turn.

  • It says "derived works". Does that include software that dynamically links to GPL code?
    – user4595
    Sep 24, 2011 at 9:28
  • @WTP: definitely yes - the whole point of the LGPL is to have a different license that allows this. Sep 24, 2011 at 10:57
  • 3
    A GUI shell wrapped around a command-line program is not a "derived work" as defined for copyright purposes. Sep 24, 2011 at 13:28
  • 1
    @Dave Sherohman - that doesn't seem clear. The accepted answer to this question says: "IMHO, in spirit, a pure wrapper that merely exposes the functionality of a GPL program should be GPL." It's not just the technical aspect of how they communicate, it's the intent. For instance, translating a book is creating a derived work. Converting it to Kindle format would be a derived work. I could see a judge ruling that adding a GUI is creating a derived work. Beware. Sep 24, 2011 at 20:58

That depends on how exactly your program is "using" the GPL program. The GPL FAQ has a rather long explanation, but it still leaves a lot open to interpretation:

You cannot incorporate GPL-covered software in a proprietary system. (...) 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. (...) 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.

I think in your example of a GUI that exists mainly to call a command line GPL program, the two clearly form a single program, so you'd have to release your code under the GPL.

  • No, they do not "clearly form a single program". So long as the underlying command-line program remains able to function in the absence of the GUI overlay, they are combined by "mere aggregation" and are not "effectively a single program". Note the examples in the text you quoted - a compiler sits on top of the kernel and won't run without it, but the kernel will happily run in the absence of the compiler. Sep 24, 2011 at 13:26
  • 1
    @Dave: Whether the underlying command-line program remains able to function in the absence of the GUI overlay might be relevant if the license status of the command line program were in question - but the question is about the GUI, which is completely useless without the command line program, and therefore it's true beyond a shadow of a doubt that they form a single program. Sep 24, 2011 at 14:44
  • Let's substitute one of the examples from the section you quoted and see how that holds up. "...but the question is about the compiler, which is completely useless without the kernel, and therefore it's true beyond a shadow of a doubt that they form a single program." Except, of course, that the text you quoted explicitly states "you can treat them as two separate programs". If it was simply a matter of dependency, then you could never run closed software on Linux because that software would be "completely useless" without the (GPLed) kernel. Sep 25, 2011 at 11:23
  • @Dave: Except, of course, that compilers and all kinds of closed software are NOT useless without the Linux kernel, since they can and do run on anything that implements the POSIX and/or C library standards, and provide significant functionality of their own. Completely different matter than a GUI wrapper that exists solely to drive one specific command line program. Sep 25, 2011 at 14:53
  • 3
    You're wrong on the GUI part, though. That same GUI wrapper will work with other CLI programs, in particular later versions of the original. That is relevant in this context, because it means the original GPL rights on the underlying program can still be exercised. If I recompile it to be 10% faster, the CLI doesn't hinder me.
    – MSalters
    Sep 27, 2011 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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