Embedded Linux and the Law

Embedded Linux and the Law
By David Beal and Michael Barr, Embedded Systems Programming
March 13, 2003 (7:33 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020729S0028

The rising popularity of Linux, combined with perceived cost savings, has spurred many embedded developers to consider a real-time Linux variant as an alternative to a traditional RTOS. Here's the straight dope 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.^[1] 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 sit uation is much more straightforward.

Copyleft

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).^[2] 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 s ame 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.^[3] 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.

David Beal works for Lineo, where he is the general manager for the Embedix embedded development tools. He earned his BS degree in electrical engineering from the State University of New York. His e-mail address is daveb@lineo.com.

Michael Barr is the editor in chief of Embedded Systems Programming. He earned his BS and MS degrees in electrical engineering and worked as an engineer for a number of years. He wrote Programming Embedded Systems in C and C++ (O'Reilly, 1999) and is a lecturer at the University of Maryland. He is also a regular presenter at the Embedded Systems Co nferences. His e-mail is mbarr@cmp.com.

Endnotes

1. For a summary of the basic terminology, consult: Barr, Michael. "Know Your Rights: An Open Source Glossary," Embedded Systems Programming, September 2000, p. 80.

2. www.fsf.org/licenses/licenses.html#GPL

3. www.fsf.org/licenses/licenses.html#LGPL