It's safe to say that few IT pros enjoy maintaining compliance with software licensing agreements. Some of us put in enough effort to ensure that we'll emerge from an audit relatively unscathed, but few delve into the details to know precisely what we can and can't do with the software we've purchased -- er, licensed. In fact, I'd hazard a guess that not one person reading this has actually read the license agreements for all the software they run.
However, as the cloud becomes more popular and more of us start to use it, we may need to all get used to reading the fine print. Although the problems are more apparent in larger enterprise-class software suites, the license agreements for a wide range of software today actually prohibit their use on hardware that isn't owned by the licensee -- effectively ruling out use in the cloud. Worse still, others prohibit use in virtualized environments or impose potentially crippling licensing costs should you want to run in a virtualized environment -- cloud or not.
The fact that these kinds of license restrictions exist isn't always apparent to the users and IT pros installing them. As most people who've used the cloud or virtualization know, pretty much any kind of software without inherent hardware dependencies will run just about anywhere. Chances are that the software and the license key you've paid for will work whether you're installing it on a "legal" bare-metal server or an "illegal" cloud-hosted virtual instance.
If it will usually work fine, why the limitation? The answer to that $64,000 question varies based on which vendor you're talking about. Some vendors simply don't understand how the cloud works or why their customers might want to use it. Others understand the cloud all too well and hope to reap the benefits of the recurring subscription revenue model it enables by offering their own proprietary cloud services, rather than let customers use someone else's cloud.
In either case, it's increasingly important for CIOs and IT pros alike to be aware of what license limitations might exist for the software they use or are considering using. Failure to do so could hamstring your plans for moving to the cloud or, worse, find you on the wrong end of a financially crippling software audit.
One of the very first things to watch for involves hardware licensing keys. Although you can often work around them by introducing an Ethernet-attached USB hub, many times the licensing software is too smart to fall for that. For software vendors that sell software licensed by a hardware key, the key effectively is the software. Chances are your attempts to virtualize it or move it into the cloud won't be successful. However, if you ask the software vendor, you may find it will support a software-based licensing scheme, so it's always worth checking.
The second red flag is software platforms that are licensed by the processor socket or core. These hardware-related metrics almost always cause trouble when you try to virtualize or go to the cloud because the concept of a socket or core changes substantially in both cases. A good example is IBM WebSphere. On a physical server, you pay a certain amount for each processor core you use to run WebSphere. However, in a virtualized environment, you pay a different amount for each processor core that WebSphere could run on. In an on-premises virtualization environment, that could mean any processor core within an entire cluster of virtualization hosts -- not just the ones that the WebSphere VMs are using. Unless you have a whole cluster's worth of WebSphere workloads, this can be prohibitively expensive. The bottom line is that any piece of software that is licensed by a hardware-based metric (processor, core, or server) could be a problem and warrants close inspection.
But many of the software vendors that have restrictions for on-premises deployments have also done quite a bit of work to make it possible to run their software in the cloud. Continuing to use IBM WebSphere as an example, Amazon.com has a deal with IBM to offer IBM software products on Amazon EC2 instances using Amazon's familiar per-hour-per-instance pricing model. That's great because it shows a willingness on the part of IBM to allow its software to run on a third-party cloud. However, what if you start to use IBM software on EC2 and then decide to move away from Amazon.com? Can you get the same pay-as-you-go licensing somewhere else, or are you locked into using Amazon.com?
An organization that makes the effort to understand software licensing terms will find itself better positioned to take advantage of the flexibility that the cloud offers. Organizations that don't do this licensing homework may find themselves tied to expensive on-premises software or forced into proprietary vendor-owned cloud offerings.
This article, "The software licensing gotchas in the cloud," originally appeared at InfoWorld.com. Read more of Matt Prigge's Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.