OPEN SOURCE LICENSE RISK
Open source license risk in containers and images.
Open source license risk in containers and images is the exposure most teams never record, because the terms travel inside a layer rather than a line of code you wrote. This article shows where relicensed components hide, why a rebuild can change your obligations, and how to map and contain the risk.
A container image is convenient precisely because it hides complexity. You pull a base, add your application, and ship one artifact that runs the same everywhere. The cost of that convenience is visibility. Open source license risk in containers and images accrues inside layers you did not author and rarely inspect, and the license state of every one of those layers travels with the image to wherever it runs. The component you never chose can still be your obligation.
Most license tracking stops at the source repository. Teams scan the code they write and the direct dependencies they declare, then assume the picture is complete. It is not. The operating system layer, the language runtime, the system packages, and the tools baked into the base all carry their own licenses, and those licenses are part of what you distribute when the image moves. The gap between what you scanned and what you shipped is where the risk lives.
Why container layers carry hidden exposure
An image is built in layers, and each layer can introduce components from a different source under different terms. A base image might pull in hundreds of system packages. A language base might add a runtime and its standard library. Your build step then layers framework dependencies on top, many of which carry their own transitive trees. The final artifact is a stack of licenses, most of them inherited rather than chosen.
The practical problem is that these inherited components are invisible to a developer reading a manifest file. They do not appear in your dependency declaration. They are present only because the base image author put them there. When you treat the base as a black box, you accept its license posture without recording it, and that posture can include a source available component that does not belong in a product you intend to keep proprietary.
How a relicense reaches you through an image
Relicensing is the event that turns a quiet base layer into live exposure. A project you depend on changes its terms, a maintainer rebuilds the base image to include the new version, and you inherit the change the next time you pull or rebuild. Nothing in your own repository changed. The trigger was upstream, and it arrived through an image tag you trusted.
The license families that drive this concern are the source available ones. As of August 2023 HashiCorp moved Terraform, Vault, Consul, Nomad and Packer to the Business Source License 1.1, with the community fork OpenTofu. As of March 2024 Redis moved to a model that includes the Server Side Public License, with the fork Valkey. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021, with the fork OpenSearch. MongoDB moved to the Server Side Public License in 2018. Source available is not open source, and neither the Business Source License nor the Server Side Public License is approved by the Open Source Initiative. If any of these tools sits inside a base image or an init container in your estate, the relicensing terms can apply to software you are already running. For the distinction in full, read why source available is not open source.
Does building or shipping an image count as distribution?
Distribution is the trigger for many copyleft obligations, and containers blur where it happens. Pushing an image to a public registry, handing it to a customer, or embedding it in a product that ships can amount to distribution. Running an image purely behind your own boundary usually presents a different profile. The answer turns on facts and on the specific license text, which is why this is a question for your own counsel rather than a rule you can apply from a blog. What you can do without counsel is record exactly which components are present and how each image moves, so the question is answerable when it is asked.
How to map open source license risk in container images
The method is the same one that governs the rest of your estate, applied at the layer and package level. Generate a software bill of materials for every image, not just for the source repository. A good bill of materials reaches the operating system packages, the runtime, and the transitive dependencies, and records the license of each component rather than only its name. Refresh it on every build, because the whole point is to catch a change the moment it arrives.
Give source available its own category
A bill of materials that lumps every visible source license into one bucket will not save you. The single most useful refinement is to flag source available licenses, the Business Source License and the Server Side Public License in particular, as a distinct category that triggers review. That way a relicensed component surfaces at the registry gate, before it propagates across hundreds of images, rather than in an audit after it already has.
Pin and control your base images
Floating tags are how surprises arrive. Pinning base images to a known digest means a rebuild gives you the same content you reviewed, and a deliberate update becomes a decision rather than an accident. Pair pinning with a small set of approved base images that you actually scan, so the surface area you inherit is bounded and known.
Containing the exposure once you find it
When the map turns up a relicensed component in an image, the response is the same disciplined sequence used anywhere else. Confirm how the image moves and whether the use is competitive or service oriented in the sense the license restricts. Size the blast radius across every image and environment that inherits the component. Then choose a path: migrate to a community fork such as OpenTofu, Valkey, or OpenSearch where one fits, remove the dependency, or negotiate a commercial license if continued use is the right call. The choice should hold under scrutiny rather than simply relocate the exposure.
Containers do not create new license rules. They make the existing rules harder to see, which is exactly why they deserve their own place in your method. Treat each image as a distributed artifact with a full license inventory, and the surprise upstream change becomes a flagged finding you handle on your own schedule. The open source license risk guide sets out the complete approach, and these companion articles go deeper: permissive vs copyleft vs source available explained and open source license risk for the board.
COMMON QUESTIONS
Questions buyers ask.
Why is open source license risk in containers and images hard to see?
A container image bundles an operating system layer, language runtimes, and packaged dependencies into a single artifact. The license state of every layer travels with the image, but most teams only track the code in their own repository. The result is a gap between what you think you ship and what the image actually contains.
Can a relicensed component reach my estate through a base image?
Yes. A base image you pulled months ago can include a component that has since moved to a source available license such as the Business Source License or the Server Side Public License. When you rebuild or pull a newer tag, the new terms can arrive without any change to your own code.
Does building a container count as distribution?
It depends on how the image moves. Pushing an image to a public registry, shipping it to a customer, or embedding it in a product can constitute distribution, which is the trigger for many copyleft obligations. Internal use behind your own boundary usually carries a different profile. This is a question for your own counsel.
How do I map license risk in container images?
Generate a software bill of materials for each image that reaches the layer and package level, record the license of every component including transitive ones, and refresh it on every build. Flag source available licenses as their own category so a relicense is caught at the registry rather than in an audit.
Is this article legal advice?
No. It is commercial and licensing risk analysis, not legal advice. For interpretation of license terms and distribution questions, engage your own counsel.
CONTAINMENT
See every license inside every image you ship.
A confidential open source license risk assessment. Independent, buyer side, paid only by you.
Not ready to talk? Read the free open source license risk guides first.