From For Publishers

Various topics pertaining to the technology of license management, both internal to license managers and the use of license managers in software products.

Virtual License Pools

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.

Read more

Licensing and Pricing Strategies for “Short Duration” Applications

Many valuable software tools that require floating licensing run for only a short time. These include various solvers, development and design tools, and other specialty software products that are designed to perform very specific tasks very quickly. Unlike typical interactive or desktop applications, these short-burst applications typically do not have a GUI of there own, but are often launched by other applications within a product suite.

Read more

Software “Test Drives” – Best Licensing Practices

Of the many advantages to using a license manager, the easy creation of eval/trial/demo versions of your packaged software is arguably one of the most powerful. Using an electronic license with an expiration date, and possibly a "demo" flag, makes your product accessible to would-be buyers. Since electronic 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.

Read more

License Portability

Not for Everybody, but Dongles Provide License Portability

The overall reputation of dongles "took it on the chin" in past decades. Dongles were perceived to be inconvenient, clumsy, unreliable and expensive. Not so fast! The dongle is seeing a rebirth. Late model USB dongles are both reliable and inexpensive. Through it all, dongles remain extremely popular in some market segments including applications that are deployed in laboratory, testing, and remote "in the field" locations.

Read more

Licensing on Virtual Machines

Virtual Machine (VM) software has been a major factor in increasing computer utilization and efficiency. VM software allows users to segment a computer into multiple "virtual" systems, each with its own copy of an operating system each acting fully independently from the others. For software vendors, this "machine replication" can be a problem, one that can make profits become "virtual" too.

Read more

The Right Hostid

Finding the Optimum Balance between Security and Convenience

Ensuring License Compliance
Generally speaking, independent software vendors (ISVs) want their customers to have access to all the licenses that they buy, but not more.  One of the ways that ISVs ensure that customers do not exceed their allotment of licenses is to place checks within their applications to limit how many and where licenses can be used. Most ISVs use a license manager (like RLM) to perform these checks for both stand-alone and floating licenses. But ISVs are also careful to select a license model that minimizes inconvenience for themselves and their paying customers.

What is a hostid and why do I need one?
A software license manager uses the term hostid to refer to a unique identifier for a specific computer. The hostid is used by licensing software to “lock” a license (or pool of licenses, in the multi-user case) to a machine so that they can be used on only that computer.  The hostid is a parameter used to generate the license key’s security signature, thereby rendering the license unusable if it is moved or its hostid is modified.

The Security v. Convenience Continuum
The decision on which hostid to use is usually based on trade-offs made along the security vs. convenience continuum. While this may not be immediately obvious, there are always trade-offs between making something (software, a car, a building) more secure vs. less convenient to access. Should it allow access through a turnstile or a vault? ISVs should choose security-convenience policies that are in line with their beliefs and business models. Luckily, computers have many different elements that can be used as a hostid, so there is probably a hostid to match virtually any ISV’s policy goals. However, no single hostid type will satisfy every ISV, so let’s consider your hostid choices and examine the potential pros and cons of each one.

What are the issues?
The most important questions are:

  • is it a standard part of every machine (which is another way of asking “is it convenient”)
  • is it secure enough, and
  • what does it cost.

Convenience…
As much as possible, you want the hostid to be native to the machine. In other words, you want it to be ubiquitous and its contents to be easily obtained via a standard system command. In this way, you avoid the delays, expense and potential confusion of having to send special software or extra hardware to the customer prior to the sale of your products – everything is already there.  Your customer can get your software up and running as quickly as possible.

… v. Security
For maximum security, you want the hostid to be difficult to modify, or at least non-trivial to modify. Most ISVs who use software license managers want to use the most secure hostid possible, but with an eye toward convenience (ie., customer satisfaction) and cost control, at the same time.

Once upon a time…
From a software licensing point of view, an ideal hostid choice would be a standard unique serial number burned into every CPU.  This was tried by Intel in the late 1990s but the idea failed, not on technical grounds, but primarily on the basis of concerns over privacy.  The fear was that software could be used to track users’ behavior and identity to a specific computer as they surfed the web.

What are my Hostid Choices?

NIC Addresses
The most common hostid choice is the Network Interface Card (NIC) Ethernet media access control layer (MAC) address.  It is built into every modern workstation and server and can be easily queried through software. Although on some systems the NIC address can be re-programmed, creating the potential for the same license to work on multiple machines, connecting these machines on the same local area network will cause networking problems. So, although there are some security issues with NICs, they remain a good hostid choice.

IP Addresses
IP addresses, or IP address ranges, are of little use as hostids from the software vendor’s perspective.  Most users do not have fixed IP addresses, so they tend to be too transitory to rely on as hostids.  However, IP address ranges are convenient for end users to use to allocate pools of licenses to specific sub-nets.

Disk Volume Serial Numbers
Like the NIC above, disk volume serial numbers are commonly used as hostids (Windows only).  They are convenient, but do suffer from being easily modifiable, making them less than ideal from a security point of view.

Names as hostids?
What if you weren’t so concerned about security?  What if you wanted your licenses to be valid no matter where your user installed the software? This is a pretty common vendor policy. In this case, it might make sense to use the customer’s username as the hostid.  It’s also possible to use the hostname of the system as the hostid, giving the customer the flexibility to move the software to new hardware without getting a new license – as long as he resets the new machine’s hostname to match.

Hostid Lists
There are cases where you want to allow a license to run on any machine in a list. For instance, if a workstation has multiple NIC addresses, you could license to them all, and as long as one of them was found in the list, the license would be valid.

The Irrepressible Dongle
Dongles, small serialized USB devices, remain a good hostid choice for high-value software where security is paramount. Dongles allow your users to move the software from machine to machine by simply moving the dongle.  The downside to dongles, however is that they add cost, must be shipped, can fail in the field, and they can be lost or stolen.

Hardware Serial Numbers
If you sell software on a specialized hardware device that has its own unique serial number, then the obvious choice is to use that number as your hostid.  For you, this situation is probably ideal because the serial number is always there and it is secure.  Be sure to verify that the licensing technology you use can support a unique or non-standard hostid mechanism.  Some licensing vendors provide ISV-specific callback routines to support just this situation.

Serial Numbers
If your goal is to simply “tag” your licenses, then you can serialize them so that you can identify the customer to whom they were originally sold. This is useful as a marker to track the original customer without tying the license to a physical host.

Custom Composite Hostids
By combining multiple machine identifiers, you can build a composite hostid where ALL of the identifiers need to match in order for the licenses to remain valid.  This is a very strict approach leading potentially to numerous re-licensing operations whenever a relevant machine element is changed.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

The Hidden Costs of “Rolling Your Own” License Manager

If this title intrigued you at all, chances are you work for a company that sells software it creates, what many call an Independent Software Vendor (ISV).  Most ISVs feel, rightly so, that they’re pretty good at writing software.  And when the time comes to consider adding a license manager to their software (see last month’s newsletter article) some ISVs feel it best that they just write the license manager part themselves, and be done with it.

Let us suggest why that may not be the best course of action for most ISVs.

Core Competency:
First, let’s look at the role of software development staff at an ISV.  Their job is to create the products that their customers want to buy.  Easy enough.  But at what point does the ISV decide to use a third party product for some type of functionality?  Well, only they can answer that, but here’s a suggestion: if the need for something new in your product goes beyond your engineers’ area of expertise, it probably makes sense to use a third party product for that cool widget, or license manager, or whatever you’re looking to add.  Otherwise, your engineers will be distracted from what they do best–be it CAD, Oil/Gas exploration, animation, etc.  Do you want some of your staff learning a new area of expertise when a valid third party market for that functionality already exists?

What’s the True Cost?
Obviously, a third party license manager has costs associated with it, both up front and/or ongoing.  But clearly, an ISV writing its own license manager must balance those costs against the true costs of “rolling their own.”

The biggest portion of the true cost to an ISV of writing their own license manager is opportunity cost.  As we point out above, an ISV’s developers are probably better at what they were hired for, likely some fairly narrow technical area relating to the ISVs core business, not license management.WWTD – What would Tiger do?
Does it make sense to pull an engineer off a core project and assign them to write the license manager?  Does Tiger Woods spend time mowing golf courses?  Sure, he probably knows exactly what to do, given that he knows a thing or two about a properly maintained fairway.  But he’s probably better off improving his game by practicing and playing.

Similarly, an ISV needs to be able to respond when new product features are demanded by its customers.  In this day and age, where “Internet time” is measured in days and weeks, ISVs can’t be distracted from their primary business.

More Hidden Costs
As if the above issues aren’t enough, ISVs also need to be concerned that end users may want a license manager that’s familiar, not Yet Another License Manager.  They may not tell their sales rep the true reason, but not being comfortable setting up a proprietary license manager could certainly make a would-be customer less enthusiastic.  And how well has that home-grown license manager been tested in the field?  Besides soliciting feedback on the features in that next Beta release, better add requests for feedback on the license manager.  Wouldn’t it make sense to use a license manager that’s already field-tested?

Not a One-Time Requirement
So let’s pretend an ISV does go out and write their own license manager.  What about when a big customer requests support for that new 64-bit platform?  Does the ISV take more internal resources to port (and test, and debug…) the home-grown license manager on the Latest, Greatest 64-bit platform?  Surely this is an on-going extra cost.  Same with costs the ISV would bear to have its developer update the home-grown license manager with new licensing features and license models.  Wouldn’t a third party just add new features and models as part of its product evolution?

The Truth Is…
We talk to ISVs all the time who’ve thrown in the towel and want to use a third party license manager.  They see the benefits of a competent third party.  They like understanding the cost structure and would rather “buy” than “build” a license manager for all the reasons above.

How about you?  Contact Reprise to discuss the benefits of using a third party license manager, or if you’d just like to start your evaluation of RLM.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website