So, to continue with the story from before…
LICENSING AND PACKAGING
As I wrote before, SLP services is awesome thing in terms of protection of code, but they also give complete solution for implementing the system of licensing app. There are no more those sorrow days when we were buying just retail versions of software (ok, buying is hard word… maybe borrowing ;). In time of ‘software-as-a-service’ and ‘pay-per-use’ solutions, SLP gives us reliable model for supporting this, through:
– turning on/off different feature sets (modules) without recompiling of code,
– adjustment of code for each users (personalization),
– business models such as SaaS (software as a service), pay-as-you-go and subscription ,
– different kinds of application upgrades (ehm, ‘upgrade’… it’s usually just a patch or correction of bugs),
– sending of product electronically, ‘on-demand’ shipping, sharing of installation media, etc.
1. Feature-level control (modular configuration)
The point is that every specific method inside the code has to be mapped with predefined module (feature), and then, before calling, it is checked if the module is activated or not. This represents a new philosophy called “license as business logic”. That means that always a full version is shipped to a customer, and then, through SLP services, business rules are defined which determine which modules will be activated and what in a whole will be influenced by that change.
Additionally, SVM records (audits) how many times a module is used (feature set). Although the code remains untouched, developers may use also Service Code Protector SDK if they want further to ‘massage’ on that functionality and adjust it their special needs.
This topic brings me back in time when I was working on first bigger projects, and on problems with the delivery and handing of different kinds of program versions. It was extremelly difficult to split what is sending and what is not sending to the customer – especially in terms of database and data objects in particular (for example, triggers which update tables of some other application modules, etc), and mess around the application and other components, references, files of all kinds, reports, changing of business rules and politics in-the-fly. Alltogether, that story will, I guess, continue to be told and lived, because, the war isn’t over – it’s just one battle won.
2. Adjustable possibilities of licensing
SLP offers building blocks (‘lego bricks’) for creating appropriate licensing model by desire of a customer and market:
– demo version – application works for a certain time period and then – either stops working or works with limited set of functionality,
– free basic version – it’s version in which basic set of functionality is offered (most commonly through limited time period), but for more advanced options (or for resuming of usage) there should be some money spent,
– subscription model – application license should be replenished regullary to make application work.
All this work is made via SLP online portal which has couple of nice forms for entering the licences and options in preparing the packages (see the picture). You can adjust start and end of licence period, or unlimited usage, ‘grace period’ (merciful time), is the license renewable, and so on.
Licenses can be configured to limit number of concurrent users and/or number of times starting the app. You can turn on application activation via internet or manually (offline). Also, you can allow licensing during the testing time even on virtual machines – VMWare/VPC (I’m just surprised that Microsoft put VMWare on first …), etc. Anyway, play around yourselft to see what else it has.
There is an option to monitor on how the users licence their applications. In fact, there is so-called SLP Server 2008 (simply put: Microsoft just cannot learn not to use word ‘server’) and SLP Online Service which monitors and waits ‘somewhere in dark and quiet’ to pops up when some activation, registration of module appears. We can, for example, find out how many times and when the application has been used, which parts are heavily used (or not used at all), and we can gradually put it in some ‘cube’ and data mine, of course.
LIFE CYCLE OF LICENCE
Bah, how I like those ‘buzzwords’, especially from Microsoft (although it’s rather old one). It’s near the day when we will use ‘GMO code’, or ‘hormonal services’, or internet clouds (oops, we’ve got this one already). So, a license is living being. It starts its miserable life with defining of products and possibilities that it gives. All this can be done by using SLP Server 2008 (locally) or SLP Online Service (web).
Further, we define a set of functionality – modules which we can additionally licence, with definition what goes with the demo version, what goes with basic version, complete (full), or whatever flavor we choose to distribute our solution (home, enterprise, etc). All this we adjust with our source code by linking the methods with SLP terminology, and that’s it.
Activation of licence
When the software is being distributed, it comes with the activation key required for its unlocking. It’s nice thing because it eases our suffer with crypting the code which anyway doesn’t have to do anything with the business rules. When the code is precompiled using SLP Code Protector, during the startup sequence of our, if one is not activated, a small wizard pops up which allow us to enter activation key and continue with our work.
What happens in the background is that the app connects with the SLP Licensing Control Portal to check the key and unlock the app for execution. If there is no internet connection available, a user has the possibility to install manually licence file.
And, at the end of the lament, I review the tools we can use for SLP services:
SLP SERVICES TOOLS
SLP Code Protector
As I said, it concerns the protection of the source code. It transforms .NET MSIL in protected encrypted SVML and links parts of the code with the ‘feature sets’, i.e. licences.
It allows transformation of MSIL into Secure Virtual Machine Language (SVML) – it contains distributable SVM for including it into the app. It allows digital signature for the licensing. Consider it SLP SDK.
SLP Service 2008 (locally) / SLP Online Service (web)
It allows management and maintenance of licensing models – defining of licenses, modules (feature sets), publishing of licences, reacting on the activation.
Packages of licences (commercial or free) for software activation. It is installed, by the way, during the creation of .msi file.
Here, I hope that I’ve made closer this topic to you, which personally interests me a lot, and impressed me because of its simplicity and practical usage.
And now, the bad news…
Microsoft sells the whole story in a few modalities.
SLP Online Service is sold subscription-based, in which there are three different kinds of it based on its power and might: Basic (costs 42 $ a month), Standard (625 $ a month), and Enterprise (which costs ‘chilli’ 1.667 $ a month).
SLP Server 2008 (which is actually a beating heart of everything) costs in standard equipment ‘from 23 thousand above’, and for Enterprise you have to spent ‘at least 60 kilos’.
Well, obviously the Mic applied the SLP system firstly on the SLP itself, and that on the package system. So, so-called basic permutation (5 methods of products) costs additional 750 $, and unlimited permutation whole 5.000 $.
Also, activation packs are additionaly purchased: 1.000 $ for 1.000 licences for commercial purposes, and 100 $ for 10.000 licenci non-commercial activation packs. I knew there is a catch. Phew!
Anyway, SLP stands as a good designed framework for protection and licensing of applications.