If you’re planning to build any networked device, it’s likely to be an embedded Linux system. And using a kit from a board vendor makes it easy to start developing the system. However, these packages rarely take you all the way to a polished commercial product.
In most cases the board vendor will supply a root filesystem and a compiler. This provides everything you need to boot a working Linux system and write your application. You’ll soon have a build process for your application, and shell scripts to run it when the device is turned on. It’s also easy to copy your application into a filesystem image, and program each device you manufacture.
But the filesystem will contain two risks. First, if you don’t know every package it contains, you won’t be able to tell whether the next major vulnerability, such as heartbleed, will affect your device.
Secondly, if you don’t know the contents, you’re probably shipping software under GPL licence. Under the terms of the licence you need to offer your customers the GPL software source code, or you cannot distribute it. Take a look at this comprehensive guide, compiled by The Software Freedom Law Center, for more information on compliance.
The key message from this guidance is, you need to have the source code for the exact version of every GPL component before somebody asks for it. If you leave it too late, you may not be able to get the code from your vendor. For instance, how much do you trust that two years later they will still be able to provide the source you built your product on?
You also need to provide the correct version of source code for each version of device firmware you ship.
There are two good ways to make sure you know what you ship. Either base your product on a Linux distribution such as Debian, or build from scratch with a system such as Yocto.
Linux distribution solves the problem by providing a package manager that can find the source for every module in the filesystem and archive it for you. The embedded build system compiles everything from source code, guaranteeing the code you have is the correct version.
Finally, there’s a lot of value in taking human error out of the process. So, you may want to consider a fully automated build process that builds both your application and the complete operating system image.
Automated build avoids shipping a corrupt firmware version on the one day somebody mistypes. It also ensures that when your developers test a bug fix, they are testing the same system the end users will receive.
And it avoids depending on one developer and a single PC as the source of all builds. Because let’s face it, one day the developer will leave or the hard disk will fail!