Are Mandatory Software Inventory Tools on the Horizon?
By Christopher Barnett
Scott & Scott LLP
Software licensing compliance is a complex task to manage. The metrics for measuring compliance often are a challenge to gather, and those metrics typically are different from software publisher to software publisher. This means that software asset management (SAM) teams need to use multiple tools and processes to gather required data and then apply different sets of licensing rules to determine whether the number of software licenses owned is sufficient to support the measured usage…for each publisher. In complex environments, the task is daunting and continuous – as soon as a license position has been calculated for one publisher, it typically is time to begin a new review for the next.
The publishers themselves typically don’t offer much help when it comes to ongoing compliance activities, or, at least, they don’t offer much help that I would recommend accepting. Most of them will be happy to come in to your environment and to initiate what amounts to a voluntary audit, but the outcome of such reviews almost always requires a license purchase – there typically are no options offered to reduce any inadvertent shortfalls through re-deploying or uninstalling software. Moreover, publishers historically have done little or nothing to meaningfully simplify their license metrics or to make the job of collecting measurement data less of a burden.
That may be changing, but not necessarily in a way that benefits licensees.
Increasingly, publishers seem to be moving toward deployment frameworks where, in addition to any software that companies use for their business purposes, they also must deploy tools developed by the publishers in order to measure their usage of the production software on an ongoing basis. While the availability of a functioning, publisher-specific measurement tool would be nice in theory, the fact that the paradigm seems to be shifting toward mandatory use of such tools is troubling. I am very hesitant to ever advise my clients to install any “mandatory” applications in their environments, especially when some such tools may incorporate functionalities – such as automated, “phone home” data transfers to the publishers or “high water mark” usage targets – that essentially eliminate any flexibility that the licensee otherwise would have to remedy over-deployments. If companies are forced to deploy measurement tools in order to use a product, then they should expect their licensing expenditures to increase significantly, absent implementation of very robust internal controls to prevent unintended usage of software products.
Here is a quick summary of how the three of the most high-profile software publishers are addressing this issue.
Oracle
Oracle does not yet require or even offer the use of a particular tool in order to measure usage of its technology products (like its Database and Internet Application Server lines). However, because of the way that Oracle sets its customers up for failure – through its bundling of all added-cost options in standard installation files and its counter-intuitive “policies” related to topics like virtualization – its products arguably are most in need of an Oracle-specific tool to gather measurement data.
During an audit by Oracle’s License Management Services division (LMS), a licensee typically is asked to deploy a number of automated, LMS-developed scripts in order to gather measurement data. One option, in theory, would be to use those scripts on an ongoing basis in order to maintain compliance. However, the output of those scripts ordinarily is not aggregated for a complete environment, meaning that it would be necessary to gather and somehow compile separate outputs for each of the servers in an environment. In addition, the Oracle script output contents may be easy for Oracle to process using whatever tools it has available to assist in that task, but they are not at all easy for humans to read. Moreover, Oracle offers no roadmap to help companies align the output contents with their licensing obligations.
As an alternative, LMS has identified a number of third-party tools on its website (scroll down to “Tool Vendors”) that are capable of gathering relevant measurement data. Those tools can be extremely useful in gathering and presenting information that companies realistically can use to facilitate licensing decisions. However, it is important to keep in mind that most of those tools will entail added costs in the form of third-party licensing fees. Unfortunately, given the number of pitfalls associated with Oracle’s licensing practices, those costs (or fees paid to experienced Oracle licensing consultants) often are a practical necessity when using Oracle’s products.
IBM
Big Blue does not yet require its customers to deploy measurement tools in all circumstances, but it does require them to use an IBM-developed tool in order to take advantage of a more favorable licensing framework in virtualized environments. Under IBM’s sub-capacity licensing model for products licensed based on Processor Value Units (PVUs), companies my purchase licenses based upon the number of PVUs allocated to virtual servers running IBM products, as opposed to the number of PVUs associated with the full capacity of the physical hosts where those virtual servers are running. This can result in immense savings, especially when the number of virtual servers running IBM products is relatively low, compared to the total number of virtual servers in the environment.
However, in order to take advantage of such “sub-capacity” licensing, and absent the applicability of a handful of narrow exceptions, companies are contractually obligated to deploy and use IBM’s License Metric Tool (ILMT) on all systems where that licensing model is to be used. The good news is that ILMT is a free tool and that its reports generally are easy to generate and to read, once the tool is properly configured. In addition, ILMT does not (currently) incorporate any “phone-home” functionalities, and IBM should only receive ILMT outputs when it requests them from the company during a license review.
The bad news is that ILMT is notoriously difficult to deploy and to configure to accurately measure usage. It is an agent-based tool that requires an ILMT component to be installed on every system where sub-capacity usage is to be measured, in addition to a dedicated collection server to receive data from the agents. If one of those agents has a problem, then the resulting reporting will be inaccurate.
In addition, once configured ILMT will capture the maximum, “high-water mark” of sub-capacity product usage during a reporting period (at minimum, each calendar quarter). Since companies are obligated to provide IBM with all historical ILMT reports upon demand, they should expect that any spikes in product usage – even if associated with inadvertent, temporary system re-configurations – will result in audit findings and increased licensing fees.
Unfortunately, unless a company can demonstrate that it satisfies one of the extremely narrow ILMT exceptions (and most companies are not able to do so), ILMT is the only option for avoiding full-capacity licensing charges for virtualization environments. IBM thankfully has not yet indicated – to my knowledge – that it intends to require an ILMT-like tool to measure usage in non-sub-capacity scenarios. However, given IBM’s embrace of IT intelligence automation (reference the strides it has made recently with its Watson technology), it may be only a matter of time before all IBM software effectively audits itself.
Microsoft
Unlike with Oracle, usage of Microsoft’s products is relatively easy to measure using ordinary SAM processes, and unlike with IBM, Microsoft historically has not required companies to use any particular tools in order to measure such usage in any scenarios. Unfortunately, that may be changing.
Microsoft long has had a relationship with a company called Unified Logic, which in the past was among a number of firms that Microsoft hired in order to conduct software audits. Unified Logic has developed a tool – called Movere – that gathers (among other things) the information that a company may require in order to assess Microsoft licensing requirements. By itself, that certainly is not a bad thing – good tools are an important piece of the SAM puzzle (though, they’re not the whole puzzle, as discussed below). However, we increasingly are seeing Microsoft require companies to use Movere as part of Microsoft’s non-contractual SAM engagements and sometimes in order to facilitate procurement or dispute-resolution discussions. Microsoft seems to be especially fond of Movere, in part, because it purports to identify the “high-water mark” of product usage for a given analysis period. As with IBM and ILMT, companies should expect even inadvertent, temporary over-consumption of Microsoft products reflected in Movere’s output to result in increased licensing fees.
Movere is not yet identified as a required tool in Microsoft’s contracts, but Microsoft’s standard audit clause now is drafted in a way that Microsoft arguably could require companies to use the tool during an audit. In addition, in Enterprise Agreements, the contractual true-up obligation for some products now references the “maximum” usage of those products during the true-up period, which aligns with what Unified Logic claims Movere is capable of measuring.
Past Movere, we also have started to see some mandatory-tool language begin to appear in some Microsoft agreements. For example, companies licensing software under a Services Provider License Agreement (SPLA) that want to host O365 client software for their clients now may sign a SPLA addendum that identifies them as a “Shared Computer Activation Qualified Cloud Provider.” That addendum obligates the SPLA licensee to deploy a “machine cookie” (once made available by Microsoft) in the registry of each machine used to host the O365 software, and that “machine cookie” then automatically gathers and reports to Microsoft information related to the usage of that software.
It seems like it is only a matter of time before that concept is adapted to require the use of Movere or a similar tool.
Being contractually obligated to deploy any tool – especially one that phones home to tattle about a company’s “high-water mark” – is bad enough. However, perhaps the worst part of this new paradigm is the fact that tools are simply a means to an end. In our experience, they almost never are an end themselves, in part, because they almost never provide a complete and correct picture of a company’s software consumption. Sometimes that is due to the fact that a particular IT environment is not compatible with a particular tool, requiring a more flexible approach to data collection. More importantly, though, every license review requires discretion and discussion in order to identify exceptions to licensing rules and instances where tool-gathered data simply are incorrect and in need of correction. The fact that software publishers to some degree seem to be moving toward a myopic, tool-centric approach to licensing is troubling.
