Quoting the VMTN Blog: The Console

In April of this year, VMware announced that we were making our virtual machine disk format, VMDK, openly available and freely usable to anyone who wanted to do so. Since then, over 2000 vendors and developers have requested to review and use our VMDK specification. The virtual machine disk format is a critical specification for customers and the industry because value-added solutions that manipulate virtual machines such as patching, provisioning, backup, and security are dependent on it.

Last week Microsoft announced that it too is moving to make its virtual machine disk format, VHD, more open. Previously VHD had been covered by a much more restrictive license. We are glad that Microsoft is making VHD more freely usable by third parties. The ecosystem has invested broadly in VMDK, but it is good that VHD now has the same accessibility.

One highly related area we are concerned about is that we’ve seen Microsoft beginning to put restrictive terms on the use of published VHDs. Specifically, it seems that Microsoft is starting to restrict use of their VHDs to MS Virtual Server and Virtual PC only. In contrast, there are over 300 VMDK-based virtual appliances available on VMware Technology Network (ranging from Oracle databases to CRM packages to firewalls to email security solutions) that are freely usable by all regardless of platform or product.

If Microsoft constrains software licensing of the content within VHDs so that the VHDs can only be run on Microsoft products, then there won’t be any real openness or interoperability for VHDs. We hope that Microsoft is committed to interoperability and open implementations for VHDs, and that the chokepoint isn’t simply moving from one prohibitive licensing constraint (VHD format licensing) to another (VHD software licensing). Microsoft should appreciate (and customers and partners have been very clear about this) that a closed system based on licensing restrictions which lock customers into Microsoft’s products and formats isn’t acceptable.

Read or comment on the original, here.