Navigating open source

The components of embedded Linux are open source so now is a good time to consider what that means, why open source licenses work the way they do, and how this affects the often proprietary embedded device you will be creating from it.

Licenses

When talking about open source the word free is often used. People new to the subject often take it to mean nothing to pay and open source software licenses do indeed guarantee that you can use the software to develop and deploy systems for no charge. However, the more important meaning here is freedom since you are free to obtain the source code, modify it in any way you see fit, and redeploy it in other systems. Open source licenses give you this right, but some also require you to share these changes with the public.

Compare that with freeware licenses, which allow you to copy the binaries for no cost but do not give you the source code. Other licenses allow you to use the software for free under certain circumstances, for example, for personal use, but not commercial. These are not open source.

I will provide the following comments in the interest of helping you understand the implications of working with open source licenses, but I would like to point out that I am an engineer and not a lawyer. What follows is my understanding of the licenses and how they are interpreted.

Open source licenses fall broadly into two categories:

• Copyleft licenses such as the GNU General Public License (GPL)
• Permissive licenses such as the BSD and MIT licenses

The permissive licenses say, in essence, that you may modify the source code and use it in systems of your own choosing as long as you do not modify the terms of the license in any way. In other words, apart from that one restriction, you can do with it what you want, including building it into possibly proprietary systems.

The GPL licenses are similar but have clauses that compel you to pass the rights to obtain and modify the software on to your end users. In other words, you share your source code. One option is to make it completely public by putting it onto a public server. Another is to offer it only to your end users by means of a written offer to provide the code when requested.

The GPL goes further to say that you cannot incorporate GPL code into proprietary programs. Any attempt to do so would make the GPL apply to the whole. In other words, you cannot combine GPL and proprietary code in the same program. Aside from the Linux kernel, the GNU Compiler Collection and GNU Debugger, as well as many other freely available tools associated with the GNU project, fall under the umbrella of the GPL.

So, what about libraries? If they are licensed with the GPL, any program linked with them becomes GPL also. However, most libraries are licensed under the GNU Lesser General Public License (LGPL). If this is the case, you are allowed to link with them from a proprietary program.

The GPL v3 and LGPL v3 have their problems though. There are security issues. If the owner of a device has access to the system code, then so might an unwelcome intruder. Often the defense is to have kernel images signed by an authority such as the vendor so that unauthorized updates are not possible. Is that an infringement of my right to modify my device? Opinions differ.