Multiplexing strategy for reducing software licensing cost

Software licensing is a complex and confusing topic. Most of us know how to use and master any given software like SQL Server, Oracle, or Crystal Report etc. But purchasing a software and figuring out the real cost is a challenge. Questions like do you want to go with named-users or per core licensing or on the basis of number of processors or total number of CPU’s are confusing. For example, Microsoft will charge you based on the number of processors in your server irrespective of number of CPUs / core per processor and Oracle will treat each core as half the processor. For example, on 4 quad core server [4 processors with 4 CPUs on each processor = 16 CPUs or cores], SQL server will cost you for 4 licenses and Oracle will result in 8 licensees [16 * 0.5 =8] [1]

Now this might be acceptable for enterprise grade tools like RDBMS or reporting solution. But many a time we end up buying 8 or 10 copies of small commodity software used by a department or a group of users working on a special project. Most of these tools are sold on per instance basis. So we end up paying for 10 copies and installing it on individual desktops. This also results in maintenance nightmare.

There is a better way to deal with such commodity tools – strategy known as multiplexing. It’s very straight forward – all you have to do is to install one instance of the commodity software on your central server and write a wrapper around it. The wrapper can be exposed over the network [LAN / WAN / Internet] using http, https etc. Yes, you will have to write a web application that will expose the interface for the commodity tool. Many a times, this strategy will work like a charm [except if licensing agreement for the commodity tool explicitly deny the permission for any such exercise]. Note – this does not involve changing any of the bits / code in the commodity software – all you are doing is to expose its public interface over the network. Threading and deadlocks might pose some challenge when shared resources are simultaneously utilized by many users. But this can be avoided by placing an explicit lock on shared resources like file folders. Additionally, this public interface can be modified to accept the inputs from internal resources like local databases, file system etc.

If used judiciously, multiplexing can deliver a great business value.

Reference:

1.http://www.microsoft.com/Sqlserver/2005/en/us/special-considerations.aspx