Question on GPL

Question

I'm starting to build a commercial application that uses an open-source library. I've been poring over various documents and postings, but I'm still having trouble. From what I understand I need to "isolate" the open source part. One way to do this is to provide a class which communicates with the open source through "vanilla" links.

The proposed solution is to modify the open-source (a command line utility) to give it some kind of API. Then develop an wrapper or proxy program that uses the API to communicate with the open-source program. Release the modified source and the wrapper as open source, but keep the rest of the source closed. Note that the open-source piece would be delivered with the code and executed either as a statically or dynamically linked library.

Does this work under GPL?

Answer 1

No, if it's GPL and you link with it, your code becomes GPL too. If it's LGPL, things are different (you can build commercial apps linked against LGPL licensed libraries), but that appears not to be the case here.

Answer 2

Before I start, I should say that I am not a lawyer, and this should not be considered as legal advice. If you need legal advice, you should hire an attorney.

As long as you are linking your program to the GPL'd software, your software is considered a derivative work of the GPL'd software.

If you wish to use a piece of GPL'd software, you should release your software under the GPL or a GPL-compatible license. Otherwise, you should find another piece of software that does what you need, or write it yourself. The point of the GPL is that the price of licensing it is that you also release your source code for your derivative work under a free software licence. If you would not consider using proprietary software without paying the appropriate licence fees, you should not use GPL

The only way in which you could isolate it would be by having an entirely separate executable, which communicated over a general-purpose interface (socket, pipe, or something), such that your software or the GPL'd software could be replaced easily. The interface that it communicates over needs to be very general-purpose; it cannot depend on implementation details of the GPL'd software, such as internal data layout or anything of the sort. Basically, if it communicates over a protocol that could be used as a general-purpose standard, then your software can talk to the GPL'd software without being considered a derivative work.

Anyhow, while it is possible to communicate with a piece of GPL'd software from proprietary software, you should not go out of your way to do so. You will be violating the spirit of the GPL, and would have to be very careful to make the interface general-purpose enough to not count as infringing. Instead, you should either find a piece of software with a different license that does what you need, write it yourself, or release your software under a GPL-compatible license.

edit: There is an interesting article posted on Linux Weekly News on this very topic. According the analysis in the article, even if you separate out an interface by which you can communicate with GPL'd software on the command line, you should do that as a clean room implementation with one group that works with the GPL'd code, one group that implements the other software, and all specs passing between them being filtered by lawyers. So, really, more trouble than it's worth.

Answer 3

If you don't link against it, you are in the clear. So instead of developing an API for this open-source command line tool, just write a little wrapper that interacts with the program directly on the command line.

Since you are not linking, and now are just executing a binary your code will not have to be released under the GPL.

You may use fork, pipe, exec and friends to do this! It is a simple solution and depending on how the application expects its input on the command line it can work very well (curses based stuff is harder ... need a terminal of some sort)

Edit:

From the comments it sounds like even this is not valid, and could still cause issues. I suggest contacting a lawyer to make sure you are in the clear, he will be able to interpret the GPL and tell you what you may and may not do with GPL'ed code.

I would think that just executing an GPL'ed program and then sending it data (a.l.a. piping data into it) should not cause your program to also be GPL'ed.

the GPL is too complex, if I use a command line tool by executing it and piping data to it my program can still become GPL. That is just weird. Give me BSD, and or MIT anytime of day, way simpler to understand.

Answer 4

With GPL I think the only way out is to wrap it in something like a COM object (which would also need to be GPL or compatabile), and connect to the object at runtime. Since this keeps you from (staticly) linking with GPL code, you'd be off the hook.

That trick will work with GPL v2 code, but may not work with GPL v3.

Answer 5

Do not believe people who talk about remote procedure call (COM) or standard IO. If there is anything to it at all, the standard IO thing comes from legacy situations like piping your output to grep and piping that into some other application.

Instead, think about it this way: Is your application a derived work from the GPL component? Could you explain, to a reasonably smart lay person, why your application is not a derivative of the open source library. You can explain stdio wrappers and COM interfaces until you're blue in the face but your lawyer, judge, customer, or whoever will not buy it. Instead you must show that removing that GPL library would not significantly modify the operation of your application. If you can't do that, well, sorry, but you're on thin ice.

Answer 6

Be aware, there are as many different interpretations of the GPL as there are people, just about.

I am not a lawyer, but I have spoken with lawyers about this subject. This is not legal advice.

Some lawyers believe that dynamically linking against the GPL is ok, and does not constitute a derived work. Others, such as RMS and his lawyers believe that dynamic linking is not OK and does constitute a derived work. Most believe that static linking is a derived work.

There is a lot of argument on the subject, and there is no definitive case law that defines what is and isn't a derived work in this regard.

See, for example This Article