嵌入式 Linux 上的开源许可证和应用:实用观点

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++.


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.

Learn About Digi Wireless Design Services
Download the Wireless Design Services brochure


什么是嵌入式操作系统? 什么是嵌入式操作系统? 嵌入式操作系统是产品的大脑。它经过精心设计和优化,可提高产品的控制效率...... 阅读博客 使用Digi ConnectCore 智能 IOmux 工具设计 ConnectCore SOM 使用Digi ConnectCore 智能 IOmux 工具设计 ConnectCore SOM Digi International 提供一系列用于开发产品设计的嵌入式系统模块。为了帮助简化任务... 观看视频 使用Digi ConnectCore 和 ByteSnap SnapUI 的机器学习演示 使用Digi ConnectCore 和 ByteSnap SnapUI 的机器学习演示 Digi International 和 ByteSnap Design 合作开发了一个有趣且具有娱乐性的海盗游戏演示... 观看视频 嵌入式安全的基石 嵌入式安全的基石 开发人员可以依靠 Digi TrustFence 实现内置安全,而无需从头开始设计功能。 查看 PDF 定制网关和路由器:何时、为何以及如何 定制网关和路由器:何时、为何以及如何 为IoT 应用程序开发定制网关或路由器在某些情况下可能是正确的方法,例如当... 阅读博客 使用设备树覆盖来修补设备树 使用设备树覆盖来修补设备树 Digi Embedded Yocto 3.0 中的设备树叠加机制使得通过小改动修复原始设备树变得更加容易。本文将分享 查看指南 Digi ConnectCore 基于 i.MX 的 SOM 可简化并加快开发过程 Digi ConnectCore 基于 i.MX 的 SOM 可简化并加快开发过程 开发IoT 产品极具挑战性,因此,很大一部分嵌入式设计项目都以失败告终。 录制的网络研讨会 Digi 无线设计服务 Digi 无线设计服务 Digi Wireless Design Services 为IoT 产品提供全面的咨询、设计和开发服务。 观看视频 嵌入式计算:设计易于制造、拥有成本低 嵌入式计算:设计易于制造、拥有成本低 嵌入式系统模块 (SOM) 市场不断发展壮大,为从零售显示屏到智能手机的各种应用提供了多种选择。 阅读博客 实时边缘处理让机器学习和机器视觉工作得更好 实时边缘处理让机器学习和机器视觉工作得更好 当今最有前途的互补技术包括机器学习(ML)和机器视觉(MV)。机器学习... 阅读博客 Digi ConnectCore 8M Nano:开发人员资源、安全性、可扩展性 Digi ConnectCore 8M Nano:开发人员资源、安全性、可扩展性 Digi International 最近宣布推出Digi ConnectCore 8M Nano 开发套件。Digi ConnectCore® 8M... 阅读博客 Evoqua Digi WDS 帮助 Evoqua 为商业应用提供与互联网连接的水监测解决方案 为了降低成本、提高效率并更好地为客户服务,Evoqua Water Technologies(埃沃夸水技术公司)通过IoT 来... 阅读故事 Vium Vium 提高制药和生物技术公司药物开发的成功率 Vium 可帮助实验室提高安全性,增强其测试药物化合物的能力,并更好地确定相关疾病的生物标志物... 阅读故事 Digi ConnectCore 8X Digi ConnectCore 8X 基于 NXP i.MX 8X 的智能互联嵌入式系统模块,具有可扩展的双核/四核性能,适用于工业IoT 。 查看产品