The 5 Trial-Licensing Scenarios Java Developers Can Encounter - and How to Support Each One

Trial licenses are a powerful sales tool for you as an independent software vendor (ISV), however the optimum approach – one that will generate sales without losing revenue -  depends on a number of factors specific to your business.

This article describes the issues you should consider, and analyzes when product activation or a key-based license manager is the better solution for each of the scenarios any ISV is likely to face

Introduction

Done correctly, a trial license allows your prospects to quickly confirm your application will meet their needs so they can proceed with purchase of a full license, but does not provide so much capability the prospect can get their job done without ever purchasing the full license from you.

You therefore need to understand where this balance lies for your products and target customers. The most common form of trial licensing is simply to allow the full product to run for a limited time, perhaps 15, 30 or 45 days, but other kinds of limits may better match the use cases for some applications:

• Disable product features or put a limit on their operation
• Set a limit on how many times certain functions will work
• Set a limit on the capacity of the product e.g. the number of open channels, the Mbytes of data that can be processed, the number or size of forms that can be opened, the number pages printable etc. as appropriate
• Insert a watermark into your application's output, making it unusable in production.

These can be combined, so a trial license could have both a time and a usage limit, and have some features disabled or limited.

You may also want to offer different types of trial licenses to different market segments, as each requires. A fixed trial period doesn’t fit every circumstance either – you may want to extend a trial for a large prospective customer who has an extended evaluation cycle. You could also change which features are available, and increase or decrease the usage limit as best balances your prospect's need to gain confidence in the product with your need not to lose out on a revenue opportunity

You probably also want to limit where the trial installation can run, so copies don't proliferate. This is done with node-locking, where the trial package will run only on one specific machine, as identified by system parameters such as the Ethernet MAC address, host ID, hard disk ID and so forth.

There are several other considerations beyond just the type of trial limits to offer:

Trial package

Most ISVs build one executable, then rely on the licensing system to set the limits on how this one package can run for each installation. However, some niche vendors of complex systems assemble a custom package for each prospect, even if they still want to set time, feature or usage limits.

Accountability

As an ISV, do you want to approve prospects before you issue a trial license to them, or will you offer a trial license to anyone while recording their contact details, or will you offer a trial package to anyone without tracking who they are? In other words, do you want prospect accountability (with or without an approval step) or not?

This can be further complicated when you sell via resellers, distributors or OEM partners. Even though you are not in direct contact with the prospects, do you want to know who they are, will your channel partner track prospects and give you the information, or will  your channel partners refuse to pass on prospect details?

Fulfillment

In most industries, prospects expect to be able to download and try software, or perhaps for a trade show or a give-away you will issue a CD-ROM. However, will all your prospects have Internet access from their machine, or will some of them have Internet access, or will none? The answer to this question determines what trial licensing options are open to you.

Serial Evaluators

A 'serial evaluator' is someone who repeatedly obtains a trial license so they can get their work done for free. They are not evaluating your product, but avoiding paying for a production license. Most ISVs want to prevent or limit this behavior: you can ensure that a prospect can only ever have one trial license per email address, or can only enable one trial license on a particular machine, or combine these limits, or add in others that suit your business purpose.

Automation

If you provide the same trial package to anyone who downloads it from your website, or to anyone who receives the trial CD-ROM, then you probably don't need to automate. However, if you want to issue a specific trial license to each prospect, perhaps also capturing their registration information, you may need to automate the process if your prospects will be numerous.

Scenarios

We’ll now describe two popular approaches: Internet-based product activation and key-based license management with deferred mode.

Scenario 1: Internet-based Activation of Trial Licenses

The most common trial-licensing scenario is where the ISV wants accountability, and the majority of prospects have a network connection. The best licensing technology in this case is Internet-based product activation.

The steps in setting up and activating a trial license are typically as follows:

1.   The ISV or reseller receives an approved request for a trial license, and configures it in the hosted license server. Each license in the server is managed under a unique code, or Product Serial Number, which is defined by the ISV/reseller.

2.   The Product Serial Number is sent to the prospect, perhaps in an email which also contains download instructions.

3.   The prospect installs the application (which is integrated with the license manager client library) and is prompted to enter the Product Serial Number.

4.   The license manager client library contacts the license server to check that a license is available under that Product Serial Number, and obtains the trial license limits as configured for that prospect in the license server.

5.   The client also automatically reads the node-locking parameters from the system on which it is running.

6.   The trial license limits, and the target system locking parameters, are encrypted in a local hidden file.

7.   Each subsequent time the application runs the license manager client interrogates the local encrypted hidden file to obtain the license limits and check the locking parameters.

The process as experienced by the prospect is as follows:

1.      The prospect requests a trial license.

2.      They receive an email with download instructions and a Product Serial Number.

3.      They download and install the software, and paste in the Product Serial Number when it is requested.

4.      Almost instantly the software is activated within the defined trial license limits, and automatically locked to their machine. The prospect can now evaluate the product, which will operate within the trial limits set by the vendor. However, the package will not run on any other machine should they attempt to copy it.

Disconnected systems

If the prospect does not have a network connection from their system when they perform the activation, that is not a problem. Competent product activation systems support several mechanisms for activating licenses on disconnected systems, with all of the same capabilities as for activation of licenses on connected systems:

i)                    "Sneakernet" – if the client cannot connect to the license server when activation is requested, it saves the Product Serial Number and the node-locking information in an encrypted file. The prospect hand-carries (‘sneakernet’) this file to a machine that does have a network connection, and uploads it at the user self-service web page built into the license server. If it is a valid activation request the license server generates the encrypted activation record, which the prospect downloads and places on their machine to complete the activation. The end result is exactly the same as for a connected system – the license is activated within the trial limits specified in the server, locked to the target system, and there is no operator overhead for you as the vendor.

ii)                  Activation by email. The file employed in the Sneakernet-based activation is sent to your operations people by email. They generate the activation record file and email it back to the prospect. However, ISVs generally find that if a prospect has access to email, they also have access to a web browser so can activate their license themselves.

iii)                Activation via proxy server. Some product activation systems do support activation via a suitable proxy server, so sneakernet may not even be needed even if the prospect’s system does not have a direct network connection to the license server.

(Note - if the expectation is that the majority of prospects will not have a network connection, then the alternative approaches outlined below may be more suitable).

This architecture supports several refinements that meet the goals of accountability, automation and preventing serial evaluators.

Accountability

If the prospect requests a trial license from you, and it is approved, you will have a record of the prospect in your CRM system (and your CRM system could also maintain a blacklist of prospects who are to be denied trial licenses). However, the licensing system can also capture prospect information as part of the license activation process.

This works as follows. When your application is installed, the user dialog box requests not just the Product Serial Number, but also the prospect’s registration data (name, email address, company, purchase timeframe etc.). This data is uploaded to and stored in the license server as part of the activation process, and can later be exported to a CRM or backoffice system.

Automation

In the basic scenario described above the trial license was configured in the license server by an operator logging in from any web browser. However, this license-configuration step can also be done automatically by having your ecommerce or backoffice system call the license server’s user registration API, if available.

Preventing serial evaluators

There are several ways to meet this goal. A common approach is to use the prospect’s email address as the Product Serial Number for their trial license. Since the Product Serial Number is specified by you as the ISV, and can be any unique string of characters, the email address is perfectly suitable. If the prospect returns at a later date and tries to obtain another trial license under the same email address, the license server will not allow their trial license to be set up, as there will already be a license in the system under that email address.

For a completely automated, accountable approach that prevents serial evaluators, you can use both the licensing system's user registration API (if available) and the client library as follows:

i)                    Set up a Trials pool of licenses in the license server. Configure pool-level license limits as required for your trial license e.g. a 30-day license with a 10-day warning threshold and a 7-day grace period, with some features constrained.

ii)                  There is no need to set up a trial license for each prospect - you just provide the same download package to all prospects.

iii)                When the trial package is installed on the prospect’s machine, it first introspects the machine name from their system. It then calls the user registration API to configure a license in the Trials pool, using the machine name as the Product Serial Number.

iv)                Your product then calls the license manager client to activate the trial license against that Product Serial Number, automatically locking the trial license to the prospect’s system. The pool-level license limits will automatically apply to this license, as they apply all licenses in the domain.

v)                  If you wish you can also bring up the dialog box to capture user registration information at activation time, and upload this as part of the activation step.

This approach has the following advantages:

-          Fully automated from both your perspective and the prospect’s

-          Automatic prevention of serial evaluators, since a second attempt at installing your trial package on the same machine will fail.

-          The prospect’s machine name is recorded in the license server, so you have accountability to that level, and you can of course capture user registration data as well.

Scenario 2: Key-based Licensing with Deferred-Mode Licensing 

The other common requirement is to provide trial licenses with no accountability and no network connectivity – one example would be when a CD-ROM is distributed at a trade show. The application can be run by anyone who receives the CD, and you won’t know who they are, but you still want to enforce trial limits so they can’t use your software without paying for it.

With a key-based license manager you generate an encrypted license key that defines the license limits for the installation where the key is installed. Some license managers also support deferred-mode licensing, which will take a licensing action, such as starting the clock on a time-limited license or locking a license to the host system, when the application is first run on the prospect’s system.

For this scenario you embed one of these special deferred-mode license keys in your trial package, and provide the same trial package to all your prospects. When anyone installs your application the license manager starts the clock on the time limit (e.g. 30 days). You can also embed a standard license manager key that sets other limits, such as a usage limit or configures product features.

All Combinations of Accountability and Network Connectivity

Conclusion

Trial licensing is a powerful tool for your software business, but the right strategy to adopt depends on what prospects will need to be able to do to give them the confidence to purchase a production license, whether you wish to approve of prospects before providing a trial, whether you want to know who all your prospects are, whether prospects are expected to usually have a network connection, and the volume of trial licenses you expect to issue.

This article has shown that the right licensing solution exists for all the different combinations of circumstances any software vendor might face.