Software Licensing “Gotchas!” – Managing Software Licensing

By Frank Venezia & Steffani Lomax, Siwel Consulting

Today’s technology industry is characterized by changes that are frequent and rapid. Some might even categorize them as “revolutionary.” These changes in technology impact how hardware is sold and software is licensed by all the major suppliers. Software publishers have responded by implementing new license models and metrics that are increasingly complex, creating a significant challenge for organizations to keep up and remain compliant with their license entitlements. What is the result? It is software licensing complexities and nuances that we call “gotchas!”

Only the most savvy software license analysts understand the licensing policies that can cause a company to spiral out of compliance. What are some of these software licensing “gotchas,” and what can organizations do to manage them?

Key Contributors to Software License Compliance Issues

In recent years, many organizations have found themselves out of compliance with their key software suppliers. Both the software publishers and end users share responsibility for this growing problem. What factors have contributed to this phenomenon?

During the .com craze, many end users believed that they were unable to download software quickly enough due to an administrative and procedural obstacle called the license key. End users had to wait to receive a specific numeric license key to download the software they needed. Many software publishers responded to this obstacle by abolishing their license key policies. Suddenly, end users had the ability to download a variety of software licenses more quickly and with fewer obstacles, which created challenges for organizations to manage and control their software licensing.

Software publishers also bear responsibility. They have responded to revolutions in technology by changing their license models and metrics frequently, while adding layers of complexity. Typically, end users lack a detailed understanding of their software contract terms and licensing metrics. To exacerbate this lack of understanding, their organizations often lack robust software asset management (SAM) processes and practices that would alleviate the compliance problems they experience today. The combination of these scenarios has led to widespread software compliance issues.

Given the constant changes in licensing models and metrics, organizations need to gain a deeper understanding of their contract terms and licensing nuances. Common “gotchas” fall into these categories:

  • Scope
  • Licensing Models
  • Product Use Rights
  • Dependencies
  • Virtualization
  • Disaster Recovery

Limitations on the scope of a software license can create compliance issues. Software publishers may limit usage based on geography, mergers and acquisitions, or increases in company revenue or employee count. From a geographic perspective, some software contracts may invoke very strict usage limitations by country, region, or even specific site. Mergers and acquisitions can come into play when software licenses are limited to specific business units, or a business may have to be majority-owned to apply. Furthermore, revenue or employee increases may trigger a change in licensing. Licenses tied to revenue or to a number of employees typically include a contract clause that corporate growth must be reported, and subsequent licensing adjusted, each fiscal year. For example, an Oracle customer could be compliant at beginning of a contract term, but if their licensing is tied to corporate revenue, they could easily become non-compliant if their revenue increases and they do not record and report these changes.

Licensing Models

It is important to understand the various licensing models available and what you are entitled to within the terms and conditions of your software contract. Some of the most common licensing models are the following: user-based, server-based, capacity-based, resource-based and bundled. Bundling can be particularly confusing: if an end user is unaware that a software product they are entitled to enables rights to other supporting products, they could purchase the supporting products unnecessarily. IBM’s WebSphere Process Server – Version 7.0 comes with several supporting programs. However, Version 8.0 is bundled with an entirely different set of products. In this case, the end user needs to understand the bundling for both version levels to ensure that they do not purchase additional software products unnecessarily.

Product Use Rights

Product use rights, such as full use, limited use, second use and downgrade rights can all have a profound impact on software compliance. A product may include full use rights, while allowing limited use for another product. If an organization is unaware of limited use rights, they may purchase new products unnecessarily. Second use enables a customer to deploy the same license on more than one computer so that additional licenses do not need to be procured. Let’s review a specific example of how downgrade rights can affect licensing:

An end user organization over-deployed Microsoft Office 2007 licenses. However, they were entitled to Microsoft Office 2003 licenses. To rectify the compliance issue, the end user had two options:

  • Option 1: Purchase additional Microsoft Office 2007 licenses
  • Option 2: Utilize entitlements for Microsoft Office 2003 to rectify over-deployment if budgetary constraints preclude the purchase of additional Microsoft Office 2007 licenses.

This end user employed licensing experts who understood the nuances and traps related to product use rights, and made a fully-informed decision. However, if the end user had been unfamiliar with the downgrade rights associated with their contract, they would have purchased Microsoft Office 2007 licenses unnecessarily.


Some license types can be dependent upon having entitlement to a base license or other products. For example, Oracle Database options or extensions require Oracle Database as the base product.

As discussed earlier, bundled products have specific limited use terms. IBM’s DB2 is bundled as part of certain WebSphere products, with deployment and access restrictions.

Server Virtualization

Due to the nature of licensing in virtualized environments, proliferation of software licenses is easy. The ability to partition servers, establish host machines and clusters, and count cores or processors results in confusion around software licensing. Here are some examples of licensing policies to be aware of with some of the leading software publishers.

IBM Sub-capacity: IBM’s Sub-capacity licensing schema is designed to help organizations drive down software costs in their virtual environments. Organizations must obtain entitlements sufficient to cover only those activated processor cores available to the specific virtual machine(s) or hardware partition(s) where that software is installed. It is important to understand the following:

  • Sub-capacity licensing typically requires a separate agreement, quarterly reporting and use of IBM’s License Metric Tool (ILMT)
  • Not all virtualization technologies or vendor’s products are supported
  • Movement within virtual farms can impact licensing
  • Without a sub-capacity agreement, organizations must license the entire server or cluster

One issue with sub-capacity licensing is that it is easy to spiral out of compliance due to the movement of virtual machines within and between server groups. Virtual environments tend to change frequently, making it critical to track movement to maintain an understanding of the organization’s license position and make licensing adjustments as necessary.

Oracle Database Licensing: Virtualization has a significant impact on Oracle Database license counts. One of Oracle VM’s main selling points is that Oracle considers Oracle VM a type of hard partitioning and VMware vSphere a type of soft partitioning. When an organization uses hard partitioning, Oracle only requires licensing for the processors (cores) in that partition. For soft partitioning, Oracle requires the end user to license all the processors (cores) in the server, even though there may be many more processors present than are allocated to the virtual machine.

It is important to understand whether hard or soft partitioning applies to your environment because there is a significant financial difference between the two.

BMC CPU Licensing: There are some important nuances to understand about BMC CPU licensing. For some products, the full physical machine must be licensed. If virtual machines reside in a farm, the entire farm must be licensed. When licensing a physical machine or farm, processors must be counted rather than cores. The software licensing “gotcha” occurs when an end user mistakenly counts cores rather than processors. This results in purchasing more licenses than needed, or reporting an inflated number to their software publisher, creating an erroneous over-deployment scenario.

Disaster Recovery: Disaster Recovery (DR) software licensing can generate some significant “gotchas.”

First, it is imperative to understand software publisher contract definitions for DR. IBM’s definition of DR is based on workload, while Oracle’s is based on frequency of use. IBM defines three levels of DR. The bottom level may equate to free licensing. An end user may be required to pay for the mid-level, while top level DR is treated as licenses in production. With Oracle, after more than 10 days of use, the licenses are considered production-level.

Secondly, it is critical to understand your own internal DR configurations and utilization, and to not assume that your company definitions match those of your software suppliers. Making this assumption can lead to software compliance issues.


In summary, here are three recommendations to avoid software licensing “gotchas:”

  • Gain a deep understanding of your contracts and the respective licensing models, metrics and nuances
  • Employ expert ITAM license analysts and contract specialists as an integral part of your ITAM process
  • Provide ITAM data analysis to your vendor management team that interfaces with your software suppliers

If you follow these guidelines, you will keep your organization in compliance, avoid software licensing landmines and save on potentially significant unnecessary expenditures. And you’ll avoid the dreaded “GOTCHA!”

About the Authors

Steffani Lomax is the Vice President of Alliances for Siwel Consulting, Inc.