Too often folks equate Software Licensing with the prevention of software piracy. That notion really misses the point. People are often surprised to find out the real reasons for software license management.

As license management technology has evolved, so has Internet-based networking and the ability to locate various clients and servers at physically distant locations. But are “distant” and “remote” always best for a software vendor’s customers?

Let’s look at some of the thinking that could go into the decision on how and where to locate license servers, and what that means for a software vendor’s choice of license management technology.

First off, it’s best to look at the question of server location in the context of a specific type of end user. Clearly, not all software is best managed with license servers, either local or across a WAN or the Internet from its intended users.

Software that is best deployed with license servers is typically low-volume and high-dollar-value software, such as is used in various engineering fields (mechanical CAD/CAM, chip design or “EDA”, oil and gas exploration, video production, etc.) So, it goes without saying that the nature of these software products, and their value to the organizations buying licenses for them, demands near-instantaneous, secure availability of those licenses, as well as the ability to easily report on their usage. In fact, this model is where the term “software asset management” is derived: non-tangible yet hugely valuable software licenses that are treated by end user organizations just like any other important, valuable physical asset.

Given that high-value software licenses must be always available, secure and reportable, where should the servers hosting those licenses be sited? On the end user’s Intranet? Across a WAN? Across the Internet?

At Reprise, our experience going back over 20 years leads us to think that the physically closer you can site license servers to their intended users, the better. Also, the fewer network devices you can put between the user and their license(s), the better. While it can be argued that networking has only gotten better over the years, with more capable routers, higher-speed connections and better system and network management, as of yet no one has figured out how to remove Mr. Murphy, of Murphy’s Law fame. And the last thing your poor, harried user needs is Murphy messing with license servers at the eleventh hour of a big project, when that important software license had better be available.

Besides availability, control is obviously important in deploying license servers. Large enterprise organizations dedicate individuals or even teams to keeping software licenses watered, well-fed and ready for their users. Inherent in that is the capability to tweak individual vendor servers, or the main server itself, so that license reservations for groups or projects and reporting are all set up to maximize the users’ benefit. So while moving all of this infrastructure across the Internet may seem appealing to the software vendor, be sure to ask your users what they would think of this. Would your users still have routine administrative access to stats about server and license availability? What happens when Port 80 is saturated when the next “gotta watch” video is posted?

While there’s a trade-off between configuring firewalls to handle non-Port 80 traffic and the immediate availability of Port 80, it’s our observation that most end user organizations want to dedicate ports and server hardware to serving valuable licenses, so that their users can get them when they need them. And now, with the concept of license “refreshing” and re-hosting, a good hybrid deployment model is available to end users of license managed software. Imagine–having the flexibility to easily move licenses from one server to another with the good availability of licenses served from a machine directly under the end user’s control. What could be better!

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

The “How To”

To deploy a named_user licensing model, the ISV 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 a 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
or
named_user=n – to require a maximum of n users to be named
or
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 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.

Many independent software vendors (ISVs) who sell their products as complete applications also sell them as re-linkable libraries. Licensing the applications is pretty straightforward, but what about the libraries? How do ISVs tackle licensing of libraries?

In these tough economic times it is critical to have the flexibility to address complex licensing policies quickly and easily. In a previous article RLM’s ‘Policy is in the License’ methodology was discussed, explaining how the RLM license policy is largely removed from your application. Since the license policy is defined in the license keys, a single binary can support many license policies.. Once RLM is implemented, you can address ever-changing business rules by simply varying the type of keys that you issue. RLM can support a wide range of licensing options and policies. Many of these policies have been covered in previous articles and are summarized here (with link to original article):

Trial and Evaluation Licenses are implemented using a license with an expiration date, and possibly a “demo” flag, to make your product accessible to would-be buyers. Since eval/demo/trial licenses can also be easily turned into full, “purchased” licenses, a trial version of your product is the logical first step in a successful sales process. Well-designed eval/demo/trial licensing programs will reduce your cost of sales, increase customer satisfaction and productivity, all while expanding your reach into wider geographies and attracting new types of users.

Floating and Node Locked Licenses can be implemented as needed and depend largely on how your software is intended to be used, shared or unshared. Floating licenses are free to “float” across the network to users who need them. The license manager controls access to these floating licenses via a central server that enforces the maximum license count that you have set for this site. Node-locked licenses, on the other hand, are usually uncounted, allowing an unlimited number of copies to run on a specified host.

NAMED_USER, or USER_BASED Licenses are a class of floating licenses that must be assigned to user names so that they cannot be used as widely as unrestricted floating licenses. With a named_user license, the license server can construct the list of users automatically as license checkouts occur, or the list can be entered/modified via the RLM web interface by the end-user administrator. Gives you more pricing depth.

Token Based Licenses are among the more-advanced features that provide a license model to your customers to enable license alternates. This is the case where you sell a single product that consists of many separately licensable components (product and sub-product model). If you sell product bundles at a special discounted price, then customers can purchase a combination of both the bundles and the components of the bundles in order to match their requirements. Token based licensing allows you to define product rights in terms of relative value between your products, or allow a user to consume a mix of your products up to a pre-determined level of value. This model also allows you to introduce new products into your customers easily since the new products consume the same licenses (tokens) that are already installed.

WAN/Time Zone Licenses use time zones in the license file to increase your pricing options. Your biggest customers usually connect their geographically dispersed sites via a WAN. When they do that, they can potentially share your floating licenses across the globe. For a variety of reasons you may want your licenses to be used only within a particular time zone.

Subscription based Licenses are supported using the start and expiration dates in the license file. Subscription licenses are priced so that they provide a lower initial cost in order to attract both new customers and those customers who are trying to preserve short term cash.

Version based Licenses can be implemented to support versioning control by either version number or version release date. License requests beyond the version number or release date would be denied, presenting an opportunity to remind the customer that access to that version requires a new license obtained only via a support contract extension, again providing an avenue for maximizing ongoing revenue.

Licensing on Virtual Machines is supported in RLM via a parameter in the license itself that controls whether it will or will not run under VM. Vendors can deliver both kinds of licenses to their customers – disabled and enabled – allowing them to, for example, issue short-term VM-capable licenses for testing and evaluation purposes, but disabling other licenses for long-term production deployment, or allow certain customers, but not all, to run their licenses on VMs.

The remainder of this article will briefly discuss a few other optional license fields. The following license keywords can be classified as ‘vendor defined’ options as they are not used by RLM to determine policy, but can be accessed by your application to further restrict usage rights or present information to the end-user:

License Options field specification is used to encode options for the product. Do you have the need to restrict information access or usage within you application? Do you want to limit the number of database records that can be created or accessed, the number of accounts that can be open, the number of portals that can be accessed, etc.? This information can be entered into the ‘Options’ field and extracted by your application to further limit or define the applications internal processes.

Contract field can be used to hold the customer’s purchase information or software agreement number. This can be displayed to the end-user to validate a support contract, etc.

Issuer field would be used to identify the organization which issued the license, such as a third party distributor etc.

Customer field can be used to identify the customer of the software and can be displayed by your application to the end-user. This can be an added incentive to keep honest users honest. It is unlikely that Mega South-East Airlines would want to use a license that was issued to Main St. Bank.

Even though it is wise when starting out to keep the implementation relatively simple, it is very important to have options to address the changes due to market pressure, economic stress or customer feedback. RLM’s licensing methodology gives you the flexibility to address the ever-changing business rules. Reprise Software’s experts can help you plan your optimal approach. Please feel free to contact us to discuss.

Consider your end user and long term support implications when designing your licensing implementation

In this article we attempt to provide a framework for how well-behaved applications use RLM. Adherence to these guidelines will be greatly appreciated by your end-users who will see more consistent implementations across their RLM ISVs. This will also translate into support savings for you, as applications from different RLM ISVs will behave in a more consistent fashion.

How do I harness the power of the license manager? What rights should I give to my customers? Let's first look at basic elements of a license that you can control, then look later at some other important parameters that can further refine your licensing policies.

Since software license keys contain entitlement information, it makes sense to protect those data from tampering and corruption. It would be tempting for an unscrupulous user to change a license count from 10 to 100 by simply tacking on an extra zero, or to upgrade your v2.0 licenses to v5.0 with a similarly simple edit.

Independent software companies are increasingly relying on innovative software licensing and pricing strategies to create steadier revenue streams. They are looking for smoother and more predictable revenue growth to make financial planning easier and to increase business efficiency and to maximize value to shareholders.

An important but easily overlooked aspect of a software license management system should be its support for and use of multiple license servers. The customers of software applications typically have more than one server machine on which to deploy license servers.

Archives

Subscribe

About Reprise

Reprise Software is a premium provider of license management software with an extensive and growing set of customers in more than 20 countries. Our flagship product, RLM, protects the revenue streams of hundreds of ISVs and yields the maximum use of licensed software for thousands of end users. We continually enhance RLM along our fundamental principles of flexibility, simplicity, power and value. www.reprisesoftware.com