Barr Group FacebookBarr Group TwitterBarr Group LinkedInBarr Group Vimeo

 Printable PDF

The rising popularity of Linux has spurred many embedded developers to consider it as an RTOS alternative. Here's the straight scoop on the legal implications for the proprietary parts of your firmware.

One of the more confusing aspects of the open source phenomenon has been the proliferation of different source code licensing schemes.

There are so many different licensing terms, in fact, that if you are considering using multiple pieces of software developed by others in your products, you'll probably want to have an intellectual property lawyer read the license agreement for each such component and advise you how best to proceed.

Fortunately, if you only want to use Linux, the situation is much more straightforward.


A common myth is that the use of any piece of open source code, including Linux, requires the user to give away the source code to their own proprietary application. In truth, most open source licenses protect only the borrowed code and do not place any restrictions on other software you might develop for use alongside it.

The specific license accompanying the Linux kernel is called the GNU General Public License (GPL). The GPL defines rules that apply when you are leveraging software you would not have had access to if the code were proprietary. Under these rules, anyone is entitled to improve or modify the Linux kernel and its device drivers, applications, and services. But because these modifications create a derivative of the existing code, they must be made public under the same licensing terms.

If you don't modify the operating system, the GPL requires only that you give credit where credit is due, do not impose any further licensing or distribution conditions upon your customers, and provide the Linux source code you used to your customers, if they request it. Those are pretty reasonable terms, by any measure.

Rules to code by

Of course, there are many situations in which an engineering organization might want to keep its own code proprietary even when that code is surrounded by Linux's open source code. This is easily accomplished provided three rules of thumb are followed during development:

1. Start proprietary software from a clean code base

By ensuring that your proprietary code does not build directly upon any open source code, you remain clear of the "derivative work" clause found in the GPL. Derivative works are the source of most legal confusion; they must typically be made open source under the same terms as the original code from which they are derived. But proprietary code that merely interfaces to open-source code is not derivative.

2. Use only LGPL libraries

The GPL requires any code that links to a GPL library--statically or dynamically--to also be released under the GPL. However, a less protective license called the GNU Lesser General Public License (LGPL) was created so that developers could link to these open source libraries in either way without being bound to release their application's source code. Most key Linux libraries are licensed under the LGPL.

3. Don't modify the interface to the Linux kernel

Under the GPL terms, any modification made to the monolithic portion of the Linux kernel must be released as open source software. Note, however, that if your application requires that you make changes to the kernel, only those kernel changes must be made public. You can still keep your application code (and even loadable kernel modules) proprietary, provided that they simply interface with the kernel via Linux's standard system calls.

If you observe these simple rules, you should be able to distinguish between Linux and your proprietary code for all intents and legal purposes. Of course, it may still be prudent to talk with an intellectual property lawyer.

This article was published in the August 2002 issue of Embedded Systems Programming. If you wish to cite the article in your own work, you may find the following MLA-style information helpful:

Beal, Dave and Michael Barr. "Embedded Linux and the Law," Embedded Systems Programming, August 2002, pp. 21-22.

Related Barr Group Courses: 

Embedded Android Boot Camp

Device Driver Development for Embedded Linux

For a full list of Barr Group courses, go to our Course Catalog. See our Training Calendar for our latest public training calendar.


Good Artticle It cleared my doubts regarding GPL

What’s happening and how it’s done. Get in the know.

Sign up for our newsletter today!

Receive free how-to articles, industry news, and the latest info on Barr Group webinars and training courses via email. 

To prevent automated spam submissions leave this field empty.