Most Software License Management programs are based on the common practice of attempting to show compliance on all software titles, and focus on the pursuit of compliance alone instead of the true value‐producing solution of license harvesting and re‐use with a by-product of compliance.
The formation of a Managed Software List (MSL), the subset of currently deployed titles that together represent 80% of the risk/value, has been successful in many Fortune 500 companies that the author has worked with to create value producing software license management solutions that are sustainable over the long term.
The MSL is typically fewer than 20% of the titles in the enterprise, which greatly increases the probability of success of software license management as well as the speed to benefit while maintaining an acceptable risk profile. This article explains the top level approach to forming the initial MSL and makes recommendations around governance and socialization of the concept.
Software Compliance – The Challenges
For years companies have been struggling with the challenge of tracking software license compliance. The increase in instances of audit over the years as well as the amount of money spent on software licensing and maintenance have raised the importance of tracking compliance in the eyes of many executives. Most have sought the help of various auto‐discovery tools, with a seemingly simple solution ‐ namely, to have auto‐discovery determine the software that is installed and in use, and to match that information with purchasing records in order to establish a compliance position.
If the purchases equal or exceed the installations, then the company is in compliance. Unfortunately, those who have tried this recipe quickly found it was not that easy. They stumbled across one or more of the following challenges which few, if any, have been able to completely overcome:
- Auto‐discovery cannot differentiate between what is a licensed software title and what is a software component that does not require a license.
- Insufficient purchasing records exist to be able to demonstrate compliance.
- Many license models are increasingly complex, and auto‐discovery is of little or no help in determining the installed base. This is especially true in server/web‐based licenses.
- The attempt to show compliance ended up formally documenting an out‐of‐compliance position, putting the company in a worse position than before.
1: Differentiating Licensed from Component SW
On “Wintel” machines, which often represent a majority of the machines on which licensed software is installed, each software executable file contains information that is generally populated by the publisher of the software. That information generally defines the file’s publisher, the software title, the software version, and specific copyright notice.
Most auto‐discovery tools will query for this information and return it. The result is an over‐abundance of information about most, if not all, of the executable files on every discovered machine. In today’s world, a typical machine might have hundreds if not thousands of such files ‐ each being reported.
The problem is, very few of the reported executable files actually represent software that requires a license. Additionally, those that do require a license often cannot describe what the terms of the license are. An Original Equipment Manufacturer (OEM) license of Microsoft Office (which, by license, cannot be transferred to another machine) cannot be differentiated from a non‐OEM license. This is because at the executable level, there is no difference ‐ only the license terms are different.
If you are attempting to match auto‐discovered software to purchased software, you are left with the daunting task of sifting through tens of, or hundreds of, thousands of individual software records, trying to determine which represent installations of software that requires licenses. Without some form of automated assistance, the task is insurmountable. Even with automated assistance, however, the task is still complex and time consuming.
2: Insufficient Purchasing Records
Businesses that overcome the first challenge are often surprised to find more installations of software than expected ‐ or installations of the wrong software. For example, the business owns licenses to Visio Standard but finds that mostly Visio Professional has been installed in the environment.
Based on how most businesses procure software and hardware, this should not be a surprise, and yet it often is. In just about any organization, an employee can purchase software on a “P” (purchasing) card, or credit card, and expense the purchase. Even though there may be a policy prohibiting that behavior, the fact is that few companies audit for compliance and even fewer, if any, take any action if such behavior is discovered. So, as is often the case, the path of least resistance is taken by employees seeking software. Additionally, independent operating entities, including small offices or business units, will often purchase software locally ‐ a practice that is not visible at enterprise level where the compliance compilations are being attempted. As another example, many companies do not “lock down” the desktop, and employees routinely download software from the internet as a result. Again, policies may exist prohibiting this behavior, but compliance monitoring is spotty ‐ so the behavior exists.
Many fail to overcome this challenge and therefore never get to experience the other two challenges.
The result of this cumulative behavior is the introduction of software ‐ much of it purchased in some form or fashion ‐ for which proof of license cannot be demonstrated. Not only can proof of purchase not be demonstrated, but local purchasing of software is done usually without respect to type of license, where “cheapest” is usually the primary consideration, so the terms under which the license was procured are often not known or documented. As described earlier, auto‐discovery cannot assist in identifying the license terms governing installed software, but it will find the software, so this widespread practice adds the additional risk that even if the company closes any compliance gap by purchasing additional licenses, a compliance issue may still persist depending on the unknown license terms of the “rogue” installations.
3: Complex Licensing
Many software licenses are complex and it seems are getting more so, with complicated formulas to determine how many license “units” are required to properly license a given installation. This is particularly true of server‐based licenses. With these types of licenses, auto-discovery is of limited benefit in that it typically cannot be used to directly determine the installed base. Software License Managers will often resort to the concept of “Application Owners” ‐ individuals who are responsible for the application and are therefore being held accountable for periodically reporting the appropriate license metrics ‐ as well as other “proxies” to closely approximate an application’s installed base (such as the number of email accounts or active logins). This tends to be more art than science, is very time consuming, and therefore is mostly done at true‐up time or in response to an audit.
4: Documenting an Out‐of‐Compliance Position
It is after having overcome the previous challenges that the last, and most costly, challenge emerges. Because of the inability to prove license coverage for all the installations that auto‐discovery identified, and because the company attempted to show compliance for all software, the result ends up being a formal report that demonstrates non-compliance. Once the report has been produced, the company is now in a worse position because it cannot simply choose to ignore the results. Either software must be de‐installed or additional licenses must be procured. To do otherwise would be to wilfully violate governing copyright law.
Is Compliance the Correct Focus?
It seems that most organizations focus on compliance when they consider software license management. However, there is a cost associated with managing software, and there is little value to be gained unless you are audited ‐ and even then the cost avoided may not offset the investment made to maintain a proactive software license management (SLM) program. Many organizations fail to consider the real value ‐ harvesting and re‐using software ‐ as the main focus for SLM. That is not to say their programs do not attempt to keep track of unused licenses and re‐use them when possible ‐ because they do. However, if you ask an executive about the purpose of the SLM program, he or she is more likely to answer “compliance.” The attempt to re‐use licenses ends up as a low‐level exercise and is usually far from optimized in its ability to produce value. In order to achieve maximum SLM value, harvesting needs to be the primary focus or the reason for the program. Compliance then becomes a by‐product.
Why is the focus important? Because a program designed around the objective of yielding tangible harvest value is different than one that is designed to ensure compliance. The processes are different, the organizational messages are different, and the embedded behavior drivers are different.
SLM = Risk Management
When you purchase an insurance policy, do you ask for unlimited coverage? “No” is the probable answer. It is unlikely an insurance company would offer it even if you did ask and it is even more unlikely that you could afford it if it were offered. Instead, you purchase a policy that extends a coverage limit that agrees with your assessment of the risk you are mitigating versus the cost of the policy. This thought process is common in many decisions ‐ both personal and business ‐ and not just in purchasing insurance.
This sets the stage for an important question. If it is common to attempt to balance the cost of mitigating risk with the actual risk being mitigated, why, then, do most businesses seek a zero‐risk position when it comes to software compliance and license management?
Tracking compliance costs money and the money being spent is in hopes of mitigating the risk of an audit that may result in having to spend unbudgeted dollars. Software license compliance is analogous to an insurance policy, and the same thought process should prevail ‐ balance the cost of maintaining a compliance position with the risk of potential audit, and such a balance is almost certainly not in attempting to maintain a compliance position on every title of software in the enterprise. Yet, that is exactly what most businesses attempt to do when they look at pursuing software license management and compliance.
Even when focusing the program on harvesting and making compliance a tangential pursuit, the thought process should be about maximizing return on investment (ROI), as with any other business decision. Maximizing ROI will also usually preclude pursuing all software titles currently installed/active in the enterprise.
The answer is to analyze and understand where the risk and value lie and to use that information to form a Managed Software List (MSL). The risk and value usually lie in the same area, which tends to be fewer than twenty percent of the software titles in any given enterprise. By focusing the software license management program on the twenty percent, up to eighty percent of the value/risk can be addressed.
The Managed Software List (MSL)
The Managed Software List is the list of software titles for which the organization has decided to proactively pursue license harvesting and, tangentially, compliance. The MSL is managed via strict governance, has specific criteria that must be met for a title to be considered for the MSL, and has an “elevated” meaning to the organization.
Take the Risk
In practically every decision a business makes an element of risk is expected ‐ and taken. After all, the cost of a zero‐risk position is almost always prohibitive. Yet, when it comes to managing software compliance, the typical company attempts to tackle maintaining compliance on every software title found in the environment ‐ regardless of how small the deployment. Consciously or not, most organizations seek a zero‐risk position when it comes to software compliance. This is possibly due to not fully understanding the complexity and the cost of attempting full compliance tracking.
The “80/20 Rule” Applies
Eighty percent of the ubiquity, value, and risk of software installed in the environment are distributed over twenty percent, if that, of the titles. One of the precepts of the MSL is that it focuses on where the value and risk lie.
To be considered for inclusion on the MSL, the following criteria should be met:
- The title must represent reasonable harvest value. It should be a title that is still largely in use and in demand within the enterprise. It should have high ubiquity, which is a large deployed base.
- The license terms must support the following:
- The license must be transferrable, meaning it can be transferred from one hardware asset to another. This is not always the case.
- The publisher will accept proof of purchase and payment as proof of license. Although this is the general industry practice, by US Copyright law proof of license is whatever the license terms dictate. To be thorough, therefore, the terms of an MSL title should explicitly state that proof of purchase and payment will be accepted as proof of license.
- MSL licenses should be centrally negotiated and managed. If a title is on the MSL, then local contract negotiation should not be permitted. Why? Because if auto‐discovery is going to be used to assist in determining the installed base (and it should), it cannot differentiate installs governed under one set of license terms from installs governed under another. Therefore, for MSL titles, centralizing the contract removes ambiguity over which terms might be in force on any given install. The only other alternative is to limit the scope of auto‐discovery ‐ which may or may not be technically possible.
- Licenses should be purchased from a Tier 1 vendor. This is for two reasons:
- A Tier 1 vendor is less likely to source counterfeit software, which makes a publisher more likely to accept proof of purchase/payment as proof of license.
- A Tier 1 vendor can support sourcing Advanced Shipping Notices (ASNs), which are the most efficient way of establishing and maintaining your current “owned” license position.
- A problematic audit history might cause a title to be considered for inclusion in the MSL or a title from a publisher who has a reputation for aggressively pursuing audits. There are times when ubiquity alone does not adequately address the potential risk.
As titles are considered for inclusion in the MSL, they should be measured against these criteria. Also, as the MSL is initially formed, current practices should be strengthened for any initial MSL titles that do not presently meet these criteria.
The MSL Must be Under Governance
The MSL represents the risk and value that the enterprise is willing to cover/pursue when it comes to software. There are usually many stakeholders in that decision. Also, the MSL is not static. Over time, ubiquity will change as will the nature of publishers. This change activity will cause some titles to drop from the MSL, while others are added. The decision to drop/add titles must be managed under governance. The general recommendation is to place the MSL under an existing strategic governance body, such as a Change Advisory Board (CAB), comprised of the proper stakeholders. Stakeholders are generally the Software License Management group, application owners (of the MSL titles), contracting, purchasing, internal audit, IT infrastructure, and legal.
How to Establish the MSL
Establishing the MSL requires some initial data gathering. Depending on existing data sources, an initial MSL can be established in about four weeks’ time by a knowledgeable consultant. The data used to form the MSL consists primarily of auto‐discovered software information from whatever auto‐discovery tool may be installed in the environment and software maintenance contract spend information, generally available from IT Contract Management. The data is organized to form the “knee” charts shown in Figures 1 and 2. The “knee” charts are used to form a visual “cut-off” and then raw data is analyzed below the cut-off to determine actual licensed software titles. The result is the initial MSL ‐ based on ubiquity of spend and deployments. The next step is to accept the initial MSL into governance and begin to align contracts, agreements, and internal practices to agree with the precepts of an MSL title.
MSL Titles have an “Elevated” Meaning
After having set up the initial MSL and its governance, your work does not stop there. It is important to begin a communications program to the organization at large about the MSL and what it means. Why? The biggest reason is to stop “back‐channel” acquisition of MSL titles. “Back‐channel” is any channel other than the prescribed method for acquiring MSL titles. As mentioned earlier in this article, such channels include purchasing from a local supplier ‐ either on a local contract or via credit card and downloading from the web and paying by credit card.
Since the primary focus of a Software License Management program is to produce tangible value through software harvesting and re‐use, understanding the compliance position of MSL titles is actually more important than before. That necessitates taking appropriate means to shut down (as much as possible) the back‐channels. The most effective means, as always, is a monetary system of charges. Any time a rogue install is discovered, the organization that owns the asset on which it was discovered is charged street price. This causes the organization to get charged twice, which quickly curbs the behavior (this has been proven to work very effectively in a Fortune 500 enterprise). The way this gets communicated is that the second charge is required since the software is an MSL title, and any license must be (re)purchased but under the global standard terms to ensure that it can be properly managed, harvested and re‐used among other reasons.
The communications program should seek to create an understanding in all software users that an MSL title is to be treated differently than a non‐MSL title, similar to how an employee is expected to treat company proprietary information versus public domain information ‐ it is handled with a higher degree of diligence.
What About Non-MSL Titles?
Does forming an MSL mean that all other software will now be ignored? No. It just means that whatever the enterprise was doing about software license management and compliance before the MSL was formed, it will continue to do for those non‐MSL titles afterwards. What this generally means is that the organization will be in a “reactive” state in the unlikely event of an audit on a non‐MSL title. It will have to form a response team, dig up information to support the audit response and negotiate through the process with the publisher or their audit agent(s). This is often the way that many organizations proceed today ‐ for all software titles. However, given that the MSL covers the ubiquitous software ‐ both from a deployed count basis and software spend basis ‐ the probability of a large unbudgeted expenditure due to such an unlikely audit is extremely low. Why? Because non‐MSL titles represent low installed base / low value software, which is why it is prudent to take the risk for those titles and reduce the cost of the SLM program by a significant factor.