There are a few basic guidelines that should be followed when integrating licensing into you software application. Adherence to these guidelines, while not strictly mandatory, will be greatly appreciated by your end-users who will see more consistent implementations from ISV to ISV.
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 are pretty good at writing software, so when the time comes to consider adding a license manager to their software some ISVs feel it best that they just write the license manager part themselves and be done with it. Here are six things to consider before you build your own license manager.
Independent software vendors who see the need for a software license manager face the universal question of whether to build or buy. Here are a few things to consider before making your decision.
Software License Adoption
How Do I Get my Company on Board?
You’ve tried to introduce the concept of software licensing into your company. But, you’re not sure of the best way to move the process forward. Here are some tips to get you to the finish line.
It All Starts at The Top
We have assisted many companies in making the transition from “trust-based” to “trust, but verify” with a license manager. To us, the key ingredient in a successful license management project starts at the top: You need executive—hopefully, Chief Executive—support and sponsorship to gain the benefits available from licensing. Since the decision to adopt license management touches so many parts of your organization, you’ll need to make sure it’s clear to others in your company that a licensing program helps increase revenue and provides visibility at the highest levels of your company.
Identify Your Go-To Person
As important as it is to have executive-level support for your licensing program, it’s equally important to have a single focal point from your organization to be the “go-to” person for licensing. Ideally this person is well-known and respected throughout the organization and has good knowledge of the functional groups that will be impacted by licensing and how they will respond. While neither an MBA nor a Computer Science degree are necessary, being able to both “walk the walk” as well as “talk the talk” are important to lending credibility to your licensing program.
Show Me the Money
The focus for the licensing program should be revenue- and profit-driven (hence the need for an executive-level sponsor). To implement licensing, your company will make an investment in man-hours. To get a return on this investment, there needs to be a payback for this in terms of increased revenue and profitability.
What’s In It For The Customer?
While more money is always a good thing, this shouldn’t come at the expense of customer/end-user goodwill. Remember, software licensing is all about keeping “honest users honest” and giving them an easy-to-use tool to help ensure compliance with the terms and conditions of your existing paper or clickwrap license agreements, as well as to easily acquire more licenses. Taking an overly negative attitude towards customers and end users with your licensing program will be immediately obvious to them and will negate benefits from increased license compliance. Talk to trusted users of your products, or co-workers most in touch with your users (support, sales, etc.) and do a “sanity check” with them on your proposed licensing policies. While no licensing system will make everyone completely happy, on balance, both revenue and customer satisfaction should go up with a well-done licensing program.
Where Do I Start?
First, reconcile your current licensing policies, agreements, and existing infrastructure (if any) with what your marketing and sales teams tell you would be most desirable. If you currently provide permanent licenses, and see that customers are asking about annual subscription licenses, that’s a good place to start. What about adding floating licensing to your existing per-CPU model? Per user? Time zone based? Put time into market research, both internal and external, to figure out where you want to go license policy-wise.
Who’s Gonna Do All This Work?
After applying great business policies via licensing, you’ll need some resources. Now’s a great time, if you haven’t done so already, to go back to that executive sponsor with a briefing on what may be possible with software licensing. Do a quick back of the envelope calculation about impacts on revenue and profitability. Be realistic; there may be a short term negative impact to get infrastructure set up, employees trained, and the product and documentation updated. However, there should be an obvious payback in the one-to-three year timeframe.
Deliver your sales pitch: Will your executive sponsor approve the internal resources to implement the programs required to create your dream software license management program; a plan that will ultimately increase revenue and profitability?
Armed with the right team, it’s time to nail down a ship date for your product(s) that will have the new licensing implementation. It’s quite likely that there’s a new release or two already being sketched out on someone’s whiteboard in the company. Request a data change (or set a new one in the future) to accommodate your licensing program. Get support from your executive sponsor if you get push back. On the software engineering side, you’ll probably need a day or so to integrate and test the licensing libraries, change the install routine, and document everything.
If at First You Don’t Succeed…
You may have some complications in your first rollout of a product with licensing. Hopefully, this will be seen as part of the normal process with software. But, it wouldn’t hurt to try to foresee all possible problems as part of getting ready to roll out licensing. Be sure to have a contingency plan for what happens when a customer is frustrated with getting your software up and running under license management. It may be worth it in the long-run to provide that customer with a temporary “everything works” license to get them over the hump and up and running with licensing. Have dedicated support and on call engineering resources in place when that all-important roll out date arrives. It’s safe to say that you’d be better off having the resources but not needing them due to your brilliant foresight and your thoughtful mitigation of all possible licensing-related problems.
Now That You’re Over the Hump
It’s time to brief your executive sponsor on the effects of the rollout of your software licensing program. They were instrumental in getting the program going and they should be able to share the glory of the success of getting licensed products out the door. As part of your rollout plan, put a stake in the ground 30, 60 or 90 days after release to come up with some simple performance metrics.
Have support calls gone up or down? What above revenues? If you time your first licensing release to coincide with the beginning or ending of a fiscal quarter, you may be able to get more bang for your licensing buck.
Make performance stats available as soon as you can and be sure to publish them inside your company. Even if the numbers aren’t all wonderful, give everyone the story, including plans for future releases with licensing, new licensing models in the queue, etc.
Making Licensing Part of The Culture
Hopefully, your results will be paid back in the short or medium term. Ideally your company is making more profitable use of the employees and infrastructure devoted to software creation and both customers/users and employees are happy with the decision to go to software licensing. If so, great; to the extent you can, keep doing what you have to push software licensing into more products in your company. Some traditional hardware companies now treat their physical products as platforms for enabling what their customer gets via a software license.
We hope you have found this article useful in your quest to adopt software licensing. If you have any questions, please don’t hesitate to contact us.
In this article we attempt to provide a framework for how well-behaved applications use software licensing. Adherence to these guidelines will be greatly appreciated by your end-users who will see more consistent implementations. It is important to consider your end user and long-term support implications when designing your licensing implementation.
Do You Really Need a License Manager? Or can you use an Activation Server as a License Manager?
In certain circumstances, you could use an Activation Server as a license manager.
This would be the case for very simple, straightforward node-locked licensing. For example, an app that runs on a phone or a tablet (or a simple application that runs on the desktop). Instead of integrating a license manager, you add a call to activate the license, and the activation server performs the initial activation on the first request, and verifies that the license is activated on subsequent requests.
- You avoid the cost of a license manager.
- The code is easier to integrate
- The software footprint in your code is smaller
- Your application must contact the activation server on every invocation.
- The licensing models supported are quite simple – nodelocked, uncounted only
How would this work?
Let’s put aside the issue of how the activation keys are created in the first place. There are a variety of ways this is accomplished, depending on your business rules.
When your application runs, you do the following:
- determine some unique charactistic of the device or computer. If it is a phone, this might be as simple as the phone number or the device’s ethernet MAC address.
- your software presents the activation key and the device id to the activation server and receive the status:
- Not Activated previously -> the server records the device ID, and returns a success status.
- Activated previously from this device -> the server returns a success status.
- If the key was activated from another device, the status would be “key already used”.
It’s really as simple as that. There is a single web services call to perform the initial activation and checks status later.
A while ago, we wrote a blog post entitled 101 license models. Since that time we followed up with posts on unrestricted license models, nodelocked license models, floating license models, and token-based license models. In this post, we explore the fifth set of license models described in that post – the Metered License Models.
Metered License Models
To review, a metered license model allow you to consume a resource when your program runs. Your customer can perform an action “N” times, or for a fixed amount of time. These licenses are usable by anyone who can contact the license server. Metered licenses can have any of the following attributes:
- computing environment limited
- customer name
- license type (beta, demo, eval)
- replace other licenses
- soft limit
- shared by arbitrary data
- shared by host
- shared by user
- software version
- timeout restrictions
- VM enabled
Ways to use Metered License Models
Metered licenses have 3 main uses:
- counting the number of invocations of a product
- keeping track of how long a product runs, or
- counting events within a product (e.g. pages printed, database lookups, etc).
In the first case, the license server decrements the meter each time the product checks out a license. For keeping track of how long a product runs, the server performs a decrement to the meter at a specified interval. Finally, for counting events, your software would perform a checkout request when the event happens.
A metered license model gives you control over the software which isn’t available with nodelocked or floating licenses. Metered License Models provide true consumptive licensing.
A while ago, we wrote a blog post entitled 101 license models. Since that time we followed up with posts on unrestricted license models, nodelocked license models, and floating license models. In this post, we explore the fourth set of license models described in that post – the Token-Based License Models.
Token-Based License Models
To review, token-based licenses are a special case of floating licenses which allow aliasing of a license or multiple license checkouts per request. These are usable by anyone who can contact the license server. Token-based licenses can have any of the following attributes:
- Aliasing of license name
- cached licenses
- computing environment limited
- customer name
- license type (beta, demo, eval)
- minimum use time
- replace other licenses
- soft limit
- shared by arbitrary data
- shared by host
- shared by user
- software version
- timeout restrictions
- token-based package
- VM enabled
Ways to use Token-Based License Models
Token-based licenses are a special case of floating licenses, and they have 3 main uses:
- packaging together a number of products and distributing a single license
- creating an alias from one product name to another
- allowing newer software to run and consume licenses distributed with older software (a special case of #1)
In the first case, packaging together a number of products, let’s say you have product a, b, and c. Create static token-based licenses for each of a, b, and c which map to a checkout of “d”. Now you distribute the “d” license, and all 3 products, a, b, and c can run with this license. Different modes of operation are possible by changing the sharing attributes on the “d” license.
To create an alias, the token definition maps one license checkout request to a different request. This is useful to transition a product’s license name.
For the 3rd case, a generic token name is the only license you deliver. All products have token license definitions which map to the generic license name. As you add new products, they use licenses which your customer already has, thus creating contention for these licenses (meaning increased sales). This allows your customers to demo your new products while consuming existing licenses – no more free demos!
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.
Don’t paint yourself into the corner – use Policy in the License.
When you think about adding licensing to your software, you want the licensing software to “do the work” of licensing. You don’t want to write special code to handle the various business cases for your licenses. When you put the policy in the license, you remove it from the application code. This makes changes down the road much easier.
RLM allows you to request a license within an application without knowing what kind of policies are present beforehand. You need to do little to no manipulation of the licensing routines themselves.
With RLM, license policy is in the license keys, where it belongs. We call this “Policy in the License”. So when your application requests a license, the license is granted is based on what licenses are found in the customer’s license pool. This allows you to address ever-changing business rules by varying the type of license keys that you issue.
Keeping Pandora’s Box Closed
Legacy license managers open a Pandora’s Box by allowing applications to store arbitrary information in the license key. This is a mistake because it requires special programming in your application to retrieve, decode and process the data. Your application then needs the logic necessary to implement the custom policy which the data specified. More importantly, this unfortunate design decision leads to the proliferation of incomprehensible license strings. Unpredictable license behavior across applications and across ISVs is the result. RLM supports new policies by enriching the syntax of the license to address new yet generally useful license policy options. Here are a couple of examples of Policy in the License:
RLM has a simple yet elegant way to define one RLM license in terms of another. It is used in two common ways.
First, it can enable “token-based” pricing models where each of your products checks out a license for itself which results in license tokens checked out from a common pool. Each product checks out a number of tokens equal to its relative value. Any number and combination of products can be used so long as the maximum number of tokens in the pool is not exceeded.
This model works especially well for companies that sell suites of related products that are used to various degrees during a project. As the project advances from one phase to another (Design, Test and Simulate), the mix of products used reflects the demands of that phase of the project. So you don’t sell a certain number of seats of each product. Instead, the user determines the mix based on his needs.
This model also allows you to introduce new products to your customers easily since the new products consume the same licenses (tokens) that are already installed.
The other main use of token-licensing is 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. If a component license is unavailable, then a higher priced bundle license, if available, can be checked out to satisfy the request as a last resort.
A token-based strategy can also address overdraft situations. In this case, when all the regular licenses are in use, overdraft licenses are consumed instead. If required, the overdraft licenses can have shorter term expiration dates so that they can be used only during a predetermined time window. And overdraft licenses are reported separately in the report log, so they are accounted for appropriately.
No changes to your application are needed to support token-based licensing – “the policy is in the license.”
WAN Licenses – use time zones to increase pricing options
Your biggest customers usually connect their geographically dispersed sites via a WAN. When they do that, they can share your floating licenses across the globe. For a variety of reasons you may want your licenses used only within a particular geographical area. With RLM, you can assign a “timezone” to the license to allow use of your software only in those zones. You could charge a higher fee for licenses that cover a wider geographical range, and less for restricted licenses.
Again, no changes to your application are needed to support WAN licensing when you use “policy in the license.”