Can I dynamically call a LGPL/GPL software in my closed-source application?

Question

I want to use a tool (ffmpeg) that is under GNU Lesser General Public License, version 2.1 GNU General Public License (GPL) version 2 for some components.

To do so, I only call it in my software as such:

System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo = new System.Diagnostics.ProcessStartInfo("lgplSoftware.exe", myParams);
p.Start();

I do not change it, I only use a built version of the software for windows.

---

Wikipedia says:

A key dispute related to the GPL is whether or not non-GPL software can be dynamically linked to GPL libraries. The GPL is clear in requiring that all derivative works of code under the GPL must themselves be under the GPL. While it is understood that static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak Copyleft). The free/open-source software community is split on this issue. The FSF asserts that such an executable is indeed a derivative work if the executable and GPL code "make function calls to each other and share data structures," with certain others agreeing (e.g. Jerry Epplin), while some (e.g. Linus Torvalds) agree that dynamic linking can create derived works but disagree over the circumstances.

---

I am really confused by all this legal things. I would have made my project LGPL as well and released the source, but this is not up to me.

So the question is: can I use it like I'm doing right now or will I be executed by an army of lawyers?

Answer 1

I am not a lawyer, and this can not be a legal advice. With that behind us, IMHO if the code you are linking against is LGPL, you are in the clear. If it is GPL technically it is a problem.

The difference between GPL and LGPL, is that linking against LGPL code, does not trigger the need to share.

Answer 2

Correct me if I'm wrong, but I believe the situation you describe is like this:

1. You have a GPL or LGPL program, built as a separate executable, with no modifications made by you.
2. You are building a closed-source application that needs the functionality of the GPL or LGPL program.
3. In your program, you use your framework or OS facilities for running another, separate executable.
4. You are using the output of that executable in your program.

If that's the case, you're not actually linking to the GPL- or LGPL-licensed program. Thus, you're not bound by the license terms of that program. This is actually a fairly common, if complicated, way to avoid licensing issues with such executables.

However, it does violate the spirit of the GPL and the LGPL.

Answer 3

You can do this with LGPL software, but you cannot do this with GPL licensed software.

LGPL 2.1 section 6 on combined works says how you can use the library in your closed source program. You can call a LGPL licensed program like you do, and you can even dynamically link to it.

The GPL has no such exception, when you use a GPL program/library as part of your program, so that it is perceived as an integral part of your program, then you have to license everything under a GPL compatible license. See this GPL-FAQ entry.

Answer 4

Linking has a specific meaning in computer programming. You're not linking GPL'ed or LGPL'ed code at all, you're only spawning a GPL'ed or LGPL'ed binary, and the GPL and LGPL permit this. Your users are free to use that binary themselves for its authors' intended purposes and are free to download and compile the source themselves, so all of their freedoms are preserved, and you're not in violation of the GPL or LGPL. (This is what the GPL FAQ is talking about by "communicat[ing] at arms length.") This doesn't even violate the spirit of the LGPL and GPL; they tolerate the existence of proprietary software and assume that at some point proprietary programs will spawn free programs and vice versa. (Otherwise, we couldn't run any GPL'ed software under Windows.)

The GPL does require that proprietary and GPL'ed programs "are not combined in a way that would make them effectively a single program." If your program is completely dependent upon GPL'ed executables, such that it wouldn't be usable without them even though it is a standalone binary, then that might place you on shakier ground. (And it's probably time to consult your lawyer to find out for sure.)

Also, although you didn't specifically ask about this, keep in mind that distributing GPL'ed or LGPL'ed software with your software means that you're required to include a copy of the license with your installer and to also distribute the source code. For example, if you package up your application in an installer and include copies of GPL'ed or LGPL'ed executables in the installer, then you're distributing LGPL'ed or GPL'ed code and must make copies of the source code available (either online, by mail-in offer, or by CD, depending on how you distribute your app). Including a link to the upstream project is not sufficient (at least for version 2 of the GPL). Read the GPL and LGPL for exact details.

Answer 5

In general, it's one of the few things that I consider to be real nasty of the GPL. What makes it worse is how contageous it can be. Still, there is a way to get around it.

First, start by defining your own interface to send over data. This will be used between your application and a separate library that you will be creating. Don't re-use anything from the GPL code because that would fall under the GPL license. However, there's nothing wrong with using a similar structure. Since this interface is your own creation, it would fall under your own license. You're free to use it any way you like.

Next, create a wrapper library around the GPL code which will also implement your personal interface. This library would fall under the GPL license and thus it gets contaminated. However, although it would expose your interface to the outside world, your interface cannot be contaminated. It's not derived or whatever. It's 100% your own code and you could use the same interface to connect to a different library.

This wrapper library will serve as a protection buffer between your own propriety code and the GPL code. Your own code would never be GPL since it's not using any GPL code directly. The interface will also serve as a solution to change the GPL code by a different solution.

It is a trick to get around the license restriction but since the interface is yours and yours only, the GPL will be blocked by it. THE GPL code and non-GPL code would be two different programs if used this way.

Still, be aware that you might need some legal advise here. There aren't many lawyers here at SO. But it is a trick that can get around this GPL license.

Answer 6

Hi, The below link may throw some light over LGPL w.r.t static linking & dynamic linking. http://www.keyongtech.com/5486103-static-linking-in-lgpl-upgrading

Karthik Balaguru