The question a teardown can answer
“Does the OpenWrt One deliver GPL compliance?” is the wrong first question for a forensic auditor, because a source download page is a claim, not a finding. The device is a useful worked example precisely because it publishes more than most routers: a per-build source archive and a hardware how-to that documents serial, JTAG, and a NOR-based full recovery path. What a teardown can establish is narrower and more useful: whether the published artifacts map to the shipped firmware, whether the physical access needed to verify and exercise that firmware exists, and where the gaps are that a vendor must close.
I treat the OpenWrt One here as a specimen for a repeatable audit method, not as a compliance verdict. The retrieved sources do not support a verdict, and I will flag every place where the evidence stops.
Tier 1: what the vendor publishes
The OpenWrt One source page states that it provides “source code downloads for the OpenWrt One that correspond to the software shipped on the device.” It also explains how those archives are produced: by cloning the OpenWrt source repository, checking out the corresponding tag, and adding the default .config and a how_to_compile_and_install.txt file (one.openwrt.org/sources/).
The listing is not a single tarball. It enumerates distinct builds: DVT Run (dd58ad968a), Test Run (c4a9265160), 2024-11-09 MP (3098b4bf07), and three later MP builds sharing tag ea17e958b9 (2024-12-30, 2025-02-12, 2025-03-07). That structure matters for an audit: “the source” is a set of artifacts keyed to build labels, and the first finding to check is whether the label on a unit in hand matches a published tag.
What this tier does not establish: that the archive is complete, that it builds, or that it reproduces the shipped binaries. The page asserts correspondence; it does not demonstrate it. I could not confirm from the retrieved text whether any archive includes a license manifest, SPDX document, or SBOM.
Tier 2: what the binary reveals
A binary-level audit starts from the flash image, not the download page. The standard workflow for an OpenWrt-based device is: extract the firmware, identify the bootloader, kernel, device tree, and early userspace, then match each component against the published source tag. The OpenWrt One’s how-to gives the physical entry points for that work.
- Serial console: the front panel has a USB-C serial console port with an integrated USB-to-serial converter that “does not require any additional drivers to be installed” and appears on the USB bus as “OpenWrt One” (OpenWrtOne-HowTo.pdf). That is the cheapest way to capture boot logs and confirm which bootloader and kernel actually run.
- JTAG: the how-to states the JTAG pins are exposed via a 2×5 pin 0.05 inch pitch connector, and points to
github.com/mtk-openwrt/openocd-scripts. For an auditor, exposed JTAG is the fallback when serial is silent or the bootloader is wedged. - Boot media: the how-to describes a boot select switch between NAND and NOR, an m.2 Key-M slot for a 2240 or 2232 SSD, and a CR1220 RTC battery.
The binary tier is where license strings, version banners, and build metadata surface. A kernel module or early-userspace binary with no matching entry in the published source tag is a discrepancy to document and raise with the vendor. It is not, by itself, proof of a violation: the component may be a System Library or separately licensed. The audit output is a discrepancy list, not a verdict.
Tier 3: what can be reproduced
This is the tier that separates “source offered” from “Corresponding Source delivered.” GPLv3 defines Corresponding Source for object code as “all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities” (GNU GPLv3, section 1). The definition also covers interface definition files and the source for shared libraries the work is specifically designed to require.
Applied to the OpenWrt One archive, the audit questions are concrete:
- Does the
how_to_compile_and_install.txtactually produce an image, and does that image match the shipped one? The source page says the archive is generated from the repository tag plus the default.config; it does not claim bit-for-bit reproducibility. I could not confirm buildability from the retrieved text. - Does the archive include the scripts needed to install and run the object code, not just the C sources? Section 1’s “scripts to control those activities” is the hook.
- Is the device tree source present for the shipped board revision, and does it match the compiled DTB in the image?
GPLv3 section 6 gives the conveyance options: object code in a physical product accompanied by Corresponding Source on a durable medium, or accompanied by a written offer valid for at least three years and for as long as spare parts or support are offered, or network access under section 6d. The OpenWrt One’s model is closest to 6d: source at a designated place, with the object code. Whether that satisfies 6d depends on the source remaining available “for as long as needed,” which is a maintenance commitment, not a one-time upload.
The repairability evidence and the Installation Information lens
The how-to documents a failsafe recovery method usable “even if the ATF or bootloader are broken”: set NOR boot, hold the front button, power up, and the NOR recovery system factory-reflashes the entire NAND from a preloader plus factory UBI image on a USB drive. It also documents NAND recovery via the rear button and a squashfs sysupgrade image, and a recovery initramfs boot.
For GPLv3 auditors, this is the practically interesting part. The GPLv3 preamble states that some devices are designed to deny users access to install or run modified versions of the software inside them, and that this version of the GPL is designed to prohibit the practice for products for individuals to use. The Installation Information requirement in section 6 attaches to “User Products.” The OpenWrt One’s exposed serial console, JTAG header, boot select switch, and documented recovery path are the physical preconditions for a user to install modified firmware. That is an observation about access, not a legal conclusion: whether any particular component is GPLv3-covered, and whether the device is a User Product for that component, are separate questions the retrieved sources do not answer.
Supply-chain verification: SPDX and SBOM
The SPDX specification is an international open standard, ISO/IEC 5962:2021 (spdx.dev). A per-build SPDX document or SBOM would let an auditor map each shipped image to its component inventory and license identifiers without reverse-engineering every binary. The OpenWrt One source page does not, in the retrieved text, publish one. That is a gap an auditor should record: the source archive answers “where is the source” but not “what is in the image and under what license.”
A reusable checklist for OpenWrt-based devices
Keep the three tiers separate and never let tier 1 stand in for tier 3.
- Map the unit to a build label. Record the tag from the source listing that matches the shipped firmware. A mismatch between build labels and shipped units is itself a finding.
- Capture the boot chain. Use the serial console to log bootloader and kernel versions; use JTAG if serial is unavailable.
- Inventory the image. Identify bootloader, kernel, device tree, and early userspace; extract license strings and build metadata.
- Match components to source. For each GPL-covered component, confirm a corresponding source entry exists in the published tag.
- Test reproduction. Attempt a build from the archive’s
.configand instructions; compare the result to the shipped image. Document any gap. - Check the conveyance route. Confirm which section 6 option applies and whether the source location is maintained for the required period.
- Check Installation Information. For User Products, confirm the documented path to install modified firmware is actually usable.
- Request the manifest. Ask for an SPDX document or SBOM per build; absence is a supply-chain finding, not a violation.
FAQ
Does the OpenWrt One source page prove GPL compliance?
No. It states that the downloads correspond to the shipped software and describes how they are generated. Proving compliance requires matching each shipped image to its source tag and testing whether the archive reproduces the binaries. The retrieved sources do not establish a verdict either way.
Is the published source archive buildable?
I could not confirm that from the retrieved text. The page says the archive is the repository tag plus the default .config and a how_to_compile_and_install.txt, but it does not claim bit-for-bit reproducibility. Buildability is a tier 3 test, not a tier 1 assumption.
Why does the recovery path matter for a license audit?
Because GPLv3’s Installation Information requirement for User Products turns on whether a user can actually install modified firmware. The documented serial console, JTAG header, boot select switch, and NOR recovery are the physical preconditions. Whether they satisfy the requirement for any given component depends on facts the retrieved sources do not establish.
What would an SBOM add?
An SPDX document or SBOM per build would map each shipped image to its component inventory and license identifiers, which is exactly what the source archive does not provide. SPDX is standardized as ISO/IEC 5962:2021, so the format is not the obstacle; publication is.