As organizations embark on a Software Asset Management (SAM) program, their first focus is usually on producing a compliance report. What is seldom, if ever, considered is the need to address certain organizational behaviors that contribute to out-of-compliance positions. The result is almost always Compliance Drift, or the inability to hold a compliance position once established.
Pulling together an understanding of the current compliance position on various software titles is usually the primary, initial focus of a SAM program. It is a project in and of itself and can take months, if not longer, to achieve. Once it is achieved, the Software Asset Manager may be surprised to have an out-of-compliance position on one or more titles. Oftentimes, the out-of-compliance position can be significant. Then the clamoring begins – how do we remediate and bring the organization back into compliance? The options considered usually range from simply purchasing enough licenses to close the gap, and/or de-installing the software from various computers. The clock is usually ticking as well, since, once the compliance position has been documented, the organization is now in willful violation of the licensing and possibly U.S. Copyright and other laws (1). The paper shows that U.S. law does not support the concept of simply de-installing software to restore compliance. Once the software has been used without proper license, the assumption is its use created benefit to the organization and the organization can be held liable for that benefit. De-installing the software after the fact cannot undo the period of benefit.
Organizations are well-advised to seek legal counsel prior to commencing any license compliance remediation efforts. Despite the risks previously mentioned with de-installing software to restore compliance, many organizations opt for that action as part of their remediation strategy. However, determining who gets to keep the software and who has to give it up can often be a significant sticking point. Also, if remediation includes purchasing some additional licenses to close the compliance gap, determining whose budget will be paying for those licenses is another sticking point. Both points could require weeks of deliberation and meetings in order to reach agreement on a strategy and/or budget approval. After those hurdles are overcome, there is the technical hurdle of exactly how the software will be de-installed. De-installation is another small project that requires planning, proper execution and oversight. This is how remediation of a compliance position, even for just a single title, can quickly stretch into a sizable project, consuming unplanned time and resources. This cycle is then repeated for other titles that are found to be out of compliance.
The issue is unless an organization wants to be in the business of continuously remediating out-of-compliance positions; the organizational behavior that created those conditions must be addressed. There is a reason an out-of-compliance position exists, and unless that reason is addressed, all the effort that went into remediating the out-of-compliance position will have to be spent again in the future as the restored compliance position will assuredly drift over time, due to the behaviors that created the out-of-compliance position originally. “Insanity” has been defined as continuing to do the same things, but expecting different results. That definition applies to being able to hold a compliance position once it has been established.
Until relatively recently, the threat of being audited for software compliance was a probabilistic event – with a low probability. Over the past several years that probability has shifted and become more of a certainty – organizations will be, and are being, audited for compliance. It has become how publishers do business and there is no reason to expect it to subside. This reality has organizations scrambling to implement a SAM practice in order to counter that threat and alleviate the risk of unexpected and unbudgeted settlements that accompany the typical audit.
However, back when the threat was low, certain attitudes toward software were formed and those attitudes influenced organizational behavior. Whether or not software was properly licensed for a given installation was a consideration, but it was usually lower in priority that acquiring the hardware and ensuring the proper resources were on the project. This led to behaviors such as deploying development licenses into production, or sometimes deploying software without license. Additionally, organizations did not put a priority on making sure legitimately acquiring new software was quick and easy. Instead, a user or project would, and still may, have to endure creating a purchase requisition, getting it approved, waiting for the purchasing cycle to complete, contacting the service desk to schedule installation, and then waiting for the installation cycle to complete.
The cycle time alone can be a significant deterrent, which then leads people to seek alternate sources for the software they need. The cycle time deterrent, by the way, is also often a reason departments will hold on to software they don’t use as they do not want to endure the request cycle again. Downloading from the internet, purchasing the software from a local store and expensing it, “pulling rank” on a technician (getting the technician to install software while they are desk-side performing some other task), purchasing through local contracts – are just some of the ways people use for obtaining software through “back channels.” People will always seek the path of least resistance – and it is true when it comes to acquiring and installing software. The problem it creates, however, is a deployment (which will be found and counted) without a record of purchase. The result is Compliance Drift.
Aiding and Abetting Compliance Drift
Other factors contribute to compliance drift. Licensing is complicated – and it appears to be getting more so. Even well-intentioned users and project leads will cause out-of-compliance issues simply because they do not properly understand the licensing rules and constraints. For example, a user downloads Adobe trial version from the internet, clicks through and accepts the license agreement, installs the product and uses it to finish whatever task they needed it for. But then it stays loaded, and after 30 days, per the license agreement, a full license is required. The user believes they have a trial version on their machine (who bothers to read the click-through agreements?) and that the trial simply expired without further issue. They are completely unaware that their action created risk for the organization in the form of an out-of-compliance position for an Adobe product. In another example, the technicians know that the organization has an “Enterprise” agreement (EA) with Microsoft, and they believe that means that everyone is entitled to any Microsoft title. Therefore, they recommend and install “pro” versions of various titles when “standard” would have sufficed. The technicians themselves create an imbalance in the Microsoft EA counts without realizing they are doing it. In yet another example, the Citrix team believes that by virtualizing the desktop through Citrix, that they only need sufficient Microsoft licenses to handle the concurrent usage. And finally, a development team brings up a new capability making use of development licensing and, after testing has completed, rolls it into production, thereby violating the license agreement.
The point is that legacy organizational behavior directly impacts license compliance, and that behavior began, in many organizations, years ago when attitudes toward software were much different than they need to be in today’s environment.
SAM programs need to be focused on more than just creating a compliance report. There is risk in solely focusing on that task since, if organizational behavior and attitudes are not also addressed, the likelihood of compliance drift is very high. The presence of a documented compliance position and Compliance Drift actually can place an organization in a worse position.
SAM programs should include addressing organizational behavior while endeavoring to pull together a compliance report. The following points should be considered:
- Embrace the concept of Application Owners (2). Application Owners not only assist in counting and reporting the deployed position of non-auto-discoverable titles, they also are advocates for SAM and are accountable for understanding the license terms of the titles for which they are responsible. They become education arms for SAM in helping the organization understand the various licensing terms
- Establish a marketing and communications (MARCOM) program. The purpose of the program is to effectively market the concept of SAM – to slowly change embedded attitudes toward software and licensing. MARCOM seems “soft” to many SAM leads and it is often not given its due. ESI finds, however, that an effective MARCOM program can significantly assist in holding license compliance
- Implement a system of financial incentives and disincentives. Nothing speaks louder than finances, where real money is being forfeited for improper behavior and/or gained for following the prescribed processes. ESI finds that a well-designed financial incentive/disincentive system can effectively nullify back-channel acquisition
- Make sure the prescribed way of acquiring software is the fastest way possible. Knowing that people will seek the path of least resistance, effort should be spent in streamlining the software acquisition cycle. This is important in helping to nullify back-channel acquisition. A typical implementation includes a self-service web-based request portal that automates the complete cycle – from request through to actual automated install of the software. Additionally, ESI has found that cutting the Purchasing department out of the request cycle reduces the time through the average cycle from days to minutes. (This results in an additional side benefit of reduced volume of purchase requests that have to be processed by Purchasing.)
- Understand and embrace the role of SAM as an educator and vocal advocate of licensing compliance within the organization. An effective SAM program usually has a lead that is visible and vocal within the organization. The role of vocal advocate is as important (if not more important) as the role of tracking the current compliance position
- Form a Managed Software List (MSL) and focus your efforts on the titles that represent the highest value and risk. Limit the scope of the SAM program so that it can be successful and deliver tangible results to the organization(3)
Compliance drift is a threat to any SAM program’s efforts. If not addressed, it can cause the SAM program to actually cost the company more money than before by having to continuously address documented out-of-compliance positions. Addressing Compliance Drift should be high on any SAM programs list of things to do.
- Readers are encouraged to review the eTelligent Solutions (ESI) White Paper entitled “Software Licensing Law, Your Rights and Responsibilities” under the tab at www.etelligentsolutions.com.
- “Counting Data Center Titles – Where’s the Silver Bullet” LitePaper™ under the tab at www.etelligentsolutions.com.
- “The Managed Software List” White Paper under the tab at www.etelligentsolutions.com.