Distribute GPL'd software with closed source library?
Is it allowed by the GPL to distribute an open source application along with a closed-source library (ie. .so or dll binary) to be used from within that application? Or does such distribution force GPL'ing of the library as well? I'm unclear as to whether this is a derived work of the GPL app or not..
8 comments
http://www.gnu.org/licenses/gpl-faq.html
Not sure if this answers your question 100%, but I hope it points you in the right direction.
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. 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.
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.
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.
Not sure if this answers your question 100%, but I hope it points you in the right direction.
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. 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.
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.
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.
I look at it like this. If you are the author of both parts, why bother making the application open source? If you aren't going to make the whole thing open source, there isn't much to be gained by you or your users. Nobody wants to contribute to an application that's half-open, especially when they're debugging something and they step into the closed library.
If the library is an OS library, then you should have no problems.
If the library is an OS library, then you should have no problems.
If they are "one program", a distinction which seems clear but ends up being a judgement call, then no, you can not do this. If they are separate programs, then yes, you can do this. Plugins seem to be okay as well, but are a gray area. But your app's core functionality must be GPL'd or GPL-able or else you could be in trouble when you distribute it.
Loadable modules are something of a grey area, but in general the consensus is that yes they are derived works of the loading program, and thus must will be covered by the GPL if the overall program is itself GPL'd. The standard disclaimer applies, I am not a lawyer and this is not legal advice.
Some app developers have solved this by adding an exception to the GPL stating that linking to the library is allowed. You can only add the exception if you are the copyright holder.
Some apps have switched to LGPL to allow linking proprietary libraries.
Some apps have switched to LGPL to allow linking proprietary libraries.
If all of the code is yours you can add an exception specifically allowing linkage to that specific library. The GPL has a special provision for doing just that.
ask the fsf? I'm pretty sure that I've read they have people that will help you.
But I think it's the other way... you couldn't write a proprietary app based on a gpl library.
Look at all the 'open source' apps based on .NET and other windows technologyies.
I my self don't believe such apps are truly open source, as they rely on non open code.
"The standard disclaimer applies, I am not a lawyer and this is not legal advice."
But I think it's the other way... you couldn't write a proprietary app based on a gpl library.
Look at all the 'open source' apps based on .NET and other windows technologyies.
I my self don't believe such apps are truly open source, as they rely on non open code.
"The standard disclaimer applies, I am not a lawyer and this is not legal advice."
I think there's an exception that says that OS libraries don't count, since that would mean that you could not write open-source software on any commercial OS.
I had a difficult time figuring this out when I released a plugin for the closed-source software LCDC under the GPL. While it's clear that you can't link a GPL library into a non-GPL executable, the reverse case seems to be more muddy. I finally settled to my satisfaction that the spirit of the GPL should not prevent me from open-sourcing a library even if that library only is meaningful when used with a closed-source executable, given that I as the copyright holder can state the intent that the library be linked with proprietary software. It's sort of like the proprietary software is my "OS" and I'm linking to it.
I had a difficult time figuring this out when I released a plugin for the closed-source software LCDC under the GPL. While it's clear that you can't link a GPL library into a non-GPL executable, the reverse case seems to be more muddy. I finally settled to my satisfaction that the spirit of the GPL should not prevent me from open-sourcing a library even if that library only is meaningful when used with a closed-source executable, given that I as the copyright holder can state the intent that the library be linked with proprietary software. It's sort of like the proprietary software is my "OS" and I'm linking to it.
Thanks - this helps.
I had read the FAQ but wasn't certain what to think after reading the plugin question. The library I have in mind definitely doesn't call back into the main app (as the faq answer says) and they share data structures only in the sense of the library taking parameters.. not sharing in the shared memory sense of both accessing an in-memory structure being maintained by the program. Quite a gray area.. but it does seem clear as to the intent now. Thanks for the sanity check!
I had read the FAQ but wasn't certain what to think after reading the plugin question. The library I have in mind definitely doesn't call back into the main app (as the faq answer says) and they share data structures only in the sense of the library taking parameters.. not sharing in the shared memory sense of both accessing an in-memory structure being maintained by the program. Quite a gray area.. but it does seem clear as to the intent now. Thanks for the sanity check!
One way of looking at it is this: Does the plugin make sense without the context of the program which calls it?
This viewpoint has been used by some hardware companies with respect to their linux drivers -- they start by writing a FreeBSD driver, and then port that driver to linux. The FreeBSD driver (which contains all the details which they want to keep secret) is obviously not a "derived work" of linux, so this keeps them safe from any arguments about GPL taint.
This viewpoint has been used by some hardware companies with respect to their linux drivers -- they start by writing a FreeBSD driver, and then port that driver to linux. The FreeBSD driver (which contains all the details which they want to keep secret) is obviously not a "derived work" of linux, so this keeps them safe from any arguments about GPL taint.