SLASCONE provides a solid framework allowing you to define your licenses requirements, regardless of your business model. You can have not just one, but multiple products.
The creation of a product (and its editions) is obviously a fundamental step in setting up your system.
PROPERTIES
When creating a product, you can set the following properties:
- Features
- Limitations
- Variables
- Constrained Variables
- Tokens
- Goodwill Tokens
- Software Release Limitations
- Expiration Types
In most cases, you are going to use only a subset of these properties. As your products and/or your business models evolve, adjustments might be necessary, such as adding a new feature.
FEATURES
Features enable the activation/deactivation of product functionality. A feature can be either on or off.
LIMITATIONS
Limitations or quotas are numerical values used in order to restrict the scale of some operations, e.g., maximum number of users or jobs. Limitations can be used/interpreted by the client application either statically or in consumption-based mode.
VARIABLES
Variables are generic fields that enable the passing of custom license information. Variables are used to transfer licensing properties that can not be represented as features or limitations. Example: a custom date.
CONSTRAINED VARIABLES
As their name implies, constrained variables are analogous to variables. The distinction resides in the fact that while variables can receive any value, constrained variables can only receive values from a predetermined, custom list.
TOKENS AND GOODWILL
SLASCONE provides 2 types of license keys:
- License key: when you create a license, SLASCONE generates 1 license key and n token keys. The license key can be used n times for activation.
- Token key: a token key can be used only once for activation.
Let’s assume a scenario in which the end-customer has two installations: a development and a production system. In this case, a license with 2 tokens is necessary. The end-customer can use the license key for both installations, or one token key for every installation.
GOODWILL
Let’s assume a video or music streaming service, whose vendor wants to avoid shared accounts. With SLASCONE the vendor can set the number of allowed devices to 3, preventing a 4th device from using the service.
In order to avoid a poor customer experience resulting from such a ‘hard-cut’, SLASCONE introduces ‘soft’ limits with Goodwill tokens. In our example, the vendor can switch from 3 to 3 + 1 (Goodwill) tokens. Goodwill tokens constitute a ‘yellow zone’, in which the client is under-licensed but can still use the software. SLASCONE provides a quick overview/analysis of activated Goodwill tokens, enabling vendors to react, e.g., by issuing a warning after the activation of a Goodwill token or by emailing affected customers.
SOFTWARE RELEASE LIMITATIONS (UPGRADE COMPLIANCE)
In a typical scenario, vendors use the expiration date to prevent a perpetual usage of the software. However, there are cases in which the customer is allowed to perpetually use software Version X, but not Version X+1. In order to address such scenarios, SLASCONE licenses carry an optional maximum software release information, which indicates the latest purchased version. Once an installation is upgraded to a not purchased version, SLASCONE returns a corresponding warning/error.
If for example, the license has a software release limitation 22, then the following applies:
- 21.X compliant (can be activated)
- 22.X compliant (can be activated)
- 23.0 non compliant (can not be activated)
- 23.1.5 non compliant (can not be activated)
Although, you would typically use major versions, the SLASCONE’s algorithms can even consider minor versions and revisions, e.g., if the license has a software release limitation 22.1, then the following applies:
- 21.X compliant (can be activated)
- 22.0 compliant (can be activated)
- 22.1 compliant (can be activated)
- 22.1.5 compliant (can be activated)
- 22.2 non compliant (can not be activated)
- 23.0 non compliant (can not be activated)
- 23.1.5 non compliant (can not be activated)
CREATING SOFTWARE RELEASES
Every time there is a new major software release, it has to be added to the list of available software versions. Supported Formats: 12.0 or 12.0.1 or 12.0.1.3 i.e., numerical fields separated by (at least one) '.'.
ASSIGNING A SOFTWARE RELEASE LIMITATION TO A LICENSE
As long as the end-customer is entitled to updates, the corresponding license has no software release limitation. As soon as the customer loses the right to updates (e.g., because the update contract was cancelled), the corresponding license has to be updated with the latest eligible software version.
This ensures that the next heartbeat is going to validate the client's software version, with the license's software release limitation.
"is_software_version_valid": true,
"software_release_limitation": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"product_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"software_release": "21.1",
"description": "string"
},
EXPIRATION TYPE
- Custom Date
- Subscription/Perpetual - if there is no expiration date use this setting
- Days after activation
Comments
0 comments
Please sign in to leave a comment.