Developers of proprietary software are sometimes leery of embedded Linux platforms, due to the implications of open source licenses such as GPL (the GNU Public License) for their applications. They are concerned that running on Linux may expose them to obligations from the open source licenses of other software components on the system in such a way that they could be required (through litigation) to share their source code with competitors, customers or the general public.
While not pretending to offer legal advice, this article presents some practical hints and suggestions for those thinking about deploying a proprietary application on an open source platform, based on the typical experience of many of our clients using common platforms like Digi Embedded Yocto, Linaro, Android and others.
Android As an Open Source Alternative
Admittedly the safest, most reliable way to avoid GPL exposure is not to run on GNU/Linux at all: Google’s Android operating system provides an open source alternative for embedded devices that was deliberately designed from the ground up to eliminate GPL-licensed software from its userspace environment, in favor of components with more permissive licenses (like the Apache or BSD licenses) that don’t require developers of derivative works to share their sources.
Modern Android releases contain essentially no GPL components (apart from the Linux kernel itself, which imposes no restrictions on applications). Distributions are available for common hardware (including Digi’s ConnectCore® SOMs), and Android has been successfully ported to many custom embedded boards.
On the other hand, Android has traditionally been less well-suited for headless systems, and to some extent it’s an OS maintained by and for mobile phone vendors and cellular carriers. Although plenty of talent is available for creating apps on phones these days, developers who are experienced with BSP (board-support packages) using embedded Android are somewhat less common in the community.
GPL considerations on embedded GNU/Linux
Embedded Linux continues to enjoy a great diversity of hardware support and a large developer community working at all levels of the software stack. For those not opposed to systems with GPL software, it can be an excellent, dependable platform choice. At least in our experience, the overwhelming majority of application software developers don’t run into legal problems with their customers, competitors, or the general public.
Application developers on embedded Linux should nevertheless keep in mind a few basic concepts and rules of thumb. We will cover the following:
- Basics of GPL
- Application vs. Drivers
- Open Source Libraries
- Static vs. Dynamic Linking
- Interprocess Communication
- Standard C Library
- Python and Other Programming Languages
Basics of GPL
GPL-licensed software is open source: the source code must be shared with anyone to whom the software is distributed. But the fundamental and most distinguishing concept of the GPL (both GPLv2 and GPLv3) is self-propagation: the GPL license applies to any derivative works, i.e. other software such as applications that incorporate the GPL software, for example by linking with GPL libraries. To boil it down, if your application links with GPL software or incorporates it in any other way, then you may be obliged to share your sources.
Application vs. Drivers
On a Linux system, drivers in general are components that compile with the Linux kernel, and they are necessarily subject to the GPL. If you write a driver for Linux, you may need to share your sources, just like all the major silicon vendors do (NXP, TI, Intel, etc.). There are some vendors who distribute kernel modules in binary form (primarily for cryptographic devices and other very sensitive hardware), but the legal status of these non-free drivers is not settled.
In any case, the majority of peripheral devices don’t have serious IP concerns at the bus interface level where driver software operates. When hardware devices do contain valuable IP, it is frequently managed in firmware inside the device and not exposed to drivers through a bus interface. An application, on the other hand, operates at the userspace level: it may communicate with the Linux kernel (via system calls through libraries), but it’s widely accepted that applications don’t have any licensing dependency with the Linux kernel.
Open Source Libraries
C/C++ applications generally must link with publicly-available libraries to access system facilities and avoid reinventing the wheel. (For example, a C program that uses Bluetooth may need to link libbluetooth, which is part of the BlueZ stack and GPL-licensed.) Since many system libraries on GNU/Linux are GPL-licensed, the application may take on GPL obligations by linking with them.
Static vs. Dynamic Linking
It’s a commonly-held belief that linking dynamically (instead of statically) protects the application from GPL inheritance, but actually this is a matter of controversy which hasn’t been fully resolved in court. The FSF (Free Software Foundation, associated with GNU) maintains that the GPL does extend to dynamically linked code: https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic.
Interprocess Communication
On the other hand, C/C++ applications don’t need to link with every system library. Many applications will get along just fine without libbluetooth or other GPL-licensed libraries. No GPL obligation is conferred on the application if it doesn’t incorporate GPL-licensed software, even when it operates in a GNU environment. If an application performs interprocess communication with GPL components (such as using DBus to communicate with systemd or other daemon processes), it is generally accepted that this does not confer any GPL obligation on the application.
Standard C library
The one library that virtually any C application needs to link with is the standard C library: the most common implementation on Linux is GNU’s glibc. Even though there exist alternative C library options for embedded Linux systems that have permissive licenses (like uclibc or musl), there’s no real need for proprietary application developers to avoid the GNU C library on account of the license: because it’s not GPL.
The GNU C library is actually LGPL-licensed: the main practical distinction between the two is that the LGPL (“Limited GPL”) makes an explicit allowance for dynamic linking: if your application links glibc dynamically (not statically), you don’t undertake an obligation to share your sources.
Python and Other Programming Languages
What about other languages? If your code is not written in C, can you sidestep the GPL because you’re not linking to GPL libraries? For example, the Python interpreter has its own permissive open-source license. It does not impose any requirement to share sources. But the Python license is also compatible with GPL. If you write and distribute a Python script and import only non-GPL Python libraries, then you may avoid GPL obligations. On the other hand, some Python libraries are GPL-licensed. (For example, if they depend on underlying GNU C libraries, so that the GPL propagates to the Python library.) As it turns out, the case for a Python application is very similar to that of C/C++.
Takeaway
Proprietary, closed-source applications can coexist with GPL software components on a GNU/Linux system. Since the legal status of dynamic linking under GPL remains in dispute, a safe course to avoid accidentally undertaking GPL obligations is to make sure your application doesn’t link with nor directly ‘incorporate’ any GPL software. This may mean seeking out alternatives for certain C or Python libraries. But the GNU standard C library itself isn’t among those, since it has only an LGPL license. There are many other GPL-licensed components running on a Linux system, but it’s generally accepted that these don’t propagate their license to an application whose code is not derived from them.
Our team can provide design guidance, complete hardware design and application development services, certification support and more. Contact us to start the conversation.