Rights Associated with Business Models

Marketects choose business models to maximize the benefits to their business. Associated with each of the business models just described is a set of rights and restrictionsthings you can do or things you get and things you cannot do or things you do not get. I've covered a few of these already, such as the right to use, the right to upgrade, and you can only run this software on one computer.

Your business model should distinguish as many rights and restrictions as possible, because each right is a way of capturing and/or extracting value from your customer and each restriction is a way of protecting your interests. Many business models, for reasons of convenience, competitive advantage, or common practice, often create a standard licensing model that blends a variety of rights and restrictions into a single package. Remember, however, that separating them can create greater value.

For example, an annual license to use the software (the business model is time-based access) commonly includes the right to use and the right to receive upgrades but not the right to receive technical support. A subscription to a software-based services model (such as America Online; the business model is service or metering depending on customer choices) may include all of these rights. This section reviews some of the rights commonly associated with various business models.

Figure 4-1 outlines some the rights and restrictions associated with particular business models. The columns list specific rights or restrictions; the rows are the business models. A check means that this right is commonly allowed by the business model. A number means that the right may be allowed by the business model and will be discussed in greater detail. I've added a column that addresses whether or not the fees paid by the licensee are one time or periodic. The timing of fees can affect the choice of model.

Figure 4-1. License rights and business models

The table's focus is the subset of license models most closely correlated with various business models. It does not attempt to capture every possible legal issue that can be defined in a license: exclusivity, warranties, indemnifications, intellectual property rights, confidentiality, or any number of other things that a savvy lawyer can think of. Most of these are not a function of the model but of larger corporate policy that governs every license model, regardless of the business model.

1. Do associate this right with the business model if providing it will give you a competitive advantage, reduce technical or product support costs, or create a stronger tie between you and your customer. Don't if your customers don't care about it or if doing so may cause them more bother or pain that it is worth. For example, in the anti-virus market you have to provide upgrades and bug fixes. In enterprise-class software, upgrades may not be as meaningful because of the large time delays that may exist between release cycles and the often substantial costs associated with integrating the upgrade into the current operational environment.

2. I'm usually surprised to find that transaction-based business models don't automatically include these rights. In these models, your goal is to drive transactions. Improvements to your software, especially those that can drive transactions, should always be made available to your customers.

3. Do associate these rights if the benefits of point 1 apply and your customers find it relatively easy to apply the upgrade and/or patches. Note that in some hardware-based business models you don't want your customers to upgrade to new software. Instead, you want them to purchase entirely new hardware, which is another reason to withhold these rights.