You're viewing documentation for release 6 (LTS). Looking for a different release?

Choose a license model

10Duke Enterprise supports various license models, allowing you to choose the most suitable model for your application.

Seat-based and node-locked licensing

A seat controls which users or devices are authorized to access the software. When using seat-based licensing, configure your license model using the SeatCountConstraint with trackingMode set to TRACKED, and define the seat count for this licensed item in your product package. On its own, this caps the number of seats but does not tie a seat to specific hardware. Without hardware as a session anchor, a user holding a seat can consume the license from any number of devices.

For named-user licensing, add the AssignedLicenseConstraint to reserve seats for specific users, so that only those with a reserved or assigned seat can consume the license. If you don’t include this constraint, the license model uses floating seats where consuming a license doesn’t require a seat reservation.

To node-lock a license, pair the AssignedLicenseConstraint with the ConcurrentSessions constraint using the Hardware session anchor, which requires the hw parameter in the consumption request. The lock is dynamic: on the first consumption request, 10Duke Enterprise ties the license lease to the device’s hardware ID and records that ID in the license token, which the client application verifies against the local hardware on each check. While a lease is active, the seat can be consumed only on that device (set the per-seat maximum concurrency to 1 to allow one active device at a time), but the license itself is not fixed to any one machine. Once the user releases the lease or it expires, the seat frees up and can be consumed on a different device. This dynamic approach reduces support effort when users switch machines, for example, after a workstation breaks down or is upgraded, lost, or stolen. See more information on the node locking constraint.

To define how many license seats a single user or a device client can consume, add the ConsumptionConstraint.

To guard against abuse, such as a device repeatedly claiming trial licenses, you can add the ConsumptionLockConstraint with consumptionLockAnchor set to Hardware, which locks consumption to the hardware ID of the device that first consumed the license.

Usage-based licensing

10Duke Enterprise supports both count-based and time-based metered licensing. See below for more details about these models.

Count-based metered licensing

Count-based metered licensing tracks consumption based on transactional quantities, such as processed transactions, API calls, or volume units.

When using count-based metered licensing, configure your license model using the UseCountConstraint with the TRACK_BY_CALLER_CONSUMPTION_COUNT tracking mode, where the application reports the number of units consumed.

When using this mode, the consumeCount parameter is required in the license consumption request. Omitting it causes the request to fail.

Alternatively, use TRACK_BY_LICENSE_SESSIONS_OPENED to count each new license session (for example, each time the device starts a run) without the device reporting a count. When using this mode, define the lease settings in LeaseTimeBehavior. For example, with the following configuration a client consumes exactly 1 use count per user and device per 24-hour period:

  • The maximum token validity for online and offline use set to 24 hours,

  • allowLeaseExtension set to false, and

  • allowLeaseRelease set to false.

Note that already-granted use count cannot be returned once granted, which means that pre-authorization hold is not possible.

We recommend that your backend application tracks its own local usage state based on successfully granted requests. Your application can increment usage counters locally and synchronize them periodically, or query the 10Duke License Consumption API directly whenever a real-time balance check is required.

Time-based metered licensing

Time-based metered licensing tracks how long a resource or application is in use. This model requires anchoring consumption to a unique session context (such as a hardware ID and process ID, or a CPU serial number) to handle concurrent usage accurately.

When using time-based metered licensing, configure your license model using the AggregateUseConstraint with trackingMode set to TRACK_BY_LEASE. The duration of each license lease is added to the cumulative use time consumed from the license.

When a lease is renewed, only the actual time consumed from the preceding lease period is added. To minimize unused credit allocation upon an early session release, configure shorter lease validity durations (for example, 1 hour) in the license model. The client application will renew more frequently, ensuring only small lease increments are allocated at any given time.

Note that already-granted use time cannot be returned once granted, which means that pre-authorization hold is not possible.

Reporting on credit usage

Reporting on consumption is a common requirement, for example, to see who used credits, on which model, and when. This data is available in the events generated each time a client consumes or renews a license. 10Duke Enterprise emits a LicenseConsumed event recording the user, the licensed item, the credit consumed, and the timestamp. To build a report, retrieve these events for the period of interest and aggregate them by user, organization, or licensed item. Renewals surface as LicenseConsumed events too (so only the time actually consumed is captured), while releases appear as separate LicenseReleased events that carry no credit.

For the full LicenseConsumed field list, see the Event API data schema. See also how to retrieve them from event storage.

Combine seat access with usage consumption

If you need to license seat access separately from metering consumption, create two separate product packages, each containing its own licensed item and license model.

Grant each licensed item in its own product package, and check both constraints when validating consumption: first confirming the user or client has a valid seat, then verifying they haven’t exceeded their use count or use time budget.

On this page