softwareOne_logo_forPrint_no_tagline_(1).jpg

Thought-Leadership Blog

FacebookIconTwitterIconlinkedinIcon

SPLA – An Overview of the Service Provider License Agreement (Part 1)

Thought-Leadership by Brett LaForge
on June 2, 2015

spla-an-overview-of-the-service-provider-license-agreement-part-1

What a difference 5-10 years can make in a rapidly evolving technology industry. Cloud, hybrid, mobility, and virtualization were all associated with different things – none of which was technology. Fast forward today and those words are echoed from every IT channel in the industry. What’s also echoed (some more loudly than others) are the licensing challenges associated with these topics. In walks our friend: the Service Provider License Agreement (SPLA).

Putting the “Service Provider” into SPLA

The SPLA acronym alone can make some people weary. For starters, who, or what, is a service provider?

A service provider can be any organization that is hosting Microsoft applications on behalf of another organization. This can range from a company that is providing email (Exchange) as a service to another company (think Go Daddy, Rackspace, etc) to a company that develops an application that runs on Microsoft Software (EMR software, Financial applications, etc.).

Companies that offer Microsoft services from one or more datacenters, a telephony network, or a private network on a rental, subscription, or services basis should be looking at SPLA. These include:​

  • Application Services Providers
  • Business Process Outsources (BPO)
  • Franchises and Franchisees
  • IT Outsourcing (providing software licenses)
  • Messaging or Collaboration Services Providers
  • ISVs (providing hosting applications)
  • Platform Infrastructure Providers
  • PC Rental Companies
  • Streaming Media Providers
  • Web Hosting Providers
  • Web or Internet Services Providers
  • Online Gaming Providers

Why SPLA and Not Volume Licensing?

Whenever a company is hosting an application on behalf of a third party, SPLA must be part of the conversation. All volume licensing programs are designed for internal consumption, not hosting solutions, as outlined in the Product Use Rights (PUR) where it states “No Commercial Hosting”.

Let’s take Exchange as an example. When you provide email to your own employees using Exchange, the customer will purchase a volume licensing agreement for those users. Why? Because these organizations are providing this service to their own employees; that’s what the program is designed for.

Let’s take it a step further and say the same company has a customer that needs email for their own internal employees. This customer does not own an Exchange server; has few resources to deploy it; and would like you to host Exchange for them. How do you license Exchange under this model? You would need to license via SPLA. Why? You would be hosting Exchange on behalf of this other company.

Top Questions You Should Ask Yourself When Providing 3rd Party Access to Your Servers

Who benefits from this access?

Is it your company or is it the company accessing?

Are you providing this solution as a service to your customers?

Are you hosting Microsoft software on behalf of another organization?

Is the third party accessing Microsoft software that is included with your own software?

Is the third party accessing software that you lease from another vendor that runs on Microsoft technology?

If any of these questions pertain to your needs, click the banner below to set up a few consultation with a SoftwareONE SPLA Specialist.

SoftwareONE-Contact-Us-CTA

Related blog posts:

Topics: Cloud and BYOD

pyracloud-demo-request

Subscribe to Email Updates

Subscribe by RSS
SHARE THIS PAGE
     

ON TWITTER