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.

Named seat 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.

Trial license constraint

To help prevent the abuse of trial licenses, you can prevent a customer from using the same trial license repeatedly on the same device.

You do this by providing a lock scope for a trial license during provisioning, which 10Duke Enterprise then ties to the device on which the license is first consumed. This creates a locking between the device’s hardware ID and any trial licenses that use this lock scope.

Let’s say a customer acquires a trial license with a lock scope product-trial, and starts consuming it on their laptop. Now their laptop’s hardware ID is locked for that lock scope.

If this customer later acquires the same trial license with lock scope product-trial again, the locking will prevent them from consuming the new license on their laptop.

The locking is not dependent on the user: even if the customer created another user account and acquired the trial license with lock scope product-trial again, they wouldn’t be able to consume the new license on their laptop.

Depending on your use case, you can use different lock scopes even when provisioning the same trial license. For example, if you release new features in your software annually, you might want to offer customers the possibility to try them out by taking a new trial license. In this case, you could provision the trial licenses using a different lock scope every year, such as product-trial-2024 and product-trial-2025, so that the previous year’s locking wouldn’t prevent a customer from using the next year’s trial.

Note: In addition to the lock scope and the hardware ID, the locking is also tied to the licensed item that was used for creating the trial license. This means that if the same licensed item is used in multiple product packages, the locking will prevent abuse of any trial license that uses the same lock scope, regardless of the product package used for provisioning it.

See instructions on how to apply a trial license constraint using ConsumptionLockConstraint in the license model and how to provision trial licenses.

The 10Duke Enterprise support for trial abuse prevention has the benefit that, if needed, you can use the same product package and license model for both your trial licenses and commercial licenses. The only differentiating factor needed is to specify a lock scope when provisioning a trial license, and to disable locking with a commercial license.

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.

Node locking 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.