SPLA Basics: Who Needs a SPLA?

We write extensively at this site about some of the finer points pertaining to licensing software under Microsoft’s Services Provider License Agreement (SPLA). However, some businesses new to the model often ask us much more basic questions, like: What is SPLA, and is it right for me?

Like most for-profit software publishers, Microsoft publishes its various software products under license agreements that generally prohibit licensees from hosting those products for “commercial hosting services.” Microsoft first introduced SPLA in 1999, when companies wanting to offer web-based services increasingly found themselves running up against the earlier incarnations of the anti-hosting language. The intent of the model was to provide a licensing framework specifically for those businesses that also allowed Microsoft to monitor and police the use of its products in those arrangements. Typical SPLA customers include data-hosting providers (e.g., HaaS, website hosts, file-sharing) and hosted application providers (e.g., hosted BDR, CRM or messaging). However, many businesses that do not cleanly fit into those categories often discover (and often to their surprise) that their services also are within the scope of the “commercial hosting services” that require the kind of rights available under SPLA.

SPLA-licensed products must (with some exceptions) be used exclusively in connection with the delivery of hosted or rental software services. It is not intended as a primary vehicle for licensing internal-use deployments, though most SPLAs include provisions allowing a limited amount of internal (usually no more than 50% of total usage per product). In addition, where “traditional” licensing models require an up-front license purchase that is formulated based on projections for future usage, SPLA entails reporting usage on a month-to-month basis and paying only for those products or license rights that actually are used each month. The SPLA licensee does not receive perpetual licenses under the agreement, but it does receive the flexibility to float its license spend up or down as needed (in addition to the hosting rights that may be required for its use cases).

However, SPLA reporting can be astoundingly complex and fraught with pitfalls. Even simple questions – like “What software are we using?” – are not so simple when viewed through the filter of the SPLA terms and associated use rights. Businesses contemplating SPLA need to obtain a firm grasp on the applicable rules and requirements of the program. Failing to do so can be an extremely costly mistake, given Microsoft’s tendency to aggressively audit its SPLA customers.