This question is asked in regards to gstreamer but it could apply to any add-on based architecture.

I have a Gstreamer based application that can ship as proprietary because I use unmodified Gstreamer in it with all LGPL parts. I may, however, also need to issue a version where one Gstreamer plugin is GPL. As far as I can tell that would contaminate the whole program.

If instead of including the Gstreamer pipeline specification in the program, I publish it with the ability to read a pipeline spec from an external file (coded per some set of instructions - i.e. as a GstParseLaunch()-able specification) can I release the program as proprietary and the pipe-spec files as GPL? How far apart would I need to publish those items, that is, would the program be in one distribution and the specs separately released in another?

What if the program is never truly released but is instead an embedded application sold inside an appliance and the appliance is sold preloaded with both the proprietary part and tghe non-proprietary part?

  • There's certainly been a lot of LGPL license restrictions I've always been unclear about...like, if a scripting language library is distributed under GPL allowing room for plug-ins, what exactly constitutes modification...Voted up from me.
    – Katana314
    May 22, 2013 at 1:00
  • See a lawyer. There is are situations for which only people having good knowledge of applicable laws and specific details can answer -- and the answer may be "you'll be sure only when a judge has decided". My understanding is that the notion of derived work is considered looking at the bigger picture and thus just changing a few technical details (and I'm aware of a case were the lawyer contacted considered that static linking of library vs a plugin scheme was just irrelevant technical details for that case) won't change the end result. May 22, 2013 at 8:56

1 Answer 1


Most of the answers can be found in the GPL FAQ.

For the interaction between GPL and non-free software, the basic rule is that they can only co-exist if they can both be executed as stand-alone programs. They may communicate with each other through standard inter-process communication features, but they should be separate programs as far as the OS is concerned. The major difference between GPL and LGPL in this is that the LGPL also allows dynamically linked libraries to be used by a non-free program.

Where it concerns plug-ins, the only things that affect the license status are the format of the plug-ins and the way that the plug-in and the main program interact after the plug-in has been loaded. If the plug-ins are separate programs, or the application treats them as such, then it is possible to have a GPL plug-in in a non-free program. If the plug-ins are libraries with any kind of back-and-forth communication, then you can't use GPL plug-ins with your non-free program.

As far as I can tell, an external specification of the plug-ins to load is not going to make it acceptable (in the view of the licenses) to use a GPL plug-in with a non-free program. You are right that the one GPL plug-in will contaminate the whole program.

(L)GPL software and embedded devices is a whole topic of its own.

The short version here is that, if you distribute a device that is loaded with GPL software, you are distributing the software, so you must make the sources available to the buyers of your device (assuming the software can be upgraded without physically modifying the device).

The intention of the GPL has always been that end-users should be able to replace the device's software with their own versions, but apparently the GPLv2 has a loophole here. The GPLv3 has made that intent an explicit requirement.


Your Answer

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

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