Use license constraints

With 10DUke Enterprise, you can limit the terms on which a license can be used by configuring certain constraints to it in the license model.

This article describes how you can use some of the most commonly applied constraints.

For more information, see the full list of constraints you can use in license models.

Node locking (concurrent sessions constraint)

A node-locked license is restricted to be used on one workstation, and is tied to that workstation. A workstation can be a desktop device, a mobile device, or a cluster of devices (known as nodes) or IoT devices.

With 10Duke Enterprise, the node lock is created dynamically as a result of the first license consumption request made by your client application. In this use case, your application must include the hardware ID of the workstation in the request, and 10Duke Enterprise ties the license lease to this hardware ID and writes it in the license token.

The client application should always check that license token signature is valid and that the hardware ID matches. In practice, this means that no additional security measures are needed for storing the tokens. The client application can store them, for example, in the file system, in Windows registry, or in local storage (with browser-based apps)—whatever is the most convenient.

With the 10Duke Enterprise approach of dynamic node locking, the whole license is not restricted to a certain piece of hardware. Instead, a seat from the license is restricted to the hardware ID for the duration of the license lease. This reduces the need for customer support considerably in situations where users switch devices for whatever reason (for example, their workstation breaks down or the user wants to upgrade their hardware).

It’s important that hardware IDs are unique. To create a hardware ID, the basic format we recommend is that you take the baseboard serial number, add other machine identifiers if desired, and use these to calculate a hash value. For browser-based applications, there are a few of options: not using a hardware ID at all, using a pseudo ID that can be in practice the name or ID of the application, or using a browser fingerprint.

See instructions and example configurations on how to set the hardware ID as one of the session anchors using the ConcurrentSessions constraint in the license model. The article also provides information on constraints for restricting concurrent usage to one seat per device/user and applying other node locking rules.

Named seats (assigned license constraint)

A named seat type of license allows unlimited use of the licensed software for a dedicated user or device client during the license lifetime. This approach usually allows the customer to stay in control of licensing while allowing unrestricted usage for the named user or device client.

See instructions and example configurations on how to apply named seats to licenses using AssignedLicenseConstraint in the license model.

Version constraint

If you’re selling version-specific licenses and you want to allow customers to only run versions of your software application up to a given release, 10Duke Enterprise can help you achieve this with the version constraint in the license model.

For example, a license may allow running any version of the software application up to the 2.x.x line of version releases (a version range), but in order to run a 3.x.x version, the customer needs a license upgrade through an additional purchase.

Version-based licensing is most commonly used with perpetual licensing and subscription licensing. Exact version range matching and regular expression matching are also supported.

See instructions and example configurations on how to apply a version constraint to licenses using VersionConstraint in the license model.

Use count constraint

If the license being sold represents a finite quantity of a resource (such as a number of gigabytes allowed for uploading data, a number of files that can be processed, or a number of requests that can be made to a server), you need to configure a constraint on the license use count in the license model.

With use count credit, the license token validity is not as important as with seat credits. You can leave it undefined, in which case the license token lifetime will match the validity of the license.

How much should be consumed from the credit can be based on the count requested by the client application in the license consumption request call.

See instructions and example configurations on how to apply a use count constraint using UseCountConstraint in the license model.

IP address and geolocation constraint

10Duke Enterprise supports business cases where license use needs to be restricted to particular geographical locations.

Common example use cases include restricting the sharing of licenses across global offices, limiting or denying access to content or services based on location information, and defining specific IP address ranges from where licenses can be consumed.

Restrictions based on geolocation are supported in license checks. This is achieved by configuring allowed geolocation constraints in the license model. A separate license model and product package are required for each region that you’re selling to.

Note: An integration to a third-party API service and IP database is necessary in order to resolve the IP location of the calling client application (for example, service from MaxMind or similar).

See instructions and example configurations on how to apply geographical constraints using IpAddressConstraint in the license model.

Utilization constraint

To allow extra flexibility for your customers and ensure license availability, 10Duke Enterprise supports the configuration of over-usage rules for situations where customers exceed their license count.

The effect of over-usage of licenses is that the license seat count is extended based on the rules defined in the license model. The value used to extend the original license credit quantity can be expressed as a number of extra seats or as a percentage of the license’s seat count.

Depending on the contractual license terms you offer, you can bill your customers in arrears for the over-usage over various periods of times (for example, at the end of each month, or over 60 or 90 days).

See instructions and example configurations on how to apply over-usage rules using UtilizationConstraint in the license model.

Consumption constraint

The consumption constraint controls how many license seats a single user or device client can consume. It’s commonly applied when floating licenses are being sold to ensure balanced availability and distribution of license seats to the authorized pool of users and device clients.

See instructions and example configurations on how to apply a consumption constraint using ConsumptionConstraint in the license model.