I’ve worked around Microsoft licensing for almost 7 years at my current employer, but even when I was doing Web development back in the 1990’s, Microsoft’s licensing —particularly for SQL Server—was infamous for its complexity, or at least for how hard it was for someone new to the realm to wrap their head around.

The more things change, the more they stay the same; Microsoft is still (in)famous for the complexity of their enterprise software licensing rules. I compiled a list of 10… excuses? that can explain, or perhaps at least clarify why licensing is still so complicated. This is far from exhaustive and applies first and foremost to Microsoft. But it can be used to explain most of what we all must live with in terms of the rules, and many are applicable to other vendors besides Microsoft, at least to some degree.

The 10 excuses, in some semblance of order are:

1. Licensing doesn’t sit still
2. The rules aren’t a secret
3. You cannot be a casual licensing expert
4. Casual licensing experts are everywhere
5. Licensing dominoes are everywhere
6. Product licensing and technology (features and editions) are fatally intertwined
7. Product licensing and programs (how you bought it) are fatally intertwined
8. Subscription-based software is making things easier
9. Subscription-based software is making things harder
   
10. Don’t stop moving unless you want to get out of the pool

1: Licensing doesn’t sit still

The rules for licensing Microsoft’s software are evergreen. Really. Once per month, in a very uniform and predictable manner, Microsoft posts the Product Terms (in the form of a Word document) to their website. There are other documents enterprise customers need to be aware of, but the Product Terms is the core of Microsoft enterprise licensing rules, and although Microsoft’s direct motivations for a specific change aren’t always visible, they’re intrinsically there. Organizations usually have their own set of rules, based on the program they are licensing through, but this document defines how the products and services align with those programs.

Over time, you can learn to see changes that were made to increase revenue, drive adoption, address a competitive threat or market stall, and sometimes, once in a while, to simplify things. Realistically, nothing in the Product Terms ever changes just because somebody felt like it.

Over time, All of the following cause changes within the document:

1. New, changed, or discontinued products or services
2. New, changed, or discontinued suites of products or services
3. Changes to how a product, service or suite are licensed
4. Changes to how these are acquired, like which programs include them
5. Expansion or contraction of the locales where they are available
6. Similar adjustments to what Microsoft has available for licensing beginning that month.

The Product Terms is a monstrously huge Word document. But it’s not insurmountable. It’s organized in a reasonably logical manner and includes a table of contents and (misleadingly) simplistic “what’s changed” section. There is also some appendices at the end that can be easily missed, but are often quite important.

The more you read the Product Terms (PT), the more sense it will… should… is likely to? make. Unfortunately, the document is so large and complex that even Word will give you an error telling you it can’t proofread the document. It’s also lightly obfuscated so that you cannot (easily) compare this month’s PT with the document from last month. Which is important, because–outside of certain circumstances–today’s rules are the rules that matter.

A key thing to remember if you really want to understand the product terms is to not trivialize the terms used in the licensing document. For example, I still often see people still interchange version and edition. They’re never interchangeable. A version is a specific release of something (5.1.2600, for example), and an edition is specific packaging of a product that defines the technology it contains (ex: only Windows Pro includes inbound Remote Desktop connectivity) and what license rights it has (ex: only Windows Enterprise lets you run it on a virtual desktop infrastructure – but this is not technically enforced).

Similarly, I like to avoid the use of terms like “purchase”, “buy”, or “own”, because those usually aren’t accurate. Instead, use “license”, and “have rights to”. It’s Microsoft’s software. You’ve just paid for the rights to use it.

2: The rules aren’t a secret

As I noted above, the rules aren’t a secret. They live in a publicly visible Word doc that is updated with a degree of precision on the first of each month. Contrary to popular opinion, you don’t even need a decoder ring to read or apply them, either. But you do need to take time and learn to process how they apply to each product – a task which is different for almost every Microsoft product (each team has different business objectives, so implements things—especially transitions between mighty morphing license models—differently).

If anything, the biggest problem is that for Microsoft’s largest customers, living within the rules effectively means that while the rules change every month, these customers usually get a stay until their next agreement renewal. This often means an opportunity to save money, but it also means understanding the set of rules your organization is living under can become quite complex, because you’re spelunking through old copies of the Product Terms (which Microsoft does provide archives of) to figure out what the rules for SQL Server were several years ago, based on software deployed a decade ago, instead of what’s on today’s Product Terms.

3: You cannot be a casual licensing expert

Looking at the first section, you can begin to understand the risks posed by a “casual licensing expert”. Anyone can open the Product Terms and, immediately, have a spark of a perspective of how to answer a licensing question. But the devil lies in the details. To answer a question about how to license a product, you usually need to understand or know how to/where to go to interpret all of the following:

1. What version and edition of software the customer has deployed, how it is used, and what licensing program it was licensed through
2. What rules and editions were in place when the product they’re running shipped
3. How they they licensed the software
4. What rules and editions are in place today, and when they signed their agreement
5. How to map “what was” to “what is” using those last two pieces of data

That last one is always the ouch moment. When my Licensing Boot Camp co-conspirator and I write about or present about licensing, it’s pretty easy to explain how the rules used to work, or how they work today – what we refer to as “Greenfield” licensing, since there’s only one semi-clean set of rules to explain at a time. Sometimes you’ll hear a Microsoft employee describe the new model for something as simple. But that’s because once they ship that new version and a new Product Terms, most people in Redmond get to wash their hands of the old licensing model. For customers, that’s when the complexity starts, and it doesn’t ever get easier.

But the most complex aspect of licensing to understand is mapping what was (what a customer usually believes they bought and own) to what they deployed, and aligning that with what the rules are today, and what they actually have rights to, due to the way Software Assurance works in concert with their license agreement(s). Learning to transpose an organization’s current software estate into current licensing terms, especially when most data you’re offered from the customer is quite likely out of date, is like learning to drive. I’m not talking not slow, casual residential practice driving. The risk of asking someone—even someone who works at Redmond and has a blue badge—a licensing question if they’re just a casual expert is that they may not know all of your data they need in order to interpolate the current rules into a reliable answer. I sometimes make mistakes while analyzing or writing about this too – and it’s been a huge part of what I do for over six years.

4: Casual licensing experts are everywhere

If you ask someone who isn’t your lawyer for legal advice, and they’re a good lawyer, they’ll most likely tell you that they can’t (or shouldn’t) provide you legal advice. The same should usually be true of licensing as well. Unfortunately, lots of people with the best of intentions will offer you licensing advice.

I’m inclined to recall a meeting we had on campus at Microsoft, where an FTE (full-time Microsoft employee) disagreed with my colleague about the way licensing worked for a part of their product. The employee stood firm. They were wrong, mind you, but they had strength in their convictions. At the end of the day, we were unable to convince him, even with information from the Product Terms. When things like this happen, I worry for customers.

One of the biggest dangers with casual licensing advice is the use of the expression, “I think I can see how it would work that way” when a customer new to the field or this product asks for validation of their interpretation. You never want to hear that. You want to hear, “It works like this. There are exceptions for X or Y, and I see why you would want, or might think, it works that way. Unfortunately, it doesn’t.”

My colleague and I often joke about the use of the expression “it depends” in our boot camps to explain away the squishy parts (actually the hard parts) of licensing. While initially amusing, the expression is often worse than useless. You see, it rarely depends. Once you have all the customer data and the rules, an interpretation is usually pretty reliable. You don’t want squishy licensing interpretations.

Auditors and attorneys never want squishy licensing interpretations.

5: Licensing dominoes are everywhere

My colleague and I often use the term “licensing dominoes” to describe interdependencies. Usually it’s how you need to license two technologies, where one relies on the other. The best example is SQL Server. To understand how to license your SQL Server estate (until 2017, when SQL also started supporting Linux), you needed to understand how to license SQL Server. And while Windows Server and SQL Server both have licensing that is (Windows Server) or can be (SQL Server) based on the processor cores in your host hardware, the reality is that if you know how to license SQL Server per-core, you don’t know diddly about how to license Windows Server (which is always licensed on a totally different per-core/client access license (CAL) basis.

To license (or to understand the licensing of a long-deployed setup of Microsoft software, you’ve got to understand the rules that define the whole stack. To license just the server side of Project Server, for example, this means you need to understand:

• Windows Server
• SQL Server
• SharePoint Server
• Project Server

That’s not even taking the client side into account.

6: Product licensing and technology (features and editions) are fatally intertwined

Once you understand all the dominoes you need to define, then you have to understand the edition(s) of those products that you care about. This is one of the more complex problems with licensing, because you again need to care about what was: “What was the edition mix in 2010, when this infrastructure was licensed and deployed?” versus what is: “What’s the edition mix of the version that Microsoft just released in October?”

For example, if you licensed Windows Server Enterprise edition in 2008, and kept Software Assurance on it until now, what edition of Windows Server do you actually have rights to now, and what licensing rules are you obligated to live under?

Given the regular shifts in client and server pricing, and regular feature packaging shifts within Windows Server and Microsoft server applications, this is one of the hardest pieces of knowledge you must get your head around to license something correctly.

7: Product licensing and programs (how you bought it) are fatally intertwined

Just like versions and editions, how you license software determines what you can actually do with the software. If you license Windows 10 through an Enterprise Agreement (EA), there are usually things you can do with it that you can’t if you licensed it through a Cloud Solution Provider (CSP) – and sometimes, vice versa.

So now you need to hold multiple multidimensional cubes in your head. For each licensing domino, you need to understand the current rules for the:

1. Program you licensed the software through
2. Current version of the software
3. Applicable edition of the software.

Then do it again so you understand what the rules were when it was deployed, if you want to transmogrify what the organization initially licensed into something that you can claim is legit to license it today.

8: Subscription-based software is making things easier

When Microsoft initially shipped Office 365, my colleague and I were all excited that non-compliance would be a thing of the past, that Microsoft would build enforcement into their own services, to reassure customers that they were, in fact, properly licensed… that it would not be possible to get out of compliance to the point where you might have significant license surprises down the road. And for certain parts of Office 356, the Enterprise Mobility + Security (EMS) suite, and Windows 10 when activated using Azure Active Directory (AAD), that’s the case… but unfortunately…

9: Subscription-based software is making things harder

Because of the way Microsoft has been adding new editions (tiers, etc.) of service to Office 365 and EMS in particular, and because some of the features of these—some of the most important features of these—are only off or on at an entire Office 365 or AAD tenancy level, compliance is stuck on a slider somewhere between intractable and impossible for customers that want to do the right thing. We’ve written at length about this at Directions on Microsoft, and my colleague recently did a Webinar on it as well. The hope is that over the coming years, Microsoft will fix this, so customers can take advantage of features in top-shelf editions of Microsoft’s online services, without fearing significant financial surprises down the line.

10: Don’t stop moving unless you want to get out of the pool

If licensing is part of your job description, it will be a part of your job description until you leave that position. I’ve seen people jump about, excitedly proclaiming about how the cloud will simplify software licensing, to the point that we’ll no longer need software asset management (SAM).

LOL.

Licensing complexity can neither be created nor destroyed, only transformed.

With new complexities introduced by cloud-based services, sometimes intermingled with how things are licensed on-premises, being license compliant – and ensuring you’re getting the correct savings for your existing on-premises estate, as Microsoft offers with their Azure Hybrid Benefits for Windows Server and SQL Server – just means a new set of SAM processes that work differently than SAM as we knew it for the last 20 years.

With this post, I initially set out to create a work that described how licensing isn’t really that complicated. But the reality is that this is not simple, and this is just describing Microsoft. A lot of our members and licensing boot camp attendees have to parse rule sets from multiple vendors – including vendors some of you wouldn’t remember.

Understanding licensing to the point where you can describe how to license something accurately and succinctly given limited data is hard. But it is possible, if you’re willing to put the time into it and ensure that you understand all of the angles first.