The Software Freedom Conservancy’s suit against Vizio is often summarized as a fight over a TV’s source code. Technically, it is a fight over a definition: what counts as the “complete corresponding source” for a Linux-based television operating system, and who is entitled to demand it. That definition is where a firmware auditor’s work begins, and it is why the case matters beyond one manufacturer’s support portal.
I want to be precise about what this article is and is not. It is not a teardown report. I have not extracted an image from a Vizio E-Series mainboard, and I am not going to describe a dump I did not perform. What follows is a scoping exercise: using the public court record and the license text, I map out what a forensic audit of a SmartCast-class device would need to establish, and where the technical questions diverge from the legal ones.
What the record actually establishes
SFC’s own case page states the sequence plainly. SFC bought a Vizio TV, found it ran Linux, asked Vizio for the complete corresponding source code (CCS), and says Vizio refused. In October 2021, SFC sued in California state court, filing as a third-party beneficiary of GPLv2 — the theory being that a purchaser holds rights in the license contract between Vizio and the kernel’s copyright holders (SFC, Software Freedom Conservancy v. Vizio Inc.).
The dispute is not whether Vizio published something. According to Ars Technica’s review of the filings, Vizio has shared some source, but SFC’s 2024 amended complaint alleges the drop does “not include all files and scripts that would permit the code to be compiled into an executable form” (Ars Technica, May 2026). That is the crux an auditor cares about: a tarball of upstream projects is not the same thing as a buildable tree.
Two rulings frame the current posture. In December 2025, Judge Sandy Leal held that nothing in the agreements requires Vizio to allow modified source code to be reinstalled while guaranteeing the device remains operable — a point SFC says it never argued (Ars Technica). In February 2026, the court declined to resolve the case on summary judgment, sending factual disputes about the license’s scope and Vizio’s conduct toward trial (Baker Botts case analysis). The case has not concluded, and no finding of violation has been entered.
The license text sets the audit target, not the headline
GPLv2’s source-provision clause is specific, and it is the clause an auditor should treat as the specification. For an executable work, complete source code means “all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable” (quoted in Ars Technica).
Read that as three deliverables, not one:
- Module source — every covered work linked into the shipped binaries, including vendor modifications.
- Interface definition files — the headers and definitions needed to rebuild against those modules.
- Build and install scripts — the toolchain configuration, makefiles, packaging steps, and flashing procedure that turn source into the image on the device.
The third item is where most compliance drops fail, and it is the one SFC’s amended complaint targets. A vendor can hand over pristine upstream tarballs and still omit the kernel .config, the device-tree sources, the cross-compiler version, and the script that assembles the root filesystem. None of those are optional under the quoted language.
Mapping the definition onto a SmartCast-class stack
The public record names specific components, and it is worth listing them because each carries a different audit burden. Ars Technica reports that SFC’s amended complaint describes at least two Linux kernels in Vizio OS: one tied to the Ubuntu-based user interface and streaming platform, and a second “custom version supplied by VIZIO’s chip vendor for the lower-level operating system.” The complaint also names BusyBox, dnsmasq, GNU Bash, GNU Tar, and SELinux under GPLv2, and DirectFB, FFmpeg, GNU C Library, SELinux, and systemd under LGPLv2.1 (Ars Technica). Hackaday’s coverage of the original filing adds U-Boot, gawk, and glibc to the list (Hackaday).
That inventory implies a layered firmware, and each layer has its own source obligation:
- Bootloader (U-Boot). GPLv2. The vendor’s board port, environment defaults, and boot scripts are modifications that must ship as source.
- Kernel(s). GPL-2.0 with the Linux syscall exception (kernel.org licensing rules). Two kernels means two configurations, two device-tree sets, and potentially two vendor patch stacks.
- Device trees. The kernel’s licensing documentation explicitly lists
.dts{i}files as carrying SPDX identifiers, and many are dual-licensedGPL-2.0 OR BSD-3-Clause. The board-specific DTS for a TV mainboard is exactly the kind of file a source drop tends to omit. - Early userspace and root filesystem. BusyBox, bash, tar, gawk, dnsmasq, systemd, glibc, FFmpeg, DirectFB. Mixed GPLv2 and LGPLv2.1, with different obligations for linking and relinking.
An auditor’s job is to prove which of these are actually present in the flashed image, in what versions, and whether the vendor’s source drop can reproduce them.
How a forensic audit would scope the device
The following is a method, not a report. I have not run it against a Vizio board, and I could not confirm from public sources which SoC, flash part, or debug header an E-Series mainboard uses. Treat the steps as the sequence an auditor would follow once physical access exists.
1. Identify the non-volatile storage and debug interfaces
Consumer TVs typically boot from a serial NOR or NAND flash part on the mainboard, often an SPI device. The first task is to read the part marking and confirm the bus. If the board exposes UART pads, a console log during boot will name the bootloader version, kernel command line, and partition layout — information that constrains everything downstream. SWD or JTAG may be present on the SoC for boundary-scan or debug, but on production boards these are frequently depopulated or locked; I would not assume access.
2. Extract the image and preserve provenance
An SPI read produces a full-flash image. The audit record should include the part number, the reader used, the image size, and a cryptographic hash of the dump. Provenance matters because the obligation attaches to the object code actually conveyed in the product, not to whatever the vendor’s portal currently hosts.
3. Carve the partitions and identify filesystems
A typical layout includes a bootloader region, one or more kernel/DTB regions, and a root filesystem — squashfs, ext4, UBI, or a vendor format. binwalk and file will identify most of these; the root filesystem is the primary target because it holds the userspace binaries that carry GPL and LGPL obligations.
4. Build a binary inventory
Extract the root filesystem and enumerate every ELF. For each, record the path, size, SHA-256, architecture, and any embedded version strings. strings on BusyBox will usually reveal its version banner; the kernel image will carry a Linux version string. This inventory — not the vendor’s manifest — is the authoritative list of works to be matched.
5. Map each binary to a source package and build recipe
This is the step that decides compliance. For each copylefted binary, the auditor asks: is there a source package that corresponds to this exact version, and is there a recipe that rebuilds it for this target? A binary with no matching recipe is an open item regardless of what the vendor’s license notice says. The deliverable is a table with one row per binary and a status of matched, version-mismatched, or no source.
Where SPDX helps, and where it does not
SPDX is an ISO/IEC 5962:2021 open standard for representing software components as SBOMs (spdx.org). The Linux kernel requires precise SPDX identifiers in all source files (kernel.org), so a vendor’s kernel tree, if published, should be machine-parseable for license identity.
But the forensic question is different. SPDX tags live in source trees the vendor controls. The flashed image contains compiled binaries with no SPDX metadata. An auditor can use the kernel’s SPDX tags to verify that a published tree is internally consistent, but cannot use them to prove that a given binary in the image came from that tree. That mapping remains manual: version strings, build IDs, symbol tables where present, and behavioral comparison. SPDX is necessary documentation; it is not a substitute for binary-to-source correspondence.
What the December 2025 ruling does and does not change
The reinstallation ruling is often read as a narrowing of GPLv2 obligations. Technically, it separates two questions that compliance engineers should keep separate anyway. The court held that the agreements do not require Vizio to permit reinstallation of modified code while ensuring operability (Ars Technica). That is a question about the remedy and the device’s post-modification state.
The audit question is upstream of that: is the corresponding source complete and buildable? A source drop can be fully compliant on that measure even if the device will brick when you flash a modified image. Conversely, a device that happily accepts reflashed firmware can still be accompanied by an incomplete source drop. The two findings are independent, and conflating them weakens both the legal argument and the technical report.
GPLv3 does add an installation-information requirement for User Products (GNU GPLv3, §6), which is why the license version matters. The Vizio dispute concerns GPLv2 and LGPLv2.1, and the Baker Botts analysis notes that GPLv3 did not apply to this case (Baker Botts). An auditor should record which license governs each component before applying either standard.
The recurring pattern from earlier enforcement
Vizio is not the first dispute to turn on the gap between “we published source” and “we published the source you need.” SFC’s own litigation history lists its 2009 federal suit against Best Buy, Samsung, Westinghouse, JVC, and others, settled defendant by defendant through 2012 (SFC past litigation). The BusyBox cases and gpl-violations.org’s action against D-Link followed the same evidentiary shape: a shipped binary, a request, an inadequate or absent source drop, and a technical report showing the mismatch.
The lesson for compliance engineering is consistent across those cases. The artifact that survives scrutiny is not a license notice and not a directory of upstream tarballs. It is a source tree from which an independent engineer can rebuild the shipped binaries, including the build scripts and install procedure. That is what the GPLv2 text demands, and it is what a firmware dump lets an auditor test.
FAQ
Does the Vizio case require Vizio to let users reinstall modified firmware?
No. The December 2025 ruling held that the agreements at issue do not require Vizio to allow modified source code to be reinstalled while ensuring the device remains operable. SFC has stated it never argued otherwise. The source-provision question remains separate and is headed toward trial.
Has the case been decided?
No. A February 2026 ruling sent factual disputes to trial, and the case remains pending. No finding that Vizio violated the license has been entered.
Can SPDX tags in a vendor’s kernel tree prove the shipped firmware matches that source?
No. SPDX identifiers document license identity in source files. They do not establish that a compiled binary in the flashed image was built from that tree. Binary-to-source correspondence requires version strings, build metadata, and in many cases manual comparison.
What is the single most useful deliverable from a firmware audit?
A binary inventory with a per-binary status: matched to a source package and build recipe, version-mismatched, or no source found. That table is what turns a vague compliance claim into a testable finding.