Blog on Software Licensing, Commercialization, and Revenue Optimization

Automatically notify customers at license expiration

Posted on

In this blog, we will cover how you can automatically send emails to customers when a license is about to expire. You will be able to select time intervals for the emails and choose to send a copy to your own email as well.

We have also uploaded this guide as a video if you find that more convenient:

This guide is based on a page in our documentation that you can find here.

Setting up automatic expiration emails

Sign in to Cryptolens and head to the Product Page. For an existing product, click on “Edit Features” and scroll down. Check the checkbox called “Automatic expiration notification” and then click on Save.

The feature is now enabled, but you need to tell Cryptolens which licenses are time-limited. This can be done in two ways:

  1. You can designate a particular feature to be the time-limited feature, meaning that any license with that particular feature set as true will be treated as time-limited.
  2. You can treat all licenses for your selected product as time-limited.

1: To designate a particular feature to be time-limited, simply select the “Time Limited” option in the drop-down menu for a particular feature’s “Type”, which can be found at the top of the Edit Feature Names page. Enable the chosen feature for the licenses you want to send email notifications to. Click on Save.

2: Check the checkbox below the list of features near the top of the Edit Features Names page called “Treat all licenses as time-limited”. Click on Save.

Now that Cryptolens knows which licenses are time-limited, your customers will receive 3 email notifications, one 7 days in advance, one 3 days in advance, and one on the day that the license expires.

Customizing the time intervals

It is possible to customize the number of emails and the time intervals when they are being sent. To do this, head to the Product Page once again, and click on Data Objects.

cryptolens_expirationnotice

Copy the object name above and paste it into the field called “Name”.

By default, the string value is 0,3,7, meaning that an email will be sent 0 days prior, 3 days prior, and 7 days prior to the license expiration date. Simply change this string value to whatever time intervals you want. If you want to send more emails, just add a comma (,) and specify how many days prior to license expiration you want to send an email. For example, to send an extra email 10 days in advance, simply modify the string to be 0,3,7,10. Press on Create when you have chosen your preferred time intervals.

Sending a copy to your own email address

Stay on the Data Objects page if you want to set it up so that you receive a copy of the email that is being sent to customers.

cryptolens_expirationnotice_send_copy

Copy the data name above and paste it into the Name field. In the String Value field, you should provide the email to which you want the copy to be sent. Press on Create.


If you have any questions, please contact us at [email protected].

Defining more than 8 features

Posted on

In this blog, we will discuss how you can add more features in addition to the 8 features that come out of the box when using Cryptolens and our software licensing system. You will also learn how to create feature hierarchies.

This guide is also available as a video tutorial in case you prefer to take in information that way:

The first step is to sign in to Cryptolens and bring up the Product Page. Once you have created a product and a license key, you may already be aware that you can click on the license key to enable or disable up to 8 features.

Let’s suppose that you’d like to add feature 9, or even define a feature hierarchy where you create a module with multiple sub-modules. This can easily be done using Feature Templates, which are described in more detail in our documentation.

Multiple Features Without Hierarchy

The example listed below allows you to add additional features without defining any feature hierarchy.

["ModuleA", "ModuleB", "ModuleC"]

You may change the name and the number of new features in the code to suit your needs. If you do not wish to make any changes, simply copy the code above and head back to the Product Page on the Cryptolens dashboard. Click on “Edit Feature Names”.

Scroll down to find the Feature Template field, and paste the copied or modified code into that field. Press the Save button and go back to the Product Page. When you press a license key, the new features will now appear below the original 8 features. The end result is shown below.

Multiple Features With Hierarchy

Let’s now suppose that you would like to add a sub-module to a particular feature. In this example, you will learn how to create two sub-modules for Module B, but the same logic can be applied to define whatever hierarchy suits your needs the best.

This section begins after the above-mentioned one ends, so if you have not already, please begin with the steps mentioned above regarding “Multiple Features Without Hierarchy”.

Head back to your Product Page on the Cryptolens Dashboard and press “Edit Feature Names”. Scroll down to the Feature Template field to find the code you pasted earlier. To define feature hierarchies, you will have to modify this code slightly.

The following code shows how to create two sub-modules for Module B. Simply replace “ModuleB” from the code in the Feature Template field with the following code:

["Module B", ["Submodule 1", "Submodule 2"]]

As you can see, the first element in the list is the name of the main feature, and the following elements will be the associated sub-modules. Using the same logic, you can define whatever feature hierarchy suits your needs. Keep in mind that you also can define sub-sub-modules.

The following code shows the end result if you just want to make three new features, whereas Module B has two sub-modules:

["ModuleA", ["Module B", ["Submodule 1", "Submodule 2"]] , "ModuleC"]

When you have created your desired hierarchy, hit Save, go back to the Product Page, and click on the license key. You will now see additional features listed below the original 8, with the hierarchy you have defined.

Below you will find what the hierarchy looks like from our example.

If you have any questions, please reach out to us at [email protected].

Bundling software licenses best practises

Posted on

As you grow your product offering, a challenge that can arise is how to differentiate between different products, and, at the same time, offer a seamless experience to your customers. We will present two approaches that can be used in Cryptolens and outline best practises when implementing license key verification in a product with multiple modules.

Using one license for multiple products

With this approach, the information about your products/modules is stored within one license key. In other words, you would just need to create one product in the Cryptolens dashboard. To differentiate between your products, you could either use the pre-defined features (F1 to F8) or define a more detailed feature hierarchy using feature templates.

This approach tends to work in most cases. However, in some cases it is still more desirable to be able to issue separate license keys for each product or module. We will describe this approach in the next section.

Separate license key per product bundled in a master license

If the previous approach is not an option, another way is to create one Cryptolens product per product/module. Typically the reason why this approach is more desirable is that it allows you to have separate trials or subscriptions attached to each license. For example, let’s suppose you have a product that offers additional features that are not part of the main product. By using a separate license key for the additional features or sub-products, you could allow your clients to test them out independently.

However, this approach would mean that your customers will need to keep track of multiple licenses at once. To solve this, we recently released an update to the API and the customer object. From now on, assuming that licenses are linked to the same customer, they can be retrieved using one API call using the customer secret.

Best practises when a product consists of independent modules

When a product is split up into independent modules, calling Key.Activate (a method used to verify a license with the server) each time a module starts is not optimal in most cases. Instead, a better approach is to verify the license with the server once at startup and then save the License Key object to file. Before another module is launched, it can check for existence of such file (and ensure that it is not too old) and then use it instead of calling the server. When it comes to obfuscation, it is more important to focus on obfuscating the method that loads the License Key object then the code that obtains the License Key object from the server.

If you have any questions, please feel free to reach out to us at [email protected].

Consumption based software licensing offline

Posted on

Licensing software that will run in an offline environment is more challenging, specifically in cases where one needs a certain response from the server (for example, to activate a new devices or record usage). However, it tends to be a real problem when changes need to be recorded fast, which occurs in the floating license model and pay-per-use model).

A few days ago, we introduced support floating license that can work offline using our license server. Today, we would like to introduce the new release of the license server that supports the pay-per-use model offline.

How it works

Instead of contacting our server to record usage, the license server will, on a regular basis, write down all the updates to a data object to disk. Each time an update is written, we will use your public-key to encrypt it along with the previous encrypted block (if you want to learn more about how it works, please check out ‘asymmetric encryption’ in this article). Since the public key is used, there is no way to see what information has been recorded, and because each update is encrypted with the previous update, once it is on disk, there is no way to tamper with the usage (assuming the client has not backed up the previous version). And even if a client would be able to tamper with this file, it may still be detected by our AI anomaly detection module. In addition to the collection of usage information, if your clients send you these files regularly, you may be able to detect any tampering with their local clock.

You can read more about our protocol on the following page: https://eprint.iacr.org/2021/937. The implementation can be found in the following repository: https://github.com/Cryptolens/license-server.

As always, if you would have any questions, please reach out to us at [email protected].

Licensing of software in containerized environments

Posted on

Protecting containerized applications (e.g. in docker) is similar in many ways to non-containarized applications. The major difference is that, in most cases, there is no reliable way to uniquely identify an instance. And even if it would be possible to identify them, it might not be desirable since oftentimes containers spin up and down very frequently.

More specifically, the challenge from a software licensing perspective is to prevent end users from exceeding the maximum number of concurrent instances.

Solution

The general solution to restrict the number of concurrent users is to use a floating license model (allows to restrict how many instances can run concurrently) and generate a random identifier upon application start (i.e. not relying on any OS information).

If your clients will have an internet connection, your application can call the Cryptolens API directly as described here. In this case, Cryptolens will be responsible for keeping track of all active instances.

If your clients will be offline, they can install a local license server that will keep track of all instances. A tutorial on how it can be setup can be found here.

If you would have any questions or need advice on how to protect containerized applications, please reach out to us at [email protected].

AI anomaly detection in software licensing logs

Posted on

Being able to find anomalies in software license logs can help you as a software vendor to detect whenever your customers experience problems (for example, with license verifications) or to detect other types of abnormal behaviour (for example, fraudulent usage).

As the amount of data increases, detecting anomalies becomes time-consuming and, in some cases, unfeasible.

To help you to find anomalies, we have released a new dashboard that will automatically let you know of any behaviour that does not conform to the norm.

How it works

The anomaly detection module works by learning the distribution of your historical data. Any group of samples that does not conform to the norm will be classified as an anomaly.

Under the hood, an autoencoder-based neural network is used (displayed below), where the goal is to train an identity function. Since there is a bottleneck layer in the middle, it forces the network to find a compressed representation of your data. As a result, it will succeed to find such representation for most of the samples. Those samples where the network struggles to find a compressed representation are classed as anomalies.

A sample can be classified as an anomaly either by its reconstruction loss (anomalies will have a higher reconstruction loss than normal samples) or by using the low-dimensional representation (the bottleneck layer) in a different method (for example, in a clustering method). In the first case, the challenge is to pick the right method to decide the decision boundary and in the latter to pick a clustering method that will be able to differentiate between normal samples and anomalies. You can read more about how it works in the following article.

Getting started

The anomaly detection module is can be accessed on the following page. It is continuously being updated, so if you notice anything or have any feedback, please reach out to us at [email protected].

Licensing software running on Raspberry Pi

Posted on

We are continuing our work on making the .NET SDK cross platform. In the latest release of our .NET library, we have added support for machine code computation on Raspberry Pi and improved the existing support for Linux.

Image of Raspberry Pi 4 Model B. Credits Michael Henzler. License CC BY-SA 4.0.

From a licensing perspective, being able to identify a device is important in order to make it possible to limit the number of end users that may use the same license. Treating a device id as an end user is very common, even though an end user can also be defined in other ways too (for example, to include the process id or username).

How to get started

To get access to the updated methods, you just need to upgrade to the new cross platform version of the library. 

dotnet add package Cryptolens.Licensing.CrossPlatform

In that version of the library, both Helpers.GetMachineCode and Helpers.GetMachineCodePI work the same way. If you prefer to use the pre-compiled binaries, these can be obtained here. It’s important to use the ones in the “Without System.Management” folder.

How it works

Every Raspberry Pi board comes with a unique serial number. The updated methods first determine whether it is a Raspberry Pi board, and if it is, hash the serial number. The machine code is of the structure “RPI_{SHA256(serial number)}”. More technical information is available in the release notes.

Related articles

Activating large number of employees when licensing software to larger clients (B2B)

Posted on

This post is a continuation of Licensing software to customers with thousands of employees (B2B) where we talked about common issues that might arise when licensing software to larger clients. In this post, we will focus on the case when your clients do not have internet access (e.g. hospitals) or where you would like to have more control over who can use your software within the client company.

Use cases

Specifically, we will explore the following cases:

  • Controlling who can activate: Typically, new devices are activated automatically, until the maximum number of machines is reached. However, you might not want that to happen, especially if you sell to a specific department in the company and don’t want users from other departments to use the software.
  • Companies with no internet access: When your clients don’t have internet access, the solution is to send them a license file where all devices are already activated. However, this quickly becomes problematic if there are thousands of employees whose device needs to be activated.

Solution

Both of the cases above share a common problem: gathering machine codes from a large number users and then activating them from your end.

Gathering machine codes from all employees

To gather machine codes (aka. hardware ids) from all employees, Customer IT needs to run a special batch script. We have prepare one that can be downloaded here. Typically, your client will use a system similar to Microsoft SCCM, which allows the customer IT to run a script on all computers and collect the result.

Activating multiple devices at once

Once the customer IT has collected all the machines, they can send the file with all the results to you. Our script will compute both the machine code and a device name (to make it easier for customers to differentiate between different activations). The can then be activated on the following page.

For more details, please check out the following GitHub repository. As always, let us know should you have any questions! You can reach us at [email protected].

Licensing software to customers with thousands of employees (B2B)

Posted on

In this post, we would like to share several new tools and practical tips that are tailored to those of you that sell to larger companies. We will cover the common issues such as management of large number of activations, offline access and reporting.

Recommended approach

When selling to larger companies, we recommend to issue one license key per client and keep track of the employees using activations. For those familiar with Flexera terminology, an activation is the same as a seat. There are two ways to restrict the number of active employees that you can your software:

  • Node-locked: in the node-locked model, once a device is activated, it needs to be manually deactivated if the customer wants to use that seat on a different machine.
  • Floating license: in this model, unused devices will automatically be deactivated when not in use, allowing your customers to install your application on any number of machines and use it concurrently on a limited number machines.

If you want to have different number of seats per feature, our recommendation is to issue a separate license per feature.

Managing activations

Typically, it’s more convenient to issue one license key per company and then restrict the number of end users (aka. machine codes/seats) to the number of workstations that will run the application. However, it can quickly become hard to manage all the end users, especially when employees leave and your customers want to free up unused seats.

To solve this problem, we have introduced the concept of “friendly name” and improved the license portal to allow your customers to query on it.

A friendly name is a way to add a human-readable name to each activated device, so that it is possible to tell which user it belongs to. Normally, machine codes are an unreadable string, and look similar to “9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08“. To make it easier to distinguish between these, you can add an optional paramater FriendlyName when activating/verifying a device. For example, if you have integrated our key verification script, you can add the friendly name as shown below:

var result = Key.Activate(token: auth, parameters: new ActivateModel()
{
    Key = licenseKey,
    ProductId = 3349,
    Sign = true,
    MachineCode = Helpers.GetMachineCode(),
    FriendlyName = Environment.MachineName
});

Our recommendation is to use Environment.MachineName as the friendly name, since if your customers use Active Directory, they will be able to see it in the admin dashboard:

To make it easier for your customers to find unused devices and deactivate them, we have added new tools in the customer portal and a new permission to deactivate devices in the customer object. There’s also a new sign up link that you can use to allow your customers to sign up with deactivation permission.

Once they are logged in, they can click on the “manage licenses” tab, and they will see a pag similar to the one below:

Here they can either manage all the activations/used seats and remove unused ones. For example, to find all my activations, the admin could click on “manage activations globally” and search for “artem(at)cryptolens.io”:

Offline access

Oftentimes, larger companies have strict constraints on internet connectivity. They may want to have their devices completely offline or without direct internet access. When your customer puts forward this constraint, our recommendation is to offer them to use our license server as a first step, which tends to be accepted in most cases. The idea behind the license server is to act as a reverse proxy, in other words, it allows devices on your customers’ network to communicate with Cryptolens through the license server, without the need of having a direct internet access by themselves. As a result, only the license server needs to be able to access the internet. Furthermore, your customers can restrict the internet access of the license server to only be able to access Cryptolens. Instead of having to do that for all their devices, they can focus on protecting one workstation running the license server. The license server is freely available on GitHub.

If your customers want to have their devices completely offline, you can use the idea of offline activation, by delivering the license file using eg. a USB stick. In simple terms: normally, when you call Key.Activate to verify a license key, you receive a signed JSON response that our client libraries convert into a language-specific object. For example, in .NET, it’s the LicenseKey object. Once you have this object you can check the status of the license, eg. features and expiration date. For devices that do not have the ability to call Key.Activate, you can instead send them the result from this method as a license file. The easiest way to enable your customers to receive these files on their own is by using our Activation Forms. Once they have provided the license key and machine code, a license file will be downloaded, which they can put on a USB stick, which is then used to activate the offline device. Under the hood, an activation form will call Key.Activate; in other words, if you want to control the user experience, you can create your own page that performs this call. Alternatively, you can manually create this file in the dashboard, by clicking on the yellow button next to the license key.

Reporting tools

Another important feature that your customers can request is to have access to audit logs. For example, if the use the floating license model, they might want to know how many seats are used at any one time so that they can scale it up or down. We are actively working on improving the customer portal to allow your customers to analyse their usage. At the time of writing, we have created standalone scripts on GitHub that you can use to generate several common reports. If you need to generate a specific report, please let us know and we will add example code.