What "entity" means on a licence
Marketplace licences are usually granted to a single legal entity - the company or person that bought them - and they cover that entity's products. Unity's Asset Store makes this explicit with two tiers. A Single Entity licence lets one legal entity use the asset in its own products. A Multi Entity licence is the one you buy when the people using the asset and the entity that owns the shipping product are different - which is exactly the shape of contract work.
| Situation | Single Entity | Multi Entity |
|---|---|---|
| Your own studio's game | OK | OK |
| Asset delivered into a client's product | Not covered | OK |
| Shared across contractors / sub-studios | Not covered | OK |
The failure mode is quiet: an artist buys a Single Entity asset to solve a problem on a client build, it works, it ships, and nobody ever asked which entity's product it was going into. Legally, the client's game is a different entity's product, so the Single Entity grant does not reach it. The fix - buying Multi Entity, or having the client buy their own copy - is cheap while the project is live and expensive once the deliverable is signed off.
Per-seat tools: the second trap
The other half of the trap is the Extension Asset pattern: editor tooling - custom inspectors, importers, workflow extensions, spline tools - is frequently licensed per seat, per individual user. One purchased seat covers one developer. A team of five sharing two seats is not "mostly compliant"; it is three seats short, and a per-seat shortfall is precisely the kind of thing a diligence questionnaire asks you to attest to. Because the editor never enforces it, the gap grows silently as the team scales.
The personal-account variant
A close relative of the entity trap is the personal-account purchase. When an asset is bought on an individual artist's or contractor's own marketplace account, the licence is granted to that person, not to the studio - and certainly not to the client. It cannot cleanly transfer into a client deliverable, and if that artist leaves, the entitlement (and its proof of purchase) can walk out with them. Two disciplines fix it: buy on a studio-controlled account for anything that will ship, and record which account holds each entitlement so the gap is visible before, not during, a deal.
Why contractors get hit hardest
An indie shipping its own game only ever deals with one entity, so Single Entity licences and personal accounts mostly "just work" for them. A work-for-hire studio inverts that: every deliverable goes into someone else's entity, so every Single Entity asset and every personally-purchased pack is a latent problem. The studios that stay out of trouble treat "which entity, which account, how many seats" as three fields you fill in the day an asset enters a client project - not questions you answer under a deadline when the client's counsel sends the IP schedule.
How the register catches it
Asset Licence Register is built around exactly these three flags. Mark a project as client work and tag an asset Single Entity, and it raises an entity-licence-on-client-work warning. Record seats purchased below the team size on a per-seat tool, and it raises a per-seat shortfall. Note that an asset was bought on a personal account for client work, and it raises a personal-account flag. All three appear as you type and roll into the exportable manifest - so the answer to the client's IP schedule already exists.