Don't Forget About Software Licensing, Page 2
Have a Thought on the Whole Lifecycle
Questions like this might not be your top priority, but the more you sell, the more difficult situations you will run into. And since licensing trouble, especially if your application requires activation, is part of the customer's first impression about your product, you don't want to make things more complicated than they are (Figure 1).
In fact, you should pay attention to the whole lifecycle in which customers buy, install, use and finally discard your product. Although this alone raises many questions, you also need to understand that third parties exist. For instance, customers might need to allow their own partners to use your application.
Assume that you sell your product to company A, which in turn partners with company B. Company A sets up a remotely accessible environment through which their partner's users can access your application. It's likely that you will require purchasing more licenses, but how about the price? Should it be the same, lower or higher? And does your activation system support cross-domain authentication in such situations?
Partner questions are one thing, but it doesn't simply stop there. Your customers might also hire temporary workers or consultants to help solve their business problems. To aid selling, you might wish to consider temporary licenses, such as six-month or one-year licenses. But even if choose not to go down this route, you must decide how the customer can assign licenses from one user to another. Again, if you use activation, you must make sure the technology supports the licensing models you are selling.
Customer requirements such as work shifts and multiple users for a single computer can bring additional complexities to your licensing. For instance, if you customer is a hospital or a factory, would the customer buy a license for each user, or rather for each computer? Should you then offer per-user or per-computer licensing models?
Sometimes, customer solutions have a long lifespan, and for compatibility reasons require using software versions that have long since ceased selling. From a customer service standpoint, it is good to have these older versions available. Many larger vendors have so-called downgrade rights that allow the customers to purchase the latest version, but use an older version if needed. Make sure you have a solution thought out before the first customer asks.
If your company is successful, you will doubtless enhance your product and release new versions of it. Your licensing model should support easy upgrades. Most companies offer their upgrades for lower cost if the customer already has licensed a previous version. This can be considered a standard practice, but lately companies have started to limit their upgrade paths so that for example only two latest releases qualify for an upgrade price. This is your call, but it's worth remembering that greediness is bad PR.
When planning your sales models, it is also useful to look into the future. In this future, it is quite certain that software as a service (SaaS) types of models are becoming commonplace. What if your customer is a software service provider and wants to purchase your application only to sell it further as a service? This is a worthwhile consideration just as it is whether you should directly offer a server-based solution.
Licensing Server and Web Applications
So far, this article has focused on licensing options for desktop applications. Although many of the options discussed are applicable to server and web applications as well, these application types have certain specific requirements.
For server applications, computing power is one of such considerations. If your application licensing isn't based on counting users, then one possibility is to count for example CPU power. However, this is today a trickier model than ever: processors have more and more cores in them, soon probably 16, 32 or more. At the same time, virtualization makes it difficult to judge the real situation. So, if you choose to take this route, be sure to update your price lists frequently enough.
In the future SaaS models and processing power rental might replace earlier CPU based pricing models. But in fact, this isn't completely new. Beginning from the 1970s, mainframe computer power could be purchased by the CPU hour. Technically, you too could collect processors usage information and base your fee on it.
For hosted web applications, the situation is usually simpler. Since almost every commercial web application has some kind of login function (i.e. it requires a user name and a password to get in), the number of users is a good licensing model. If you wanted, you could even have a monthly fee, which is a flexible model to the customer, but also offers you a steady stream of revenue.
Hybrid licensing models could also be effective. For instance, you might have an application that has both a server-based part and a client application. In such situations, you might have a single fee for the server application, and an additional fee for each user.
Let the Customer Try
The web is a wonderful thing. For one part, it can be used to let your customers know about your products. In addition to classic product pages and datasheets, you can have introductory videos, blogs and podcasts to name a few. Even with these possibilities, the best way to learn about a product is to try it.
For most software products, you can offer a free trial version as a simple web download. This is particularly useful if your application is quite small and easy to install. For larger (enterprise) software, you might want to altogether leave out a trial version, but if this is because your application is difficult to install, consider distributing the trial as a ready-made virtual machine or virtualized application. This can save hours of the prospective customer's time.
When the customer installs the trial version, it is customary to offer a 30-day testing time. Most users expect at least this minimum period, a shorter period might be considered inadequate. For server applications, the period might be even longer. For example, Microsoft's trial periods are often 180 days.
When developing your trial version, you should clearly state that the version is a trial. However, constant nagging is not a good way to earn credit. Today, many trial versions are fully functional, but for certain types of applications, such as repair and restore utilities, certain functions might be limited.
But no matter how you decide to limit the usage of your trial version, make sure it is easy to convert it into a full-blown commercial version. The best option is often to allow the user to enter a license key or serial number, which then removes the limitations. Requiring the customer to completely reinstall the product is not a good practice, though there are of course exceptions to this rule.