The great thing about open source code is the large amount of high quality code that is available and many embedded projects use FOSS code as it really speeds up development time. What is not often taken into account are the licenses for the code. Many companies often simply ignore licenses issues and some even go one step further by obfuscating the code to work around dual license issues or to hide the use of a particular open source library.
Even though history shows that few companies get sued due to open source license infringements and release of open source code modified in commercial projects often requires the community involvement, open source licenses should still be taken into consideration as the risk still exists.
I’ll give an overview of open source licenses in this blog post, as well as recommendation on how to keep your proprietary code closed.
Definition of free software
All software that are under a free software license give four freedoms to all users:
- Freedom to use
- Freedom to study
- Freedom to copy
- Freedom to modify and distribute modified copies
Notice that free here, does not mean free of charge, you can still charge / be charged for open source software (e.g. Montavista Linux).
Free Software licenses fall in two main categories:
- The copyleft licenses – Modified code must be released under the same license
- The non-copyleft licenses – Modified code can be kept proprietary, but still requires attribution
The GNU GPL (General Public License) covers over 50% of the free software projects including the Linux kernel, Busybox and many applications.
GPL is a copyleft license so it requires derivative works to be released under the same license and programs linked with a library released under the GPL must also be released under the GPL.
Some programs are covered by version 2 (Linux kernel, Busybox and others), but more and more programs covered by version 3, released in 2007.
This is a major change for the embedded market as GPLv3 requires that the user must be able to run the modified versions on the device as long as the device is targeted to consumer.
There is no obligation to release the source when the binary is not distributed. For that reason, you can keep your modifications secret until product delivery.
Once you release the binary, you should do one of the following to make sure you comply with the GPL:
- Provide a copy of the source code on a physical medium.
- Provide a written offer valid for 3 years that indicates how to fetch the source code.
- Provide a network address of a location where the source code can be found.
In all cases, the attribution and the license must be preserved.
Companies often delay the release of the source code for several months or even years after the binary is released.
GNU LGPL (Lesser General Public License) covers around 10% of the free software projects and is mainly used by libraries. It is also a copyleft license and modified versions must be released under the same license. But contrary to GPL, programs linked against a library under the LGPL do not need to be released under the LGPL and can be kept proprietary. It must be linked dynamically, not statically as the user must keep the ability to update the library independently from the program.
LGPL is used in many libraries, including the C libraries and ffmpeg.
There are many different non-copyleft licenses where you can modify the code and keep the changes proprietary. The most commonly used are:
- Apache license
- BSD license
- MIT license
- X11 license
- If you make modifications to the Linux kernel, Busybox, U-Boot or other GPL software, you must release the modified versions under the same license and be ready to distribute the source code to your customers. Kernel drivers are a gray area but most people think they do not have to be released as GPL code and the source can be kept closed.
- If you make modifications to the C library, ffmpeg or any other LGPL library, you must release the modified versions under the same license.
- If you create an application that relies on LGPL libraries, then you can keep your application closed, but you must link dynamically with the LGPL libraries. If one the libraries is GPL, then you code becomes GPL.
- If you make modifications to a non-copyleft licensed software, then you can can keep your modifications closed, but you must still credit the authors either on a web page or in a leaflet in the product box.
Best Practices with Open Source Licenses
Here are some steps to follow during the development life cycle:
- Before using a free software library, application or operating system, make sure the license matches your project constraints.
- Make sure to keep a complete list of the free software packages you use, the original version you used and to keep your modifications and adaptations well-separated from the original version.
- Conform to the license requirements before shipping the product to the customers.
- Talk to a lawyer if your company can afford it.
Bear in mind that free software licenses have been enforced successfully in courts as you can see at GPL-violations.org,
If you want to keep your modifications proprietary try to do the followings if possible:
- Always link to LGPL libraries dynamically. As long as your program does not use open source code, it can remain closed source. But if you are using GPL libraries then your source becomes GPL.
- Write your proprietary source code in a separate application and use some inter-process communication to interact with programs based on open source code.
Finally, try to keep the changes separate either by using patches or a revision control system or both. This makes keeping track of the changes easier and facilitate migration to a newer version of free software when it is made available.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.