Business Continuity: it's a governance issue (as well as, probably, a Security - Availability - issue): maintaining the operation of the business regardless of what happens around you (not to be confused with mere "Disaster Recovery", which is a subset of Business Continuity, as Business Continuity can be impacted even if your systems are nominally still available)). I talked about this in my blog recently and I now see that I've been quoted in an IT Pro article - thanks for the compliment.
In response to this, I got a comment that a server license linked to a specific MAC address might be a real business continuity issue if ever that server dies. Well, true, and I hope the vendor with such a license has an answer. But, the time to find out about this is when you are negotiating the purchase, not just after the server has crashed.
And, of course, I agree with the general point being implied: licensing should be considered as part of a Business Continuity strategy. It is not good to come up after a contingency and find that (at best) you aren't fully licensed or (at worst) that something important won't run because it is now unlicensed.
I make no secret of the fact that I don't much like conventional licensing - I prefer service-based "pay-per-use", where invoking a different instance of the service after a contingency doesn't matter, but that isn't always feasible (if it isn't something the vendor offers, for example, and you really need the software).
If you do have conventional licenses, check very carefully what happens if you lose the machine running the licensed product and have to come up with a different device - perhaps after you've lost the original license disks in a fire or whatever. Usually, you'll be ok, possibly after a small service charge for getting everything straight, but do check with your vendor NOW, before you really need to, and make sure there's a secure record of the conversation, and that anyone who might need to know about this, does. Years ago, I heard about someone who unnecessarily bought a whole set of expensive new licenses after a disaster - and the insurance wouldn't cover the cost, because the vendor would have just replaced the license disks, if asked.
There is, of course, another point to consider: the vital importance of Configuration Management to Business Continuity (and not just to recovery after a disaster). If you don't have a secure (off site) and up-to-date record of your configuration before whatever contingency took your systems down (or, more likely, severely impacted your service without actually crashing it), how can you be sure that everything is working properly when you come up - possibly on different hardware, possibly using different services, and possibly somewhere else?
Keeping track of the necessary licenses is part of Configuration Management as a whole (which includes, or complements - depending on your point-of-view - Software Asset Management), but there's a lot more to it than that. Configuration Management is about managing everything (not just the technology) that is critical to delivering a business service. And, don't overlook Open Source Software (OSS) and its licenses, by the way. It doesn't usually impact Business Continuity, because if you know you are using it you can just download it again, but OSS has a legally enforceable license and if it is essential to a service, then it should be managed.
If you can't manage everything essential to delivering a business service, how can you be confident of your ability to maintain Business Continuity (or of your systems security etc, for that matter)? If you want to learn more about configuration management, attending a meeting of the Configuration Management Specialist group (CMSG) of the BCS might be a good start.