When leveraging automation software as part of an outsourcing relationship, it is important to document what specific benefits will be realized and the impact on the overall transaction, and to consider the appropriate mechanisms to ensure that implementation, intellectual property, and exit rights are mitigated, advises Morgan, Lewis & Bockius in a web post.

Authors Barbara Murphy Melby and Sarah Bryan cover the license, implementation, intellectual property rights, total cost of ownership, and liability.

Read the article.

Fitch, Even, Tabin & Flannery LLP will present a free webinar, “Navigating Open Source Risk with Tools for Usage Evaluation and License Compliance,” featuring Philip Odence of Black Duck On-Demand and Fitch Even partners Amanda Lowerre O’Donnell, Joseph F. Marinelli, and Steven G. Parmelee.

The event will be Thursday, February 28, at 9:00 am PST / 10:00 am MST / 11:00 am CST / 12 noon EST.

Software is increasingly incorporated into products released into the market, and more companies are releasing mobile applications every day. As the percentage of open source content in use rises, the legal and security risks accompanying such use needs to be actively managed. During this webinar, presenters will provide background information and actionable advice that will assist in handling open source.

Among other insights, presenters will discuss the following:

• Assessing license compliance and compatibility
• Leveraging tools to monitor and assess risks associated with software deals and open source software incorporated into a company’s code
• Creating programs and policies to effectively manage a company’s incorporation of open source into its code
• External web service call-out or API identification and management of associated obligations, risks, and privacy concerns

Register for the webinar.

Corporate counsel often hire external technology lawyers to review, draft, or negotiate technology contracts such as software licensing agreements because of their ability to identify software licensing issues, resolve complex licensing models, and compare the subject deal to the many other unique technology contract structures to solve problems, according to a blog post by Kirkpatrick Law.

There are a few technology contract types that should signal a need for a technology attorney to review, so the article lists some software examples to narrow the focus, but these could be true for other technology types.

The article covers one-sided enterprise agreements, the short and simple agreement, and the standard agreement.

Read the article.

By Christopher Barnett
Scott & Scott LLP

In order to effectively manage their software usage and to mitigate compliance exposure, companies need to know how to gather and analyze information regarding their product usage. While some software products may have unique data-collection requirements that ordinarily would not be applicable for other products, usage levels for many products can be measured using a common set of reports that companies can prepare themselves to gather. The purpose of this and other posts in this series of blog entries is to give companies insight regarding how to gather those datasets and why that information is relevant to their licensing obligations.
______________

The backbone of deployment data for many products is a list of all devices in an IT environment capable of running or interacting with a licensed software product. This inventory should include all physical and virtual workstations and servers. In many cases, it also should include devices like thin clients that may not be capable of running installed copies of software, but that can be used to access software deployed in server environments. The list also should include information regarding the make and model of each device as well as the make, model and quantity of processors and processor cores for physical servers and virtualization hosts. (Note that information regarding virtualization environments will be discussed in a separate entry in this series.) Finally, in order to validate the completeness of the principal hardware inventory, it almost always is a good idea to obtain a secondary inventory from a source like Active Directory or an antivirus solution.

Tools

Most companies use automated, software-based inventory tools in order to gather information regarding the hardware and software present in their IT environments. Using tools is not absolutely necessary – especially in very small environments – where a physical machine count, purchasing records, and change logs may provide sufficient information to allow a company to know what it owns. However, tool-based inventories almost always represent a best practice, since manually maintained reports should be audited against other data sources. Furthermore, it is typically much less practical to maintain a software inventory manually, and the tools used to gather software-installation data for an environment typically can provide all the information needed for a hardware inventory.

The tools used will vary depending on the types of software being run in the environment and on the way that the IT resources are configured. For example, an “agentless” tool – which consists of a centralized installation that uses communication protocols to remotely gather information from other machines on a network – may be the best choice for companies that have relatively simple networks with limited numbers of domain-administrator-level credentials that can be used to access all connected devices. Agentless tools usually are less expensive and easier to deploy than other kinds of solutions. Microsoft’s MAP Toolkit is a free, agentless tool and is one of the most widely used solutions for gathering information regarding Windows-based environments. Spiceworks is another, popular, agentless tool.

However, in some cases, an agentless tool may be a bad fit. Some environments may be based on global deployments residing within multiple different domains that do not share a common set of administrative credentials. Alternatively, it may be necessary for an environment to be highly segmented for security reasons, with that segmentation effectively preventing an agentless tool from gathering information from resources in other segments. In these circumstances, an “agent-based” tool – consisting of a centralized management console and multiple, small “agent” installations on each computer deployed within an environment – may be a better fit. In that scenario, the agents typically do a more thorough job of gathering information regarding the machines where they are installed and often can be used to remotely manage those machines in addition to simply gathering data. Furthermore, agent-based tools can take advantage of encryption technology and a wider variety of communication protocols to avoid the kinds of network-configuration obstacles that may prevent agentless tools from providing meaningful information. Unfortunately, all of that functionality comes at a cost, as agent-based tools often are much more expensive and much more difficult to successfully install and configure. Ivanti IT Asset Management (formerly known as LANDESK) is a very popular agent-based tool. IBM’s License Metric Tool is another well-known (perhaps infamous) agent-based tool that may be required for companies using certain kinds of IBM software in certain kinds of environments.

Some smaller companies may not want to invest the capital or resources to deploy an IT asset discovery tool but still may not want to rely on manually-maintained inventories. In those circumstances, it may be feasible to gather information using scripts or system queries that provide the same kind of information as automated tools, but via an ad hoc process. In Windows-based environments, PowerShell queries can deliver a wealth of information regarding machines residing with the same Active Directory architecture and also regarding the users accessing those machines. System queries also play an important role in environments running Oracle software. Oracle’s License Management Services (LMS) auditors have identified a number of “verified” third-party tools capable of gathering information useful for managing Oracle license compliance. However, the most common way to gather Oracle usage data (and the way preferred by Oracle LMS) is via a set of proprietary scripts and queries that are made available during an Oracle audit. Unfortunately, Oracle LMS does not make the full set of tools publicly available, though Oracle does offer a free Database Option and Management Pack Usage script here.

In addition to the primary discovery tool, companies also should identify a secondary source of information regarding the devices running within their networks. The purpose of this kind of secondary source is to provide a means to measure the completeness of the primary inventory. If there are machines identified in the secondary inventory that are not being captured by the primary inventory tool, then a company knows either that the secondary inventory is over-inclusive and needs to be cleaned up or (more critically) that the company needs to continue deploying or configuring the primary tool to capture all of the company’s computers. Given the limited purpose of the secondary inventory, it may consist of reporting out of a variety of different tools or systems and really needs to consist only of a list of machines and (preferably) the operating systems running on those machines. There are a number of Active Directory queries that can be used in order to generate such a list. Other possible sources of information are lists of machines managed by an anti-virus solution or lists of machines identified within procurement or change-management systems.

Finding the right discovery tool for an IT environment can be a time-consuming and even expensive undertaking, but it is an important one. Most companies need to have a software-based tool for gathering the information required to maintain compliance with their license agreements. However, it also is important to keep in mind the fact that no tool is a silver bullet for compliance. All tools must be periodically tested on a regular basis to ensure that they are working properly. Furthermore, while many tools offer license-management functions, those functions face a dynamic obstacle in the form of software publishers’ ever-evolving license metrics and rules. In order to ensure compliance, it always is necessary to reconcile inventory data against the most current iteration of those rules, and that analysis may need to be a manual one.

When entering into licenses for commercially available, off-the-shelf software products, it is common to use the “vendor’s paper” for contracting, according to a post on Morgan, Lewis & Bockius LLP’s Tech & Sourcing blog.

“Using the vendor’s paper does not mean that the contract shouldn’t be reviewed and negotiated to ensure that key issues are addressed,” point out Barbara Murphy and Eric J. Pennesi.

In part 1 of the article, they discuss license types, use within the enterprise and by third parties, divestitures and acquisitions, nonproduction use, the right to relocate or change users, use outside the United States, the obligation to support, rights to successor products, payments and escalators for renewal terms.

A link on the article takes the reader to part 2 of the discussion.

Read the article.

By Keli Johnson Swan
Scott & Scott LLP

Virtualization can reduce the number of physical machines required in an environment and have several other benefits, but it can also require an understanding of complex technical and licensing concepts. Failure to properly license the environment can subject the company to unbudgeted licensing and compliance fees. The following list includes several common questions and concerns related to licensing VMware.

I. Third Party Use: Can VMware Tools be accessed by third parties?
Yes, a third party may access VMware Tools on a machine owned by the licensee, but only if a Guest Operating System is installed within a Virtual Machine. The End User License Agreement defines a Guest Operating System as “instances of third-party operating systems licensed by You, installed in a Virtual Machine and run using the Software.” It is critical to note that the customer is responsible for ensuring that any third party it distributes VMware Tools to complies with the terms of the license agreement, or it may be liable for potential copyright infringement and breach of contract claims. See VMware End User License Agreement (“EULA”), Sections 1.3 and 2.5.

II. What other restrictions apply to Third Party Use?
Although a customer may use VMware to deliver hosted services to third parties, there are numerous restrictions regarding what functionality may be shared without VMware’s written consent. Third parties may not use the software as service bureaus or application service provider or similar capacities, and licensee must not transfer or sublicense any software without VMware’s consent. Further, certain benchmark testing results may not be shared externally, nor any reverse engineering information of the software. The license agreement also restricts circumvention of any security protocols, which are also covered by the Digital Millennium Copyright Act (“DMCA”). See VMware End User License Agreement (“EULA”), Section 3.1 and 17 U.S.C §1201.

III. Conflicting Terms: Does an Order supersede the End User License Agreement?
No. All terms of the Order are subject to the EULA and are not deemed valid until accepted by VMware. The Order may outline specific use of a product but if the terms conflict, look to the EULA. A change to the EULA requires VMware’s written agreement to change standard license terms. See VMware End User License Agreement (“EULA”), Section 4.

IV. Audit Rights and Record Retention: What are VMware’s audit rights?
The EULA grants VMware the right to audit a company at any time during the License Term (identified in the Order) and two years following the expiration of the license term. This provision requires the customer to retain records for up to two years following the expiration of the license term and allow VMware to conduct a software audit to ensure compliance with the license agreement.

VMware or a third-party auditor may audit a customer with “reasonable notice” once in a 12-month period during normal business hours. A customer must immediately remediate any non-compliance. If the audit reveals the customer has underpaid license fees of more than 5% or failed to maintain proper records of software use, it must pay VMware’s costs to audit in addition to any fees for remediation. See VMware End User License Agreement (“EULA”), Section 5.

This provision represents one of the largest risks during a customer’s relationship with VMWare. The customer must accurately maintain all records related to VMware usage and license information. If a customer fails to properly account for its usage, VMware may attempt to extrapolate the data in a light least favorable to the customer, which could significantly increase its monetary damages for non-compliance. Additionally, failure to comply with the terms of the license agreement could result in involuntary termination. See VMware End User License Agreement (“EULA”), Section 10.

V. Termination: Does VMware have the right to terminate the licenses?
Yes. VMware is allowed to terminate the license pursuant to the EULA for the following reasons:

a. Breach of the Agreement
VMware is allowed to terminate the agreement for non-payment of the Order within 10 days of sending the customer a written notice. Additionally, VMware is allowed to terminate the licenses if a customer breaches the terms of the agreement and does not correct the breach within 30 days of receipt of VMware’s written notice. This provision is particularly important because VMware can terminate the licenses for failing to comply with the licensing terms.

b. Insolvency
VMware may also terminate the licenses if a customer becomes insolvent (through the admission in writing or in bankruptcy proceedings).

The End User License Agreement does not contemplate termination by the licensee except upon the termination of the license term. See VMware End User License Agreement (“EULA”), Section 10.

VI. Effects of Termination: What happens to the licenses after Involuntary Termination?
If VMware terminates a license, the customer no longer has the right to install or access the software. Additionally, the EULA requires the customer to immediately stop using the software and uninstall it and return any media. See VMware End User License Agreement (“EULA”), Section 10.

VII. Confidentiality: Can a customer share VMware pricing or purchase orders?
No. Specific information, including license keys, pricing, marketing materials, or any other non-public information exchanged between the customer and VMware are confidential and may not be shared without VMWare’s permission. It is important to note that this provision survives the termination of the agreement. See VMware End User License Agreement (“EULA”), Section 10 and 11.1.

VIII. Data Privacy Implications: Does VMware protect customer data?
The EULA acknowledges that VMware may obtain and share with a worldwide group of companies in furtherance of providing software services, but it agrees to act as the controller of this information and to comply with the applicable data protection legislation. See VMware End User License Agreement (“EULA”), Section 11.4.

Customers should carefully analyze VMware’s license terms and agreement in order to ensure that VMWare’s protections are sufficient for the customer’s needs.

See “VMware Audits – What You Need to Know About Licensing Rules Pt. I.”

Join Our LinkedIn Group

By Christopher Barnett
Scott & Scott LLP

Many of our clients have been contacting us in recent weeks (mid-late 2017) regarding notices they received from Microsoft requesting an internal self-assessment of their license positions under their Services Provider License Agreements (SPLAs). Naturally, many of those clients have questions about that process and the ramifications of cooperating with Microsoft.

For those who may be unaware, SPLA is the principal licensing framework that Microsoft uses in order to enable online service providers to incorporate Microsoft’s software products in the solutions that those providers host for their customers over the Internet. Unlike traditional license agreements, which typically entail capital expenditures in order to acquire perpetual software licenses that can last longer than the term of the purchasing agreement, SPLA entails a monthly reporting model. Each month, service providers measure their usage of Microsoft products in their hosted environments, and they report that usage to authorized SPLA resellers. The resellers then generate invoices based on those reports, which the service providers typically pay as an operating expense.

Like all commercial Microsoft licensing agreements, SPLA gives Microsoft the right to conduct audits to verify that its products are being used (and reported) consistent with applicable licensing terms. In many cases, Microsoft designates third-party firms, such as KPMG, Deloitte or Pricewaterhouse, to gather the necessary inventory data and to prepare a report comparing the usage previously reported under SPLA against the deployments measured based on the audit data. Microsoft then reviews the auditors’ reports, and the audited companies then usually place supplemental license orders under their SPLAs in order to resolve any under-reporting identified through the audit process. For service providers with high volumes of monthly usage, the dollar amounts of those supplemental orders can be well into the millions of dollars.

Under most SPLAs, Microsoft has the express right to require its SPLA licensees to complete the self-assessment process in lieu of submitting to a “traditional” SPLA audit conducted according to the process described above. However, even if that right were not stated in the SPLA, we would recommend that our clients comply with the self-assessment process in an effort to avoid any more burdensome audit activity to be undertaken by a third-party auditor. The self-assessment process represents a much more favorable framework for verifying compliance with SPLA, for at least the following reasons:

• No deployment or usage information needs to be submitted to Microsoft. In most cases, the self-assessment process typically is completed when a licensee provides a signed, written certification confirming that it has completed an internal review and either (1) that all SPLA usage has been properly reported, or (2) that a supplemental report has been submitted in order to resolve any identified, past under-reporting. It usually is not necessary to provide Microsoft with any deployment counts or any further details regarding the results of the internal review.
• No under-reporting penalties appear to apply. The SPLA self-assessment notice message typically requires only that a licensee report additional license quantities to the reseller in order to resolve any past errors. In other SPLA audits, Microsoft has the right to apply a contractual penalty for any under-reporting, and that penalty typically consists of 25% markup over list SPLA prices. The self-assessment notice does not indicate that the contractual penalty would apply for any supplemental orders placed as a result of the self-assessment process.

We therefore ordinarily recommend that our clients cooperate with SPLA self-assessment requests.

In theory, the self-assessment process should mirror a SPLA licensee’s monthly reporting process. If the licensee has mature software asset management (SAM) processes in place, then each month it should be gathering and archiving all the data that it should require in order to confirm its usage of any Microsoft products installed in its environment. For that reason, a confident licensee in that position could sign and return the requested self-assessment certification immediately upon receiving the self-assessment request.

However, many licensees are not in that position, and for them, the self-assessment represents an excellent opportunity to assess and review their internal monthly reporting processes. We regularly work with SPLA licensees to conduct those sorts of initiatives, identifying tools that would be capable of gathering information relevant to licensing information as well as reports that should be generated and gathered each month in order to confirm usage levels. While the kinds of reporting used will vary, depending on the kinds of Microsoft products being licensed under SPLA, the typical set of reports includes the following:

• Hardware Inventory – One or more reports identifying all physical and virtual servers and the operating systems running on those machines.
• Software Inventory – One or more reports showing all Microsoft products installed on the computers identified in the hardware inventory.
• Virtualization Data – Reporting that maps virtual machines to their physical hosts and provides relevant information regarding those hosts’ hardware configurations.
• Active Directory – Reporting that identifies the computers included in the hosting domain(s) and also the user groups and accounts with access to those computers.
• Secondary Inventories – While not requested in every audit, Microsoft’s auditors also may ask for secondary data sources to validate the completeness of the device inventories generated from the other sources identified above. The list of devices from an anti-virus solution is a common request.

We also typically advise our clients to create and maintain archives of all reports gathered each month in order to support their SPLA reports, so that historical usage may be validated during any SPLA conducted in the future by one of Microsoft’s selected audit firms. Absent that kind of historical data repository, Microsoft’s auditors often attempt to extrapolate historical usage levels based on data collected during the audit – those extrapolated findings often are inaccurate and can result in inflated SPLA audit resolution demands from Microsoft.

Business leaders who receive self-assessment requests from Microsoft should work with their teams to determine their level of confidence regarding the monthly SPLA-reporting practices. If there is any doubt regarding the maturity of those practices, then the team should undertake an initiative to implement any appropriate improvements and, absent any unique concerns, to provide a timely response to the self-assessment request. If the team believes that it lacks any subject-matter expertise in order to complete that initiative, then it makes sense to engage a knowledgeable attorney to assist with the process.

Robert J. Scott, who represents some of the world’s largest companies in enterprise transactions with Microsoft, will present a webinar on how the legal issues in enterprise agreements have shifted dramatically as Microsoft and other major vendors emphasize their cloud offerings.

The complimentary event will be Wednesday, August 23, 2017, at 11 a.m. CDT. CLE credit is pending in Texas.

Scott says The key issues in modern enterprise agreements are driven by privacy, security and regulatory compliance.

This webinar will discuss traditional and newly developed Microsoft licensing models, principal concerns about current licensing models, types of license agreements, and primary causes of exposure in enterprise-level Microsoft software audits. Scott will explain how he helps clients define their requirements up front, builds term sheets for negotiation, and how he approaches negotiating the key issues in Enterprise deals with Microsoft’s legal and business teams.

The webinar will cover:

Microsoft Licensing Models
*Perpetual vs. Subscription
*User vs. Device
*Microsoft’s SPE Offering

Agreement Types
*Microsoft Business & Services Agreement
*Online Subscription Agreement
*Enterprise Agreements and Enrollments
*Microsoft Products and Services Agreement (MPSA)

Key Legal Issues
* How to Define Requirements
* How to Build a Term Sheet
*Transitioning to Office 365
*Limitations of Liability
*True-Up Terms
*Price Protection
*Business Downturn
*Restacking Your CPS
*Audit Rights
*Regulatory Compliance – HIPAA, GLBA, GDPR
*Affiliate Definition
*Acquisitions and Divestitures

Register for the webinar.

Join Our LinkedIn Group

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.

Join Our LinkedIn Group

By Keli Johnson Swan
Scott & Scott LLP

Autodesk sometimes reaches out to its customers to offer additional services, products, or upgrades on existing software. Autodesk’s business team may offer to conduct a license assessment to confirm a customer is properly licensing all of its software as part of the offer to provide additional services.

Autodesk may also request that the customer use Autodesk’s Inventory Analyzer (“AIA”) tool to capture the installations on the network and submit the data to Autodesk to review. The self-assessment process with Autodesk’s business team is different from an Autodesk audit initiated either directly from Autodesk pursuant to Section 9.7 of Autodesk’s License and Services Agreement, or from an entity such as BSA| The Software Alliance, which pursues copyright infringement investigations on behalf of Autodesk.

In some cases, responding to a request for a self-assessment can escalate into a contractual audit. It is significantly more time-consuming and expensive to defend a contractual audit.

The following are tips for navigating the self-assessment process and reaching a resolution for any licensing disputes.

1. Conduct a secondary review of the audit data to confirm accuracy. Although no auditing tool is infallible to errors in reporting, Autodesk will typically use the AIA results without validating their accuracy. A secondary review of the audit data can identify and correct any mistakes, including erroneous reporting of the same installation of software under different Autodesk software suites. Because Autodesk regularly requires customers to make purchases based on the data from the AIA, it is important to ensure the AIA is accurately reporting the installations in the environment.

2. Carefully scrutinize reports of current licenses to ensure all licenses are properly reflected. In addition to ensuring the audit data is accurate, Autodesk customers should also ensure that Autodesk’s entitlement reports reflect all of its existing licenses. If a customer discovers that any licenses it owns are not registered, or registered in the wrong name, it should take all of the necessary steps to correct those issues. With few exceptions, Autodesk typically objects to requests to transfer ownership of a license.

3. Dispute any inaccuracies in Autodesk’s assessment of license gaps. Sometimes Autodesk and a customer may disagree about the existence of any gaps between the number of Autodesk installations and the number of entitlements the customer owns. The disagreement may stem from inaccurate installation information, failure to properly apply licenses for other versions of the products (e.g., downgrades or upgrades) or missing license entitlements. Regardless of the nature of the dispute, a customer should carefully review all of the terms and conditions of the relevant license agreements in to ensure that Autodesk is properly calculating any licensing deficiencies. If necessary, a customer may choose to provide additional information to clarify or resolve any disputes. For example, some Autodesk products allow a backup copy to be installed on a laptop as long as the laptop and desktop instances are not used concurrently and each copy is accessed only by the same user. A dispute may arise if Autodesk counts both installations and applies only a single license, therefore creating a deficiency where none exists according to the text of the license agreement.

4. Engage In Consistent Communications with Autodesk. The most common reason Autodesk may escalate a customer dispute to its legal team is because the customer refuses to communicate after receiving an audit report indicating that there are license deficiencies. If a customer stops communicating with the Autodesk sales team, Autodesk will often escalate the issue to the legal department, where the penalties can become more severe. Autodesk may require the customer to pay a penalty that greatly exceeds the MSRP of the products in question. Although customers should not concede to resolve the dispute if the audit data or license entitlements reflected on the audit findings are significantly incorrect, a customer should communicate in writing all objections to the audit findings. Although it is not ideal, from a financial perspective, a customer may choose to agree to disagree on some minor discrepancies related to the audit in order to reach an amicable resolution. If a customer chooses this option, it must ensure that the agreement reflects all of the necessary provisions to protect the customer against any future claims.

5. Negotiate a resolution that includes a release of liability for all claims existing at the time of the assessment. Non-traditional Autodesk audits may allow more flexible settlement terms, which include the acquisition of new products or subscription maintenance rather than paying a penalty for past infringement. However, the most important provision is the release of liability provision. This release ensures that Autodesk cannot later seek additional damages for licensing deficiencies that occurred prior to the settlement. Unless the settlement specifically includes the acquisition of software to cover the deficiencies, the release does not typically create a license. In other words, without either purchasing software to cover a deficiency or removing the deficient installation, Autodesk could assert a claim for infringement for any installation that remains deficient after the parties finalize the settlement agreement. Management may also choose to enact additional protocols to prevent any unauthorized installations on a customer’s network.

These are just a few key issues to consider when resolving an Autodesk software license dispute. If it becomes necessary, it may be helpful to consult an attorney with expertise in Autodesk licensing disputes.

Join Our LinkedIn Group

By Keli Johnson Swan
Scott & Scott LLP

BSA| The Software Alliance (the “BSA”) is an organization that acts on behalf of software publishers to enforce copyrights. The membership of the organization may undergo changes, which can impact an existing software audit if a member leaves during the course of the audit and the BSA no longer has power of attorney to enforce the copyrights.

The BSA has lost of a few members recently, including Parametric Technology Corporation (“PTC”), Minitab, and TechSmith Corporation. Some publishers choose to enforce their own copyrights, while others elect to engage competing organizations such as the Software & Information Industry Association (“SIIA”) or Software Compliance Group. Recently, the BSA also gained new members, including DataStax, Salesforce, Splunk, and Workday.

The changes to the BSA’s membership may affect the scope of the audit, and a company targeted by the BSA should take the following steps to mitigate its exposure.

1. Review the publishers identified in the initial audit letter

The BSA’s initial audit letter will identify the specific BSA members participating in that particular audit. Although subsequent correspondence will often request the audit include all BSA members listed on its web site, the scope of the audit is limited to the members identified. This is particularly important because the BSA members must choose to participate in each audit. Otherwise an audit target may not be able to obtain a release of liability for potentially infringing software published by the non-participating BSA member.

2. Check Existing License Agreements for Audit Provisions

Once a company receives an audit request from the BSA and confirms the BSA members identified in the initial letter are active members of the BSA listed on its web site, it is important to check existing license agreements for audit rights. Some Microsoft license agreements contain specific audit provisions specifying notice requirements, a third-party auditor, and frequency of any software audits. Often these provisions can supersede the BSA’s requests for those particular products. Many companies request the BSA exclude any software that is bound by a specific audit rights provision in an existing license agreement from the scope of the BSA audit. This tactic often saves significant time and expense. However, Microsoft may opt to engage in an audit directly at a later date.

3. Obtain a release of liability for any non-compliant software

Some publishers are members of more than one third-party agency, and often a company receives more than one audit request governing the same time periods. In any event, if a company is paying to resolve a software audit, that company should get a release for the products in the scope of the audit.

The release of liability may be contingent on remediating any non-compliant software within a specific timeframe outlined in the settlement agreement. Software audits are complex, time-consuming, and burdensome. It is helpful to seek advice from an expert to navigate scoping and other legal issues.

Join Our LinkedIn Group

By Christopher Barnett
Scott & Scott LLP

It is common practice for software publishers to incorporate by reference various licensing rules and policies to govern the usage of the publishers’ software products. For example, Microsoft’s volume license agreements (such as MPSAs or Enterprise Agreements) incorporate Microsoft’s Product Terms, Online Services Terms and Service Level Agreement for Online Services (among other documents), with a specific references to those documents, indications of which versions of the documents will control during the term of the agreement, and the URL of the websites where current versions of the documents may be found. While Microsoft’s licensing terms occasionally can be somewhat ambiguous or difficult to apply, the documents incorporated by reference in its agreements are comprehensive and serve to reasonably define the parties’ respective rights, obligations and expectations regarding usage of Microsoft’s products and services.

Oracle takes a different approach, one that reasonably may be characterized as “hiding the ball” from its customers.

Oracle’s current, standard-form OMA and OMA Schedule P (governing software usage) does incorporate a number of documents by reference, including but not limited to:

(1) “Program Documentation,” defined as “the Program user manual and Program installation manuals,” available at: http://oracle.com/documentation

(2) Oracle technical support policies, also available at: http://oracle.com/contracts

(3) The Program-Related Service Offerings document, also available at: http://oracle.com/contracts

(4) Various program-specific documentation sets identified in the License Definitions and Rules section of Schedule P, also available at: http://oracle.com/contracts

(5) Oracle’s Processor Core Factor Table, also available at: http://oracle.com/contracts

(6) Oracle’s Application Licensing Table, also available at http://oracle.com/contracts

That list may seem fairly lengthy at first glance, but it is deficient in a number of respects, as follows:

Notably absent from the list is Oracle’s (infamous) Partitioning Policy, which currently is available here: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf .The Partitioning Policy also does not appear to be clearly identified at the http://oracle.com/contracts website that is referenced so frequently in the OMA.
The Partitioning Policy is a truly problematic document.

Schedule P includes the following definition:
“Processor: shall be defined as all processors where the Oracle Programs are installed and/or running.”

Schedule P then provides a number of program-specific rules for calculating the number of Processor licenses required for licensed servers. However, the basic definition above would appear to pertain to all of those use cases.

Oracle customers whose use of Oracle programs such as Database Enterprise Edition has been the subject of audit activity know all too well that Oracle’s License Management Services (LMS) compliance teams do not limit their reviews to a natural definition of what constitutes “installed and/or running.” Instead, LMS applies concepts described in the Partitioning Policy to vastly expand the scope of what most IT professionals would assume those words to mean. In particular, LMS uses the policy to support its contentions that only specific kinds of virtualization technologies (which notably do not include VMware) may be used to limit the number of licenses required in virtualized environments, and, absent strict adherence to those rules, that all physical processors on all physical hosts in a virtualization environment must be licensed to their full capacities for all Oracle products running anywhere in the environment.

Despite the fact that such a counter-intuitive and aggressive policy is nowhere expressly incorporated in the OMA, LMS typically insists on that interpretation, potentially upon pain of terminating a customer’s licenses or escalating to litigation.

While it is mentioned in Schedule P, the Application Licensing Table (ALT) is not really where Oracle says it is.

The ALT identifies and defines a number of licensing prerequisites and Oracle technologies that may be bundled with certain Oracle Applications (such as E-Business Suite). It is a critical document for understanding the scope of the licenses that companies purchase for those Applications.

However, when you browse to http://oracle.com/contracts, the ALT is not identified on the displayed page. Instead, the page contains links to a few policy documents, plus sub-pages where agreement-specific information may be found. Clicking on the link to the “Oracle Master Agreement” displays a page from which the ALT is conspicuously absent. To get to that document, it is necessary to click on the link for the Oracle “License and Service Agreement” (OLSA), which is a different kind of master agreement governing usage of Oracle products and services.

That kind of ambiguity regarding the location of incorporated terms may seem to be a minor issue. However, it nevertheless further complicates an already complicated licensing universe, and it also offers LMS yet another way to surprise Oracle’s customers with previously unidentified licensing requirements during audits.

Unlike Microsoft’s agreements, there also is no “version control” language in the OMA to identify which, specific ancillary documents have been incorporated into the agreement. That fact provides Oracle an excellent opportunity to change the terms upon little or no notice.

Oracle generally provides little or no meaningful guidance regarding how to avoid unexpected license exposure.

For example, in Microsoft’s Product Terms, each product typically includes a list of added-cost functionalities related to that product and the additive licenses that are required in order to support such usage. By contrast, there is nothing stated either in the OMA or in any readily accessible, ancillary documents that defines when a licensee of Oracle Database Enterprise Edition is required to purchase licensing for added-cost Database options, like Active Data Guard or Spatial and Graph. This is true even though those added-cost options are included with the default Database installation package and often require technical reconfigurations in order to avoid triggering a licensing obligation.

As a result, during an audit, LMS often will ask a targeted entity to run Oracle’s proprietary measurement tools to validate product usage, and the outputs of those tools will reflect usage of Database options or other, added-cost functionalities that target’s business teams never intended to use or knew that they were “using.”

All of the above confusion related to the basic structure and presentation of Oracle’s licensing rules again emphasizes the need for companies using Oracle products to consider engaging and periodically working with a knowledgeable, third-party Oracle licensing consultant. I consider those kinds of engagements to be a necessary cost of business for using Oracle’s products, and they need to be factored into financial models whenever companies considering making or maintaining significant investments in Oracle software.

Join Our LinkedIn Group

By Christopher Barnett
Scott & Scott LLP

Image by Peter Kaminski

Oracle maintains what I consider to be the most aggressive audit program of any major software publisher. Its licensing rules can be extremely difficult to understand, and they frequently are not clearly stated in the applicable license agreements. Moreover, Oracle’s License Management Services (LMS) team typically is unforgiving when it comes time to apply those rules, and it often uses Oracle’s ambiguous license terms and confusingly constructed contracts to prepare audit findings that can cause heart palpitations for business owners.

Companies that have been audited by Oracle can (and sometimes do) attest to its distinctiveness in this regard. Among other publishers, Microsoft is similarly inflexible in the application of its license rules, but those rules generally are more clearly stated and accessible for software asset management teams. Conversely, IBM’s licensing rules can be even more byzantine than Oracle’s, but my experience is that it often is more willing to work toward a fairer compromise when an audited company can point to mitigating factors that resulted in audit shortfalls. In contrast, Oracle really does seem to be unique in insisting on rigid and uncompromising application of unreasonably complex licensing rules and metrics.

Oracle’s audit practice also is noteworthy for the fact that it usually conducts all of its audit in-house, through LMS. By contrast, Microsoft, IBM and many other publishers often work with officially impartial, third-party accounting firms, such as Deloitte, KPMG, PwC and E&Y, to conduct their reviews. Participation of such external fact-finders typically affords a better opportunity to provide meaningful clarification and comment before the publishers receive the audit findings.

Given those facts, business and IT leaders of companies that have invested in any quantity of Oracle software products need to pay special attention to their usage of those products, and they also need to be mindful of what to expect when Oracle eventually pulls their number eventually for an audit by LMS. Here are some of the most important audit risks to keep in mind when using Oracle products:

Tread Carefully When Virtualizing – Oracle’s requirements when using its products in virtualized environments can be daunting, depending on the hardware where the Oracle solutions are to be deployed. Oracle allows its licensees to us “Hard Partitioning” to limit the number of software licenses required for a server or a cluster of servers. However, while Hard Partitioning may mean different things to different IT administrators, it means a set of specific requirements for Oracle, all of which must be carefully controlled in order to avoid unpleasant licensing surprises. In particular, Oracle does not recognize any VMware technology as a satisfactory “Hard Partitioning” technology, even though VMware is a recognized market leader for virtualization solutions.

Here are the requirements set forth in Oracle’s current Partitioning Policy:

1. You must use Oracle-approved technologies to hard-partition your servers. Those technologies currently include the following:
   • Physical Domains (also known as PDomains, Dynamic Domains, or Dynamic System Domains),
   • IBM’s LPAR (adds DLPAR with AIX 5.2),
   • IBM’s Micro-Partitions (capped partitions only),
   • vPar,
   • nPar,
   • Integrity Virtual Machine (capped partitions only),
   • Secure Resource Partitions (capped partitions only),
   • Fujitsu’s PPAR,
   • Solaris Zones (also known as Solaris Containers, capped Zones/Containers only) (provided additional requirements are satisfied), and
   • Oracle VM Server (provided additional requirements are satisfied)
2. If the software is to be deployed on certain Oracle Engineered Systems, then the licensee needs to use Oracle VM Server and Oracle Enterprise Manager (OEM) to set up and report on “Trusted Partitions” where the software will be running. OEM can be deployed in either “Connected” or “Disconnected” mode: in the former, OEM reports on software usage directly to My Oracle Support, while in the latter the licensee is required to generate quarterly usage reports and to retain those reports for at least two years.
3. In every case where an Oracle technology is to be used as a Hard Partitioning technology, it is necessary to follow Oracle’s technical instructions for the use of that technology:
   • Oracle Solaris Zones
   • Oracle VM Server for x86
   • Oracle VM Server for SPARC

Failure to adhere to Oracle’s requirements can result in the virtualized environment being licensed for installed Oracle products based on all physical cores used to support the infrastructure, even if there is only one VM running the product on a single host in a virtualization cluster. Never mind the fact that this effective prohibition on the use of VMware with Oracle products may not be mentioned anywhere in the applicable license agreements or in any document incorporated in those agreements. In effect, LMS merely applies the assumption that since VMware makes it so easy for VMs to migrate to other hosts, the processors on those hosts must be licensed for the Oracle software.

Know What is Installed and Running – Another favorite tactic is to surprise customers with licensing fees associated with product options that the company never actually used. Many Oracle products – such as its ubiquitous Database software – are deployed from installation files that include a catalog of added-cost options and packs. Those options sometimes inadvertently may be enabled during the installation process or at some point thereafter and then turned off without ever having been used. However, the software’s usage logs record the enabling of the options, and that log data often is among the information demanded by LMS during an audit. If LMS determines that the options were enabled at any time – even if only once, seven years or more before the audit data were collected – it is common for those options to be included among the audit findings.

Companies using Oracle Database products therefore are well-advised to work with knowledgeable consultants when setting up their systems, to ensure that only those product features licensed and intended to be used are enabled on the company’s computers. To the extent that Oracle products have been running in the environment for some time, it may be worthwhile to undertake an initiative to confirm what is currently enabled and what the logging date say about the options that may have been enabled in the past.

Know How to Scan – Finally, Oracle audits also are noteworthy for the limited set of tools that LMS will accept as sources of audit data. The auditors’ first choice is always a set of proprietary LMS scripts and other tools that it will make available to the company at the outset of the review. However, those tools do not generate outputs in a format that is easy for anyone other than Oracle to review, so companies that use them may not know what they are telling LMS about the environment. We typically do not recommend that our clients share any deployment information with any auditor without first reviewing that information internally for accuracy and completeness.

Fortunately, LMS also accepts outputs from a limited number of third-party tool providers, as follows:

• Easytrust
• Flexera Software
• Hewlett Packard Enterprise
• iQuate
• Lime Software
• Nova Ratio

However, the tools published by those vendors typically are not free for larger organizations to use. Furthermore, even though they may gather information that LMS is willing to accept, they may not gather all of the information that LMS says it requires to complete an audit.

Therefore, it is a wise practice for companies using Oracle products to consider engaging and periodically working with a knowledgeable, third-party Oracle licensing consultant as a necessary cost of business for using Oracle’s products. Many consultants have experience working within LMS, and they typically can provide insights regarding the best tools and methodologies for staying on top of how many Oracle products require licensing within an environment.

By Keli Johnson Swan
Scott & Scott LLP

Disputes involving software usage are on the rise for businesses of all sizes. In some cases, technical teams respond to a software publisher’s or a third party’s audit request and provide significant amounts of data without notifying anyone on the corporate governance or the legal teams. It is critical for those teams to evaluate the publisher’s legal ability to audit, and to identify the data the publisher is entitled to request.

It is not uncommon for the legal team to discover the existence of a software audit or license verification after the company has received a demand for damages arising from alleged over-usage of software.

Often, employees responding to an audit request do not understand the request and provide inaccurate or incomplete information. Once this information is disclosed, it can expose the business to a damages claims arising from any license deficiencies. If the information is inaccurate, it is an uphill battle to rectify it and reach a resolution.

There are a few key tips to minimize unauthorized disclosures and to avoid potential liability.

1. Institute Communications Protocols for Inquiries from Third Parties

Depending on the size of the company, there may be varying resources available to respond to an audit request. Whether a company has a single person in charge of the IT assets, outsources to a managed services provider or other third party vendor, or dedicates an entire department to managing software deployments and licenses, it is helpful to institute protocols outlined in an employee handbook (or vendor agreement) that prevents individuals from disclosing information without seeking management’s approval.

Some types of audits appear to be non-threatening “license verifications” or requests for software asset management reviews, which sometimes creates a false sense of security for individuals who may otherwise seek management approval prior to sharing information. Even these seemingly innocent requests should be treated with caution.

It is helpful to have an established protocol that employees can reference when they receive a request for information related to software assets. The teams should be required to notify the legal and governance representatives as part of the protocol.
It is also important to ensure in any agreements with a third-party IT vendors that they will not release any information without company approval, even if the third party manages all software on the company’s network.

2. Educate Business and Procurement Teams

Larger companies may dedicate entire departments to the business side of software negotiations, including management and procurement. These negotiations should always be supervised by inside or outside counsel.

Sometimes, during the business negotiations, these teams may disclose information regarding the company’s software installations that the publisher later tries to use as leverage in future negotiations. For instance, if during a business negotiation, the procurement team describes a current use case that is outside the scope of the license grant, the publisher may claim that it is entitled to payment for the past improper usage.

It is crucial that these departments are trained on the specific types of information that may be disclosed and to ensure that the information provided is properly vetted for accuracy and legal implications.

3. Routinely Conduct In-House Self-Audits

Finally, a company should assign a specific individual or team to conduct routine self-audits and internally track entitlements to ensure license compliance. The benefits of this process is two-fold: 1) If the company receives an inquiry regarding its software licenses, it can quickly and accurately collect the necessary information, and 2) the information can be verified by the IT staff and management prior to disclosing it to a third party.

The first step in receiving a software-related inquiry is to identify what type of information is being requested, and whether a response is mandatory. In some of these situations, a company has no obligation to respond. In others, a failure to provide a timely response may escalate the matter to potential litigation. All inquiries should be brought to the attention of both management and the legal department to determine how to proceed.

By Christopher Barnett
Scott & Scott LLP

Image by Patrick

Software-compliance audits initiated by IBM can be extremely burdensome and time-consuming and can force companies to face challenges that are somewhat unique among major-publisher audits. For one example, a significant component of IBM’s business model is the acquisition of other software vendors and the integration of those vendors into IBM’s product portfolio, which can complicate the task of identifying the appropriate license metrics and entitlements owned. For another example, companies seeking to license IBM products based on processor resources in virtualized environments must use IBM’s License Metric Tool (ILMT) in order to avoid licensing the products based on the full capacity of the host infrastructure. The ILMT question can become a significant satellite issue to explore during an audit, and failure to demonstrate compliance can yield substantial licensing exposure.

However, once all of the data-collection and license-reconciliation tasks have been addressed, IBM’s auditors will generate a final audit report, and IBM will prepare a proposal to resolve the audit findings. At this stage, companies will need to turn their attention on structuring an appropriate settlement framework that definitively resolves all calculated license shortfalls as well as all, underlying licensing concerns that may have contributed to an imperfect outcome.

Here are some important subjects to keep in mind when negotiating the resolution with IBM:

• Fair Purchasing Options

IBM’s default audit resolution typically will incorporate a requirement to purchase licenses equal in kind and quantity to any license shortfalls calculated during the audit. Thus, if a company was found to be over-deployed for WebSphere Application Server (WAS) by 1,000 Processor Value Units (PVUs), IBM will require the company to purchase 1,000 PVU license for WAS. In addition, IBM also usually will require the company to purchase two years of retroactive support for the shortfall license quantity. However, there often are a number of opportunities to maximize the value of the audit resolution:

(1) Minimize Retroactive Support.

If the company can demonstrate that product installations associated with license shortfalls were deployed within the two years prior to the audit, then that information should be discussed in order to reduce the amount demanded for retroactive support.

(2) Reduced or Compromise Purchase Quantities.

Audited companies should not hesitate to request compromises associated with inadvertent licensing shortfalls. For example, if a compliance problem resulted from the company’s failure to deploy and use ILMT, then the company should seek to reduce the number of licenses to be purchased for the product in question, provided either that the products are re-deployed or that ILMT is installed following settlement. These arguments sometimes are more compelling when the company can demonstrate unsuccessful attempts to satisfy the licensing requirements prior to the audit. Furthermore, they can be especially compelling when the company can demonstrate that IBM had an opportunity to advise the company regarding the compliance concern prior to the audit – and failed to do so – or that IBM had an affirmative obligation to satisfy the licensing requirement (such as through a statement of work for implementation services).

(3) Substitute Products & Services.

Whenever a quantity of licenses included in an audit settlement demand would address calculated shortfalls without providing prospective value to the company (for example, because the software either can be re-deployed or uninstalled following settlement), the audited company should seek to substitute those purchase quantities with alternative purchases consistent with the company’s go-forward needs. This approach typically is easiest for IBM to accommodate when licenses for one product are to be substituted with licenses for another product that was not found to be a compliance problem during the audit. IBM also has a strong desire to transition business to a cloud-services model, and it also may be willing to substitute those services in place of a perpetual-license demand. However, IBM’s hardware and professional-services offerings usually are not accepted as substitute purchases.

(4) Strategic Pricing Discounts.

Never underestimate the power of direct negotiations between business teams. IBM may be willing to offer further discounts if it perceives an opportunity to become a strategic vendor for the audited company. This can be especially true for companies willing to commit to subscription or other ongoing service-delivery relationships with IBM.

• Post-Settlement Compliance Obligations

Any product-specific compliance problems outside of license shortfalls that were identified during the audit need to be definitively resolved through the audit settlement.

The most obvious item falling within this category would be a prospective need to deploy ILMT. Large organizations especially may be unable to install and configure the tool quickly following settlement of an audit. Therefore, the audit close letter or settlement agreement needs to define the post-settlement ILMT deployment obligation, providing for sufficient time to complete the project. It also may be advisable to seek IBM’s commitment to support the ILMT implementation and to allow for additional time to complete the project, provided that the company has made reasonable progress toward completion.

Another item to keep in mind here would be any compliance concerns that may have resulted from IBM’s acquisition of a vendor from which the audited company previously may have purchased licenses. If there were any licensing allowances granted by that vendor prior to the acquisition, then the audit close letter should address whether and to what extent those allowances will be carried forward, either to facilitate the company’s continued use of pre-acquisition versions of the software in question, or to transition to post-acquisition versions of that software.

• Release, Forbearance and Other Legal Terms

Finally, it is critical to ensure that the audit settlement really is a complete settlement of all issues reviewed through the audit process. This means including a strong release of past liability in the audit close letter or settlement agreement that includes all audited products and business operations. It also means seeking a reasonable period of audit forbearance following the audit, so that the company has time to adjust its software-asset management procedures in preparation of the next licensing review. In addition, if any licenses need to be assigned from one organization to another within the company’s enterprise in order to ensure co-forward compliance, those issues also should be resolved with the audit settlement.

By Robert J. Scott
Scott & Scott, LLP

Almost every business today operates with the support of digital tools. One recent survey put the number of companies investing in digital technologies to transform their business at an astounding 97 percent. Conducting business in this digital age means licensing software from major publishers, such as IBM, Oracle and Microsoft, and the subsequent acknowledgement and anxiety that software audits from these and other providers are not only likely, but they can wreak havoc on your company.

It typically goes something like this: You receive a letter from your software publisher and it says there is an audit coming. It contains threatening language and warns not to make any changes to your environment.

At this point many companies simply wave the white flag and open the doors of their entire IT infrastructure to the software vendor. However, this comes with risks. The scripts that auditors use to discover the illicit use of software (intentional or not) can cause problems in an IT infrastructure, and consume valuable staff resources and money.

Better-prepared companies, on the other hand, deploy tried-and-true practices for negotiating a software audit. Often, one of their first moves is to negotiate with the software vendor.

Case-in-point, a few years ago, the candy maker Mars received a letter from Oracle saying that it had been selected for a software audit. Mars, being a large and well-run company, knew the risks the audit posed to its IT infrastructure, so it pushed back. One of the issues at the heart of Mars stalemate with Oracle was the scripts that Oracle wanted to run. Mars wanted Oracle to agree that any damage inflicted by scripts probing the Mars infrastructure would be paid for by Oracle.

According to a recent survey by IT services firm Technologent, 65 percent of organizations were subject to a software audit in 2016 and 23 percent were audited three or more times. Almost half (44 percent) of surveyed organizations paid $100,000 or more in true-up costs to vendors due to noncompliance, a sharp increase from 25 percent the prior year. Twenty percent paid more than $1 million in true-up costs, more than double the number in the previous year (nine percent).

These numbers are intimidating. But in fact, you have more room to negotiate an audit than you likely realize. Here are some questions to keep in mind when you negotiate with software publishers demanding audits across your enterprise IT infrastructure.

• The license agreement may not obligate you to run any third-party tools in connection with an audit. You should certainly have your legal team review audit provisions of the operative license agreements to understand your rights
• If the audit clause requires the customer to provide reasonable cooperation, that can easily be accomplished without running the auditor’s tools
• Consider what data collection methodology will you offer the auditors as an alternative?
• Where scripts are being considered, test, test, test.
• What are the vendor’s obligations to provide a remedy for audit scripts that lead to failure of performance in systems being probed?

The digital transformation of business has exploded in recent years and so, consequently, has software licensing. Worse, software is characterized by multiple licensing rules and models, which leads to more companies falling out of compliance. This is why having enterprise wide strategies in place for dealing with and pushing back on software audits has become as important to businesses as their accounting practices.

This article originally appeared on TechCrunch; you can read Scott’s articles on TechCrunch here: https://techcrunch.com/contributor/robert-j-scott/

Scott & Scott LLP will present a webinar on preparing for and responding to software audits.

The event will be Tuesday, Jan. 31, 2017, beginning at 11 a.m. Central time.

In this free CLE event, Rob Scott will cover:

• Types of Software Audits
• Publisher & Third Party Audits
• Legal Issues Arising in Software Audits
• The Audit Defense Process
• Software Discovery
• Proof of Purchase Analysis
• Producing Audit Materials
• Negotiating Resolution
• Settlement Agreements

The webinar qualifies for 1 hour Texas CLE (California CLE pending). CLE Credit will only be available with the live event. It will not be available with the recording.

Register for the webinar.

Join Our LinkedIn Group

By Christopher Barnett
Scott & Scott LLP

Companies with experience licensing Microsoft software and services through Enterprise Agreements know that small forests could be felled to produce the paper required for the typical document stack. EAs often incorporate a dozen or more different components, including some or all of the following:

• Microsoft Business and Services Agreement or Microsoft Business Agreement (Microsoft sometimes will agree to use existing master agreements)
• Online Services Supplemental Terms and Conditions (if an existing, older-form master agreement is to be used)
• Enterprise Agreement (Microsoft sometimes will agree to use existing base EAs)
• Enterprise Enrollment
• Customer Price Sheet
• Product Selection Form
• One or more custom terms amendments (if custom terms have been negotiated)
• One or more standard-form amendments (to cover product-specific or service-specific matters for which Microsoft offers off-the-shelf terms)
• Product Terms (typically incorporated by reference)
• Online Services Terms (typically incorporated by reference)
• Service Level Agreement for Online Services (sometimes incorporated by reference)
• Supplemental Contact Information Form
• Tax Terms and Conditions Form
• Signature Form

Many of the standard forms are administrative in nature and rarely incorporate substantive terms or conditions. However, Microsoft occasionally will incorporate substantive or potentially substantive language in forms that otherwise would appear to have only administrative purposes. A good example is the Customer Price Sheet (CPS).

The primary purpose of the CPS is to list the products and services being ordered under an EA, the order quantities, and the prices to be paid. The CPS also typically identifies the prices that will apply to true-up orders during the term as well as end-of-term buy-out prices for subscription licenses.

Toward the end of the CPS, there usually are included sections labeled “Product Notes” and/or “Terms and Conditions.” Ideally, those sections should be used exclusively to help navigate the CPS and to clarify any custom license metrics that may apply to the EA transaction. However, Microsoft sometimes will include language in those sections that should be the subject of legal negotiations or even that contradicts substantive terms that may have agreed in a custom terms amendment. For example, the parties may reach a special agreement regarding the mechanics for placing incremental true-up orders, but the notes in the CPS may reference standard true-up procedures. This can be especially problematic in time-sensitive negotiations, because the CPS often is among the last documents to be finalized for legal review and approval.

Businesses neglect a thorough review of all EA document components at their peril. Business and legal teams need to push early and often to insist that Microsoft circulate final-form versions of each and every part of the document stack as soon as possible to ensure a smooth transaction. Those teams also need to be prepared to scrutinize every page of that stack to ensure that there are no surprises that are inconsistent with the business’s expectations.

By Robert J. Scott
Scott & Scott LLP

It has been said that software is the new oil. It fuels the information revolution. And in this metaphor, software audits are the meters that measure the flow—and extract maximum revenue for software makers. The auditors arrive on your company doorstep to “true up” your license and make sure you’re paying for all the software your employees are using. They probe and flag noncompliance.

Gartner Research Group has estimated that 68% of organizations will have their software assets audited in the next 12 months. This is up from 63% in 2013 and continues the upward trend of the recent past. In fact, every major software maker has embraced a strategy of revenue enhancement via software licensing audits, including IBM, Microsoft and Oracle.

Software audits are usually not a pleasant experience. The scripts that auditors use to discover illicit use of software (intentional or not) can themselves create problems in your IT infrastructure, consume valuable staff resources and money, and negatively impact your bottom line. Software publishers don’t typically telegraph their audits, which means an audit can trigger large unbudgeted payments for penalties and other hard and soft costs that impact financial performance. Following each unsuccessful audit, there’s a greater chance your company will be audited again and every audit is time-consuming, stressful and potentially damaging to your bottom line.

So what can be done?

First, companies can push back on software audits. Most businesses have more room to negotiate an audit than they realize. Second, you should have audit response policies in place to ensure that audits are dealt with in a systematic way rather than the typical “reactive mode.” Lastly, you should start thinking and treating your software licenses like fixed-assets that are carefully tracked and managed in your financial reports, which should lead to better outcomes.

More than six decades ago, business got on board the computer revolution. Now every company is racing into “digital transformation.” Technology is ubiquitous and software keeps it all running, across the globe. So it’s no wonder software audits have become so common-place for enterprises big and small. They are now a part of life, which means that now is the time for your business to put in place management practices to alleviate the stress and financial burden of software audits. Scott & Scott has defended over 500 software audits over the last ten years. If you are interested in benefiting from this experience, reach out to us and learn how we help client’s manage the risk of software audits.

By Keli Johnson Swan
Scott & Scott LLP

The end of the year is a busy time for software publishers and entities like the BSA | The Software Alliance (“BSA”) and the Software & Industry Information Association (“SIIA”) to resolve an audit target’s copyright infringement dispute by entering into settlement agreements. While it may be advantageous for a company to reach a quick resolution by the end of the year in order to resolve any outstanding disputes or potential monetary penalties, it is critical not to rush through settlement without carefully considering provisions in a draft settlement agreement.

The following are a few provisions that should be carefully considered before executing an agreement.

Release of Liability.
The release of liability is arguably the most critical provision in a settlement agreement because without it, a company is still exposed for any potential copyright infringement claims. These provisions should be read very carefully because software publishers sometimes limit the provisions to specific circumstances, and make the release of liability contingent on several factors, including post-settlement remediation and other ongoing responsibilities.

Warranty.
Often software settlement agreements contain a provision that the release of liability is contingent on the accuracy of the audit materials that were submitted. This is particularly important because a company should make every effort to ensure that it conducts an accurate self-audit immediately after the audit request is received.

Post-settlement obligations.
The BSA and SIIA have specific terms it requires in settlement agreements, which requires that any software that was discovered to be unlicensed during the course of the audit is uninstalled or replaced with licensed software. Additionally, a software publisher or the BSA or SIIA may seek to include provisions that are more restrictive than the software license agreement requires, such as future on-site inspections. These terms generally can be negotiated so it is important to seek legal counsel before executing a settlement agreement.

Confidentiality.
While some targets of software audits wish to share their experiences to educate others, most companies prefer not to have any negative publicity related to resolving copyright infringement claims. The confidentiality provision should be carefully crafted to prevent the software publishers, BSA, or SIIA from publishing a press release about the settlement agreement.

These are just a few issues to consider when reaching a settlement to resolve alleged copyright infringement claims. If in doubt, contact an attorney experienced in software licensing and copyright infringement matters.