Microsoft has named a new general counsel, reviving a position that was left vacant about two years ago when the former GC left to join music streaming company Spotify in 2016, reports The Seattle Times.

The new GC will be Dev Stahlkopf, most recently the deputy general counsel in the company’s HR legal team. She will report to Microsoft President Brad Smith, who also serves as chief legal officer. Smith’s responsibilities are not changing, the company said.

Reporter Rachel Lerman writes that Stahlkopf will focus on aligning the company’s legal teams and implementing new projects, the company said. The legal teams in Redmond will report to her.

Read the Seattle Times article.

By Christopher Barnett
Scott & Scott LLP

Most software audits pertaining to products licensed under perpetual licenses (such as licenses acquired under a Microsoft Select Agreement, MPSA or (usually) Enterprise Agreement) incorporate a snapshot-in-time approach, where licenses owned generally are compared to deployments identified through data collected about current-state product deployments. In contrast, audits pertaining to products licensed under a Microsoft Services Provider License Agreement (SPLA) incorporate a strong historical-use element. Since SPLA pricing is based on a monthly reporting model, SPLA audits look at historical usage during the period covered by an audit (often, three years or more), and then compare that historical usage to a licensees’ historical usage reports.

And that historical-usage element is where almost all SPLA licensees routinely fall short.

Most companies licensing software under SPLA simply do not keep records regarding their usage quantities for past months. Microsoft’s license agreements typically contain requirements to “keep accurate and complete records relating to all use and distribution” of Microsoft’s software, but most businesses simply do not make the connection between that obligation and their monthly reporting procedures. As a result, there is a gaping hole in data collection for most SPLA audits.

The SPLA gives Microsoft the right to presume that unreported use identified during an audit month began at the commencement of the end-user relationships associated with that unreported use, unless a licensee can reasonably demonstrate a different scope and duration. This is where an element of creativity often can bridge the gap to a successful SPLA-audit resolution.

In the absence of historical data, Microsoft and its auditors often are willing to consider alternative approaches for estimating historical usage. For example, if the missing historical data pertain to products licensed per user, then one option could be to estimate changes in user license requirements over time based on changes in the licensee’s monthly revenue for the corresponding period. Alternatively, it may be appropriate to estimate historical usage by comparing usage to reporting for the audited month, and then applying the same ratio to reported quantities for previous months. User account creation dates also often are a relevant data point for these purposes.

For products licensed per processor or per core, it often makes sense to use a combination of resource-creation dates and records regarding past changes to the environment. For example, if the licensee can demonstrate through e-mails or other sources of information when it deployed additional infrastructure or server products over time, those records may be used to identify the earliest dates for which certain products should have been reported during the audit period.

In our experience, Microsoft’s auditors often are willing to consider different sources of information, but their preference always will be for the explanations that are supported by the most evidence. The stronger the factual basis for arguing in favor of a particular outcome, the better the odds of a successful resolution. In contrast, the more a licensee effectively asks Microsoft to trust it regarding past usage, the more doubtful those odds become.

Of course, the very best way to address the risks associated with SPLA audits is to plan for them. A standard part of any SPLA licensee’s reporting procedures should be to save an archive of historical usage reports generated by auditable inventory tools. For software and hardware deployments, those tools include System Center, MAP Toolkit, and Lansweeper, among others. Additional sources of information include RVTools (for VMware virtualization data) and Active Directory queries (for information regarding the Organizational Units and Security Groups to which authorized users belong). Well prepared SPLA licensees should be in the habit of preparing their monthly reports accurately and on time based on up-to-date deployment information and then saving that information every month, so that it never becomes necessary to determine the most appropriate, creative approach for filling data gaps.

By Christopher Barnett
Scott & Scott LLP

Companies that have long relationships with Microsoft know that the company’s form licensing agreements have steadily evolved over time, and typically for the worse. If software licensing can be said to have any “natural laws,” certainly the First Law could be paraphrased to something like: “If you agree to an inch, be prepared to give a mile.” So it is with Microsoft’s standard-form Services Provider License Agreement (SPLA).

The most recent iterations of the SPLA include a handful of noteworthy changes, relative to the forms that many current SPLA licensees may have signed at the beginning of their relationships with Microsoft. Those changes include the following:

• End User License Terms (EULTs) now apply to all end users.
  In the past, the EULTs – a form end-user license agreement for SPLA providers to include in their customer contracts – were necessary only in connection with services that included Client Software or Redistribution Software. All other end user agreements needed to include terms that aligned with a laundry list of requirements that was set forth in the SPLA. The laundry list now is gone, and all end user agreements now must incorporate the EULTs. As a result, all SPLA providers will need to be familiar with the EULTs and will need to be prepared to incorporate them into their customer agreements.
• No limitation of liability when defending Microsoft.
  The new SPLA now expressly provides that the standard, mutual limitation-of-liability included in the Microsoft Business and Services Agreement (the master agreement to which the SPLA is attached) no longer applies to a licensee’s duty to defend Microsoft against certain third-party claims. Thus, a SPLA licensee could have effectively unlimited exposure arising from such claims. That state of affairs may be inconsistent with a licensee’s internal insurance or risk-management policies.
• Extensive new audit rights for Microsoft.
  The most troubling new developments pertain to audits. The audit clauses in all of Microsoft’s license agreements has become more and more burdensome for licensees over recent years, and the new SPLA forms are no exception. Past SPLAs said very little regarding audits, leaving most of the parties’ audit-related obligations to be defined by the MBSA. However, the new forms contain language broadly obligating licensees to provide Microsoft’s software auditors with “access to all servers running the Products,” without defining what that “access” entails. In addition, in some forms Microsoft has incorporated extensive, new provisions related to “anti-corruption” policies, recordkeeping and audits. Those anti-corruption audits theoretically would be limited to confirming a licensee’s compliance with the new SPLA’s anti-corruption requirements. However, those requirements include an obligation to maintain an accounting system that would enable Microsoft to probe every aspect of a licensee’s finances related to SPLA.

Prospective and renewal SPLA licensees with bargaining power should seriously consider mounting a determined effort to seek appropriate amendments to the above (and other) terms in the new SPLA form. Absent appropriate amendments, companies providing hosting services may want to think about organizing their infrastructures and business models to minimize or eliminate their reliance on SPLA licensing.

Christopher Barnett
Scott & Scott

There are many good reasons that businesses often cite in seeking to transition their IT operations to a vendor-delivered Cloud environment.

It’s scalable.

It’s more reliable and secure than what the business may be able to deliver for itself.

It’s (often) cheaper than keeping the environment in-house.

Then there’s this one:

“All I have to do is pay a monthly fee, so no stressing over software-licensing rules.”

Not quite.

In many cases, it is true that, where the vendor is providing licensing for software products to be used in the company’s Cloud, the licensing requirements that are directly applicable to the company may be significantly reduced. Often, the only requirements that remain are things like: “don’t copy or reverse-engineer the hosted software,” or “don’t provide third parties with access to the hosted software.” Pretty easy.

However, even though some of the more technical requirements may no longer be the company’s contractual obligation, the vendor’s failure to adhere to them can cause trouble.

For example, a Cloud vendor may propose offering hosted virtual desktops-as-a-service (DaaS) running the Microsoft Windows operating system. Unfortunately, Microsoft currently offers only two options for DaaS service providers:

1. DaaS through the Microsoft Services Provider License Agreement (SPLA) via the Microsoft Windows Server Operating System, or

2. DaaS through Dedicated Outsourcing using your customer’s Microsoft Volume Licensing agreement.

Option 1 is incompatible with the proposed services, because it entails use of desktop “experience” functionality included in the Windows Server operating system, not the Windows operating system itself. That leaves Option 2. However…

Option 2 also usually is problematic, because “Dedicated Outsourcing” in Microsoft-speak means that the physical server infrastructure used to deliver the DaaS services must be dedicated exclusively to the company receiving those services and must not be used by any other customers of the DaaS vendor. Spinning up one or more new, physical servers for each customer often is something that many DaaS providers simply cannot afford to do.

Of course, if the vendor messes up in licensing its hosting environment, that is primarily going to be the vendor’s problem. When Microsoft discovers the compliance problem, then it likely will look to the vendor to remedy the problem, not to the recipients of the vendor’s services. However, our experience is that SPLA audit exposure in particular can be very significant and occasionally even financially crippling. If a vendor builds a service model around a misunderstanding of fundamental licensing concepts, then the remedy sought by Microsoft following an audit could jeopardize the vendor’s business operations. The result could be a discontinuation of the DaaS services, a need to transition to another provider within a short window, and, potentially, unexpected and permanent service interruption.

Businesses therefore need to develop and to maintain a working knowledge of software-licensing rules, even if they are not going to be directly responsible for adhering to those rules within the context of a hosted-service relationship. Contract language related to warranties, indemnification and limitation of liability may help to mitigate some of the risk associated with inadequately licensed hosting environments, but a better bet would be to go into a vendor relationship knowing that the services to be delivered do not, on their face, violate applicable licensing policies.

By Christopher Barnett
Scott & Scott LLP

Microsoft is in the process of transitioning many of its volume-licensing customers from the Select Plus Agreement to the new Microsoft Products and Services Agreement (MPSA). (More information on the transition framework is available here.)

A notable difference between the Select Plus Agreement and the MPSA is that the MPSA is self-contained and is not signed subject to a master agreement, such as a Microsoft Business and Services Agreement (or its predecessor, the Microsoft Business Agreement). Under Select Plus (and still under the Microsoft Enterprise Agreement), most of the important, substantive legal terms associated with the licensing relationship were contained in the MBA/MBSA. Those terms included Microsoft’s duty to defend against certain third-party claims, limitations of liability, and governing law, among others. They also included Microsoft’s audit rights.

Unfortunately for Select Plus customers, though consistent with Microsoft’s notorious habit of steadily making its agreements less and less advantageous for its customers, the audit terms contained in the MPSA are significantly more onerous and markedly less reasonable than were the corresponding terms in past master agreements. A comparison of the MPSA terms to the terms in an MBA (which still remain in effect for many Microsoft customers) reveals the following:

1. Under the MBA, Microsoft could initiate an audit only during the term of a license agreement and for one year thereafter. There is no such limitation in the MPSA. The practical effect of that difference may be somewhat less significant for MPSA customers than it would be, for example, for Enterprise Enrollment customers, since the MPSA has no defined term. Nevertheless, if an MPSA customer were to decide in the future that it wanted to cancel the MPSA, the audit rights in the MPSA would remain in effect in perpetuity. (It is worth mentioning that Microsoft’s current MBSA also contains no time limitation on audits, so Enterprise Agreement customers face the same problem under the default terms.)

2. Under the MBA, Microsoft’s auditors were required to be subject to “a confidentiality obligation.” We often have relied on that language in advising our clients to obtain non-disclosure agreements with auditors before the commencement of audit activity. There is no corresponding language in the body of the MPSA.

3. Under the MBA, Microsoft was required to provide advance notice of audits, which had to be conducted during normal business hours and “in a manner that does not interfere unreasonably with [the customer’s] operations.” There are no such requirements in the body of the MPSA.

4. The MPSA requires the customer to “promptly provide any information reasonably requested by the independent auditors retained by Microsoft in furtherance of the verification, including access to systems running the Products.” There was no such specificity in the MBA, and there certainly was no requirement for the customer to provide “access” to its computer systems. Especially for licensees in heavily regulated industries, that term may conflict directly with applicable obligations related to IT security.

5. The MPSA indicates: “Additional details about the [audit] process are included in the Licensing Manual.” The Licensing Manual is defined as “the statement published by Microsoft (updated from time to time) at the Licensing Site. The Licensing Manual includes details about the processes supporting this Agreement.” The Licensing Manual (currently available here) includes the notice, confidentiality and “unreasonable interference” audit terms that, as noted above, otherwise are missing from the body of the MPSA. However, the MPSA states: “…Microsoft may change the…Licensing Manual from time to time, subject to the terms of this Agreement.” The MPSA does not contain any stated limitations on Microsoft’s right to change the Licensing Manual. Therefore, the durability of the procedural audit protections noted in the MPSA is wholly subject to Microsoft’s discretion.

6. Finally, under the MBA, in the event that “material unlicensed use” was found, the licensee was required to purchase any necessary licenses at retail rates. Under the MPSA, that purchase must be made at 125% of prices then available to the licensee. That upcharge could lead to significantly higher compliance costs following an audit. (Bear in mind that Microsoft typically does not accept uninstalling software as an acceptable remedy for unlicensed usage – license purchases almost always are required.)

In my opinion, the MPSA’s audit language is wholly unacceptable. Before accepting the agreement, my recommendation would be to insist on amendments addressing the above concerns. However, many current Select Plus customers with agreements that now are set to be terminated may find that they have little leverage to demand any changes to the default terms. Since the MPSA does not require a three-year purchasing commitment (like an Enterprise Agreement), Microsoft may have little up-front incentive to negotiate reasonable and appropriate revisions to the agreement terms.

Finally, the above concerns related to audit terms are in addition to indemnification and limitation-of-liability language in the MPSA that also may be inadequate, especially if the customer has plans to invest heavily in Microsoft’s Online Services offerings (e.g., Office 365 and Azure).

Current Select Plus customers need to carefully weigh their licensing needs and alternatives before moving forward with any significant expenditures under an MPSA.