Enforcing Licensing Models

Once you've defined your business and licensing models, and ensured that your tarchitecture can support them, you have to decide how strongly you wish to enforce the licensing model. Typically, enforcement means disabling some or all of the application when the license manager determines that the license has been violated. You can avoid creating or using a license manager and rely on the honor system, create your own licensing manager, or license one from a third-party provider.

The Honor System

The honor system is the simplest and easiest way to enforce a license model. You simply expect your customers to honor the terms of the license, which means not changing the license terms, illegally copying the software, changing configuration parameters to obtain more use of the software, and so forth. You're not giving up any rights, as you still have legal protection under contract law if you find your customer cheating. Rather, you are putting nothing into your application to explicitly prevent your customer from cheating.

I suspect that a large percentage of software publishers rely on the honor system. Whether or not this is a good choice should be based on a careful analysis of several factors, including the relationship you have or want to create with your customer, the potential for lost revenue, and your ability to track the use of your software via the honor system. Compare these against the cost of creating, maintaining, and supporting a more advanced licensing system or licensing such a system from a third party. An additional motivation to use the honor system, especially with enterprise software systems, is that it provides account managers with the opportunity to talk with customers each time the license is up for renewal, and to possibly convince them to purchase more software. In consumer software, where you may have tens of thousands to tens of millions of copies, the honor system may not be a good choice. In enterprise-class software, where you may have several dozen to a few hundred customers, it may be a good choice, especially if you maintain a close relationship with your customers through support or service organizations.

Home-Grown License Managers

In this approach the development team creates the infrastructure for license management. Such a solution is not industrial strength, in that it is often relatively easily defeated. However, it has the advantages of being low cost, lightweight, easy to implement, and completely in control of the development organization. Once you've made the choice to enforce the licensing models, the economics of defeated enforcement must be considered to determine if a home-grown solution is sufficient or a professional system is required. If your software costs $700 per license, a home-grown system may be acceptable. If you're software costs $70,000 per license, there is simply too much money to lose with a home-grown license manager, and you're better off switching to a professional solution.

Some kind of home-grown license management is almost always required for session-based licensing schemes, because the development organization needs complete control over the software's response to the system running out of the internal resources it needs to manage sessions. In other words, do you stop the application (extreme, not recommended) or simply refuse the session (common, but the associated issues are application specific).

It Doesn't Have to Be Unbreakable

One enterprise-class system I helped create provided for a combination of named and concurrent users: Any number of users up to the concurrent user limit could log on at the same time, but only users explicitly identified were allowed access. We implemented our own lightweight but extremely effective licensing manager. The number of concurrent and named users were simply stored in an INI file, with user IDs and passwords stored in a database. Changing either of these entries defeated the licensing scheme, in that if you licensed 20 concurrent users but changed this to 100, you cheated my employer out of 80 concurrent user licenses and tens of thousands of dollars in license fees. We didn't expect anyone to actually cheat, and to this day I know of no company that did. The net was that for a reasonable development effort we were able to devise a scheme that "kept honest people honest."

Third-Party or Professional License Managers

Professional license managers are typically organized in three main components: the license generator, a client (or local license manager), and a server (or remote license manager). The business model and the software being enforced will determine how you use these components .

The License Generator

The license generator generates a valid license for consumption by the client and/or server. Most license managers will generate digitally signed licenses based on public key cryptography that cannot be altered and that can be used to prove that the rights delivered to the license manager are correct. License generators are typically located at the independent software vendor (ISV) or its agent and are integrated with other backend infrastructure systems, such as order fulfillment, which may initiate license generation, and accounting systems, which may use the records maintained by the license generator for billing. Once a license is generated it can be distributed in a variety of ways, including fax, phone, e-mail, or direct connection from the server to the license generator via the internet.

The Client

The client license manager manages the software running on an end user's computer or workstation. At its simplest terms, it either allows or prevents access to a given application or licensed feature. The client can typically be configured to operate in one of two ways. One is as a standalone, in which it manages enforcement without working with the server. This mode of operation is common for single-user, consumer-oriented software run on one machine and works well for time-based access or usage models.

Here is an example. You work for SuperSoft, which markets SuperDraw. You want to distribute a 30-day trial of SuperDraw, which can be thought of as a free rental. When SuperDraw is installed the client-side license manager is also installed to enforce these rights along with the digitally signed trial license (e.g., the trial expires and the software cannot be used after 30 days).

The other mode of operation requires the client license manager to work with a server to enforce license rights. This mode is common in business-oriented software that uses metering, such as named or concurrent users. When the application is invoked, the client license manager checks with the server to determine if access is allowed. Your customer must be connected to a network, and you need to consider application behavior when your customer is not connected.

The Server

The server component interprets digitally signed licenses and provides a variety of enforcement services to client license managers. As just described, the server component is required (in one form or another) for the licensing models that support counting or metering.

Here is an example to illustrate how a server works with a client to enforce license rights. You're licensing a high-end CAD system that wants to sell concurrent user licenses at $8K per user. In this case the software can be installed on any available workstation, but each user consumes a concurrent user. The server works with the client to keep track of each concurrent user and ensure that the license terms are properly enforced. This model may seem like a great model, but remember that you still must handle the unconnected user. The easiest way to handle unconnected users is to simply not support them and instead require connected use.

Although I've talked about enforcement, I haven't addressed how your software interoperates with the client and/or server components of the license management system. Normal software, or the software that you create to fulfill your customer needs, has no concept of enforcing a business model. Something must be done to it to prepare it for license management, and the way you do this can vary a lot for home-grown systems. Third-party license managers, on the other hand, generally employ two approaches to integrate the software with the license manager: injection or APIs.

• Injection: Given a "normal" application, the "injection" approach analyzes the object code and "injects" into it new code that typically obfuscates and/or encrypts the original code and adds the client license manager to enforce the license. In other words, injection works just like a virus, albeit a beneficial one. Table 4-1 lists some of the advantages and disadvantages of the injection approach.

• API: In this approach developers write to an API (or SDK) provided by the license manager vendor. The API provides for such things as license registration and enforcement (e.g., it has calls for "checking the validity of the license" or "logging in a concurrent user.") This approach is not strictly required for concurrent licensing, but it makes implementing such schemes vastly easier. APIs can be used with interpreted languages, but most vendors feel that using them in this manner does not provide very strong security. More plainly, it is relatively easy to hack the API approach in Java/C#. Table 4-2 captures the advantages and disadvantages of API-based approaches.

Table 4-1. Advantages and Disadvantages of the Injection Approach

Advantages	Disadvantages
Requires little or no work by developers Can result in more secure protection, because the injection approaches obfuscate and/or encrypts code	Increases size of code Decreases execution performance Can only be used with binaries; typically not suitable for interpreted languages

Table 4-2. Advantages and Disadvantages of API-based Approaches

Advantages	Disadvantages
Provides maximum flexibilityyou can control exactly how the license model works Can be used with interpreted languages	If not used properly can be easy to defeat Creates lock-in to an existing vendor Usually takes longer to implement a complete solution Can lead to a false sense of security

While professional third-party license managers have many virtues, you need to evaluate them very carefully . Consider the issues in the following sections when conducting this evaluation.

Business Model Support

To the best of my knowledge, no licensing manager supports all of the business models listed earlier. For example, I don't know of any that provide direct support for most hardware-based business models (such as per CPU or per-expansion-card). Most work best if you alter your business model to work well with their specific technologies.

Traditional license managers provide a fixed set of models with fill-in parameters. An example is a time-based usage scenario, in which you simply fill in the amount of time. More modern license managers provide a license scripting language, similar to languages like Visual Basic, that allows you to create customized scripts for creative licensing models.

Platform and Operating System Support

Make certain your license manager vendors can provide support for all required platforms and operating systems. When examining their supported platforms, take the time to explore their development roadmap, because, when a new version of an operating system is released, your development efforts are stalled until your license management vendor supports it!

Check Cracker Web Sites to Determine Solution Strength

It is easy to create a simple license manager. It is very hard to create an industrial-strength license manager that will consistently thwart crackers, maintain the security of your software, and ensure that you're getting the maximum revenue from your licensing model. If you don't have the skill to assess the strength of the solution, hire a consultant who does.

Check Backend Integration and Volume Capabilities

As stated earlier, the license generator is almost always integrated with backend systems. Examine your potential license manager vendor's ability to integrate its system within your environment. While you're doing this, make certain they can also meet your performance, volume, scalability, and stability requirements.

Make Certain Operational Environment Matches Yours

License managers create a whole host of operational issues. For example, customer service representatives may have to regenerate a license, or create a temporary evaluation license on the fly, or cancel a previously generated license. You'll have to make certain that the integrations created between your license generator and other backend components are sufficiently scalable and reliable. Make certain that your license manager vendor can meet your operational requirements. In other words, if your customer service environment is completely Web-based, make certain your license manager vendor can provide all required functionality via a browser.

Check Branding and User Interface Control

When the code enforcing the license detects a violation, chances are good that some kind of error message will be displayed to the user. Assess the degree of control you have over the content and presentation of this error message. You want to make certain that it meets all of your usability requirements, especially internationalization. You don't want to discover that your vendor has twelve dialogs it might bring up in obscure circumstances, and that you can't change any of their contents.

Examine License Content and Format

The format and content of the license should be understandable and should match your business requirements. Anything generated by your system, even if it is not used by the license manager, should be digitally signed. For example, you may wish to put a serial number inside the license to integrate the license generator with other backend systems. Any custom or proprietary data that you store in the license should be signed.

Examine License Distribution Capabilities

Licenses can be distributed in a variety of ways. Make certain the vendor supports the approaches that are most important to you. Internet, e-mail, phone, and fax are the most common license distribution options.