Even in The Cloud – Keep an Eye on Software Licensing

in Blogs

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.