RFC: Rebuild media function licensing on the IAMT Dynamic Software Licensing model

[znerol2]

The problem

The dmfdeploy platform deploys media functions on demand. Some of those functions will come from outside publishers and will need a commercial licence to run. The platform has no licensing model yet. ADR-0045 parks the topic behind a reservation seam with four calls (check, reserve, release, usage) and a descriptor block of {class, count} pairs. It's still Proposed.

In September 2026 the International Association of MediaTech (IAMT) published Dynamic Software Licensing Best Practices v1.0.0 (DSL). It's an industry model for this exact problem: short-lived, automated media workloads that move between sites and clouds. DSL separates the durable commercial entitlement from the time-bounded, signed lease that binds part of it to one running workload (§07.01). Today's ADR-0045 doesn't fit that model. It reserves seats before deploy, binds them to an inventory id, and counts with one number where DSL uses dimensions such as channels and frame rate. The function descriptor is being designed now, so this is the cheapest moment to change the shape, before any publisher builds against it.

Section numbers below (§, Annex, and requirement ids such as INT-2) refer to the DSL document.

Proposed decision

The draft ADR decides only what the DSL text settles. Everything else is an open question below, and the platform builds no licensing adapter until those questions have answers.

1. The platform is an orchestration client. The vendor or the customer runs the DSL control plane, and that control plane is the ledger for entitlements, leases, policy and usage (§07.02, §07.07). The platform triggers lease acquisition when it provisions a function, which §10.02 allows, and takes part in teardown (INT-2). It doesn't host a control plane. Observing leases alone isn't enough, because DSL agents don't revoke their own leases (§10.05), and someone has to return the licence at teardown.
2. The function's licence agent calls Issue, with the workload's own identity. The agent ships inside the function's package (§07.04, §07.07, §10.02). The lease binds to the workload's identity (IDB-1, IDB-2) and renewal re-checks it (IDB-3). The launcher never holds or presents identity evidence. It gives the agent an opaque workId and the descriptor's entitlement fields. This depends on the platform's workload identity work: the control plane has to trust the cluster's token issuer, with no standing vendor access into the cluster (IDB-6).
3. workId correlates; it never binds. The platform supplies it for idempotency and audit (§07.01, §10.01, INT-4). The platform keeps its own record of the human who asked for each action, linked through workId, because DSL audits lease events only.
4. Plan holds nothing. DSL checks quota only at Issue (§10.02) and has no hold call (Annex B), so a platform-side hold couldn't stop another consumer taking the slot.
5. Closing a lease is Revoke. DSL's one closing call is DELETE /v1/leases/{leaseId} with a required reason, and the lease becomes REVOKED (§10.05). Teardown sends reason decommissioned. A failed launch revokes any lease it got. A lease already REVOKED, EXPIRED or TERMINATED counts as closed. A REISSUING lease, or a refused close, is a failure the operator sees.
6. The descriptor gets an optional licence: block with app (the publisher's DSL application id), modality, an optional term sent as licenseModality (such as hourly), and dimensions, each a publisher-documented name and a quantity (MTR-1). modality is the project's own classification, built on the §04.03 modality concepts. It's distinct from the licenseModality values in §10.02. The required SPDX field software_licence describes the software's own licence and stays separate. Grace policy and limits belong to the entitlement in the control plane (OFG-3, §11.02).
7. Grace reaches the operator as console alarms. Countdown and exhaustion alarms, naming DRAIN, DEGRADE or STOP, show in the console (OFG-6, OFG-7). "Leaked" leaves the vocabulary, because an abandoned lease expires on its own (Annex D). The project adds its own reconciliation rule in its place: an unreleased lease is one still active whose workId matches no live instance.
8. Conformance is a later target. The next release claims no DSL conformance. A later adapter slice targets interface conformance as an automation adapter (§08.01) at Profile B (§08.04), without reissue, failover or usage submission. Any backend is measured against the canonical endpoints (Annex B), token claims (Annex C), lease states (Annex D) and grace policy fields (OFG-2).
9. The next release stays declared-only. The descriptor may carry the licence: block and the console may display it. Nothing calls a control plane, gates a launch or stores lease state. Release text says "licence declared" and not "licensed."
10. The inventory isn't the ledger. The platform's inventory records which functions run and may hold workId or leaseId as a reference. Lease state stays in the control plane.

What changes from today's ADR-0045

• The platform no longer owns a reservation ledger. It orchestrates an external one.
• check and reserve go away. Plan holds nothing, and the workload's agent issues the lease at Provision.
• The lease binds to workload identity and not to an inventory id.
• release becomes DSL Revoke, with a reason.
• The descriptor block moves from {class, count} to an app id, a modality and dimensions.
• "Leaked" becomes "unreleased lease," and grace gets alarms.
• These parts carry over unchanged: declared-only for the next release, no "licensed" claim, and no lease state in the inventory.

Open questions

These block the adapter slice. Each comes with a recommendation; push back on any of them.

1. The workId contract. DSL requires a string and specifies nothing else. We need its construction and encoding, its length and character set, who generates, persists and delivers it to the agent, what a retry, a restart and a new launch do to it, and whether it's namespaced by tenant. Recommendation: the platform generates one value per function instance per launch and stores it with the instance. A retry of the same launch reuses the stored value, and a new launch gets a new one. It's delivered to the agent as package configuration and stays unique within the tenant.
2. Entitlement query and lease lookup. Annex B has no entitlement query and inspects a lease by leaseId only, but the agent, which the platform doesn't control, receives that id. The choice is a required backend extension (an entitlement query and lookup by workId, with defined requests, responses and errors) or a fallback in which the agent reports its leaseId and Plan only ever shows unknown. Recommendation: accept both. Prefer the extension, fall back to the agent report, and never show an entitlement as covered without an answer.
3. Does a controlled teardown need TERMINATED? Annex D keeps TERMINATED separate from REVOKED, but no baseline call reaches it. Recommendation: use Revoke with decommissioned and accept REVOKED, unless a backend offers a documented terminate extension. Ask IAMT whether a future revision should add one.
4. The readiness predicate. Issue enters ISSUED or ACTIVE (Annex D). What makes a launch "ready": a lease state, the agent receiving a token, or the application validating it? Recommendation: ready means the agent has a token the application validated locally, and the lease is ISSUED, ACTIVE or RENEWED.
5. The authority to close leases. Revoke needs elevated control-plane authority (§10.05). We need the principal type, its tenant and workload scope, how it's stored and rotated, and whether the platform acts as a delegated tenant administrator or forwards the requesting human's authority. Recommendation: a dedicated machine principal per environment, scoped to revoke within one tenant, held in the platform's secret store and rotated on a schedule, with the human recorded on the platform side.
6. The grace display contract. Which signed policy and token fields drive the countdown, which clock it uses, what the console shows when agent telemetry is stale or absent, and which component emits each alarm. Recommendation: the agent or control plane emits alarms and the console displays them. Where the console computes a countdown itself, it uses the token's exp and the signed policy's grace fields, and it shows "grace state unknown" once telemetry is stale.
7. The modality enum and dimension alignment. We need the exact modality values and how dimension names and units line up with the capability classes the platform's marketplace work is defining. Recommendation: time, process, outcome and unit-pool, following §04.03. Where a dimension names a resource the capability classes define, such as channels or frame rate, use their name and unit. Elsewhere, publishers document their own upper-case names.
8. The unreleased-lease rule. Its source of truth and race window, since a lease can be active a moment before or after its instance appears in the inventory. Recommendation: the inventory is the source of truth, and a lease counts as unreleased only after it has outlived its instance by one renewal period. It raises an alarm and an operator closes it.
9. The OpenAPI companion. Annex B names the file api/dsl-api.openapi.yaml, but the document gives no address for the repository that holds it. Recommendation: find the authoritative repository before anyone designs the adapter.

How to comment

Reply in this thread. Quote the decision point or open question by its number, and say whether you agree, disagree, or have evidence either way. Citations to DSL sections help the most. When the thread settles, the revised ADR-0045 follows in a pull request that links back here.

[znerol2]

The proposed ADR-0045 text is now in draft pull request #782, so you can read the exact wording next to this thread. Keep the discussion of the decisions and open questions here. That PR stays on hold until the thread settles.