Key concepts

Before you start working with 10Duke Scale, learn about the key concepts.

Products

The 10Duke Scale product model enables you to issue licenses based on a predefined structure and a set of rules. Products serve as a catalog of what is being sold and licensed.

A product can have one or more product configurations, predefined product variants that a customer can buy or subscribe to. Each product configuration holds the information on what features are enabled and what license model applies.

Products and product configurations can store reference identifiers from external systems. This is useful when mapping product information between, for example, e-commerce, product data management, and customer relationship management (CRM) systems.

Your preconfigured products also help to reduce the complexity of e-commerce integration and help to keep the responsibilities between systems clear.

See how to set up your preconfigured products.

You can also define the product and feature information for a license on the fly—see more on feature licenses below in this article.

License models

A license model describes the rules that govern how licenses can be consumed, for example, the number of concurrent devices allowed per user, and how many seats a user can check out from a license.

When you’re using preconfigured products, each product configuration holds information on the license model applied. When you issue a feature license and define the features on the fly, the system applies a default built-in license model.

License model settings are stored in each license at the time a license gets issued. This means you can safely make changes to your product’s license models without affecting existing licenses.

See how to define license model settings for your preconfigured products and how to apply concurrency rules in license consumption.

Customers

The customers (licensees) in 10Duke Scale represent your customers that you issue licenses to. The customers can be individual users (B2C) or organizations (B2B).

See how to manage customers.

License consumers

While a customer is the party that you have issued a license to, a license consumer is the party who is entitled to use the license.

In B2C scenarios, the customer and the license consumer are typically the same person. But even in these cases, there may be multiple license consumers that use the same license that the customer has purchased (for example, subscriptions where multiple family members can use an application).

10Duke Scale supports three types of license consumers: a person (user), a device, and a license key. See how to manage license consumers.

Users and devices

A license consumer is often a user, but devices are becoming increasingly mainstream as well. 10Duke Scale supports identity-based licensing for users through integration with a standard identity provider using OAuth/OpenID Connect (OIDC).

License keys

The third license consumer type, a license key, hides the true identity of who or what is consuming a license. A license key is a unique code associated with a license, and it functions as a shared secret between you, the vendor, and the license consumer who is using your licensed product. A license that has a license key can only be consumed using that license key.

Licenses

A license describes the right to use a certain asset, such as a product and its features and functionalities. A license reflects part of the contract that you, the vendor, have with a customer.

See how to issue licenses.

License quantity type

Depending on the quantity type of the license, license consumption is measured in different ways:

• A seat-based license anchors the use of the license to a computer (a device in more general terms), or limits the number of concurrent instances of the client application.

• A use count-based license counts the unique consumption of a specific entity in the client application. The counting takes place in the client application, and 10Duke Scale maintains the total remaining quantity and the change to it as reported by the client application.

• A use time-based license counts the total aggregated use time of a license. Measuring the time takes place in the client application, and 10Duke Scale maintains the total remaining quantity and the change to it as reported by the client application.

Product vs. feature licenses

You can apply product and feature information to licenses in two different ways:

• Set up predefined products in 10Duke Scale, with product configurations that include the feature names as well as a license model, and use these to issue licenses.

  When issuing licenses using this option, all you need to know is the product configuration ID, the customer that you’re issuing the licenses to, and the quantity that you’re granting in the license.

  Preconfigured products are always needed when issuing licenses using activation codes.

• Issue licenses and specify the product and feature names on the fly—in 10Duke Scale these are referred to as feature licenses.

From the license consumption point of view, both options result in the same kind of a license structure. Both types of licenses specify a product name and a list of feature names, and the only difference is that product-based licenses also specify the product configuration that was used.

License containers

Licenses are stored in customer-specific license containers, which are used to control license consumers’ access to licenses, and which help you organize customers’ licenses.

While one license container is typically enough for a B2C customer, there may be use cases where you want to use multiple license containers for B2B customers.

For example, if a B2B customer has purchased multiple licenses with different usage constraints or features, they would typically want to control which of their users can access each purchased license.

See how to manage license containers and how to use them to manage access to licenses.

Activation codes for issuing licenses

You can use activation codes for Just-In-Time (JIT) license provisioning when a customer or end user first uses your application.

You generate activation codes that hold information for issuing licenses, and distribute them to your customers alongside their purchase or subscription.

Anyone in possession of an activation code can redeem it to trigger the creation of a license. Typically, a B2C customer is also the end user who redeems the activation code, and with B2B customers the activation codes are redeemed by the company’s or organization’s end users who will be using your application.

See more on activation codes and how to use them.

Activation codes vs. license keys

So what’s the difference between activation codes and license keys? On the surface, both may just look like codes that you distribute to customers to access your application.

In short, an activation code is a method for issuing a new license, whereas a license key is a method for consuming a license: it’s one type of a license consumer, same as a user or a device.

An activation code is a code that you can create and distribute in advance of license creation. It’s not limited to any specific customer: it can be redeemed by anyone. You could compare an activation code to a gift card to a webshop: it doesn’t tie you nor any customer to anything yet. When the code is redeemed, a license is issued and linked to the customer who redeemed it.

A license key, on the other hand, is generated at the same time when a (key-based) license is created, which also ties it to the customer who is the licensee. It’s literally the key to a particular license: that license can only be consumed using that license key.

With respect to validity, an activation code is a temporary code that has no use after it has been redeemed. A license key is a permanent key for accessing the license it was generated for, usable while the license itself is valid. Note that activation codes allow you to leave the start of the license validity period undetermined, if needed: each customer’s license validity will start when they redeem their code.

Using an activation code doesn’t exclude the use of a license key in any way. You can create activation codes that will issue key-based licenses. In this case, the customer will in practice exchange one code with another: they enter the activation code, and get back a license key for accessing your application.

License consumption

License consumption is the process through which a license consumer accesses your software application by consuming seats, use count, or use time from a valid license.

The license consumption flow consists of the checkout of a license, a periodic heartbeat, and the release of the checkout. A successful checkout provides your application with a license token that authorizes the use of the license.

A license can be checked out by a user or a device, and key-based licenses can be checked out anonymously using a license key. The license checkout is based on the product name in the license.

See how to consume licenses.

Enforced vs. metered consumption

A license can be consumed either in enforced or metered mode:

• In enforced consumption, the license specifies a certain quantity that is consumed when the license is used.

  Depending on the quantity type in the license, the quantity can be the number of seats available in the license, or the use count or amount of use time that the license allows.

  A checkout in enforced consumption requires that the license has sufficient quantity available.

• In metered consumption, the quantity available in the license is unlimited.

  10Duke Scale tracks the license consumption (the seats in use, the use count, or the use time) based on API interactions, and the usage statistics are available through 10Duke Scale metrics and insights.

Regardless of the consumption mode, your client application needs to keep 10Duke Scale up to date on the quantity being consumed throughout the license consumption flow, and needs to report the final consumed quantity when the checkout is released.

See more about reporting the quantity consumed.

License consumption flow

In both enforced and metered consumption, your client application uses 10Duke Scale API interaction protocols to handle the license consumption flow:

1. The application checks out the license to start the consumption of the license. The application uses the received license token to enforce the license on the usage of the application.

2. The application makes periodic heartbeat calls to acknowledge and authorize the continued consumption of the license.

3. The application releases the checkout to end the consumption of the license. This also includes reporting to 10Duke Scale the final quantity that was consumed from the license.

See more details on the steps in the license consumption flow.

The license checkout can also be done manually from the UI console (for enforced consumption), which allows downloading license tokens, for example, to support offline use cases or embedding license tokens in manufactured devices.

License token

At checkout and at every heartbeat, your client application receives a license token from 10Duke Scale in JSON Web Token (JWT) format. The license token is secured with a signature created by 10Duke Scale.

The license token carries information about the license to the client application, such as which license consumer it authorizes to use the product, which features the license enables, whether seats, use count, or use time will be consumed, and whether consumption is enforced or metered.

See more about the content of the license token and how to handle them in your client application.

Feature flags

Feature flags, also referred to as feature toggles, provide a license consumer-oriented view into what products and features are available for use through all the licenses that the license consumer has access to.

Feature flags allow you, the vendor, to modify the system and application behavior without changing code, which is useful, for example, for enabling and disabling features and functionalities in the application.

To understand the general concept of feature flags, check out martinfowler.com.

10Duke Scale feature flags are driven by licenses, with the main difference to regular licensing that requesting feature flags for a license consumer doesn’t consume the licenses. This is a benefit if licenses are the required driver, but it’s not feasible to limit their use by quantity or to meter the use and invoice accordingly. 10Duke Scale is unable to track the use of the features because there’s no license consumption, so the application needs to track feature usage by some other means.

Example use cases for feature flags:

• Provide new features for evaluation or deliver new functionality to users rapidly but safely.

• Drive available features by geographic area, based on using different product configurations per geographic area where the product is supplied to.

• Drive seasonal or campaign-based availability of features, based on using time-limited product configurations. 10Duke Scale provides the product configuration and licensing aspect and, for example, the e-commerce system is responsible for determining the coupling between a seasonal offering and the correct product configuration to use.

Examples of technical purposes:

• Ship alternative code paths within one deployable unit and choose between them at runtime.

• Provide features and functions based on licensing without involving the license consumption aspect.

If you’re applying feature flags, the basic questions that must be answered are how long a feature flag will live, and how dynamic the toggling decision must be. The benefit of license-driven feature flags is native support for answering both of these questions.

The feature flag API returns a super-set of a product/feature breakdown, which means the application that consumes the information is completely decoupled from the license instances that drive the result. The license validity time frame answers the question “how long”, and expiring licenses and issuing of new licenses with evolving product configurations answer the question “how dynamic”.

See more information on retrieving feature flags.