CNX Software – Embedded Systems News

Open Source Licenses Overview: GPL, LGPL, Apache, BSD,…

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:

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:

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:

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:

Practical Examples

  1. 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.
  2. If you make modifications to the C library, ffmpeg or any other LGPL library, you must release the modified versions under the same license.
  3. 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.
  4. 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:

Bear in mind that free software licenses have been enforced successfully in courts as you can see at,

If you want to keep your modifications proprietary try to do the followings if possible:

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.

Support CNX Software - Donate via PayPal, become a Patron on Patreon, or buy review samples