Table of contents

Part 1
Part 2   <— You are here
Part 3
Part 4


This is second part of my series on getting paid for your SharePoint software. If you have not already done so, please read part 1.

In part 1, I discussed how you need to be able to do four things to transform a piece of software into a product that you can get paid for:

  1. Distribute the software
  2. Deploy the software
  3. License the software
  4. Copy protect the software

Of these, licensing and copy-protecting the software prove to be the most difficult on the SharePoint platform. Please read part 1 of this series for details on why. Because licensing and copy-protecting software are closely related, I will discuss various options for structuring SharePoint software and their impacts on licensing and cop-protecting the software.

 

Option 1: License and copy-protect the installer

You could spend a lot of time, effort, and money trying to create the "un-piratable SharePoint app". And what if it doesn’t sell? You spent all that effort protecting something people don’t want. Consider incorporating the licensing and copy-protection into the installation utility only, and not the rest of the application.
  • Licensing – Package your SharePoint application WSP with SharePoint Solution Installer. Add a wizard step to call your license validation component. You can check for things like the number of servers in the farm, validate the entered license key with another piece of information like the person’s email address, check whether the farm is WSS, MOSS Standard, or MOSS Enterprise. This provides a minimal level of licensing validation but does not allow for things like activating features over time, trial-ware, responding to changes in server count, users count or other changes in the farm.
  • Copy protection – There is very little in the way of copy protection with this method. There is nothing to prevent a malicious customer from taking the files and assemblies from your application and manually copying them to another farm.
  • Level of effort – This is by far the fastest option to implement as it does not require any changes to the application itself. You could easily complete this within a few days to a week.
Option 2: License and copy-protect the application assemblies

This option is more involved than option 1, because SharePoint lacks the infrastructure to easily deploy the types of components that are typically present in off the shelf license validation tools. Please read part 1 of this series for details. I would only recommend this option if you already have software that is either selling or broadly distributed; i.e. you know people like and user your software.

  • Licensing – You have a number of options here since the licensing can now be more deeply integrated into the application logic itself. You have the potential to activate different features based on the type of key the user enters, implement time-limited or feature limited software (trial-ware), or just about anything else you can imagine and your license validation components support. The down-side: you have to modify your application code, perhaps extensively.
  • Copy protection – This option has a better copy-protection story. Since you are modifying and recompiling your application assemblies, you can integrate the copy-protection features of your license management components into the assemblies. However, this generally means that you need to issue and store environment-specific keys, like Windows and Office does. For example, the user enters a product key that is combined with information like the farm ID or farm server hardware signature to store an activation key (not the original product key) on the customer’s environment.

    The trick is to store those activation keys securely and prevent the software from being moved from one environment to another. One difficulty with environment-bound keys is that you will need a central repository that you control that will be used to keep track of which product keys have been activated on which environments. This means that the customer’s SharePoint will need connectivity to the Internet to activate the product keys. But, the servers will only need Internet connectivity when the server or farm-bound key is being activated. This is what key activation schemes like the one that Windows uses do. The problem with this scheme is that you have to be able to handle servers that don’t have Internet connectivity. Microsoft handles this by providing a call-in number.

  • Level of effort – The level of effort here is significantly higher than option 1. You could easily spend anywhere from a couple of weeks to a few months retooling the application to incorporate license-awareness and writing the necessary infrastructure code to deploy, manage, and revoke licenses. You will need to build or procure a license activation repository. I have used Quick License Manager from Interactive Studios with good results. They provide a license management runtime that can handle environment-bound keys and a license activation repository. For an extra fee they will even host the repository for you. Also, because this option requires modifications to the application, you will need to do full regression testing on the application functions and the deployment, updated, and un-installation processes.

To be continued in part 3…

Check back soon for the third article in the series. In part 3 of this series, I will show how some creative changes to the application design and to the business model for the application can give you the best of all worlds.

Technorati Tags: SharePoint,WSS,MOSS 2007,SharePoint 2010