From License Models

License Models and techniques to license your software.

Software Licensing Best Practices - Software License Entitlements

Software Licensing Best Practices-Part 4

For software vendors, the most valuable aspect of using a license manager is the freedom to define exactly how your customers buy and use your software products. You can match the attributes of your licenses to the precise needs of your customers and markets. Equally valuable is the ability to address unusual opportunity-specific requirements from your biggest and most important customers or new technology partners.

Read more

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.

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.

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!