Microsoft Software Licensing and Protection (SLP) Services

  • Article

When I was in Seattle to attend an internal technical conference, there were banners all over the convention and exhibition center, and the banner says "Software Licensing and Protection Services". In self-deprecation humor style, I quipped to my colleague that this sounds like the company is providing "bouncer" services to our ISV partners.

Having said that, and humor aside, I knew this is exactly what many of my ISV partners have been waiting for. In any commercial software initiative, software intellectual property (IP) protection is of utmost importance and is an integral part of any product development manager's mind. I attended the breakout session to find out more about SLP.

Essentially there are two important components in SLP as its name suggests; software licensing, and protection. The first thing that comes to mind about software licensing is how to license your software to your customers. From the end-user perspective, and especially to one who's been using Microsoft products, product activation by means of a product key comes straight to your mind. If you're thinking this, you're spot on! As for software protection, the R&D or product development manager demands it. I know this because once upon a time I was a R&D Manager in an ISV, and I wanted to protect my company's IP. For more selfish reasons, I just don't want the hard work that my team and I had poured into the product for months get pirated.

In the .NET world, you have heard of code obfuscation. There are many literature around this so I don't think any explanation around this is needed in this blog entry. However let me point out from the perspective of the development team. Let's say I am developing a Web service, and I'm licensing this to my customers by means of subscription.  Typical service-oriented architecture (SOA) styled, if you will. How do I protect and charge (and I do mean both, after all we need to make a living after all) my customers for the operations that they could invoke in my Web service. This also allows me to differentiate my service offerings to my customers. If I am a component library developer, I would be leaning towards similar tactics to ensure only licensed customers could invoke my library. The key to this is really in the service itself, that first of all the code protected (using PKI technology) beyond mere obfuscation (which could be reverse-engineered), and that the code is fully aware whether the client is "authorized" or licensed to invoke it in the first place.

Please check out all the resources about SLP on our website, www.microsoft.com/slps:

· SLP Services Developer Center on MSDN to find blogs and forums where you can interact with other customers and technology experts

The verdict: My ISV partners need not reinvent the wheel, they could just rely on Microsoft for all our best practices in licensing and protecting our software, and they just focus on what they do best. Develop/market/sell their solutions/applications.