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

Policy in the License

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:

Token-Based Licenses

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.

Overdraft licenses

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

101 License Models – Floating License Models

A while ago, we wrote a blog post entitled 101 license models.  Since that time we followed up with posts on unrestricted license models and nodelocked license models.  In this post, we will explore the third set of license models described in that post – the Floating License Models.

The Floating License Models

To review, floating licenses are the most commonly used license models.  These licenses can be used by anyone who can contact the license server.  The floating license models provide the richest set of license control. The floating license models we talked about are these:

Ways to use floating license models

Floating licenses are not generally locked to any machine – although they can be. They are served by a license server which is itself locked to the host where it runs.  In other words, in general floating licenses work anywhere, but only up to the maximum concurrent license count imposed by the server.  Floating licenses are the most popular licenses used by software publishers since they allow the maximum flexibility in pricing as well as day-to-day usage by end-customers.

The traditional, or “plain vanilla” floating licenses are by far the most popular of all.  They allow a software publisher to sell more valuable licenses (often at a higher price) as compared to node-locked licenses.  For the customer, the added flexibility to use a license on any client on their network provides significant extra utility and value, when compared to licenses node-locked to each client.

The other models listed are generally variants of the traditional floating license.  By adding these attributes to the license, additional restrictions apply.  Often a publisher will restrict the timezone where a license is available, or the platforms on which the software is allowed to run.

A named-user license is a special case of a floating license. It allows the customer to assign particular users to the licenses.  Over time, these users can be changed, but not too often. This gives the customer the flexibility of a floating license model, but restricts the usage to the names on the list only, not to the general user population.

Finally, license sharing (for example,  shared by host) allows multiple instances of the software while consuming a single license.  In the case of shared by host, multiple instances running on the same host would consume only one license.

We will explore the last two License Models (Token-based and Metered) in future blog posts.

Software Monetization – That’s Fancy Talk

“Software Monetization” – What does it mean to your business?

Industrial companies are increasingly using software as the driver of their future growth. Sustainable growth is fed by profits. But to grow profitably, you need to ensure that your software infrastructure has the proper licensing controls built-in, so that you can get paid for the fair use of your products.  This is what we mean by “software monetization”… turning your products, whether software or software-driven devices, into dynamic, profitable businesses.

Protect and Defend

The first step is IP protection. Adopt a technology that gives you a satisfactory degree of security to prevent unlicensed use, and to deter imitators (grey-markets) who would use your IP to compete against you. We all know that no software is totally hack-proof, but you have to make malicious attacks against your products non-trivial.

Control through SOFTWARE MONETIZATION

Once you have protection built-in, you can ensure that your customers fairly pay you for their use.  The best way to accomplish this is through tamper-proof licenses that specify the terms of use in the license. Licenses can define expiration dates, rights to future updates, where and how much of your software can be used, and license sharing attributes, among others.

SeamlessNESS

Consider how your customers will obtain licenses or activate your software. Fully leverage near ubiquitous connectivity to simplify installation and authentication, whether it is through in-product activation or by supporting floating licenses by deploying license servers in the Cloud. Your choices should reflect how your customers use your products, as well as their own preferences. For example, some customers will insist on staying off the public Internet, so make sure you have a strategy for these cases.

Shake the Trees

Increasing profitability comes from both your current base, as well as new markets. Monetization means extracting revenue from existing bases by giving them choices of new feature bundles, and by scaling price to the value that they receive. New pricing models, such as monthly/annual subscriptions, token-based licenses, and usage metering may cast a wider net into your existing markets. Perhaps a super-low price point, or even a free version is a way to broaden your base. Conversely, there may be valuable features that you currently bundle that could be offered as an up-sell opportunity. Monetization also means delivering totally new products/features using the same licensing technology to derive new sources of revenue.

Product Lifecycle

Your customers are always on the move, and that means your licenses have to move with them. With software licensing, you have mechanisms for customers to self-serve. After your customers easily convert a trial versions into paid versions, they can later move licenses to a new machine, or add new modules, or upgrade to a new release. In all cases, access is in their hands, but you are always in control.

Software licensing also helps manufacturers simplify supply chains by reducing the number of unique physical devices needed to address multiple market segments while extending the useful lifetimes of these devices.

Business Intelligence

What if you could know which parts of your products were used the most, how often? With software licensing, you can gather and monitor actionable product usage data, not just to calculate an invoice, but also to gain marketing insight into how your product is used, and where to allocate precious development resources.

Software licensing services easily tie into CRM and E-Commerce/payment platforms for speedy quote-to-cash.  This means timely revenue recognition and an improved customer experience.

Build on the Shoulders of Giants

In-house development of software monetization tools offers little competitive advantage. Worse, it can derail engineers from development of new features where true product differentiation and competitive advantage lives.

Fortunately, today’s software developers welcome the paradigm shift toward designs built on a combination of licensed code and in-house application software. By acquiring a 3rd-party software monetization solution rather than building it, development organizations enable themselves to focus their efforts on delivering more innovative products more quickly within shrinking market windows.

Top 3 Software Licensing Models

This article discusses the Top 3 Software Licensing Models – subscription license, perpetual license and consumptive license.

Software customers and publishers negotiate pricing based on both the perceived value of the application and how the application will be used.  The software licensing model defines how the product will be used.  Let’s define the top 3 software licensing models.

Perpetual license – a non-expiring license to use an application. The customer has no obligation to pay for support or update services.

Advantages: Simple to deploy and manage. Customers may be able to expense the purchase as capital.

Potential downside: Difficult to securely handle machine upgrades and software redeployment. Publisher is locked into the old license policy for years.  Customers may end up using very old software versions to save money if they elect to forego maintenance.  This in turn could lead to poor publisher reputation when software becomes outdated. For the customer, perpetual licenses require larger initial outlay.  For the publisher, perpetual licenses require a steady stream of new license sales to maintain revenues. Pressure to discount is high.

Subscription license – a renewable license, usually annual, including software support and updates during the coverage period. The license is automatically terminated unless it is renewed.

Advantages: Encourages steady, predictable revenue flow to publisher. Lower initial cost for the user, faster approval cycle. Allows for short-term rentals. License policy can be changed at renewal time. Limits license exposure to overuse when machines are decommissioned or upgraded. Customers are able to annually expense the budgeted license renewal fees. Less price discounting pressure. Encourages on-going client-vendor relationship.

Potential downside: Increased license management overhead. Requires accurate record keeping to manage license life cycle.

Consumptive license – This license has a periodic fee based on usage. Payment can be before or after use. Example cases: overdrafts, utility-pricing based on time or work done, etc.

Advantages: Maximum license and pricing flexibility. Price most closely related to value. Encourages steady revenue flow to publisher. Lowest initial cost for the customer. The customer is never denied a license.  License policy can be changed at any time. Customers may be able to expense the license fees as they occur, perhaps monthly. Least price discounting pressure. Encourages on-going client-vendor relationship.

Potential downside: Requires most license management overhead. Reliable license usage reports must be created periodically, and mid-cycle to check against budget. Licensing must be integrated into CRM or accounts receivable systems. Customers may have issues with privacy.

Cloud-Based License Management

This Article Describes Cloud-Based License Management and in particular several problems solved by this approach.

Traditional floating licensing requires a license server installation on the end customer’s network. Although this deployment strategy is still the most common, you can improve the situation by moving the license servers into the cloud. Let’s look at the issues where Cloud-Based License Management can be of some considerable help.

The crux of the matter is that when you deliver licenses to your customer, you lose control. When you manage your customer’s licenses in the cloud, then you retain control. It’s that simple.

Some of the advantages of delivering licenses in the cloud are…

Customer Preference – Some customers don’t want to set up a license server. They feel this is the vendor’s responsibility. Most small customers don’t have in-house IT support. Licensing in the cloud eliminates the need to install and maintain the license server locally.

Reduce Support Time – Installing a license server can sometimes cause problems. Licensing in the cloud eliminates this task altogether.

Instant Revenue – The publisher can recognize revenue immediately. No more waiting around for the customer to track down the hostid of the server.

Use Anywhere – Your customer can run your software anywhere: on virtual machines, in classrooms, labs, at off-site training, and at trade shows, etc.

License Rehosting – Traditional floating licensing makes it difficult to securely rehost a customer’s license server when it fails or when it is decommissioned.  This is not an issue with licensing in the cloud.

Suspend/Reinstate Licenses – Traditional floating licensing also made it difficult to terminate or suspend licenses. With the license server in the cloud, you can easily deal with non-payment or lapsed subscriptions.

Modify license inventories – With cloud-based license management, it is easy to change license counts up or down, and handle version upgrades.

Usage-based licensing – Pricing software based on usage relies on accurate records. In traditional license server deployments, license usage data is collected at the customer site, making it difficult to collect. With cloud-based license management, the report log containing the usage data is on the cloud, not at your customer’s facility.

Always up-to-date – Your cloud-licensed customers take advantage of upgrades to the server software immediately when released. Backward compatibility of the client-side ensures this.

Failover Servers – Maximize license server up-time with automatic failover server setup, at multiple datacenters.

Post Use Billing

Post Use Billing – an alternative to Subscription or Permanent License Grants

There are situations where it is impossible to anticipate the level of usage of a software package before it is actually used.  In cases like this, a fixed number of permanent licenses or subscriptions may not satisfy your customer’s needs.  Many ISVs and their customers prefer a licensing option which allows the software to be used in excess of some predetermined limit, and then invoiced after-the-fact for the actual usage which exceeds this limit. This type of license model has been referred to as Pay-Per-Use, or Metered or Post Use Billing.

Of course, your life is full of real-world examples of post use billing: your water bill, your electric bill, etc.  Why not adopt this common model to software as well?

RLM supports most flavors of this license model with a combination of metered licenses and an authenticated usage report log.

RLM supports metered, or pay-per-use licenses, with the METER keyword in the license line. When you create a METERed license, the license server maintains a number of meters each with an individual count. When your application runs, the license server decrements the meter after each successful license checkout, and (optionally) periodically while the application continues running.  To utilize this effectively, the license server needs to be under your control, ie. not installed on your customer’s network.  RLMCloud is perfect for this, since you control the servers and hence the meters.

Alternately, you can issue more floating licenses than your customer has purchased, then use the report log to determine usage in excess of the purchased licenses.  At the end of the month, for example, you would invoice your customer for the excess usage.   This is possible because RLM’s usage report logs are authenticated  so that you can verify that they haven’t been modified.  Even better, if the license servers are under your control in RLMCloud, you have continuous access to the report logs.

By using a Post Use Billing license model in addition to your normal permanent or subscription licenses, you can help your customers utilize your software more effectively as well as increase your revenues.

RLM and RLM Activation Pro – what’s the difference?

RLM and RLM Activation Pro – what’s the difference?

Sometimes people are a bit confused by the Reprise product line, in particular, wondering about the difference between RLM and RLM Activation Pro. The two products work together, and both products involve a server component, so that’s the basis for the confusion.

Let’s start with a couple of definitions:

  • RLM (the Reprise License Manager) is a software license manager. You (a software publisher) integrate RLM into your product, and RLM keeps track at runtime who is using your product licenses. RLM can do this entirely within the client library (linked into your application), or, more commonly, your application makes a request of the RLM License Server to “check out” a license. The license server runs either on computers in your customer’s network, or in the cloud if you are using our RLMCloud service. Your application uses RLM every time it runs to verify that the license rights are still present, thus enabling use. RLM, however, never gets involved in the issuing of the actual license files to your customers.
  • RLM Activation Pro, on the other hand, is a Software Activation product. Software Activation’s purpose in life is to generate and dispense the license files for your product to your customers with minimum fuss. Activation Pro also has a server component which we call the activation server. Your application contacts the activation server and supplies a short text activation key, and in exchange, the activation server returns the license which enables your product. Generally, this is done once, right after your customer purchases your software, not every time your software is invoked.

So in summary, RLM provides runtime checking that your application is licensed to run and that the current usage of your application is within the limits you have set, every time your application runs. Activation Pro is used once at the time your customer purchases your software in order to retrieve the license file which is specific to that customer.

Using a License Manager as a Load Balancer

(or, if all you have is a hammer, everything looks like a nail)

Introduction – The Problem

At Reprise Software, our main product, the Reprise License Manager (RLM) runs on many different platforms (19 at last count). Since our product is a client-server product with an API, we have a set of regression tests that we run both during development and at each release.

One issue of testing a license manager is the desirability to run tests that both succeed in checking out licenses from a license server as well as tests that fail. Given that our product (RLM) is inherently a network-based product, and also given that clients can broadcast to discover a license server, our experience is that running regression tests on multiple machines on the same network at the same time will result in some number of checkouts succeeding that should have failed.

In the past, we have worked around this problem by timing the starts of our regression tests suites so that the individual tests would not overlap each other and yield incorrect results (in this case, incorrect results from the test environment, not from software faults). While this works fine in a development environment, it is extremely awkward during a release cycle when the goal is to build and test many platforms simultaneously.

The Solution – License Management

Since the regression tests are primarily run by a single user, the solution was to create a set of licenses, one per test, then use the License Manager as a Load Balancer to serve them with a single instance per license, nodelocked to the username of the person running the test. Each test checks out it’s own license, and if the license request is queued, the test waits until granted. Now, the tests synchronize across all platforms with the same test never running on multiple platforms at the same time. Different sets of licenses are served for different network segments.

We serve the licenses using RLMCloud, so that the license server is always available, even when development machines go down.  An extra benefit is that our normal regression tests also test the RLMCloud servers at the same time. Win win.

101 License Models

101 License Models – a license model for everyone.

License Managers are known for providing flexibility in how you price and license your software.  This blog post discusses 101 license models available to you with the Reprise License Manager.   These models fall into 5 main categories – Unrestricted, Nodelocked, Floating, Token-Based and Metered License Models.  We have discussed some of these in the past, and will talk about others in future blog posts.

So here we go…

Unrestricted License Models

These license models are not locked to any machine or license server.  In other words, they work anywhere.  Often these are appropriate for demo licenses or if you want to be able to display something about the license in a startup dialog, but allow it to run anywhere. Unrestricted licenses can have any of the following attributes:

  • any
  • customer name
  • demo
  • expiring
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • permanent
  • serial number
  • software version
  • user-locked
  Nodelocked License Models

These license models lock the license to a particular computer, and in addition provides other restrictions.  Nodelocked licenses can have any of the following attributes:

  • uncounted
  • computing environment limited
  • customer name
  • detached demo
  • expiring
  • single
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • permanent
  • platform-limited
  • software version
  • timezone-limited
  • upgrade other licenses
  • user-locked
  • VM enabled
    Floating License Models

Floating licenses are the most common usage of a license manager.  These are usable by anyone who can contact the license server.  The floating license models provide the richest set of license control.  Floating licenses can have any of the following attributes:

  Token-based LICENSE MODELS

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:

  Metered license models

Metered licenses provide a “postage meter” type of licensing model. Metered licenses work either with pre-paid or post-use payment.  Metered licenses can have any of the following attributes:

  • per-hour
  • per-invocation
  • per-event
  • computing environment limited
  • customer name
  • expiring
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • password-protected
  • permanent
  • platform-limited
  • replace other licenses
  • software version
  • timezone-limited
  • user-locked
  • VM enabled

License Management as a Pricing Tool

Using License Management as a Pricing Tool

Do you want to maximize revenue while pricing your software in ways that make sense to your customers? A software license manager, such as the Reprise License Manager (RLM), is an indispensable pricing tool that can help you to design and enforce pricing models that are right for your customers, while giving you the flexibility to quickly adapt to new sales opportunities.

A License Manager Gives you Flexibility and Control
When a license manager is properly integrated into your software, it is able to interpret and enforce virtually an unlimited number of licensing and pricing schemes. You implement your licensing polices primarily by:

  • specifying parameters in your licenses, and
  • deciding how to handle unsuccessful license requests (to deny or permit use).

These two levers allow you to customize your license policies by product, customer type, location, etc.  You don’t need to maintain unique software builds for each case because licensing is mostly controlled by the license manager.  This also means that you are poised to quickly revise your policies to react to new business opportunities that crop up – without having to re-release your software.

What should I license?

First, you have to decide what to license. Usually applications are licensed as a whole using a single license, but in some cases you may want to license additional extra cost features. This helps to keep the price of your basic product low, while collecting extra revenue from the customers who value the advanced functionality. You may want to take this concept a step further to create multi-product “bundles” that correspond to common user types, or even support a tiered pricing model with “Basic”, “Advanced” and “Pro” versions to add greater pricing depth.

Which types of licenses?
Determining the right licensing model requires an understanding of how your customers use your products.  If your application is dedicated to a specialized niche purpose, you can use a named-user or node-locked license.  On the other hand, if the product is meant to be widely shared or used collaboratively, you might want to use floating or concurrent licenses.  If you support both types of licenses, then you can usually charge a price premium for the floating license, since it provides more value to your customer.  Price premiums can range from as little as 10-20 percent to a factor of three or more, depending on the type of software and how it is used. In general, it’s best to offer multiple license types because it helps you to deepen your account penetration by reaching more user types.

What is a “user?”
Defining the term “user” may sound like a strange exercise, but its meaning may have a profound effect on the scope of your licenses.  Getting it right means that your customers will use your software precisely as intended.  Question: should the same user on the same machine consume only one license of your software regardless of the number of copies he uses concurrently? Also, should a floating license that is used for only a short duration be allowed to return to the license pool immediately, or should the license manager force a delay to encourage the sale of more licenses.  As you can see, defining a “user” accurately is extremely important.  When defined properly in both your software license agreements and within your technical implementation you avoid confusion with customers about the scope of your licenses.

Should licenses expire?
Obviously, if you settle on using a subscription licensing scheme, you’ll want your licenses to reflect the paid license period, but even if you sell perpetual licenses, you may want to limit the duration of the license (start and end dates) so that licenses require periodic refreshment in the field. This can come in handy when you make wholesale changes to your pricing/licensing model at some point in the future (including switching license management vendors) – knowing that at a certain date, all old licenses will eventually expire.

Should licenses match a specific product version?
Although version numbers in licenses can restrict which application version can run, most publishers prefer allowing older versions of software to consume newer licenses, but not the reverse. Some publishers creatively use license version numbers to manage support contract periods.  For instance, a license that specifies a version of “2018.0101” would support any version of the application released before January 1, 2018. New licenses (with new “version dates”) are issued only to customers who renew their maintenance. Used in combination with a license expiration date, a license could permit permanent access to the latest version released during the user’s most recent paid maintenance period – without the license itself ever expiring.

“Post-use” licensing model
Another new source of revenue might be aimed at those customers who would rather pay for your software based on their actual measured usage. Again, a license manager is the perfect pricing tool for this because it can capture the details of the customer’s usage history allowing you to build accurate invoices weekly, monthly, or quarterly.  You could use a “post-use” model on a customer by customer basis, maintaining it as a revenue-positive alternative to your traditional licensing models used for the majority of your customers.  Perhaps you could sell a base level count of floating licenses to a customer, then use “post-use” billing to handle peak over-usage situations.  This creates extra revenue for the publisher and allows the customer to continue working during unusually busy times.

We’ve only scratched the surface here, so if you would like to discuss how license management can address your particular requirements in more detail, please contact us.