A build system aimed at license compliance

The OpenWrt One is a router powered by the open-source firmware from the OpenWrt project; it was also the subject of a keynote at SCALE in 2025 given by Denver Gingerich of the Software Freedom Conservancy (SFC), which played a big role in developing the router. Gingerich returned to the conference in 2026 to talk about the build system used by the OpenWrt One, which is focused on creating the needed binaries, naturally, but doing so in a way that makes it easy to comply with the licenses of the underlying code. That makes good sense for a project of this sort—and for a talk given by the director of compliance at SFC.

He began with an overview of the OpenWrt One, noting that they are ubiquitous throughout the venue as the routers used by the conference. As might be guessed for a device from the SFC and OpenWrt, there are multiple interesting features that are not present in most routers of this sort. That includes a USB-C port that provides a serial device to a connected host on the front of the device, two separate Ethernet ports on the back, one of which supports power over Ethernet, various expansion options (M.2, mini-PCIe, mikroBUS), and an internal JTAG header for hardware debugging. The expansion options will come in handy, because "we do expect this device to last at least ten years, if not 20 or 30". More information about the device can be found in our November 2024 review.

There are multiple reasons why a company or organization might want to create and sell an embedded Linux device, including for profit or to generate funding for non-profit efforts, which is what the SFC and OpenWrt are doing. No matter what the reasons for developing it are, there are some requirements that devices need to meet; an important one is to comply with the licenses of the code that was used in the device. In order to comply with any requirements that there may be, the first question that needs to be answered is: "What is in this thing that I am trying to get compliance for?"

Answering that question can be complicated, he said, but it does not have to be, as he will show. A list of all of the upstream packages, along with their version numbers, for software that is installed on the device is the starting point. A list of the out-of-tree patches that have been applied to those packages is next. Hopefully, the number of such patches is low, because each one is something of a potential liability from a functionality and security standpoint. In the case of the OpenWrt One, the developers were "so excited" by the device that "they upstreamed basically everything that was required" for it to run a mainline kernel and other components.

An embedded device may require some non-free components that will also need to be enumerated. There is also the persistent question of whether linking proprietary code with copyleft code creates a derivative work, which Gingerich said that he briefly wanted to mention. "A lot of companies spent a lot of time and money trying to answer this question and, frankly, this is not the biggest problem that we see with compliance in various devices." It is something that companies worry about, but he would be focusing on the main problems that the SFC sees when it is assessing the copyleft-license compliance for devices.

OpenWrt build system

The OpenWrt build system, which was used for building the OpenWrt One, of course, makes it easy to create the tar file (or "tarball") of source code used to build the binary that is needed to install onto the device. The tarball is what is needed to comply with the copyleft licenses that apply to the code being shipped in the device. It needs to be ready and available when the device ships to users, not a month or three months down the road. An offer to provide the source code must accompany the device as well; for the OpenWrt One, that offer is prominently printed on the box it comes in.

In order to create all of that, the OpenWrt base tree Git repository can be cloned. It is a small tree; "basically it just controls a bunch of things about how to compile and install other packages". The OpenWrt build system is derived from Buildroot, but has diverged from that upstream over the 22 years since OpenWrt started in 2004. The "make menuconfig" command will allow the user to choose various configuration options, which results in a .config that reflects those choices. Then, "make download" will download all of the source tarballs and create a subdirectory called feeds to contain metadata about them.

The last piece of the puzzle is "how_to_*" files, though they do not need to be called that, Gingerich said. These are what the GPLv2 calls "the scripts used to control compilation and installation of the executable". The GPLv2 is the license of Linux, BusyBox, and many other programs, of course.

These files are "something that people who hack on things would naturally create"; if the developers want others to be able to install and run their project's code, they are going to create instructions on exactly how to do that. "The natural intent of the developer and the requirements of the license go hand in hand", he said.

Collecting the information about what is in the binary "gives us a minimal set of things that we can reason about". For example, complying with the EU Cyber Resilience Act (CRA) requires knowing whether the device is subject to security vulnerabilities; having a full list of all packages and versions helps determine which, if any, vulnerabilities need to be investigated and/or fixed. Another area where compliance comes into play is for certification, like that of regulatory agencies such as the US Federal Communications Commission (FCC). If, for example, something changes in the upstream wireless firmware for the device, it may need to be recertified. The OpenWrt One has been FCC certified, which means that running OpenWrt on other FCC-certified devices is legal, he said. "If a company says 'oh, no, we can't let you install OpenWrt because the FCC won't let us', that is wrong."

The end result is a 1.2GB tarball for the OpenWrt One, which includes "all of the source code for all of the toolchains that are needed, the cross-compilers, and all of the upstream packages". He noted that 1.2GB may seem like a lot but the SFC routinely receives candidate releases of source code from companies that are up to 20GB in size "with a lot of, you could say, extraneous things in them". He suggested that audience members might end up with a source tarball by requesting it from the maker of some kind of device, such as a television, refrigerator, or washing machine, but that they might find it comes without any instructions on building and installing that code. "That would be a problem", he said, and encouraged people to report those problems to the SFC.

Example how_to files

Meanwhile, people working on embedded devices and looking to follow the OpenWrt model may want some examples of what the how_to files might look like; the examples would also provide a framework for anyone evaluating a source release to determine "if you are getting what you should be getting". His examples came from the SFC Use The Source project, which collects candidate releases of source code along with analysis of what was found therein. At the site are examples of both compliant and non-compliant releases, but he wanted to highlight a few that demonstrate compliant instructions for building and installing code onto the devices.

The first, as might be guessed, was from the OpenWrt One (source code releases, Use The Source entries: 1, 2). He started by showing a diff of the top-level directory of a source tarball compared to the OpenWrt base tree. It shows that the source release adds a .config file, a feeds directory for metadata, and a dl directory that contains all of the downloaded source-package tarballs. Beyond that, there are three text files: how_to_basic_wifi_config.txt, how_to_build_system_setup.txt, and how_to_compile_and_install.txt. The first of those is not required by the GPL, but is helpful for users; the other two fulfill the GPL requirements.

The setup for the build system is fairly straightforward, since OpenWrt has extensive information on needed packages for various Linux distributions. Those were distilled into package-manager command lines for Alpine Linux, Arch, Fedora, Debian, Ubuntu, Gentoo, openSUSE, and others in the how_to_build_system_setup.txt file. That file is short, 67 lines, but how_to_compile_and_install.txt is even shorter still: 24 lines with a few simple commands, which result in a new firmware image being installed on the device. As part of that, make builds the cross-compiler toolchain needed, untars and builds all of the other packages based on .config, and then assembles the result into the image. "Simple and straightforward", he said.

He went through three other examples of "how_to" files in order to show that it is "not just us, everyone is doing this or at least sees that they need to do this". He showed the instructions for a Samsung television source release, which included instructions on how to build the Linux kernel and BusyBox binaries and, then, turn the latter into a Squashfs root filesystem image. A second set of instructions gave a step-by-step process to install the images onto the television. The release does not include any of the proprietary Samsung code for television functionality, just the GPLv2-covered works; a project called SamyGO is creating code to run on top.

An example of a source release for a ThinkPenguin router was up next. "It is perhaps the simplest of all of them." The company ships a CD with the source code alongside the device itself; the instructions are, effectively, just to run make and then browse to the web interface of the device to use the "upload firmware" option. "It's very cool that ThinkPenguin has provided such simple instructions for what can be a very simple operation."

The last example was for an AVM FRITZ!Box router, which provided a bit more of a "prose" script than others, but complies with the letter of the GPL requirements. The commands that AVM (now FRITZ!) provided are those that the company used on a specific version of Ubuntu (22.04.4) to update files in the firmware image. It relies on a GitHub repository for some of the tools, which Gingerich noted could have simply been included with the source distribution instead. There is nothing wrong with doing it that way, but there is a risk of falling out of compliance if that repository moves or disappears.

He noted that, while companies often know that they need to provide this information, there are lots of examples out there where they have not done so, sadly. Even if there is an offer for source, following the instructions to obtain it may not result in getting everything needed. If that is the case, or if it is unclear, users can upload the source releases and firmware to the Use The Source site to allow others to have a look. He invited attendees to visit the SFC booth in the expo hall to talk more about the OpenWrt One, perhaps purchase one, and, of course, to hopefully become a supporter of the SFC, which is a US non-profit.

Q&A

The first question was about the routers at SCALE, which the asker had heard were either running NixOS or that there were plans to do so. Robert Hernandez from the SCALE tech team said that they were "not running Nix on the OpenWrt One ... yet", though Nix is running on the core routers and other servers for the conference. Gingerich said that the SFC has provided routers to some distributions that indicated interest in running on the hardware; it already can run Debian, "and it would not surprise me if you see NixOS running on the OpenWrt One in another year or so, or maybe even sooner". Hernandez noted that there is experimental support for NixOS on the OpenWrt One in the SCALE network repository on GitHub; one of the routers at the conference is running NixOS as an experiment, "so it works".

Gingerich said that is "one of the neat things" about the device. He was a bit surprised that the OpenWrt developers were insistent that the project name not appear on the router; it only says "One" on it. "They knew from the start that they didn't want it to just be an 'OpenWrt thing'". He was quite happy to see other distributions running on the device; "it is exactly the kind of thing we want to encourage and support and a big reason why we made the OpenWrt One". The SFC is increasingly concerned that more router makers are locking down their devices, often in violation of the GPL; while the organization does enforcement activities, "sadly we cannot enforce against every single company that violates the GPL".

Another question was not directly related to the talk, but was about the U-Boot project; has the SFC "taken ownership" of the project? Gingerich said that he would characterize it differently; U-Boot had joined SFC as a member project in December and, as is usual, the project had transferred domain names and the like to a stewardship by the SFC. The project can move those elsewhere in the future if it chooses to, he said.

Following up, the attendee asked about who was maintaining U-Boot going forward, but Gingerich said that was not changing. The SFC simply handles the non-coding aspects of running the project: organizing conferences, paying developers, managing finances, and so on. It is nice to see that important projects like OpenWrt and U-Boot are choosing to join the SFC, he said. In response to a question about patent trolls, he added that the organization does have resources to help its member projects if they are being approached by patent trolls, which is another reason a project might want to consider joining.

The final question was about "what's next?"; the One seems like a successful project, "is there going to be a Two?", and, more generally, what does the future hold? There was some discussion of another device a little over a year ago, Gingerich said; there is still excitement for building a Two, but there are some supplier hurdles in the way of building the specific device desired. So it is not clear what the Two will look like, it might be a smaller, cheaper device; it is probably a year or two out before we see any new device, he said. The success of the OpenWrt One has caused the SFC to look at other types of hardware as well; "routers are not the only place where there are concerns about companies locking down devices". He closed by thanking attendees for all of the work that they do in free and open-source software.

The YouTube livestream from the room is available, though it has a persistent problem with the slide display; the slides are available separately.

[Thanks to LWN's travel sponsor, the Linux Foundation, for its travel funding to attend SCALE in Pasadena.]