By staff

Using an Activation Server as a License Manager

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.Activation Server as a License Manager

Advantages:

  • You avoid the cost of a license manager.
  • The code is easier to integrate
  • The software footprint in your code is smaller

Disadvantages:

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

101 License Models – Metered 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 modelsnodelocked license modelsfloating 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:

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.

RLMCloud – Licensing-as-a-Service

Reprise Software offers licensing solutions for both node-locked and concurrent (floating) licenses. As you have read elsewhere on this blog, virtually every type of license is supported. This article presents a overview of RLMCloud, our Licensing-as-a-Service offering.licensing-as-a-service

If you support concurrent (floating) licensing, Reprise offers both traditional on-premise license servers that your customers set up on their own networks, and license servers in the RLMCloud.

RLMCloud is an easy-to-use solution for hosting your product licenses on standard RLM license servers in the Cloud. Reprise’s Cloud licensing solution is turnkey, and 100% hosted by Reprise Software, Inc. It is administered through your browser. Your customers use your products without installing license servers on their own networks.  Their floating licenses are in the Cloud instead.

Best of all, RLM supports both Cloud-based license servers and on-premise license servers. For example, you can simultaneously support large enterprise customers who insist on on-premises license servers and smaller customers who would value the convenience of a Cloud-based license server.  RLM supports this within the same version of your application with no code changes.

Address the Challenges of on-premise Software Licensing

RLMCloud solves some of the more challenging issues with on-premises license servers, such as:

  • no longer need to ask your customer for the license server hostid
  • no more license server set-up/maintenance required by end customer
  • eliminate hostid spoofing
  • virtual machine cloning is no longer an issue
  • license server rehosting is no longer an issue
  • instantly disable licenses for non-payment, or for lapsed subscription
  • upgrade/downgrade licenses without special “replace” or “upgrade” licenses
  • enable secure pay-per-use payment models using RLM report log
  • set up automatic failover server support

Support for mobile platforms

If your software runs on a mobile platform, or you write applications in programming languages that are not directly supported, then the new RLM Web Services API with RLM Activation Pro offers further benefits:
– uses standard https, no firewall issues
– supports many additional development platforms, including iOS and Android
– supports many additional development languages, such as Java, Delphi, Python, etc.
For more information on RLMCloud, Licensing-as-a-Service, or Activation Pro, please contact [email protected] for a live demo.

101 License Models – Token-Based 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 modelsnodelocked 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:

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!

 

Implement a Recurring Revenue License Model

Recurring Revenue License ModelFor 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)

License Subscriptions

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.

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

Support RenewalsRecurring Revenue License Model

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.

Business Advantages

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.

The Transition

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.

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.

Policy in the License

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 relativpolicy in the licensee 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.

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.

Zeenyx Software Relies on Reprise

Zeenyx Software Relies on Reprise

Zeenyx has been using RLM in its product, AscentialTest, since 2009. They feel certain that they made the right choice right from the start. Their customers consistently find that RLM is both easy to deploy and administer. They appreciate the flexibility of their deployment choices. They are happy to see that the Reprise team continues to keep up with changing requirements by offering their RLMCloud solution. Zeenyx plans to provide RLMCLoud as an option in the future.

Currently Zeenyx uses node-lock, time-based licenses to support free trials. Almost all of their installations use the physical license-server model with a few exceptions where customers have chosen to use a hardware key so that they can deploy their license server on a virtual machine.

About Zeenyx Software

Zeenyx Software, Inc. provides an enterprise level Test Management System that encompasses test planning, development, data management, and execution. Founded in 2006, Zeenyx created AscentialTest, a next generation testing solution that eliminates the need for programming skills, allowing users to build robust, highly maintainable, and reusable tests. AscentialTest is helping Fortune 500 companies reduce the cost of testing by making testers more productive.

Home Brew replaced by RLM at Live2D

Home Brew replaced by RLM at Live2D.

As a small developer of graphics software, we were looking for a way to securely distribute our software globally. Our first option in 2013 was to develop our own “home brew” license management system.Home Brew replaced by RLM

We wanted to protect our product in a way that was robust yet fair to our customers.  However, developing such a protection system could drain too many resources that could have been used to improve our product. Even if we managed to develop a decent license management system, it would have required further development effort.  We would still have to handle maintenance, patching holes, and developing a user interface that could be used across our organization.

We started looking for a turnkey software licensing solution from an experienced company. After speaking with multiple potential vendors, RLM stood out for many reasons. The professional support and advice we received from Reprise addressing both technical and commercial issues was Reprise’s most notable advantage. For example, Reprise asked us which parts of our product we truly wanted to protect. We then realized that we were trying to address every possible scenario, however unlikely. This question led us to focus on what was really important to our business and to avoid pitfalls.

After four years, RLM has become an integral part of our business and will continue to be in the future.

FX Vendor Mootzoid switched to RLM

Mootzoid switched to RLM from “home-made licensing”

Mootzoid switched to RLM

In 2008 Mootzoid started developing and selling plugins. At that time, no software license manager was used because the number of customers and users was just too small to justify investing time or money into a software licensing system.

As the user and customer base grew, the need for a software licensing system became evident. Mootzoid developed a very simple in-house software licensing solution in 2010.

It worked well at the beginning.  However, problems became apparent after only a few months. Too much time was required to maintain and support this very limited proprietary software licensing system. Furthermore, larger studios and potential customers expressed their doubts about the ‘amateur’ licensing system.

Switched to RLM

In 2011 Mootzoid decided it was time to dump its in-house licensing and switch to a more robust system.  Mootzoid wanted a system that was used by other software development companies.  They also wanted a system that was familiar to systems administrators of larger studios. At that point, Mootzoid switched to RLM.

Adding RLM licensing to the Mootzoid plugins was done in one afternoon.  Acceptance by the customers was good. Studios expressed their satisfaction that the Mootzoid tools were now using something that fit better into their existing licensing process pipeline.

Since 2011 all Mootzoid plugins running under Window, Linux and OS X are using RLM.  The decision to make the switch has never been regretted.

About Mootzoid

Around 2008 Mr. Eric Mootz decided to stop freelancing and to instead develop and sell plugins for 3D applications under the name “Mootzoid”.

The first two plugins were a fluid solver and a particle mesher, both available for the Softimage platform only. In the years that followed, the plugins were continuously enhanced, were ported to other 3D applications and were used by increasing numbers of freelancers and studios around the world. During that time new tools were developed as well, including flocking solvers, particle renderers and versatile meshing plugins.

All tools have been used in many film productions such as TV commercials and movie projects. Several schools of 3D and universities in Europe, Australia and the USA take advantage of the Mootzoid free educational license model, using the plugins exclusively for teaching and research purposes.