SQL Licensing in SPLA

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. The SPLA program also grants access to the latest versions of SQL Server without separate upgrade fees, and helps providers provide flexible billing options to customers.

However, SQL Server offers multiple licensing models and edition constraints that can trip up even experienced providers and software services resellers in the Microsoft business.

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

For broader context on how SQL Server fits into SPLA overall, it helps to understand the Microsoft SPLA program essentials alongside these 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 who can be licensed using Subscriber Access Licenses (SALs).

• 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 option, 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.

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, and similar minimum core rules apply to Windows Server licensing in SPLA.

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

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.

According to Service Provider License Agreement training materials, auditors frequently identify specific errors regarding SQL Server:

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 agreement.

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, something we also cover in depth when discussing Exchange & SharePoint licensing in SPLA.

License Mobility vs. SPLA licenses with software assurance

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, a pattern that also appears in Microsoft Dynamics licensing under SPLA. 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, along with any required Remote Desktop Services (RDS) licensing in SPLA when users connect via remote sessions.
• You must be an Authorized Mobility Partner and retain the verification forms.

When choosing between SQL Server editions, many providers also evaluate whether workloads should run under SPLA or CSP, making a hybrid SPLA and CSP hosting strategy increasingly important.

SQL Server Standard Edition

SQL Server Standard Edition offers flexibility in Microsoft licensing. It can be licensed either by Subscriber Access License (SAL) or by Core, depending on your environment and user count. This makes it suitable for a variety of hosting scenarios, especially where you have a moderate number of users or need to optimize costs between user-based and core-based licensing.

SQL Server Enterprise Edition

The Enterprise Edition of SQL Server is performance-focused and designed for high-demand environments. Licensing for this edition must be done by Core only, reflecting its use in scenarios with uncountable users or intensive workloads. This edition is ideal for large-scale applications requiring advanced features and scalability.

SQL Server Web Edition

SQL Server Web Edition is a cost-effective option specifically tailored for public websites and web hosting scenarios. Like the Enterprise Edition, it must be licensed by Core. This edition is optimized for web hosting providers who need to serve many users without licensing complexity, making it a popular choice in shared hosting environments where a SPLA licensing and FinOps platform can help control ongoing costs.

Because FVB often spans SPLA, CSP, and BYOL scenarios, many providers use a unified Octopus Cloud View licensing platform to keep these environments compliant.

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 and may also be evaluating data center licensing under the CSP program alongside SPLA. 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, taking full advantage of the broader Flexible Virtualization Benefit.

How it works in practice

In practice, similar BYOL and virtualization considerations also appear when hosting Office or Access-based solutions, such as Microsoft Access Runtime licensing in SPLA.

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), which is equally relevant when applying FVB to Microsoft Office licensing in SPLA.
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, a topic often discussed within the Octopus Cloud SPLA & FinOps community.
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).

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

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