A longtime RLM customer discovers some hidden value.
Sometimes, it takes a customer to prod you into a new way of doing business to help you understand the full functionality that you’ve had all along.
This week I met with one of my customers who was using RLM Internet Activation to issue standalone, uncounted licenses for their desktop applications. Generally, each of their customers used only a handful of licenses, so their licensing process involved giving each customer an activation code that was valid for a small number of separate activations, according to the number they had ordered. Things were going great, except…
They told me that a few of their largest customers were worried that as their staff came and went and as new machines were added and others decommissioned, their activation count would become depleted too fast. They wondered if there might be a better way to handle licensing for such a dynamic user population. The answer was simple, sort of back to the future.
What they determined their customers really needed was a pool of licenses so that their users could come and go knowing that the total concurrent user count would not exceed the total number of licenses.
My customer asked me where they could get the RLM license server to support this alternate deployment model. I said, “You already have everything you need. It’s part of the standard RLM kit.” The customer then asked, “What do we have to change in our application to support floating licensing?” I told them that no source code changes would be required because all that has to change are the types of licenses they issue… a nice surprise for them.
More about Floating and Named User Licenses
Floating licenses are the most versatile of the license types. If floating licenses are available, anyone on the network with the application software product and access to the license server can get a license to run. This is tremendously powerful for software user organizations. But, there are times when software publishers (ISVs) want to sell the convenience of floating licenses while enforcing a more restricted named_user license model.
In the named_user model, the idea is to restrict license access to only users who are on a list.
Business Benefits of the Named User Model
The benefit of named_user licenses to the software user community is that their regular software users will not have to contend with other users for licenses. The licenses are in effect dedicated to the group of named users. These licenses may also be less expensive than floating licenses. The ISV, on the other hand, benefits because he can sell named_user licenses, perhaps at a lower cost, that better match the spirit of his license agreement. If he chooses, the ISV can still sell unrestricted floating licenses, but at a premium to the named_user type.
Names can be Dynamically Assigned
In Reprise Software’s RLM, named_user licenses allow ISVs to require that user names be included on a list in order to use the licenses. The list can be assigned by the system administrator, or RLM can create the list “on the fly.” The number of users in the list can be less than, equal to, or greater than the number of licenses available. Once a user is added to the list, he can be deleted, but once deleted, he must remain off the list for a minimum number of hours (24 hours by default). This prevents the manipulation of the system in an effort to defeat the named_user license policy.
If the number of named users is smaller than the number of licenses, then this small group will share the larger pool (assumes that it’s feasible for a single user to consume more than one license at a time). If the number of named_users is greater than the number of licenses, then the larger pool of named_users will contend for the available licenses.
Managing the List
As was mentioned earlier, the license server can construct the list of users automatically as license checkouts occur, or the list can be entered via the RLM web interface by the end-user administrator. If entered manually, either individual user names or GROUP names (as defined in the ISV server options file) can be used.
Named_user licenses utilize the INCLUDE functionality of the license server, and do not need a fully populated list of users before the licenses can be used. In fact, no users need to be specified since the license server will add users who do not appear on the list if the current list size is less than the number of allowed named users.ustomer discovers some hidden value.