SQL Licensing in SPLA

SQL Server in SPLA is costly to get wrong. SAL vs Core, the 4-core minimum, virtualization, passive failover, and BYOL/FVB all matter. MSPs and hosters: don’t let SQL licensing become an audit finding.

For Managed Service Providers (MSPs) and hosters, the Services Provider License Agreement (SPLA) is the primary vehicle for offering Microsoft software services. Among the various products available, Microsoft SQL Server is arguably the most critical to license correctly due to its high cost and complexity.

Unlike internal licensing, SPLA allows you to license software on a monthly basis to provide "Software Services" to third parties. 

However, SQL Server offers multiple licensing models and edition constraints that can trip up even experienced providers.

Below is a breakdown of how to navigate SQL Server licensing in SPLA, ensuring you remain compliant while optimizing costs.

The Two Main Licensing Models

In SPLA, SQL Server is licensed under one of two models: Subscriber Access License (SAL) or Per Core. The model you choose depends on the specific edition of SQL Server and your hosting architecture.

The SAL Model (Subscriber Access License)

This model is ideal for environments with a low, countable number of users.

  • How it works: You acquire a SAL for every unique user or device authorized to access the software.
  • No Server License Needed: Under the SAL model, you do not need to pay for the server software itself; you only pay for the users accessing it.
  • Availability: This model is available for SQL Server Standard but is not available for SQL Server Enterprise or Web Editions.

The Per Core Model

This model is designed for environments with uncountable users (like public web applications) or high user counts where SALs would become too expensive.

  • How it works: You license the processing power (cores) available to the SQL Server. It allows an unlimited number of users to access the licensed server.

Availability: This model applies to SQL Server Standard, Enterprise, and Web Editions.

The "Rule of 4": Minimum Core Requirements

If you choose the Per Core model (or are forced into it by using Enterprise/Web editions), you must adhere to the minimum requirement of 4 core licenses.

Whether you are licensing a physical server or a virtual machine (VM), you must assign a minimum of 4 core licenses per physical processor or per Virtual Operating System Environment (VOSE).

  • Example: If you run SQL Server on a VM with only 2 virtual cores, you must still purchase 4 core licenses.

Packaging: Core licenses are sold in 2-core packs, meaning you must purchase at least two 2-core packs per instance.

Virtualization and Hyper-Threading nuances

In modern hosting, almost everything is virtualized. When licensing by virtual machine, the number of licenses required equals the number of virtual cores in the virtual OSE (subject to the 4-core minimum).

However, Hyper-Threading introduces a critical compliance factor:

  • Usually, one license covers one virtual core.
  • However, if a single virtual core is mapped to more than one hardware thread, you need a license for each hardware thread.
  • In short: You must cover the total computing power allocated to that VM.

Common Compliance Pitfalls (The "Gotchas")

According to SPLA training materials, auditors frequently identify specific errors regarding SQL Server:

  1. The "Passive" Failover Trap

SQL Server often includes benefits for passive failover instances (active-passive clusters). However, a common mistake is neglecting the Operating System. Even if the SQL instance is passive and free of charge, the Windows Server it runs on is not. You must report active Windows Server licenses for both the active and passive nodes in SPLA.

  1. The Hidden Dependencies (SharePoint & CRM) 

If you are hosting applications like SharePoint or Dynamics CRM, remember that they require a SQL Database backend. A frequent compliance error is reporting the application licenses (e.g., SharePoint SALs) but failing to report the underlying SQL Server licenses.

  1. License Mobility vs. SPLA

If your end-customer has their own SQL Server licenses with Software Assurance (SA), they may be able to use "License Mobility" to move their licenses to your shared datacenter. In this scenario:

  • The customer provides the SQL licenses (via their Volume Licensing agreement).
  • You (the provider) do not report SQL on your SPLA.
  • You must still report the Windows Server licenses via SPLA.
  • You must be an Authorized Mobility Partner and retain the verification forms.

Summary of Editions

  • SQL Server Standard: Flexible. Can be licensed by User (SAL) or by Core.
  • SQL Server Enterprise: Performance focused. Must be licensed by Core.
  • SQL Server Web: Cost-effective for public websites. Must be licensed by Core.

Special Scenario: The Flexible Virtualization Benefit (FVB)

The Scenario: "TechCorp" Moves to the Cloud Imagine a customer, TechCorp, who has already purchased SQL Server Enterprise Core licenses with active Software Assurance (SA) or active Subscription Licenses directly from a reseller. They want to move their database to your datacenter to save on hardware costs, but they do not want to pay for SQL Server again through your SPLA fees.

  • The Old Rule (License Mobility): Previously, TechCorp could move their SQL licenses to your shared servers using "License Mobility." However, they had to fill out verification forms, and they were required to use your SPLA licenses for the underlying Windows Server operating system.
  • The New Rule (Flexible Virtualization Benefit): Under FVB, if you are an Authorized Outsourcer (see definition below), TechCorp can bring their SQL Server licenses and potentially their Windows Server licenses to your shared servers.

How it works in practice:

  1. Check your Status: You must be an "Authorized Outsourcer." This simply means you are a service provider who is not a "Listed Provider" (currently defined as Alibaba, Amazon, Google, and Microsoft).
  2. The Customer's Responsibility: TechCorp installs their own licensed SQL Server on your shared hardware.
  3. Licensing Math: TechCorp must license the Virtual Machine (VM) by virtual cores. The same "Rule of 4" applies: they must cover all virtual cores in the VM, with a minimum of 4 core licenses per VM.
  4. Reporting: You (the hoster) do not report this SQL Server usage on your monthly SPLA report. The customer is using their own "Bring Your Own License" (BYOL) rights.
  5. No Verification Form: Unlike License Mobility, FVB does not require the specific License Mobility Verification Form. 

Why this matters for you: This benefit allows you to compete with the "big clouds" (Listed Providers). Listed Providers generally cannot offer this flexible BYOL option for Windows Server on shared hardware. As an Authorized Outsourcer, you can host TechCorp's entire stack (Windows + SQL) on shared infrastructure without forcing them to buy new SPLA licenses, reducing their Total Cost of Ownership (TCO).

Simplify SQL Licensing with Octopus Cloud

With the Flexible Virtualization Benefit, hosters can support customers’ existing SQL Server licenses on shared infrastructure while staying fully SPLA-compliant. 

Octopus Cloud guides service providers through SPLA, FVB, and all licensing nuances, ensuring deployments are cost-efficient and audit-ready. Reach out to our team to simplify your licensing and optimize your cloud services.

Ready to make your next move?

Experience the speed, ease, and limitless scalability of our platform.