I really like this post. Very clearly and quickly explainedthe differences between different type of licenses.
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
GPL License

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.
LGPL License

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.
Non-copyleft licenses

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
Practical Examples
- 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.