Automating license distribution

Recently, one of our LM-X clients asked me: “What’s a good way of enabling the efficient creation of licenses in an automatic way?”

It’s a question that gets asked fairly often, so I thought it might be useful to share some of my thoughts and experiences.

The scenario in this case was as follows:

1. The client’s application is freely downloadable from their website;
2. Once a user wishes to execute the application, he or she needs a commercial or trial license – this license may or may not already exist on the user’s machine.
3. Trial licenses are time-limited but are otherwise fully functional.
One common approach to addressing this kind of licensing is to develop a complete website through which users can request licenses. Although this may not be a bad idea in its own right, it will often involve that application developers need to dedicate resources to areas such as Web design, which might not be their forte; This was the case with the client we were speaking to, so the approach we recommended involved the development of the server-side aspects of a Web system, together with a “request” mechanism built into the application itself, which would be triggered in the event that no valid license was found.

Such an approach, as well as often being more easy for many developers to implement, also has a number of advantages over using a fully Web-based system. For example, in this case the client wished to tie the licensing together with the user’s hardware. While it might be possible to pass hardware information to a Web server from a browser via, say, an Active-X component, it can involve quite a lot of work, and won’t be supported by all browsers. When developing the code inside the client application itself, the application can handle getting the information about the hardware, using the normal protection API, and can pass that information, together with the user’s name and email address (provided via a dialog that is presented to the user), to a website that accepts the content. And there’s a certain elegance to an approach that keeps everything “inside” the application as much as possible.

A quick note: some people we’ve spoken to have considered a somewhat similar approach, but where their application send emails with the requisite licensing information. While doing things in this way might on the face of things allow a developer get up-to-speed fairly quickly, it’s not an ideal approach: sending emails reliably from a deployed application is likely to be problematic, based on the various ways in which a user might access – for example, by Webmail or using an ISP’s SMTP server – and will also likely require additional work from the server side, since processing incoming emails is a less routine task than is processing incoming HTTP requests.

Using simple HTTP requests to a managed Web server, then, a developer’s backend system can send out an email to the user with the license content, along with instructions as to where the user should put the license file. You could of course take this a step further, by having the Web server automatically return a license to the requesting application, which would then process it/save it in the correct location as required. But, by having the license sent to a specific email address you can ensure that people do not use bogus email addresses when requesting licenses.

Let’s look at how you’d implement this, step-by-step:

1. Code the application to check whether the user has a commercial or trial license by calling the “load license” procedure of the license manager;

2. If a license is found, the application continues to execute as usual;

3. If no license is found, the application calls the appropriate routine for gathering hardware identification from the user’s system;

4. Code a simple GUI dialog that requests the required user information, allowing the
user to type in his name and email address. Although it’s not usually especially interesting to users, you may wish to display the hardware data that you will be sending, so that the user is aware of all information that will be sent to the server;

5. Make sure to tell the user that the license will be sent to them by email;

6. Develop code on your Web server that accepts and processes input via an http request; develop code in the application to send the appropriate http request with the information collected from the user and from the user’s machine. The client who we were speaking to is developing their software in C#, whose .NET framework provides easy access to the http protocol;

The Web application should be developed to read the passed http information, and to call the license generator to generate, say, a 30 day trial license. With LM-X, this is a simple process – a license can be very quickly generated with the use of a simple XML template; the Web application can simply write out a template, call the license generator, and then send that license to the user via email, with instructions as to what to do with the license file.

Of course, I am simplifying the process of generating the Web system, here, and your own applications might include additional security checks such as checking for duplicate hardware information (to prevent users from requesting multiple licenses with multiple email addresses), integrating with an existing CRM system, etc. You can always tweak things to match your specific scenario; but, in short, I feel that incorporating the license generation request into the application itself, you can provide an efficient, user-friendly approach to the users of your software. Although developing the Web side of things may at first seem complex, our experience is that it need not be so, especially since developing a full Web front-end is not required; and the costs of any development are easily justified by the time you’ll save in avoiding the manual creation of licenses. And, of course, you can take things further – by keeping track of user license requests, incorporating tracking parameters into different distributions of your product (say, using and tracking slightly different Web requests in versions of your application that you distribute via CD from those you distribute online), and so forth – the possibilities are endless!