As more Independent Software Vendors (ISVs) adopt Reprise License Manager™ (RLM) in increasing numbers, we decided to provide advice on how to optimize the process and ensure a smooth transition from another technology to RLM.
For more predictable revenues, consider a Recurring Revenue License Model.
Software vendors increasingly rely on a recurring revenue license model and other pricing strategies to create steadier revenue streams. These strategies result in smoother and more predictable revenue growth which makes financial planning easier and increases business efficiency, maximizing value to shareholders.
A license manager such as RLM is an essential tool to implement these changes. It enforces license policies that promote higher recurring revenue.
Recurring revenue comes from three main sources:
- Renewable license fees (subscriptions)
- Annual maintenance fees
- Fees based on usage (pay-per-use or consumptive models)
Increasingly, software vendors offer both perpetual licenses and license subscriptions. Subscription licenses are priced so that they provide a lower initial cost in order to attract new customers as well as customers who are trying to preserve short term cash. Subscriptions often seem less risky to customers too. If the product doesn’t live up to expectations, then the customer has only limited financial exposure.
Subscription licenses are renewable licenses, usually annual, including software support and updates during the coverage period. The license is automatically terminated unless it is renewed.
Prices for annual subscriptions are generally some fraction of the perpetual license alternative. Many companies aim for a crossover point of 4 to 5 years after which the costs for the annual license begin to exceed the perpetual license fee plus the annual support costs. So, an annual license might be priced at 40% of a perpetual license.
The License Manager’s Role
Supporting the concept of term licenses are license expiration dates. Days before the license expires, your software can display the number of days remaining. This technique improves customer satisfaction because the user is prepared for the renewal event. When the customer signs up for another term, new licenses specifying the new expiration date can be sent to replace the expiring license.
If you automate license renewal from within your product using an Internet activation solution, such are Reprise’s Activation Pro, the process is seamless.
Software vendors who rely primarily on perpetual licenses can still use licensing techniques to enforce support renewals to generate higher renewal rates. Customers are encouraged to renew their support agreements when license managers restrict access to desirable new releases.
A flexible approach is to specify a “latest release date” in place of the product version number in the license. This date represents the maintenance coverage period. In other words, it specifies the latest future software release date that can be supported by this license. Of course, applications must be programmed to request licenses consistent with the “born on date” of its release.
Pay Per Use Pricing and Post-Use-Billing
Some software vendors offer yet another payment approach – pay per use or post-use billing. What better way to stabilize your revenue stream than to charge based on actual usage?
License managers produce detailed report logs of license activity, recording data such as: product name, number of licenses granted, user name, host name, and duration. With this information, you can periodically produce invoices that reflect your customers actual use. Popular license managers, like RLM, write the log in plain text so that it can examined directly. Also, the log is authenticated to ensure data integrity, and can be “anonymized” to address potential privacy concerns.
License managers that are deployed in the cloud, such as RLMCloud, collect the usage data for easy analysis and invoice generation.
Recurring revenue models:
- encourage steady, predictable revenue flow to the publisher
- lower initial cost for the user, and faster approval cycles
- allow for short-term rentals and faster new feature introduction
- allow license policy to change at renewal time
- Limit license exposure to overuse when machines are decommissioned or upgraded
- let customers expense the budgeted license renewal fees
- lessen price discounting pressure
- Encourage tighter client-vendor relationship because support is bundled.
All other things being equal, companies with recurring revenue pricing are valued higher than companies who rely mostly on perpetual licenses. For these companies, revenue recognition is immediate. It is also easier to weather a bad quarter or flat market. Bundling customer support in the license fee helps to retain customers and boost support renewal rates. Sales compensation can reward new orders at higher rates than renewals, but lower rates than perpetual licenses. Since end customers cannot opt-out of support, customer satisfaction is improved.
If your company plans to shift from perpetual to subscription licensing models, expect lower initial growth rates. But, since new customer acquisition builds revenue incrementally on top of revenue base from renewals from previous years, after an initial period of slower growth, revenues will exceed perpetual-only models.
The mechanics of making the transition work may mean modifying your licensing code at the api level in order to handle automatic renewals. Also, your CRM system may need to be coupled more tightly to make sure that renewal orders and cancellations are reflected into your licensing solution. Remember, SaaS is not required for recurring revenue, the delivery model is irrelevant. You can still sell desktop on-premises applications and gain from recurring revenue licensing models.
Restricting Usage: Nodelocked Licenses
A while ago, we wrote a blog post titled 101 license models, and a followup on unrestricted license models. In this post, we explore the second set of license models described in that post – Nodelocked Licenses. To review, the Nodelocked Licenses we described are:
- computing environment limited
- customer name
- detached demo
- license type (beta, demo, eval)
- software version
- upgrade other licenses
- VM enabled
Because these licenses are locked to a machine or user, they are more restrictive than the previously-described unrestricted license models.
You use nodelocked licenses when you want to restrict how and where your software is used. Since nodelocked licenses do not require a license server, your customer is up and running with a minimum of fuss.
What you can do with Nodelocked Licenses
With nodelocked licenses, you have quite a bit of flexibility – you can:
- allow any user running your software on the nodelocked machine access,
- allow only a single copy of your software to run on the (specified) machine,
- provide an expiration and/or a start date for the license,
- create options so that you have an opportunity to upsell to your customers,
- specify that the license is not usable on a virtual machine,
- include the customer name, for use in a startup screen. This often deters software theft.
Sometimes our customers use user-locked licenses, which are locked to an operating system’s notion of the user name rather than the computer’s hostid. While it is possible to have multiple humans logged in as the same user name, this can be inconvenient for certain applications.
In addition to all these options, you can also upgrade a license to a newer version when a customer stays on maintenance.
We will explore the other main License Model categories in future blog posts.
Unrestricted License Models
A while ago, we wrote a blog post titled 101 license models. In this post, we will explore the first set of license models described in that post – the Unrestricted License Models. To review, the Unrestricted License Models we talked about are these:
- customer name
- license type (beta, demo, eval)
- serial number
- software version
These licenses are not locked to any machine or license server. In other words, they work anywhere. So, given that a customer can use as many of these licenses as they want, why would you ever want to use one of these?
One reason may be that you want to restrict how a license is used, as opposed to how many copies of that license can be used. At Reprise, we license RLM to an ISV, but we do not restrict how many develpers can use the development kit, nor do we restrict how many copies of their application that can be used. We do this by using an unrestricted license model – we lock the RLM license to the ISV’s short name (what we call the ISV name). Once “out in the world”, a customer can only have software from one ISV of a particular name, so multiple companies would not use the same ISV name to license their software. This provides sufficient licensing protection for our software. A customer who has purchased an RLM license would get a permanent license with this ISV name, whereas a demo customer would get an expiring license with an ISV name of “demo”.
Another Reprise product that is licensed in this way is our Activation Pro product. This is a server-based product, and the real value comes from having a single server that activates the licenses for an ISV’s customer, but we allow our ISVs to run multiple copies of this server, primarily so that they can do testing on a second installation.
Similarily, a product could display a customer’s name in a splash-screen. Most legitimate businesses would not want another company using software that was licensed to them by name.
Frequently, our customers use user-locked licenses, which are locked to an operating system’s notion of the user name. While it is possible to have multiple humans logged in as the same user name, this becomes inconvenient.
Also, ISVs might license their main program using floating or node-locked lienses, while some ancillary program or utility uses one of these unrestricted license models so that there is some amount of control, but provides convenience to their customers.
We will explore the other main License Model categories in future blog posts.
When customers install licensed software, a question that often comes up is "when do I need a license server?" In this blog post, we talk about the various jobs a license server performs, and when it is needed to support different license types.
Daniel Steven Birns, Jan 18, 1954 – July 28, 2016
Some of you may know Daniel as “the FLEXlm support guy”. Others may know him as the lead FLEXlm developer. Many more (outside of GLOBEtrotter and Reprise) know him as an extremely talented musician, one who never seemed to find an instrument that he couldn’t master quickly.
We knew him as a dedicated, enthusiastic co-worker, a good friend, and a dedicated husband and dad.
I first met Daniel in 1993, when we were porting FLEXlm to the 88k processor. Daniel worked for 88open, the industry consortium, and when I contacted them for help with the port, he said “I’ll just come over and help you”. Well, he did, we went to lunch, and during lunch I realized that I needed to hire him to support FLEXlm.
Within 3 weeks of Daniel’s arrival, it was clear that it was a waste to have him only supporting the product, so I made him the lead developer, and the 2 of us continued to support FLEXlm. Daniel remained the lead developer from 1993 until 2000. During this time we had many, many good-natured knock-down, drag-out fights over the direction of the product, but the result in every case was an improved product. When we sold GLOBEtrotter to Macrovision in 2000, Daniel remained lead developer for a year or two, at which point, he left to spend more time with his music.
While Daniel never worked at Reprise, we always stayed in touch and of course, many of us saw him at several of the GLOBEtrotter reunions.
Daniel, we’ll always love you and miss you, and we hope you are in a better place.
Advanced Use of Token-Based Licenses
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:
LICENSE SOFTWARE_CO write 1.0 PERMANENT TOKEN SIG=XXXX TOKEN=”<office 1.0 1>”
LICENSE SOFTWARE_CO calc 1.0 PERMANENT TOKEN SIG=XXXX TOKEN=”<office 1.0 1>”
LICENSE SOFTWARE_CO present 1.0 PERMANENT TOKEN SIG=XXXX TOKEN=”<office 1.0 1>”
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:
LICENSE SOFTWARE_CO office 1.0 PERMANENT 6 SIG=XXXX share=uh
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:
LICENSE SOFTWARE_CO write 1.0 PERMANENT TOKEN SIG=XXXX TOKEN=”<writerPro 1.0 1>”
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.
Software License Management and The Dongle.
Dongles have had a long and checkered past when used for Software Copy Protection and Software License Management. In the 1980’s and 1990’s ISVs selling high-value desktop and/or workstation class software to scientific and engineering customers needed to “lock” their software so that it can’t be shared with others. If even a single unlicensed copy is used, a serious revenue hit would result. What to do?
Dongles provide serial number to lock licenses
Along came the dongle. Well, it wasn’t originally called a dongle. It was a “hardware key” or “security key” or “security block”, and many other names including product names like hasp. In any case, the dongle, as it is now commonly known, was a solution to the software locking problem. It was a primitive physical device consisting of some simple electronics that, when queried through software, returned a factory-preset serial number to which a software product could be tied. This was a boon to software developers who at the time were experimenting with using, of all things, floppy disks as keys.
Weaknesses soon found
But, as soon as the use of dongles became more widespread, inherent problems surfaced. Early dongles used parallel printer ports of the PC (remember those?). Dongles were designed to allow printers to connect pass-thru style, but since these ports often had non-standard electrical characteristics including power differences, dongles sometimes failed in the field.
Failed dongle == failed software. Not good. So, ISVs kept FedEx and UPS busy, sending overnight dongle replacements – the cost of the overnight trip exceeded the cost of the dongle. Other problems surfaced too: dongles were lost or stolen, users failed to install updated software drivers to keep up with OS revisions, the dreaded dongle-snake appeared (so many dongles chained together that they literally fell off the PC), etc.
Along comes PC networking
But the biggest factor in the dongle’s demise was the arrival of PC networking. Once networks became popular, software could be tied to the hardware address of the ethernet communication card. Licenses began to be shared over the network as software license managers (like RLM) exploited the power of interconnected users to allow even casual users access to valuable software licenses.
Dongles still solve license mobility problem
So, dongles waned in popularity as a general solution for licensing software, but they found a new use – to lock the license manager’s license server to a computer. Dongles allow the license server to be moved by the end-user without involvement from the software publisher. Also, today, dongles are much cheaper, more reliable and are usually connect via USB ports – making them easy to attach to a modern PC.
Today’s floating license management and dongles
Floating licensing provides a mechanism for licenses to be shared among networked users. The whole license pool can be locked to a single server using either the server’s host ID or a dongle acting as a proxy for the server’s ID. In this way the license manager encodes the dongle’s serial number as part of the pool of licenses
Supporting Virtual Machines
In addition to the mobility advantages of dongles, virtual machine software dedicates the USB port to a single VM instance, so using a dongle is a good way to lock a license server to an instance of a virtual machine, without worring about the license server being replicated across the network.
Dongles are still an important part of a complete software license management strategy, and will likely remain so for some time.