The last edition of KEYnote introduced you to the fundamental concept of the CodeMeter License Transfer function. Today, we will present the best practices for creating transferable licenses with CodeMeter License Central. All you need is CodeMeter License Central 2.20b, CodeMeter 6.10a, and a Universal Firm Code.
The Bigger Picture
As a software developer or vendor, you are using CodeMeter License Central to create licenses. Your users activate those licenses on a networked server, and it is up to you to define whether these licenses can be deactivated again.
On the network, the user can either use the license directly on the server, or the license can be borrowed locally by being transferred into a local CmContainer. When a license is borrowed, it is flagged as used for a period of time and can be used locally offline without any need for a standing connection with the server. After the prescribed borrowing period has elapsed, the license automatically reverts back to its original state: It has expired locally, but is available again on the server. The user also has the option to return a license earlier. You, the software vendor, define the maximum period of time a license can be borrowed.
Firmware 3.0 and CodeMeter 6.20 are required to use a CmDongle with borrowed licenses.
Creating the CmContainer Type
Let us consider the CmContainer types in CodeMeter License Central. There are three pre-defined types for the evaluation of Firm Code 6.000.010:
The CmDongle type is used to activate licenses on a CmDongle or allow the user to transfer a license onto a CmDongle. The SmartBind type is meant for licenses on the server or licenses that are activated on a user device directly via CodeMeter License Central. The special CmContainer BorrowClient type is meant for the temporary borrowing of licenses. Distinguishing between two software-based CmContainer types helps keep source and target containers apart. The BorrowClient type also uses SmartBind to link the borrowed licenses with the machine in question.
Create a Transfer Type Template
The template for the transfer types is created in the next step. The evaluation Firm Code 6.000.010 comes with one pre-defined template.
The settings for the transfer type define the period of time a license can be borrowed and which targets are allowed. The example in the image shows a maximum borrowing period of 30 days and the BorrowClient as transfer target. If you want to include CmDongles as possible targets, simply add another item in the list.
The options “May be pulled” and “May be returned” are kept unchanged, as they are meant for different types of transfers, like moving a license permanently.
The option “Firm Item must exist” allows to determine whether users can use an empty machine to borrow the license, or whether an activated BorrowClient CmContainer has to be installed on it beforehand. The activated BorrowClient CmContainer could be created automatically during the online registration of the device via CodeMeter License Central. If the transfer target is a CmDongle, then that CmDongle already has to have the Firm Code in place. The option allows to restrict where users can transfer their licenses. As this also restricts the ease of use and comfort for the user, the option should be used sparingly.
To turn off this option, you need an “Annual Flat License” type from Wibu-Systems, which allows you to create as many licenses as you need within a set annual limit. If the license type is “License per CmContainer”, the option cannot be unchecked.
Creating an Item
To finalize the borrowable license, an item needs to be created. In the section CmContainer Type, you set on which CmContainer types the license can be activated; in our example, this is the SmartBind type.
You also define whether and, if so, which license transfer types have to be used.
In our example, the sample item for the evaluation Firm Code 6.000.010 is optimized for using a license on a server on the network. It checks whether the same license is already present and, if it is, adds the new license to the license quantity.
Preparation is finished, and the borrowable license can be created.
In order to create a borrowable license, you simply create a ticket under the menu item “Create Order”. For this purpose, you use the item you have just created and create five licenses, each with a single user limit. This ticket is sent to the user.
The user activates the licenses on the server, e.g. via WebDepot. With the choice of five licenses for each user during the license creation process, the user can employ different servers on the network. For our example, we assume that the user is activating all licenses on a single server.
Once the licenses have been activated, the user can borrow them for use on different computers, e.g. by using License Manager in our example. License Manager is a sample, included in the CodeMeter SDK as source code and can be freely customized.
In the standard scenario, the license is kept on a server on the network. The user starts License Manager on the client that will receive the license. To find the license on the network, the user selects the “Include Remote Server” option. In our example, this takes him to the local PC that is set up as a server.
The user now selects the license he wants to borrow and clicks on “Borrow License”.
The user is then asked to define the period of time he wants to borrow the license. As the maximum period has been set to 30 days, the user can choose any period of time between 1 second and 30 days. License Manager is a sample application; the actual format of the borrowing period can be adjusted to match the needs of the actual target group.
After the borrowing process is complete, the user will see two items:
the license on the server on the network, with one of the five available licenses now marked as used, and
the freshly borrowed local license, which can only be used on this specific machine.
Can users deactivate licenses on the server while they have been borrowed? It is simple to do so, as long as enough licenses are available. In our example, the user has five licenses, of which one has been borrowed. After one license has been deactivated, four remain on the server – three readily available, and one currently borrowed. What happens if the user deactivates more licenses than are available? This would create a temporary negative quantity, but the option has to be allowed, since users might manoeuvre themselves into a dead end. This can happen in particular if licenses are deactivated offline, which can take some time between the deactivation request and the resulting license update. That is why CodeMeter allows both options:
Allow a negative quantity, monitor the deactivations as they happen via CodeMeter License Central, and intervene if needed.
Forbid negative quantities and offer user support where needed.
The standard setting allows temporary negatives, which is the user-friendly and resource-efficient option.