Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
When developing commercial software, licensing options and sales models are often an afterthought. Often, development and coding are the main focus areas. Things like sales prices and licensing are often the details left for the marketing department to determine. Software licensing, however, is also technology and can be a deal-breaker if not done properly.
In fact, customers today expect to have solutions to a multitude of needs. For instance, many users have both a desktop computer and a laptop. If you sell your product to a single user, should he or she be able to use the software on both computers? Will they be able to use it on their home computer?
Similarly, corporations want flexibility. They might acquire another company or merge their businesses. They might be using Windows Terminal Server or Citrix XenApp systems and run your application multiple times on the same server. Or, they might virtualize your application or load-balance it on two or more servers. Do you have a licensing model for these situations?
This article talks about different licensing options and sales models for software products with focus on smaller ISVs. The aim of this article is to provide information about different licensing options and best practices. Let’s begin the tour from regular desktop applications.
Exploring Licensing Options
Finding the best licensing models for your software can be difficult. This is especially true if you are not aware of all the possibilities that customers have learned to purchase software. Table 1 lists common licensing models and related considerations.
Table 1. Common software licensing models and considerations
- Per-User and Per-Computer
- Concurrent, Time limited
- Per-Processor
- Educational, government and non-profit discounts
- Home usage
- Terminal Server/Citrix usage scenarios
- Hosted applications, CPU hours
- Virtualized environments
- Multi-boot computers
- Trial periods
The basic licensing model for end user applications is the per-user model. This means that a single user would be able to use your product on any number of computers, including desktop, laptop and home computers. Should you like to restrict for instance home use, you could state so in your licensing agreement. The clearer the agreement is the better.
An interesting option to enhance the traditional per-user or per-machine models is the concurrent licensing model. In this model, a certain number of users can utilize the product at one time. That is, any user (depending on the licensing rules, of course) could use the product provided that the maximum number of simultaneous users is not exceeded.
The concurrent model is particularly useful for applications that are needed by many, but not very often. Thus, the customer can provide the application for many of its users, but only pay for the actual usage. Work shifts might also be attractive usage scenario for the concurrent model.
Note that different companies use different names for concurrent licenses. Some call them networked, floating or simultaneous user licenses, but the idea is the same. It is common for the price of a concurrent license to be three to five times the price of a regular per-user license. There might also be limitations on how many installations a concurrent license allows; for instance a single license might let the application to be installed on 20 computers.
Activation – Bliss or Dread?
Many ISVs worry about pirated software and lost sales. If this is a concern to your company, the easiest option is to clearly state in your licensing agreements how your application is licensed and the unauthorized use is illegal. Clarity helps: too complicated agreements irritate users and can lead to lost sales.
A statement on an agreement can be a little toothless, though. Since Windows XP’s debut in 2001, mandatory software activation or registration has become increasingly common. Simple and working activation can be good, but too many application developers fail to imagine how things could go wrong. For instance, Internet connections might malfunction or your licensing servers might be down for maintenance. But while you maintain, business on the other side of the globe is in full swing.
Assume that you sell your solution with a license that allows a single activation. Computers crash and the software needs to be reinstalled. How would your licensing engine supporting this situation? Or, the customer needs to move the license from one employee to another. Could that situation be handled without a costly phone call to your support organization?
Uncommon situations can cause trouble for activation systems, but so can time. For instance, can you guarantee that your licensing servers still support activating older licenses after, say, ten years? If you sell perpetual licenses to your customers, then legally you ought to provide activation services for a long time. Recent collapsed music businesses and DRM server shutdowns provide an example of what happens when activation is taken offline. The same thing applies to software systems.
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.
Selling Through Resellers
Some especially smaller software companies rely on the direct sales model, where their products can only be bought directly from them. Yet, many software titles are also available through resellers, which can help to increase your sales and improve your marketing reach.
When you start building a channel, i.e. bringing resellers (or even distributors and resellers) into your selling equation, there are several things you need to be aware of. First and foremost, resellers are there to make a business from selling, supporting and/or training your products. Again, a good rule is to keep things simple and supportive.
Supporting means for one part, that resellers expect to have some kind of compensation for their efforts. This can be done with a direct discount from the price with which you sell the products directly. Alternatively, you could provide some kind of sales commission. For example, this might be based on quantities sold quarterly. It is also wise to put some marketing efforts into your budget, as you cannot expect the reseller to sell much if your marketing budget is non-existent.
When your reseller closes a deal, make it easy for him or her to send in the order. Remember to always keep the reseller in the loop when you send the order confirmation or the license keys, since the customer is likely to contact the reseller before contacting you. If there is a problem for instance with the license key, you want your reseller to solve the issue quickly.
It’s also worthwhile to document your selling process. This benefits both the resellers and your customers. Remember to take the whole lifecycle into consideration: from buying and installing the product to using it and finally moving it to another user or computer.
When you have resellers and/or distributors in your business model, timely announcements about new products, changes in prices, and so on are key. At the very least, let your channel know about important changes several weeks before the fact, not the day after. Resellers likely have other products to sell than just yours, and you must respect that their focus isn’t 100% in your products alone.
If customers are aware of your resellers, they can send in their quote requests to both you directly and your resellers. If you have multiple resellers, they probably can figure out proper pricing themselves. But since only you can determine the pricing level, it is important not to undermine the possibilities of resellers by selling lower than the channel. A direct sales person only looking for his quarterly bonus can bring down the motivation of the whole channel. Thus, you need a policy for such situations.
Conclusion
Software companies usually want to focus on their core business: development. However, all commercially operating companies need to have a revenue stream, and if it’s selling the software, then you need to think about sales strategies. Software licensing is equally important than your business model (whether it contains a channel or not).
In this article, you learned about the different options and caveats of software licensing. Sometimes, licensing is an art form just like software development. The wealth of options and scenarios can be overwhelming at first, but once you start looking around, you will find that many other software companies have already tackled similar situations. It might just be that they use different vocabulary.
This article discussed different business models, including direct sales and selling through resellers. The more partners you have in your model, the more open your company needs to be. Keep the information flowing and train your channel.
These can be considered the starting points. Now, start tuning your own model!
# # #
About the Author
Jani Järvinen is a software development trainer and consultant in Finland. He is a Microsoft C# MVP and a frequent author and has published three books about software development. He is the group leader of a Finnish software development expert group at ITpro.fi. His blog can be found at http://www.saunalahti.fi/janij/. You can send him mail by clicking on his name at the top of the article.
