Notes / Software & IP
GPLv3 firmware in consumer devices: release checks and distributor warranties
Connect source delivery, installation rights and updates to the promises a device supplier makes to its distributor.
Your team is preparing a firmware update for a smart home hub. The firmware includes GPLv3-covered software and an Apache 2.0 library. Engineering asks whether the licences are compatible. A distributor asks you to cover every customer claim, including claims involving modified firmware.
Apache 2.0 code can be included in a GPLv3 project. The supplier still needs to check what recipients must receive and how the distribution contract allocates responsibility. A compatible library does not answer either question.
This hypothetical example connects the technical release to the promises a device supplier makes to its distributor.
Start with the software you will actually ship
The Apache Software Foundation confirms that Apache 2.0 code can be included in GPLv3 projects. Compatibility does not work in reverse: a combined work containing GPLv3 code cannot generally be distributed solely under Apache 2.0. Check the version carefully. Apache 2.0 is incompatible with GPLv2-only; GPLv2-or-later code allows a choice of a later GPL version. Apache Software Foundation: GPL compatibility.
Separate, independent programs distributed together may qualify as an aggregate under GPLv3 section 5. Being on the same device does not itself make them one combined program. Apache obligations also remain relevant: include the licence, identify modified files and preserve applicable notices, including relevant NOTICE attribution. GPLv3, section 5; Apache License 2.0, section 4.
I would ask Engineering for the release version, component list, applicable licences and an explanation of how the components interact. The review needs to reach the code in the shipped image.
Check the source package and its delivery
When you convey covered object code, GPLv3 requires Corresponding Source through a permitted delivery route. This includes the source and scripts needed to build, install, run and modify the covered work, subject to the licence's exclusions. A link to the latest development branch may miss the version supplied. GPLv3, sections 1 and 6.
If you use a written source offer under section 6(b), it must remain valid for at least three years and for as long as you offer spare parts or customer support for that model. Simply passing on another party's offer under section 6(c) is permitted only occasionally and non-commercially, where you received the code with that offer. For downloads under section 6(d), another party may host the source, but you must provide clear directions and ensure it remains available as required. GPLv3, section 6.
Ask an engineer to build the relevant firmware from the proposed source package. Resolve missing scripts, dependencies and instructions before offering it to recipients. Identify who maintains access and answers requests after sale.
A distributor's own obligations depend on its actions, territory and legal basis for copying or distribution. Reselling devices already placed on the relevant market with the copyright owners' consent normally needs no further permission where distribution rights are exhausted. Importing devices, installing or updating firmware, or offering it for download needs a separate assessment. EU Software Directive, articles 4 and 5; UK IPO: exhaustion and parallel trade.
The agreement should assign notices and source delivery, including responses to requests. If the distributor updates devices before sale, specify whose update process it uses and who provides the source for that version.
Test the installation route on the device
When covered object code is conveyed in, with or specifically for a User Product as part of a transaction transferring the right to possess and use it permanently or for a fixed term, section 6 requires Installation Information alongside the source, subject to the exception below. User Products include consumer goods and items designed or sold for incorporation into a dwelling. A business buyer does not automatically exclude this classification. GPLv3, section 6.
Ask Engineering to demonstrate how the recipient can install and run a modified version on the shipped hardware, including unlocking and signing steps. Publishing source code does not establish that this works.
The exception applies if neither the supplier nor any third party can install modified object code, for example in ROM. A manufacturer's ability to install modified covered code through over-the-air updates rules out that exception. The required information must also prevent interference with the modified software's continued functioning solely because it was modified. This is not a guarantee that every modification will work. GPLv3, section 6.
Key architecture matters. If a signing key is necessary for installation and execution and no effective alternative exists, the required information includes that key. The Free Software Foundation explains that the required key must be provided to the device owner on request; it need not be published. Where devices have individual keys, only that device's key needs to be provided. A shared key for the whole product range is not automatically required. FSF: signing keys.
Decide what the supplier will support
Section 6 does not itself require continued support, warranty or updates for recipient-modified software or the affected product. The FSF also explains that a warranty can be limited to unmodified software. Network access may be denied where the modification materially harms network operation or breaches rules and protocols for communication across it. This concerns network communication, rather than any rule a service operator chooses to impose. GPLv3, section 6; FSF: conditional warranties; FSF: network rules.
Cloud functions need attention too. The FSF distinguishes troubleshooting support from web services needed for a device to function, which it considers should generally remain available to modified versions, subject to the network exception. Where remote attestation checks the software running on the device, the FSF says Installation Information must provide a way for modified software to report itself as legitimate. Ask Engineering whether either feature affects the proposed installation route. FSF: support services; FSF: remote attestation.
Then check the supplier's own promises. An unconditional distributor warranty can create responsibilities the team has not priced or planned to support. Compare a manufacturing defect unrelated to customer changes with a failure caused by modified firmware disabling a protection mechanism.
For the supplier-distributor contract, I would consider exclusions limited to defects or losses caused by modifications not supplied or approved by the manufacturer, misuse or unlawful operation. Installing different firmware should not become an automatic answer to every claim.
Mandatory consumer rights also matter. In the UK, section 31 prevents exclusion or restriction of specified consumer liabilities, including the section 16 requirement concerning digital content included in goods. Consumer Rights Act 2015, sections 16 and 31.
For EU goods with digital elements, sellers must ensure consumers are informed of and supplied with necessary updates, including security updates. For a single supply, the period depends on reasonable consumer expectations. For continuous supply, the directive ties it to the applicable seller-liability period. A seller may have recourse against a responsible earlier participant in the chain under national law. The distribution agreement should allocate updates, duration, notifications and related costs. Directive 2019/771, articles 7(3), 10 and 18.
Make the distributor agreement workable
I would use the technical findings to review five parts of the contract:
| Distributor request | What I would clarify before agreeing |
|---|---|
| A warranty covering every device, however modified | Covered defects, supported versions, duration, remedies and causal exclusions. |
| Reimbursement of every customer claim | Attributable costs, investigation, customer handling and control of the defence. Urgent consumer remedies and safety measures need their own process. |
| Exclusive ownership of all firmware and future developments | Rights the supplier can grant, third-party licences and separately commissioned work. Recipients retain GPL rights, which section 10 protects against further restrictions. |
| Uncapped liability for any open-source breach | Actual failure scenarios, available remedies, proportionate risk allocation and liabilities that applicable law does not permit the parties to limit. |
| Updates throughout the product's life | Which updates the supplier provides, for how long, how the distributor and consumers are informed, and who bears related costs. |
Transferring copyright in the supplier's own work does not remove recipients' existing GPL rights. An agreed liability cap also does not cure a licence breach or settle a third-party claim. GPLv3, sections 2 and 10.
Check changes to radio behaviour separately
If an update changes radio behaviour, ask Engineering what changed and whether existing compliance evidence covers it. Relevant questions include frequencies, power, operating regions and user controls.
A testing gap goes to the appropriate laboratory; an unclear country-specific requirement goes to specialist counsel. Where feasible, assess a release with the unresolved feature deferred, provided the remaining release has itself been checked.
What I would want before approving release
I would ask for a short record of the release version and components, licence conditions, source delivery, any required installation method and its test results. Record unresolved product-compliance questions and check that the distributor agreement reflects the support and remedies the business can provide.
Engineering and Sales should know what is ready to ship, what remains unresolved and who owns the next step.
For the wider contract review, see open-source software warranties and customer contracts. I help technology businesses review software rights and the promises in their customer contracts through a code rights review.
The outcome depends on the software, product, complete licence terms, contract and applicable law.