Some vendors are charging licensing fees for each processor or even each processor core in a server. In an article on Network World Oracle is described as charging for each individual core on multi-cpu, multi-core systems. My view is that this type of pricing is too confusing and cumbersome for vendors or customers to track, espeically as virtualization allows a server instance to migrate between various physical systems. I think the licensing should be according to the server instance and dispense with trying to grab every possible dollar off the table. Some vendors license their software according to the power of the processor instance in use and I don’t necessarily have a problem with that, as long as the power increments are in big enough chunks that it doesn’t cause customers headaches when they try to honor the vendor’s licensing policy. When you look at most of the apps, you’ll find that other factors create bottlenecks that limit overall performance, so the vendors aren’t giving away major value with a more easily implemented licensing policy. I say “So What” if there are 16 cores working on a DB server when the I/O system is limiting performance to the same as for a 4 core server.
This sort of thinking is what drove us at Netcordia to license our products based on device count. The major performance limitation of a good network management system is the number of SNMP objects polled and the polling frequency. The number of interfaces typically drive the number of SNMP objecs at a greater rate than any other factor. We found that few customers know how many interfaces they have in their network, but they often know roughly how many devices they have. Computer Associates has used ‘per element’ licensing, which customers disliked because they didn’t know how many elements they had. Licensing by device follows the ‘Simpler is better’ approach, making our customers much happier and making it easier to work with them.
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html