ALA OEM and embedded use restrictions

Software that a buyer licensed for its own internal operations sometimes ends up inside a product the buyer ships to others, or embedded as a component of a larger application, and those uses are governed by terms quite different from ordinary internal deployment. An audit that treats every running instance the same way, without separating internal use from redistribution or embedding, can assert an obligation that the grant never created or, conversely, can claim that ordinary internal use breached a restriction that does not apply. ALA OEM and embedded use restrictions is the question of how an Additional License Authorization treats redistribution to third parties and embedding inside another product, and how the defensible reading holds any finding to the use the grant actually licensed and restricted.

This field note explains what OEM and embedded terms typically do in an ALA, where a finding misreads them, and how the grant decides the count. It pairs with our ALA and entitlement review track.

What OEM and embedded terms mean in an ALA

An OEM right permits a buyer to redistribute the software, or functionality built on it, to that buyer's own customers, while an embedded right permits the software to run as a component inside another application rather than as a standalone tool. These are distinct grants with their own conditions, and most ordinary licenses do not include them; a standard internal use Additional License Authorization typically restricts the software to the buyer's own business and does not permit redistribution or embedding without a separate authorization. The decisive question in any finding is which grant actually applies to the deployment in front of the auditor, and a reading that assumes the wrong grant produces the wrong number. Establishing what the grant permits begins with the close reading set out in ALA territory and use restrictions.

Where a finding overreaches on redistribution

The common overreach treats internal use as if it were redistribution. A buyer that runs the software entirely within its own operations, even when that software supports a service the buyer sells, is not necessarily redistributing the software itself, and a finding that counts internal supporting infrastructure as an OEM deployment can demand redistribution licensing the buyer never needed. The reverse overreach also appears: where a buyer does redistribute under an OEM grant, a finding may try to count internal copies that the OEM terms already cover, double counting the same use. Both errors come from failing to separate the use categories, and the correction is to classify each deployment by what it actually does. This is the same classification discipline applied to functional use in ALA development versus production rights.

Embedding and the deployment count

When the software runs embedded inside another application, how it is counted depends entirely on the embedded grant's metric, which may differ from the standalone metric for the same product. A finding that applies the standalone metric to an embedded deployment, or counts each embedding instance as a full standalone license, can overstate substantially. Where the grant counts deployments or capacity, the count must follow the grant that actually governs the embedded use, not the metric that would apply if the software ran on its own. The way grant language fixes the unit of counting is examined in ALA grant language and the deployment count, and embedded deployments turn on exactly that language.

How bundles hide the OEM and embedded question

OEM and embedded rights are frequently acquired inside bundles, where a redistribution or embedding right for one component sits alongside ordinary internal rights for others, and the bundle paperwork does not always make the distinction obvious. A finding that reads the bundle as uniform internal use can miss an embedded right the buyer holds, or assert a redistribution obligation the bundle never created. Untangling which components carry which rights is the bundle problem examined in how ALA bundles obscure true entitlement, and it frequently decides whether an OEM or embedded reading even applies.

How the OEM and embedded reading reduces the number

In a recent engagement, a finding counted a buyer's internal supporting deployments as if they were an OEM redistribution, demanding redistribution licensing across infrastructure that never left the buyer's own operations, and applied the standalone metric to a component that ran embedded inside another application. Reclassifying the internal infrastructure as ordinary internal use, and counting the embedded component under the grant that actually governed it rather than the standalone metric, removed a large share of the asserted figure. This is the ordinary mechanism: every deployment correctly placed in its true use category, internal, OEM, or embedded, settles the count for that deployment against the grant that governs it. Applied across a mixed estate, this reading is part of how we deliver the 68 percent average reduction we have achieved across more than 200 defended audits.

Evidence that fixes the use category

Defending an OEM or embedded reading rests on evidence about how each deployment is actually used: deployment topology, the products the software is embedded within, distribution records where redistribution occurs, and the authorizations that grant the OEM or embedded right. This record establishes the true use category for each instance, which is what the grant charges for, against a scan that counted instances without distinguishing how they were deployed. Assembling that evidence is the same discipline applied throughout entitlement defense, and for OEM and embedded use it is what answers a finding that flattened distinct grants into one.

Fixing the OEM and embedded question forward

After the present finding is corrected, the forward agreement should state plainly which components carry OEM or embedded rights, how those rights are counted, and how they differ from ordinary internal use, so a future review cannot reopen the count by misreading the use category. A clean forward arrangement records the redistribution and embedding rights the buyer actually holds and the metrics that govern them, removing the ambiguity that let the audit overreach. If a finding has counted your internal use as redistribution, or applied a standalone metric to embedded software, open a case and we will hold the count to the use the grant actually licensed.

For the full method, read the complete OpenText audit defense playbook, and for entitlement defense across the Micro Focus estate see our ALA and entitlement review track.