Is it appropriate to release incomplete open-source firmware, or in other words, to release only GPL software but not proprietary software source code?

How are non-open-source programs, in compiled firmware for a router/embedded device, allowed with the open-source, Linux-based operating system and other GPL software?

For example:

If a company releases compiled firmware and source code for a router but only releases the source code for GPL software within the firmware, is it okay, according to the GPL, that the firmware source code would be uncompilable because it is incomplete and is missing the proprietary part of the software?

5 Answers 5


You should contact the FSF and the copyright holders to know if you're in the clear.

For Linux non-open-source firmware code is usually shipped along the source as binary blobs - but I don't think you can link with a blob, you can only load it as if it were data. I'm not really sure of this so I can be wrong.

If I recally correctly the original NeXT Objective C compiler (derived from gcc) tried to ship only the modified gcc code and compiled object code for the ObjC parts but the FSF took that as a license violation and later NeXT released the code.

Once again, contact the FSF and the copyright holders.

  • Actually the NeXT (Apple) case is the one I've described in my answer. Long story short: they only released modified parts of GCC, which were totally useless without ObjC runtime, which they kept closed source.
    – vartec
    May 1, 2011 at 23:54

It should never be the case that GPL'd code used in conjunction with proprietary code is "uncompilable", because the license forbids such use. You cannot link (have them share the same process space) proprietary software with the GPL, you can only have the different processes launch each other, or communicate via some message passing mechanism.

In the case of packaged software that contains both GPL and proprietary parts which are not linked, the GPL requirement is that you are entitled to replace the GPL'd parts of that package with modified version of it, and restricting such replacement is a violation of it's terms.

Firmware is usually just a package of different programs which run independantly, so the GPL parts of the package are always recompilable.

The trouble with firmware is that vendors can release the source code as required by the GPL, but not provide any reasonable mechanism to replace the software, by limiting how the hardware is accessed. This has been called "Tivoization" by the FSF, and the GPLv3 was created to prevent vendors restricting the ability to modify the GPL parts of firmware like this.


IANAL, but... There are variations in what GPL licenses say you can do with libraries, etc. If your proprietary code uses GPL'd libraries as shared libraries, then you are OK in general. Some libraries explicitly allow a "linking exception", which allow you to statically link the library with your code. The eCos operating system (which is linked to your application as a library) has a linking exception.

A Linux device driver which is loaded into kernel space is a somewhat controversial area. In fact, if a non GPL'd driver is loaded, you'll see a "tainted kernel" message.

If you're writing some kind of proprietary software that uses GPL'd bits, I'd make sure to talk to someone who really knows what all the various licensing terms mean.


There is no requirement for the GPLed code you release, to be useful, stand-alone product. In fact in the past there was similar case, NeXT (now Apple) has released their modifications of GCC preprocessor for Objective-C, which were totally useless without runtime library, which they kept closed-source.

An article about the case.


You need to look at how the GPLed code is associated with the proprietary code. If the GPLed portion won't compile on its own, then definitely the code as a whole is a derivative work of the GPLed code, and must be released under the appropriate GPL or not released at all. (You can still use it for internal use, but the implication was that you would distribute it as part of a device.) Similarly, if the GPLed and proprietary code compiled separately but statically linked together, that's a derivative work of the GPLed code.

If you were to separate out the GPLed and proprietary code so that they were separately compilable programs, communicating only by standard inter-process communication protocols, then the GPLed and proprietary code would be two separate works, and only the GPLed portion would be under the GPL.

Anything in between is up for question. The Free Software Foundation takes a fairly liberal view of what constitutes a derivative work, but ultimately it's a matter for a court to decide.

As always, when trying to use software with a license with restrictions in ways that weren't intended by the license, either get a different license from the copyright holders (if possible and affordable), or consult a lawyer. Nobody here (unless the actual copyright holders are on programmers.se) can reliably advise you on exactly what's allowed and exactly what isn't.

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.