Expected reading time: 10 minutes
Two Outdated Container Assumptions
“Containers only run open-source and in-house applications, not commercial software.” Many IT teams still hold this belief, which, in turn, quietly shapes how they approach container licensing. The belief is not baseless. Containerization earned its reputation as a developer’s tool because that is how it spread. Initially, open-source communities, individual developers, and engineering teams adopted it outside formal IT governance. In fact, for years, teams used containers mainly to develop and experiment, not to run commercially licensed software in production.
In addition, a second assumption usually follows the first: “If commercial software does run in containers, it needs only a fraction of the licenses, since a container uses just a slice of a server.”
Both assumptions describe where containers started, not where they are today. As a result, they can leave organizations with compliance gaps and unbudgeted costs.
The Reality – Commercial Software in Production Containers
Commercial Software Is Already Present in Containers
Two developments moved containers into production. First, CI/CD pipelines turned image building into an automated, repeatable part of software delivery. Then orchestration platforms such as Kubernetes made it practical to run containers reliably at scale, with handling scheduling, scaling, and recovery. Add the benefits of portability, resource efficiency, environment consistency, and faster delivery, and the case for adoption is clear. According to the CNCF Annual Cloud Native Survey 2025, 82% of organizations using containers now run Kubernetes in production, up from 66% in 2023. Deployment of databases in containers are the most common containerized category , followed by web and application servers.
The technology landscape is equally established. Kubernetes has become the de facto standard for orchestration. Docker remains the common tool for packaging applications, while Podman offers a daemon less alternative. For example, widely used Kubernetes platforms include Red Hat OpenShift and the native container management solution from the major cloud providers, such as Amazon EKS, Azure AKS, and Google GKE.
Over time, commercial vendors have followed. IBM EDB Postgres Enterprise, Confluent Platform, DataStax HCD, Red Hat Ansible Automation Platform, Elasticsearch, and MongoDB are among the commercially licensed products that organizations actively deploy in containers. Leadout has observed this directly across client engagements in multiple industries. Therefore, commercial software in containers is now a routine part of enterprise infrastructure.
Container Licensing: A Different Set of Rules
The second assumption as mentioned in the introduction does not hold either. Container licensing depends on how each publisher defines and counts a deployment, not on how small a container looks. Depending on the model, a containerized workload can need a fraction of its previous licenses or a multiple of them. That raises two uncomfortable questions. Are organizations equipped to manage the compliance risk that comes with container licensing? And are software publishers themselves equipped to address it?
Why This Persists – Discovery and Publisher Blind Spots
The myth survives partly because the evidence is hard to see. Leadout has observed the same compliance challenge at every maturity level, including clients with well-established IT and Software Asset Management (SAM) functions. For example, some leave containers outside the scope of SAM because the process is unclear. Meanwhile, others combine manual audits, custom scripts, and partial tool integrations, which rarely add up to a complete or sustainable process. No widely adopted playbook exists, so every organization we have observed is improvising to some degree.
Where Traditional SAM Discovery Falls Short
The first root cause is discovery. To begin with, traditional SAM discovery assumes stable assets, such as physical servers and virtual machines, that persist long enough for periodic scans and reconciliation. Containers, by contrast, can be created, scaled, moved, and removed between scans without leaving a record. In our engagements, the SAM tools we tested could detect containers on a host. Without additional integrations, however, they could not reliably identify what ran inside them. For instance, some even relied on scanners built for vulnerabilities rather than licensing. Meanwhile, newer tools look more promising, and we are still evaluating them. Nevertheless, so far, we have yet to see a tool that can serve as a reliable source of truth for container licensing.
This is not mainly a feature gap. Rather, containers break the assumptions that traditional SAM relies on:
- Ephemerality and rapid scaling: containers may live for seconds or minutes, and orchestrators create and remove instances automatically in response to load. As a result, the license-relevant footprint can change within a day, meaning that today’s snapshot may look nothing like tomorrow’s.
- Image versus runtime: an image defines what teams can deploy. However, under most licensing models, only running containers consume entitlements. Consequently, conflating the two produces inaccurate license positions.
- Shared hosts and nested dependencies: many containers share one host, and a single image can bundle commercial components that never appear in a traditional inventory.
Publisher Licensing Rules and Maturity Gaps
The second root cause sits with the publishers. Some products have no clearly documented methodology for containers at all. In contrast, others document a model but attach conditions. IBM, for example, publishes a container licensing guide, but the model only applies under Kubernetes orchestration and requires IBM License Service to track usage. Outside those conditions, IBM offers no clear methodology. Therefore, publishers are not always equipped for containerized compliance either.
Better scanning alone cannot fix this. Therefore, organisations must first decide what to measure, over what period, and under which publisher’s licensing rules.
The Hidden Cost of Architecture Decisions
The financial exposure in container licensing rarely sits in the arithmetic. Instead, it sits in decisions that teams make without licensing in mind.
Take EDB as a first example. Its licensing guide ties the subscriptions required for containers to the CPU “limits” value in a Postgres pod’s configuration, multiplied by the number of running instances. A deployment set to 2 CPUs per pod, running 4 instances, therefore needs 8 subscriptions. The formula is simple. However, the risk is that instances scale automatically, or at the discretion of engineering teams who cannot see the licensing consequences.
Another example is sharper. Some per-OSE (Operating System Environment) licensing models carry a minimum core or vCPU requirement per container, however small the container is. Split a 4-vCPU workload into twenty containers capped at 0.1 vCPU each, and if each triggers a 4-vCPU minimum, a 4-license workload becomes an 80-license bill. SAM practitioners know this problem from virtualization: an architectural choice made for performance quietly multiplies cost by a factor nobody modelled.
Whether such minimums apply is genuinely contested. Some publishers treat each container as its own segregated licensing unit. A counterargument is that a container holds application dependencies, not a full operating system. Ultimately, the contractual definition decides, and definitions differ between publishers. This ambiguity rarely works in the customer’s favour, because the publisher holds the audit rights. Consequently, any interpretation an organization adopts alone carries a real risk of later dispute.
What Mature Organizations Do Differently
Mature organizations stop treating the SAM tool as the sole source of truth. Instead, they rebuild the container licensing question around data that often already exists in the build and deployment pipeline:
- The Software Bill of Materials (SBOM) describes what an image contains, and can expose commercial components that discovery tools miss. It records composition, not consumption: it does not show how many instances run or for how long.
- In addition, orchestration metadata, such as labels and annotations in Kubernetes, records what is actually running, provided teams enforce tagging standards and ownership.
- Deployment configuration files, such as manifests and Helm charts, show what teams intended to deploy. An opportunity for SAM to reconcile them against runtime data.
Today, security teams generate most SBOMs for supply-chain and vulnerability management, and we have not yet seen a working handoff to SAM. However, waiting for one is not a reliable strategy. In practice, the better model runs both ways: security’s runtime visibility feeds SAM’s entitlement interpretation, and SAM’s licensing knowledge informs security’s prioritization. After all, security tooling answers “is this dangerous?”, while only SAM can answer, “is this entitled?”.
Choosing the Right Governance Approach
Mature organisations also choose their governance posture deliberately. For example, where commercial software in containers is still new, they set up a proactive vetting gate. In contrast, where containers are already widespread, a gate is not realistic, so corrective visibility is the practical starting point. Neither posture is wrong. They are simply different starting points.
Container Licensing in Practice: Lessons from Client Cases
We have observed containers running EDB Postgres that were invisible to every discovery tool. A script that the platform team had written for operational reasons, watching for Kubernetes pod spin-up events, finally caught them. As a result, the client rightsized the pods at deployment and mitigated a contractual risk of a multitude of their annual contractual value. The lesson was not to write more scripts, but to design discovery into the build and deploy pipeline. Likewise, visibility at a different customer led to a move to an open-source version of commercially licensed software.
Practical governance actions for container licensing
- Establish which container technologies are in use. Governance can only cover what is known. Start by identifying the platforms in your estate, such as Kubernetes distributions, OpenShift, managed cloud services, or standalone Docker and Podman hosts. Furthermore, there may be several at once, across teams, clouds, and on-premises. Ask platform and engineering teams, product owners, and cloud account owners, and check the container registries.
- Clarify the licensing rules before deployment. Review each contract for its definitions (e.g. OSE, instance…), core-counting method, and any per-container minimum. Where the container methodology is undocumented, get the publisher’s position in writing. If they cannot provide it, treat that as elevated risk.
- Introduce a vetting gate with two linked checks: a contract review to confirm the licensing methodology, and a review of the planned deployment (CPU limits, instance counts, container splits) against it. One without the other leaves a gap.
- Give SAM a seat in engineering decisions. Splitting a workload or scaling instances is a performance decision today; however, it should also be a visible licensing one.
- Cap and monitor where needed. Kubernetes resource limits have been used to keep deployments within a predictable footprint. This is a general resource control repurposed for licensing. Therefore, it must be set up deliberately and paired with instance-count monitoring.
- Build the inventory from the pipeline. Combine SBOMs, orchestration metadata, and deployment configuration, and enforce consistent labelling so the data is usable.
The Leadout perspective
The challenges of container licensing are widely documented. However, what is scarce is experience in overcoming them. There is unlikely to be a single tool that resolves the issue. Instead, a workable approach combines technical visibility, publisher-specific licensing knowledge, and a method for measuring deployments over time. Consequently, our work with clients focuses on three things: defining what a license-relevant deployment looks like in a containerized environment, identifying the data needed to measure it, and turning that data into a repeatable compliance process.
Because vendor terms, maturity levels, and engineering cultures differ, a tailored solution is required. For example, at one client the answer was a correction-focused control; at another, prevention at the point of entry. Ultimately, as with container licensing itself, the right approach depends on the specific context. If you are running commercial software in containers, or expect to, we would be glad to help you find yours.
Key takeaways
- Containers are no longer just a developer’s playground: commercial software runs in them in production today.
- Traditional SAM discovery and metrics were built for stable assets, and no tool we have seen or worked with fully closes the container gap.
- In particular, licensing cost is driven by architecture and scaling decisions, such as capacity limits, instance counts, and container splits, that are usually made without licensing input. Depending on the publisher’s model, containers can cost a fraction of the previous requirement or a multiple of it.
- Vendor contracts decide the answer. Review them contract by contract, and get the vendor’s position in writing where it is unclear.
- The most effective organizations combine SBOMs, orchestration data, and deployment configuration, work alongside security teams, and give SAM a formal role in deployment decisions.
Curious how this applies to your organization? Let’s talk. Schedule a call with us.
Share this message: