I wrote an earlier blog post about the generalities of SharePoint (you can check it out here) but thought I would review further by providing an example. Here’s a fictitious story about SharePoint, and why I think there is so much confusion.
Dave worked for an insurance software company XYZ. They were in a pickle to say the least. His focus was developing software, not licensing it. He used a SharePoint site to host a line of business application that he charged a fee for customers to consume. I will save you the details of the application, but hopefully you will get my point.
This application went out to the insurance broker community as well as the broker’s customers. That being said, not all the information accessed was the same. Every broker (non employees of the insurance software company; not affiliated in any way) had access to their own unique information through their own credentials. Every end customer (the broker’s customer) had access to their own individual information as well. Dave decided that the number of users would be in the thousands, surely a processor based license would do the trick.
He went ahead and used SPLA because he knew his company was hosting and providing a commercial service. (he also read page 9 of the PUR for volume licensing “prohibit commercial hosting”) For two years he licensed by processor that covered all the users. Secondly, he never reported SQL. SQL is not being accessed directly, just used to collect the data. He also licensed Windows via SPLA.
One day Dave stumbled upon my blog. After doing a little research, he found a blurb “need a SPLA license for direct or indirect access.” He wondered if SQL would be considered “indirect.” While contemplating whether he should have licensed SQL, he thought of his solution in its entirety. If he removed the SQL server from SharePoint, would it still work? Of course it wouldn’t, which is why he needed a SQL SPLA license too. Now his heart was really pumping. Dave almost had a stroke. Then one night he was having a difficult time sleeping, and decided to check out the SPUR. After all, the SPUR surely would put him to sleep pretty quickly! Before his tired eyes closed for the night he happened to read “Hosting SharePoint 2013.” Curious what this was all about, he poured a cup of coffee and sat down only to find what he was doing was completely wrong. Here’s the blurb he read aloud, waking not only his dog, but his wife as well. Ouch.
All content, information, and applications accessible by internal users must also be accessible to external users. Access to servers that provide content, information, and applications that are limited to internal users, must be licensed under SharePoint Server 2013 SALs. “External users” means users that are not either (i) your customer’s employees, or (ii) your customer’s onsite contractors or agents. All other users are “internal users.”
The first sentence almost put him over the edge “ALL content, information, and applications by internal must also be accessible to external” He called SPLA 911 and got help. He owed two years of SQL and SharePoint user licenses, not processor. Why? All content was different for each individual user. No content was the same; user license would apply. If the company had a public site with the same information, and everyone sees the same thing, he could have used the processor license to cover everything.
Poor Dave…he lost his job, his company owed thousands of dollars in underreported licenses, and his dog and wife were still upset with him from waking them up in the middle of the night.
Moral of the story –
1. Service Providers (and resellers) get mixed up by the definition of “external user.” External user under SPLA is not your customer, but your customer’s customer. (the end customer). All information must be accessible by the external user and your customer. SPLA is not always the same as volume licensing.
2. Never…under any circumstance…wake your wife up in the middle of the night.
Don’t be Dave…
Thanks for reading,
SPLA Man
SPLA Licensing 