Posts Tagged ‘bsd’

Raspberry Pi Bootloader License Precludes it to Run on Competing Broadcom BCM283x Boards

July 19th, 2016 17 comments

Yesterday I wrote about ArduCAM Raspberry Pi compatible module, that packs most of the features of Raspberry Pi Zero or Pi Compute module into a 24x24mm board, and is based on Broadcom BCM2835 processor. One person also started a thread on Raspberry Pi forums about the tiny module, and one of the Raspberry Pi engineer and forum moderator replied that will would breach the bootloader license.

Raspberry_Pi_Bootloader_LicenseThe important part is the sentence highlighted above:

This software may only be used for the purpose of developing for, running or using a Raspberry Pi device.

ArduCAM module is only Raspberry Pi compatible, so it would indeed breach the license, and you can get into troubles if you planned to use that module in a commercial project, especially in countries where IP protection is taking seriously.

This raises a few questions. First why did the Raspberry Pi foundation chose that restrictive license? The obvious answer would be to protect there investment, but it’s also possible that since the bootloader and firmware is related to the GPU, video codec license may also have been a part of the decision.

The other issues is that after ordering 5K Broadcom BCM2835 processors for the first run of their ODROID-W module, Broadcom decided not to sell the processor anymore to Hardkernel subsequently. The exact reason is not known, but there are speculations that it was because of the Raspberry Pi foundation, and the license above may have been a reason for it. So could this also happen to ArduCAM? In theory yes, but If I’m not mistaken the company is based in China, and there are multiple smaller distributors, but it may not be quite as easy for Broadcom to block them.

The final question I has is whether it could possible to legally use the board without using the bootloader. Maybe… thanks to Kristina Brooks work on an open source bootloader for Raspberry Pi, released under BSD and GPLv2+, and not including any “Raspberry Pi only” conditions. There are some serious caveats such as no support for video codecs (licenses are part of it too), and while it can boot Linux, some things are broken.

If you are based in mainland China, and your customers are all based there, you probably don’t have to care about any of this, but in the western world, commercial projects should probably keep using official Raspberry Pi parts, or other solutions not involving Broadcom processors, nor official Raspberry Pi OS images.

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

October 10th, 2011 1 comment

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

General Public License Version 3 LogoThe 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

Lesser General Public License Version 3GNU 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

Berkeley Software Distribution LicenseThere 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

  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:

  • 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,

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.