Named User Licenses

Named User Licenses are a new type of license that is bound to a specific user. This might sound simple at first, but virtually every person has very different expectations of what this means in practice. The good news first: CodeMeter can cover all of them.

In essence, the different expectations of Named User Licenses would fall into two categories. On one side, there is the viewpoint of software developers who expect to increase their revenues with this new licensing model. On the other side, there are end users who want to allocate or reserve the licenses they have bought for specific persons or groups of people.

Named User as a Licensing Model

From the software developer’s point of view, a Named User licensing model is a good alternative to the Concurrent User model, which typically keeps licenses on a license server in the network. This license can be used by several different users, even if only one user can use it at any given time. If a client has three licenses, three people can use the licensed software at a time, irrespective of who they might be. One popular feature is the ability to borrow such licenses, which would mean transferring the license for a defined time from the license server to a local computer or connected dongle. After the defined period has expired, the license automatically reverts back to the server, where other users can access it.

In the case of Named User licenses, the software developer would bind the license to one specific user. The license can and must only be used by that person. Typically, Concurrent User licenses are worth more, because they can be used by several users. The client needs to own fewer of them to serve his users. Their values can be different by a factor of between 1.5 and 3.0; in the case of office applications that are used more frequently and for longer periods of time, the factor would lie nearer the lower end of 1.5, whereas with analytical tools or compilers that are used rarely and only for brief periods, the factor can often reach 3.0. By using the Linger Time option, even short-use software like compilers can be licensed effectively via networks. The license then “lingers”, that is, it remains reserved for the last user for a defined time after its last use, and can only be released to other users after the linger time. Products that are normally used on a permanent basis typically avoid using Named User licenses.

Who Controls the User’s Name?

Controlling the user name is the essential challenge when using Named User licenses. Software developers are naturally interested in keeping full control to prevent misuse of their licenses. At the same time, they need to account for use cases in which the user name has to change, e.g. when an employee who had been using the license leaves his job, sometimes years after the original definition of the license. Many solutions have been put forward for achieving this balance between control and complexity.

Simple Contractual Controls

The simplest solution is to control the named user just by contractual limitations, without any technical precautions or with a simple watermark in the license that does not limit the software’s functionality.

CodeMeter can integrate the watermark in the protected data or customer owned license information, and read it by API during runtime.

Binding to a Database Account

Developers of client-server applications like bug trackers are in the optimal position of having a distinct account for each user of their applications. Using group accounts (like Team, Team1, Team2 etc.) normally has major disadvantages for the client. When the client uses up all of his accounts, he can delete obsolete accounts to recover space for new users or buy more licenses.

In such cases, the maximum number of registered users is entered as the license quantity. The application on the server reads this information and compares it regularly, and whenever new accounts are created, with the current number of accounts. If a license has been breached, no new accounts can be added. Alternatively, accounts above the paid limit can be deactivated, or all users receive an error message.

Single User License via a Portal

A common and simple form of implementation is a single user license bound to a specific machine. This is often used in combination with a user portal. Every user of the client is given his or her own account, and the license administrator of the client allocates a license to each user. The user can now activate the license on his or her computer. If he or she needs to move the license, e.g. to use it on a second workstation, the user can deactivate the license and reactivate it on the other system.

This can be done with CodeMeter License Central and a simple change to the WebDepot license portal. A single user license is the standard licensing model of CodeMeter and is immediately available.

Software as a Service

Named User licenses are a popular option when offering Software as a Service, with the software developer providing cloud access to the application in question. Since the system is operated by the developer, he can effectively control how the licenses are being used. Nonsense names and group accounts can be identified and the problem remedied with a “quiet word” with the client.

Similar to when the license is bound to a specific user name, CodeMeter can again set the maximum number of accounts in the license and monitor them in the software. The special advantage of CodeMeter in this case is that it can combine Software as a Service with on-premise software or act as a token for the reliable identification of a user.

Hard Binding to a User Name

Excellent controls are possible by binding the license to the log-in name of the user. This option has been completely remodeled for CodeMeter 6.30 and is now available as a ready-for-use licensing model. In this case, the developer chooses whether the license is tied to a user name, a user name and domain, or a user name chosen by the developer himself.

When licenses are bound to a user name with or without specified domain, CodeMeter handles almost the entire process automatically. The developer simply needs to add the right user names and, optionally, domain. When the license is used, CodeMeter Runtime checks the user name and domain automatically on the client PC. If a fitting Named User license is available, it would be used first. Otherwise, a Concurrent User license is chosen. If neither a Named User nor Concurrent User license, an error message is displayed.

A user name from an existing database can be used for binding the license to a user name. The CodeMeter API informs the software in the CodeMeter Runtime of the user name in question.

But what happens to the process when user names change? This can be defined with entries in CodeMeter License Central that are completed when the license is activated. An adjustment to the WebDepot license portal or the software activation assistant and gateway allows the name to be overwritten upon each activation. To change the user name, the license is deactivated and reactivated with a new user name. The developer can decide how often this can be done, simply count the instances, or enforce a hard limit. CodeMeter License Central gives you the option of accessing the last value and the date when the value was changed. This makes it easy to implement models like “Change every 30 days”.

Named User Licenses from the Client’s Point of View

There can be instances when a client wants to use a Concurrent license like a Named User license. For instance, two teams might want to share ten licenses. The two team leaders want to have a personal license reserved for themselves, while the other eight licenses should be at the disposal of their team members.

The client’s administrator can do so by configuring the settings in CodeMeter WebAdmin. The administrator would allocate one license each to the two team leaders, which would behave like Named User licenses. The administrator can also define the rules for using the remaining licenses, for instance reserving three licenses exclusively for each team and leaving the final two up for grabs.

This type of setup is popular particularly for accounting reasons. One team might have paid for four licenses, the other for six. All ten licenses are stored on a shared server, but each team might want exclusive access to the licenses it bought. To do so, both teams need separate Active Directory groups, with one team getting four and the other team receiving six licenses.

 

KEYnote 32 – Edition Fall 2016