By staff

Shared Floating License

Count unique users of your application with the Shared Floating License.

We’ve discussed the floating license in a previous blog post.  A floating license allows a specified number of independent instances of your application to run anywhere on your customer’s network so long as that number does not exceed the predefined limit specified in the license.  But what if you want to allow each user to run multiple instances of your product, while still limiting the number of users who can access the product at the same time?  The Shared Floating License works well in this situation.

shared floating licenseWith a shared floating license, separate program invocations from the same user (or the same user on the same host) consume only a single license.

To implement a shared floating license in RLM, specify a license server with the SERVER line, and set the count field of the license to a positive integer.  The license itself has no associated hostid, meaning that it will run anywhere. The license should also have a “share=” attribute, and the value is any combination of the letters “u”, “h”, and “i”.

With a shared floating license, you have a good bit of control over the actual sharing of the license.  You can share the license across invocations of your product that have the same:

  • username
  • hostname
  • isv-defined string

or any combination of those 3 parameters.  So, for example, you can share a license requests from the same user on the same host by specifying the share= parameter of the license as “share=uh“.

In addition, you can limit the amount of sharing that is allowed.  For example, if you want to allow up to 5 invocations from the same user to share one license, but the 6th invocation to consume an additional license, specify “share=u:5“.

Shared Floating Licenses work well for interactive applications where the user will naturally bring up multiple copies to get a job done.  In this case, consuming a single license for multiple invocations seems like a natural and fair way to license your product.


Named User Licenses

named user licensesNamed User Licenses – Let your License Manager build user lists dynamically

Floating licenses are the most versatile of the license types. When available, anyone on the network with access to the license server can get a license to run. This is tremendously powerful for the software user, but there are times when software publishers want to sell the convenience of floating licenses while enforcing a more restricted license model. Named user licenses do just this by restricting access to users who are on a list.

Business Benefits
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 publisher, 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 publisher 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 publishers 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 – all at the publisher’s option. 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.

The “How To”

To deploy a named user license, the publisher does not need to modify his RLM-enabled application at all; it’s controlled in the license certificate itself.  To create a named user license the named user keyword is simply added to a standard floating license certificate, in one of the three following ways:

named_user – to require the same # of users as there are licenses
named_user=n – to require a maximum of n users to be named
named_user=”n min_hours” – to require a maximum of n users to be named, and to specify the minimum number of hours before the deleted user name can be re-added back to the list.

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 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.

Best Practices for License Management

Best Practices for License Management

Time spent paying attention to best practices for license management will pay dividends down the road in customer satisfaction. Following a few basic guidelines will be greatly appreciated by your end-users who will see more consistent implementations from ISV to ISV.

Let’s dive right in:best practices for license management

The Product name you use to check out a license for a product should be as close to the name of the product you sell as possible. We consider it best practice to use the name of the product from your price list.  This is probably the most important thing you can do in your implementation.

In practice, it’s often quite reasonable for ISVs to use multiple license names in an application – just keep it within reason. A good rule of thumb is to use a new license if you charge separately for that feature.

Fewer checkouts per product are generally better from an end-user support and understanding standpoint. In the early days of license management, companies literally “went crazy” adding license checkout calls to smaller and smaller pieces of their application, which resulted in several licenses required to run one product. Resist the temptation to do this.

Installation of Your Product and Finding the Licenses

When you integrate licensing into your product, you need to think about how you will deliver the licenses for it to operate. A large percentage of support calls occur during the installation of the software application. One way to decrease the support burden is to make the installation of the license file as seamless as possible.

For less complex applications deliver the license via automated Internet Activation, such as Reprise’s Activation Pro.  This can make for a much easier installation experience for the end-user.

For more complex applications manually delivering the license may be the best option. Delivery of the license file via email or downloading it from a web support location may be more appropriate. Make sure that it is clear where the license file should be saved.

It is also critical that the application be able to locate the license file at runtime. When Integrating RLM into your product there are a few ways that your application and license server can locate the licenses they need to operate. We provide a “best practices” section in the RLM Reference manual that outlines the best way to define the parameters for defining the license file location. If you follow this advice, you will have a better end-user experience.

Best Practices for License Roaming

A common floating license option provided to end-users is License Roaming. Increasingly, users want to take their work “on the road.” RLM’s built-in license roaming capability allows users to check out a license from a server, physically disconnect from the server and continue to use the license for a specified number of days on their notebooks or laptops, after which the license is automatically returned to the server. Again, no extra work is required beyond enabling roaming in the license file. As an ISV, you control whether licenses are able to roam, and how long they can be checked-out in the disconnected state.

RLM license roaming was designed to allow ‘disconnected’ use for short durations up to a few weeks.

Best Practices for Product Evaluations/Demos

One compelling value of software licensing is to provide a way to promote and market your application to prospective buyers. You should provide demo or evaluation licenses to your customers. Here is a brief summary of best practices for this scenario that can help increase sales.

  • Expose all functionality to the user – even if you limit scope of use, show the user what could be possible.
  • Show “number of eval days remaining” on the start-up screen – creates user urgency and an expiration date creates timetable for sales follow up.
  • Always remind the user how to buy, even after the eval has ended, by providing a link to information on how to buy
  • Do not require the software to be re-downloaded or reinstalled when upgrading to a paid license – this is one key value of a license manager.

One of the primary goals of software licensing is to increase revenue opportunities. In order to maximize the efficiency of software licensing, it is critical to spend time in planning and design. Various license models can be utilized to increase revenue opportunities and varying degrees of security can be incorporated. It is also important when implementing software licensing, that the end user’s interaction be considered.

A software License manager like RLM is an indispensable tool that can help you to design and enforce pricing models that are right for today’s customers, while giving you the flexibility to quickly adapt to new opportunities as they emerge.

Increase License Server Capacity with Disconnected Use

Cloud Computing Highlights the Need for Increased Server Capacity

Last time, we talked about how an increasing number of software vendors are hosting license servers crowdin the Cloud for their end customers and how client-side caching decreases the load on the license server.  Another requirement for license servers in the Cloud is the ability to serve more clients than a traditional on-premises license server.

To address this challenge RLM supports “disconnected use.”  While a normal RLM client application requires a socket to remain open to the license server for the lifetime of the license checkout, with “disconnected use” the socket is closed after the initial checkout, and only re-opened when the application performs a heartbeat to the license server.

Since RLM v10.0, “disconnected use” allows software vendors to initialize RLM in a way that sets communications with the license server to a “disconnected” mode.  Our internal testing indicates that a license server can support roughly 10 times the number clients using disconnected operation, as compared to the usual connected operation.  The limit with disconnected operation is generally reached when the server can no longer process heartbeats from all the clients in a timely manner.

For a more detailed technical description of this feature, including some performance guidelines, please refer to the RLM Reference Manual section entitled “Disconnected Operation.”

Client-Side Caching Improves Licensing Performance

Cloud Computing Highlights the Need for Client-Side Caching

An increasing number of software vendors are hosting license servers in the Cloud for their end customers. The longer physical distance between client and the license server introduces more network latency.  License checkout times may be slower over these longer distances compared with those over a local area network. Applications with short duty-cycles or massively parallel applications that require frequent checkouts over a short period of time are affected the most. To address this challenge RLM supports “license caching” on the client.

Since v10.1, RLM lets software vendors create licenses that specify a “cache time” in seconds so that when licenses are checked out, RLM will create a cached license on the local client machine.  If the same user on this host subsequently checks out the license before the cache time expires, then the local cached license is used, avoiding a connection to the license server.

To use caching, the license must specify the keyword “client_cache=N” where N is duration of the cache period in seconds. Any license with a client_cache specification is treated by the license server identically to a license with a min_checkout specification.

For a more detailed technical description of this feature, please refer to the RLM Reference Manual section entitled “Client-Side License Caching.”

Token-Based Licenses, part 2

Advanced Use of Token-Based LicensesToken-Based License

Last time, we discussed how to license all your products as a function of a single base license, by using a Token-Based License.  Today, we will talk about the other 2 uses of token-based licenses:

  • create product bundles or packages (much like Package licenses), or
  • let a user consume a more-expensive alternative license when a more-common product is unavailable

If you want to create a product bundle called “office”, and that the components of this bundle are “write”, “calc”, and “present”, you would proceed as follows:   your 3 products would each check out the appropriate license (write for write, calc for calc, and present for present). To create the product bundle, you would create 3 token definitions for the 3 individual components:




These token definitions define how the products are packaged together, and don’t vary from customer to customer. Now, when your customer buys the office product, you issue them an office license, like this:


This license allows 6 copies of the office package to float on your customer’s network.   If the same user uses both write and calc, they still only consume a single license due to the share=uh specification in the office license.

As we said before, the best part is that you don’t have to do anything special to start using Token-Based Licenses. You implement the RLM API as you would for any supported license model. No need to create a second version of your product to support Token-Based Licenses – it’s built in.  In each product, check out a license that is specific to that product, for example, “write”.

For another example, let’s say that you sell both write and writerPro licenses, where the writerPro license includes all the functionality of write, plus more.   If your customer has both write and writerPro licenses, they may run into the situation where they are using all their write licenses, and the next user wants to use write, but no licenses are available and yet there are unused writerPro licenses.

If you define a token-based license for write that uses the writerPro license, then your customer can use the more-expensive writerPro license to run write.  That license would look like this:


Of course, they would need to have both write and writerPro licenses available for this token definition to do any good since the TOKEN license itself doesn’t authorize any license usage, it is simply a mapping from one checkout request to another.  And in this case, they would want the licenses to be in this order:

  • write license
  • write token definition
  • writerPro license

This order ensures that requests for write first use the write licenses, then if none are available, they would use writerPro licenses.




Token-Based Licenses

Using Token-Based Licenses to Increase Licensing FlexibilityToken-Based Licenses

Once you have mastered the basic license models that all license managers provide, it might be time to take a look at some of the more advanced models.  Token-Based Licenses provide advanced license options that aren’t available any other way.

In prior lives, we invented “Package” licenses, but these turned out to have many problems, most of which are solved by Token-Based Licenses.  In addition, Token-Based Licenses enable functionality well beyond the old Package license.   In particular, a Token-Based License allows you to:

  • create product bundles or packages (much like Package licenses), or
  • define all your product licenses as multiples of a single base license, or
  • let a user consume a more-expensive alternative license when a more-common product is unavailable

Today, we’ll discuss the idea of licensing all your products as a function of a single base license.

If you define a single base license then use multiples of that base license to enable all your products, this gives your customer the ability to mix and match different products from your catalog up to the total limit of the number of base licenses purchased.  This has the additional advantage of allowing your customer to use new products before they have gone through the purchasing cycle for them – the ultimate “try before you buy” experience, since they are using actual purchased licenses to evaluate your new products, and can do so without even contacting a salesperson.

The best part is that you don’t have to do anything special to start using Token-Based Licenses.  You implement the RLM API as you would for any supported license model.  If this is already done, great!  No need to create a second version of your product just to support Token-Based Licenses – it’s built in.  In each product, check out a license that is specific to that product, let’s call it “write” for example.

Next, when you create licenses for your customers, you would create some number of the base licenses.  We will call them “base” for this example.

Finally,  you create a token license that relates a “write” request to “base” licenses.  Typically, this mapping would be generic (ie, the same for all your customers), although you can make the definition customer-specific as well.

You may decide that a v1.0 request for “write” requires 3 v1.0 “base” licenses.  If this is the case, you would use a license line like the following to define the token mapping:


This license tells RLM that when a v1.0 “write” license is requested, it should instead check out 3 licenses of the “base” v1.0 license.

Be sure to also include in the customer’s license file the appropriate number of “base” licenses.  For example, if your customer wants to be able to run 2 copies of “write” at the same time:


In the above example, the customer will consume three “base” licenses for each instance of “write” that they run, up to a concurrent limit of 6 “base” licenses, or two concurrent instances of “write”. Additional products can be defined in terms of “base” licenses as well.

Next time, we will talk about other ways to use Token-Based Licenses.

The Floating License

The Floating License – The most common license model

Last time we discussed the nodelocked and nodelocked counted licenses, which are license grants that allows your software to be used on a particular computer, and on that computer only.  A far more common license is the floating license.  The floating license is what mfloating licenseade license managers famous, and it is supported by all major license managers. A floating license allows a specified number of independent instances of your application to run anywhere on your customer’s network so long as that number does not exceed the predefined limit specified in the license.

The floating license was originally made popular when we developed FLEXlm at GLOBEtrotter Software; in particular, Sun Microsystems’ use of floating licenses for their compilers made most software developers aware of the power of this license model. 

As we discussed in our blog post describing the nodelocked license, having several license models in your price book allows you, as a publisher, to price differently depending on your customer’s situation, which allows you to capture the optimal amount of revenue for a particular customer.  Nodelocked uncounted licenses may be appropriate for some of your products, while floating licenses are more appropriate for others.  A mixture of floating and nodelocked licenses can help maximize revenues depending on your customer’s situation.

If your application is meant to be used collaboratively, you might want to use floating licenses.  If you support both nodelocked and floating licenses, then you can usually charge a price premium for the floating license because its usage terms are less restrictive.  Price premiums can range from as little as few tens of percent to a factor of three or more, depending on the usage profile of the software and how it is shared. In general, it’s best to offer multiple license types because it helps you to expand your account penetration by reaching more users.

To implement floating licenses in RLM, specify a license server with the SERVER line, and set the count field of the license to a positive integer.  The license itself has no associated hostid, meaning that it will run anywhere. The license server (specified by the SERVER and ISV lines) keeps track of the number of instances in use.  A floating license always requires a license server, so it is the next step up in complexity from nodelocked licenses.   Neither RLM-Embedded nor RLM-EZ support floating licenses.

Next time:  token-based licenses.

Licensing Solution – Build or Buy?

Should you Build or Buy a Licensing Solution?

Independent software vendors face the question of whether to build or buy a licensing solution.  Build or Buy a Licensing Solution

At first, you may need only a simple licensing model.  You’ll say, “Hey, we’re a software company.  We’re smart. We know what we need, and my guys can whip this thing up over the weekend.”  OK, if you limit the scope of the development project to only the functionality that you know you need initially, then you could build a passable licensing solution. But that approach ignores future needs. Ultimately, “build or buy” is more a business question than a technical one. Do you want to set out on a course to build and maintain in-house solution as your customers and markets change?

Future-proof your licensing

To paraphrase a popular bumper-sticker – “Change Happens.”  A home-brew license manager must be designed to account for change – not just changes in operating systems and development environments, but also changes in end user preferences for licensing models and deployment platforms. For instance, did you envision the proliferation of tablets ten years ago? Did you predict the increasing use of software in-the-cloud? How about license subscriptions?

Breadth Matters

Widely used software license managers, like RLM, are designed to address a wide set of platforms, languages, vendor licensing policies and end user deployment preferences. The added breadth of a commercial license manager helps you to respond quickly to competitive pricing threats and to address sales opportunities that require “funky” licensing terms – without waiting for your development team to enhance your home-grown software licensing solution to accommodate the necessary changes.


When you design your own license manager, your customers are the sole “guinea pigs.”  They are the only ones who can help you find bugs and improve performance of your licensing software.  By using a third party license manager, you benefit from a huge user community banging away on the licensing software, ensuring maximum reliability across a more varied set of usage conditions.

Who’ll draw the short straw?

If you decide to build your own software license manager, who on your team will write it?  We often see software engineers eagerly take on the challenging task only to discover that it’s not as easy as it looks. Even more common is the dilemma of the “pigeon-holed” engineer who, after completing v1 of the licensing software, desperately wants to move on to a more interesting project.  But instead he is stuck maintaining the licensing system he wrote because he is the only one on staff who knows how it works.  Argh!  I wonder how long he’ll stay at his company?  Who wants to inherit his code knowing that newly introduced changes could cause unintended consequences that could be disastrous to your reputation?

Licensing Experts are truly Rare Birds

The Reprise License Manager (RLM) was designed by experts who have been in the trenches for over two decades. They know what works and what doesn’t forBuildor Buy a licensing solution ISVs and their customers. They are passionate about this technology niche, and take pride in solving difficult licensing challenges with relative ease. If you “buy” rather than “build,” these guys become your in-house licensing experts… who won’t leave you high and dry.

Buzzword Alert!

Core Competencies – Time-to-Market – Opportunity Costs. These well-worn phrases remind us that we should stay focused on what we do well. Your development effort should be directed toward making your innovative products more robust and competitive. Developing your own license manager distracts from that focus – it will slow your progress and will result in longer release cycles causing you to potentially miss some important sales opportunities. When you choose a 3rd party license manager, the time you save could be used to widen your competitive lead and to integrate licensing more tightly into your CRM or Order Management system.

Street Knowledge

You want to support not only standard licensing models, but you also want to leverage your customers’ knowledge of licensed software to minimize their learning curve with yours. End customers are willing to tolerate a few different license managers, but not dozens.  If your license manager is significantly different from others, your prospective customers may reject your solution.


Stay nimble. Stay focused. Choose a software licensing solution provider who knows what works well, and will remain your long term trusted partner.  Don’t be lured by the hope of saving money by writing your own. Today, 3rd party software license managers are affordable for companies of all sizes. In the long run, a third-party solution is the best business choice.

Software Trials without the Internet

Creating Software Trials without the Internet

Most software vendors offer trial copies of their software to potential customers for short-term evaluations.  The trial may run in full or reduced-functionality mode, but only for a short time, 30 days or so.  Sometimes, they want to create software trials without the Internet being available.

Ideally, the evaluation/trial starts when the user is ready, not when he/she first requests the evaluation.  While it’s possible to use an on-line activation system to implement the “start when I’m ready” functionality, that of course requires an Internet connection.

Commonly, vendors use an Internet activation system such as Reprise’s Activation Pro to authorize trials. This works well when the customer has an Internet connection, but what do you do when there is no Internet connection? For instance, what happens if the user is flying at 35,000 feet, or simply has no Internet connection?

RLM offers a capability called “detached demo” to handle this case. Through RLM, your application creates a short-term license that authorizes your product to run for ‘n’ days… without an Internet connection. After the demo period ends, RLM ensures that the user can’t reinstall the demo on the same machine. It allows one demo period only.

The benefits to this approach are clear – when the user is ready to test your software, he gets access for the full n-day period, even when disconnected from the Internet. This experience creates higher customer satisfaction, reducing the common claim: (“I couldn’t find the time to test, can you please send me a new eval key?”) and should result in a increased sales.