Open source in embedded systems
From Google Summer of Code Mentor Wiki
Open source in embedded systems
Host: Joel Sherrill, RTEMS
There were about 15 people from various projects including Rockbox the open source Icarus Verilog project. Others in attendance were interested in embedded systems either as a hobby or professional interest but their open source project was not particularly targeting embedded systems.
I did not have a presentation as I wanted this to be an open discussion about the problems and challenges we faced.
The first topic was licensing issues for embedded systems. The issue of GPL compliance for embedded systems is a problem with projects like BusyBox and companies like Linksys being well known examples. A GNU/Linux embedded system must make available all GPL and LGPL source and modifications. But smaller embedded systems like many RTEMS systems and no-OS systems are statically linked which means that using GPL source will propagate GPL redistribution requirements to the application code. As mentioned in the Android talk, this makes GPL software particularly unappealing in the embedded community segment which statically links. And many are not accustomed to redistributing source even when it is not related to their application.
Even though it has OS properties Rockbox is a complete embedded application. They are GPL and have to be conscious of licensing of submitted code.
In contrast, RTEMS is an OS which users (usually) statically link with their application. As a project, we do not include pure GPL code in the main libraries since it could propagate the GPL requirements onto end user code. We do provide GPL libraries but they are always packaged separately and must be explicitly used.
Embedded developers usually do not want to open their application control code. It is specific to their hardware and often the core, unique value the company has. Graphic card vendors are an example. In other cases, there may be regulatory issues such as with WLAN.
Safety critical systems got some discussion. If an avionics, medical, or ABS brake system used GPL/LGPL software, a relinking kit with some source would have to be made available to those receiving the device that is the end product. In the automotive case, this would mean that the "relinking/source kit" would have to be available as a standard part at an automotive dealer. End users could potentially reprogram safety critical subsystems in their car. If this is done incorrectly or the software fails, it is possible people could be injured or killed. Although possibly not legally responsible for the damage, the automobile manufacturer would almost certainly find themselves on the wrong end of a high cost liability law suit. Is the possibility of this enough to prevent the inclusion of GPL software in safety critical systems?
The Verilog person (Stephen Williams - Icarus Verilog) mentioned that the use of VHDL and Verilog to program hardware blurs the line between hardware and software and often the interpretation of standard open source and free software licenses is not completely clear as you turn the software into hardware.
Co-existence of closed and open source software and hardware is a fact of life in this space. Proprietary tools are used to layout the compiled VHDL onto a specific part and process. Hardware assisted debuggers (JTAG, BDM, etc) are often expensive and only if lucky provide a gdb interface. There are projects to address this issue with Chris Johns' (RTEMS Steering Committee member) open source BDM GDB server for the Coldfire being an example.
NOT DISCUSSED: After I got home, I realized we did not discuss the impact of Non-Disclosure Agreements (NDAs). In the years I have worked on RTEMS, we have encountered multiple hardware vendors who require NDAs to get access to manuals for long shipping hardware. Many of these have drivers in the *BSD and Linux kernel.
