Remediation for embedded and shipped software.

Remediation for embedded and shipped software is a different problem from remediation for internal systems, and the difference is distribution. An internal service can be patched in place and the old version forgotten within a sprint. A product you ship is in the world: installed on customer infrastructure, burned into firmware, running on devices you will never touch again. When a relicensed component is inside that product, you cannot recall the copies already out there, and the terms attach to how you continue to ship, support, and update from this point on. The exposure has a long tail.

That changes both the urgency and the method. The component is no longer just yours to manage; it is something your customers depend on, which means a clean cut is rarely available. The broader set of remediation paths and how to weigh them sits in the pillar on open source remediation and alternatives.

Why remediation for embedded and shipped software raises the stakes

A relicense inside a distributed product creates exposure that internal use does not. Distribution conditions in a source available license can govern how you may continue to ship the software and on what terms. A copyleft style license such as the GNU AGPL can reach further, attaching obligations to provide corresponding source and potentially extending to code that links to the covered component. For an embedded product, where the licensed component is fused into a larger system, working out where those obligations begin and end is a serious question, and it is one for your own counsel rather than your engineering team.

There is also a support dimension that internal systems do not carry. Customers expect security updates for years. If the only patched versions of a component are released under restrictive terms, you face a choice between shipping updates you may not have the right to distribute and leaving fielded products unpatched. Neither is acceptable for long, which is why this exposure cannot be parked.

Start with a bill of materials for what you ship

You cannot remediate distributed software you cannot see. The first step is an accurate bill of materials for the product as shipped, down to the transitive layer, with the license state recorded on every component. This is harder than it sounds for embedded products, where components arrive through vendor toolchains, board support packages, and prebuilt images that were never inventoried at the time. Each of those is a place a relicensed component can hide, and each needs to be opened up rather than assumed clean.

The inventory should cover not only the current release but the versions still under support in the field, because the obligations that matter are the ones attached to what customers are actually running. Building that picture is itself an exercise in mapping, and the discipline of keeping it current is the same one set out in building an open source remediation roadmap.

Choose a path that accounts for the installed base

The remediation options for shipped software are the familiar ones, but each carries a distribution twist. Migrating to a fork such as OpenTofu, Valkey, or OpenSearch keeps the capability under an open license and is often the cleanest answer, provided the fork is compatible enough to ship. Replacing the component removes the exposure but means a product change that has to roll out to the installed base through your normal update channel. A commercial license can cover continued distribution, but the pricing for a product that embeds and redistributes a component is a different conversation from internal use, and it has to reflect units shipped rather than seats.

The decisive factor is usually the installed base. A change that is trivial for new builds can be slow and expensive to push to devices already deployed, and for some hardware it may not be possible at all. That reality has to sit at the front of the decision, alongside the cost comparison covered across the remediation cluster, including the realities of mixed and distributed estates in remediation for multicloud and hybrid estates.

Plan for the long tail of fielded units

Even after the next release is clean, the units already in the field remain part of the picture for as long as you support them. A practical plan separates the two timelines. The forward fix changes what you ship from now on and is the priority, because it stops the exposure growing with every new sale. The installed base is then handled on a defined schedule: which units can be updated remotely, which require a service visit, and which will simply age out of support before any change reaches them. Putting numbers and dates against each category turns an open ended worry into a managed program.

Throughout, the distribution and copyleft questions belong with your counsel. The advisory job is to map the exposure, size each path, and sequence the work; the legal interpretation of what a specific license requires when you ship is theirs to give.

Where this leaves product teams

Remediation for embedded and shipped software rewards teams that see the problem early and plan for the tail. The components that cause the most trouble are the ones nobody inventoried because they arrived inside a toolchain or an image, and the products that recover fastest are the ones that already knew what they shipped. An accurate bill of materials, a clear view of obligations from counsel, a chosen path that accounts for the installed base, and a schedule that separates the forward fix from the fielded units: those four together make a distributed relicense a managed event rather than a recurring liability.

The shipped product is the hardest place for a relicense to land, precisely because you cannot take it back. That is also the reason to act before the next release rather than after the next audit. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license and your distribution obligations, your own counsel is the right place to turn.