Tag: licensing service

Licensing software to customers with thousands of employees (B2B)

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.

Automating offline activations

Many times your customers may have either restricted internet access or no internet access at all. Although Cryptolens is a cloud-based licensing solution, you can still use it to protect offline devices. In this post, we cover three ways internet access can be restricted and how license key verification can be performed.

Periodic internet access

If your users are connected to the internet on a regular basis, we can cache the response from the “Activate” method each time we are able to contact the server. If, at some point, internet connection would not be present, we would fallback on a cached version of the license object.

When using this approach, it’s important to define how long time your users can be offline. There is a field called “SignDate” in the license key object, which is the time when the response was signed by the server (i.e. the last time you successfully called Activate). So, if you only want to allow your users to be offline for 30 days, you can compare the current date with the “SignDate”.

License server (re-routing)

If your users have certain devices that have no direct internet access, one option is to use a license server, which will re-route all requests through a server hosted by the user. Only the server has internet access.

There is currently a Windows version of the server, freely available on GitHub.

Air gap (no internet)

If the devices have no internet access at all, we can use a similar idea that was described in periodic internet access, with the only difference that we always fallback on the license file.

In Cryptolens, there are three ways you can create such a file:

In the dashboard

Next to each license key, there is a yellow button which can be used to create license files:

Using activation forms

Activation forms allow your customers to download activation files themselves.

Using the API

If you want to automate license file creation, you can either call the Activate method using one of our client APIs or call the Web API directly (eg. using curl).

How to Skip Royalties for Mobile Apps using Software Licensing

Problems with App store?

Limited Functionality

One clear problem with any App store is that you’re locked in to use their limited set of licensing models (i.e. ways to sell your app). This is evident when you want to support proper subscription based model (i.e. customers need to pay on a monthly or early basis to continue to use your app). Many big companies, such as Microsoft and Adobe, are starting to charge their customers on a recurring basis, for instance in Office 365 and Adobe Creative Cloud. Now, you no longer buy the “product” but rather the “service”, which means that we want to give our customers a great user experience independent of the platform, may it be a tablet, a smartphone or a PC. Unfortunately, this is very difficult to implement and manage across multiple platforms  if you use built in functionality of the App store (and other app stores) because you’re locked in into their ecosystem.

High Royalties

Not only are you locked in into their ecosystem, they also take 30% of your revenue that you could have used to develop your application further.

Say you sell your service for $100/per month. Then you have to pay $30 per month in royalties, which adds up to almost $400 per year. Note, this is in addition to the fee that you payed to register a developer account.

How is this solved now?

One question that comes into our mind is following: How do companies like Spotify and Uber avoid to pay Apple the 30% transaction fee? The common denominator is that they use a custom licensing component that they maintain themselves. For example, to use Spotify, you need an active subscription (even if the app is free), which you can get outside of the Apple store, for example, on Spotify’s website. So, technically, no transaction occurred in the app itself.

Solution

The idea is to avoid using the built-in functionality of the App store as much as possible. You can do this in the following two ways: either you develop a licensing component from scratch or use a third party.

Building from Scratch

If you have some time at your disposal, you can create a licensing system from scratch or use an open source library, such as SKGL. The advantage is that you get to design it specifically for your needs. Using open-source systems can save you some time, but please keep in mind that you might instead need to spend time on configuring it and possibly extending depending on your requirements.

Using Third Party

The idea here is simple: “Why invent the wheel?”. Software licensing and monetization is such a common problem so there are solutions out there that can do just that.

First of all, they will probably cover many cases and secondly they are also cheaper than doing it on your own (after all, think about the time it would take, which is approx. 2-3 months, and later maintenance).

The critical bit is maintenance. Imagine that your business model changes and you have to restructure your licensing solution. If you use a third party, they most likely have what you’re looking for, so changing won’t be hard. Otherwise, you have to do it yourself from scratch.

Example solution using SKM

In order to get a working licensing component, one way to go is to use SKM – a cloud based licensing as a service. SKM is like a toolbox that contains many of the tools that you would need to set up a licensing system within hours. In comparison to many of the alternative solutions, it’s aim is to be accessible, which includes being affordable and simple-to-use. Moreover, one of the values is transparency and developer friendliness; many of the tools used in SKM are available open source and free of charge.  It’s very simple to get started.