Open-source software with its accessibility, reliability, and means of support clearly threaten the commercial software vendors who provide proprietary solutions. Using Linux for embedded development threatens the future market share for companies such as Microsoft and Wind River. It's in their best business interests to spread fear, uncertainty, and doubt within the embedded industry.5,6 For many years, Microsoft didn't consider Linux a threat in the desktop, server, or embedded arenas. That situation has changed, as Microsoft has stated that Linux is now its number-one target.7 Microsoft's attention to Linux further enhances Linux's position as a viable option for embedded development. Many developers see open source as a building block to create powerful products. Microsoft sees Linux as a threat to its future dominance of the embedded operating systems.
Use of open-source software has specific implications. In the context of using Linux for embedded design, open-source software has to do with a particular licensing model called the General Public License (GPL).8 (The entire GPL is not covered here, but we will address some GPL requirements that affect you and your embedded Linux design.)
Linus Torvalds originally released the Linux kernel source under GPL. This means that you are free to use and redistribute Linux without royalty or licensing fees, but you must make the Linux source code available to your customers. You can't sell Linux, but you can sell any distribution media or enhancements that you develop. For example, when you purchase a Red Hat Linux product, you aren't buying Linux from Red Hat; you're buying Red Hat's enhancements to Linux. Red Hat's enhancements include a program that simplifies the installation process and some other goodies. GPL states that all "derived work" must also be released under GPL. This means that if you modify some piece of Linux kernel code, your modification is also covered under GPL. If you distribute a product based on your modified kernel code, you must make available not only the original kernel source but also your modifications to it, in source form. At this point, you may be asking, "If I never touch the kernel source code but just use Linux for a product, how does GPL affect me? Do I really have to make my product available in source form?" The answer depends on how your product is linked and what it is linked to.
Let's assume, for example, that your embedded product contains a device driver or kernel module that you developed. You have an option to include that device driver in the kernel binary code at compile time or deploy the driver as a loadable module. If you build and distribute a kernel that includes your device driver, then your device driver code is automatically included under the GPL and you must make its source code available to your customers. Device drivers or modules that load dynamically after the kernel boot process are not included under the GPL, and you don't have to distribute your source code.
Designing products with Linux and other open-source software doesn't mean you have to make your software open source. Use of loadable modules and LGPL libraries protects your intellectual property.
If an embedded product executes solely in the user space (that is, it has no kernel code or device drivers), it is not affected by the Linux kernel source code GPL. An embedded product running an application in the user space can be affected through linking to libraries that are included under the GPL or another licensing model, called LGPL. Originally called the Library General Public License, LGPL now stands for Lesser General Public License. This licensing model allows developers to link to code, such as libraries, without having their code automatically included under the GPL. GNU released glibc under LGPL.9 If an embedded application statically or dynamically links to glibc for functionality, the application is not included under the GPL or LGPL, and you do not have to release your source code.
Use of open-source software promotes creativity and allows developers to quickly design embedded applications that are reliable and robust. Basing your embedded design on open source software doesn't automatically mean that you have to release your intellectual property in source form. It's quite possible that you can develop device drivers and kernel modules that load after the kernel boot process and your user space application code links to LGPL libraries.