Shipping a NAS appliance with mixed open-source components
Northwind Storage ships a 2U NAS appliance built on Linux 6.6. Four components are in the image: (a) nwfs.ko, a custom kernel module that calls register_filesystem and uses symbols exported with EXPORT_SYMBOL_GPL; (b) nwmgmtd, a closed-source userspace daemon that talks to nwfs.ko over a netlink socket; (c) a patched GRUB 2.12 with a custom theme, used in the signed UEFI boot chain; (d) BusyBox 1.36. The company sells the appliance to customers and includes a printed notice: 'Source code for modified open-source components available on written request; offer valid for two years.' Nothing is published otherwise. Engineering wants nwmgmtd to remain proprietary and wants the boot chain to keep rejecting unsigned bootloaders. Legal asks you, the Linux engineer, which obligations are triggered and what must change before the next shipment. The kernel module is not upstreamed and the GRUB patch is not sent upstream either.
1. Which of the four components create source-code obligations, and which can remain closed? Justify each component separately.
Read the worked answer
Treat each component separately.
- nwfs.ko - The kernel is GPLv2. A module that calls kernel functions and specifically uses
EXPORT_SYMBOL_GPLsymbols is treated by the kernel community, and by the FSF, as a derivative work of the kernel. It must therefore be GPLv2-compatible, and the complete corresponding source for the module must be provided to recipients. This is a community and legal interpretation rather than a court ruling, but it is the interpretation a vendor should plan around. - nwmgmtd - It is a separate process. Netlink is a documented kernel ABI, not linking against kernel code. A proprietary userspace program that merely uses kernel interfaces is generally not a derivative work, so it can stay closed, provided it does not include GPL code.
- GRUB 2.12 - GPLv3. You distribute a modified version, so you must provide the modified source under GPLv3, including the theme and patch.
- BusyBox 1.36 - GPLv2. You distribute binaries, so source must be provided or offered under GPLv2.
So three components create source obligations; only nwmgmtd can remain closed.
2. Is the two-year written offer acceptable? State what the licences require and how to correct the notice.
Read the worked answer
The notice is not compliant for two reasons.
- Duration. Under GPLv2 section 3(b), when you distribute object code you may use a written offer, but it must be valid for at least three years. GPLv3 section 6(b) has the same three-year minimum, and it must remain valid for as long as you offer spare parts or support for that model. A two-year offer expires too early, so a recipient in year three would have no way to obtain source.
- Scope and form. The offer must be a written offer to give the source to any third party who possesses the object code, not a vague 'available on request'. It should identify what is covered and how to request it.
Correction: change the notice to a three-year written offer, list the covered components and the exact source version or tag, and publish the source at a stable URL as the simplest route. Retain proof that the offer was made. Also check that the offer covers the GRUB patch and BusyBox, not only the kernel.
3. The signed boot chain rejects any modified GRUB. What does this imply under GPLv3, and what are two workable options?
Read the worked answer
GPLv3's Installation Information requirement is the issue. GRUB is GPLv3, and it is conveyed in a User Product, the appliance, where the customer receives permanent possession. If the signed boot chain refuses to execute a GRUB built from the provided source, the recipient cannot install and execute a modified version. That is exactly what the Installation Information provision is meant to prevent, and a locked chain can be read as an additional restriction on the GPLv3 work.
Two workable options:
- Provide installation information. Document how the owner can enter UEFI setup, disable Secure Boot or enroll their own key, and boot a self-built GRUB. If you must keep Secure Boot, you could offer a signing service for customer-built GRUB, but that is operationally heavy.
- Avoid the GPLv3 bootloader. Use a GPLv2-licensed bootloader for which the anti-tivoization clause does not apply, and keep the signed chain. GPLv2 still requires source for that bootloader, and the kernel's GPLv2 obligations are unchanged.
Do not simply state that the source is available while the hardware rejects it; that is the trap the question is testing.