Do VMware SDK License Limits Go Too Far?

Despite an obvious need to attract more independent software vendors and more third-party applications to help manage VMware-based virtual infrastructures, VMware is using licensing terms to put both its customers and ISVs at risk of license violations every time they use a piece of software not written by VMware.
Most people don't read the fine print of End User License Agreements [EULA] carefully, and with good reason. License terms tend to be overly restrictive, overly detailed and -- as is often demonstrated when the more extreme versions are tested in court -- unenforceable.
Nevertheless, they do form the basis of the legal agreement both customers and ISVs rely on when they work with VMware.
The problem is that the language in the EULA for VMware's software developers kit (SDK) makes it almost impossible to create for-fee software using any of the SDKs provided by VMware.
That makes it almost impossible for end users to buy applications that don't violate their license agreements and -- worse -- stifles development of the third-party applications that are critical to both customers and to VMware's ability to compete with Microsoft.
Yes, there are quite a few ISVs with commercial products out there, as the show floor at VMworld will attest.
But unless each of those ISVs uses a much more permissive license agreement than the one VMware distributes to most users and developers, both the ISVs and their customers could be in for a surprise.
Now I am not an attorney but these terms are just a little too limiting for me:
You may download and make a reasonable number of copies of the Toolkit contents for your personal use solely for the purpose of creating software that communicates with VMware Software ("Developer Software")
This implies that the VI SDK cannot be used to create third-party software. Or at best, that you cannot ship a copy of the VI SDK with your software. It also implies you can never use the VI SDK within the confines of a business because anything you create has to be for your own personal use. Personal has a cut and dry definition: you, yourself as an entity. It does not necessarily mean "a corporation" or any other entity.
Other restrictions include forbidding use of the toolkit "to design or develop anything other than Developer Software।" Which is defined as "personal use."


What Does It All Mean?
That means you as a third party can't use the SDK to develop software for which you plan to charge or that is to be used in your business as opposed to personal use. So you can only develop items for your own personal use outside the business world without violating the agreement.
That means any third-party software you use that was built using a VMware SDK is likely to be in violation, which will put you in violation.
And all those time-savings tools you have written to use in your job? Sorry, that's not "personal use," so they're a violation, too.
And if you rent space on your servers to other organizations, you can not include the use of any tool in this and you cannot use the tool for business use anyways.
And don't forget that "you may not use the VMware name or any other trademarks or server marks of VMware in connection with programs that you develop using the Toolkit."
That implies that when you write documentation for your purely "personal use" tool, you cannot even use the terms VMware, ESX, GSX, ESXi, VirtualCenter, or anything else specifically owned by VMware within the documentation.
How would you even specify how to use the tool if you can not mention the products with which it is meant to be used?
This seems like a pro forma argument. There's not much evidence that VMware is trying to prosecute ISVs for building for-fee software for VMware.
But it goes a lot further than that. Software developers live and die by the EULA. This one is clearly designed to stifle everything they do in relation to VMware.
VMware's apparent isolationism and restrictive licenses is source of debate on then VMware Communities Managemnt API forums. VMware does not court ISVs the way Microsoft does.
This is something VMware needs to wake up to, and quickly. VMware is in a battle for its survival with Microsoft, whose major strength is not its operating systems. Its greatest strength is the ability to attract third-party developers that, in turn, attract more customers, who attract more developers, and so on.
A big part of Microsoft's virtualization event Sept. 8 will be focused on third-party tools and integrators.
Can we expect the same at VMworld?
VMware needs to court ISVs, rather than putting them off and stifling development with restrictive EULAs and no longer existent developer-support programs. There used to be the VMware Technology Network (VMTN), which was much like the Microsoft Developer Network (MSDN), but that has disappeared. I think VMTN should be resurrected to aid developers.
VMware can change license agreements, just as it did when it modified the VMware ESX Server EULA to allow hosting of Virtual Machines.
The SDK EULA must also be changed to allow ISVs to produce valuable and much needed products.
More importantly, VMware has to realize it is not and should not be acting alone. There is a legion of developers and customers out there that are eager to work with the company and to improve the security and manageability of VMware virtual infrastructures.
Helping them will help VMware; continuing to restrict them will help Microsoft. You don't have to be an attorney to reach that conclusion.

Reference : http://www.pcworld.com/article/150680/vmware_sdk_license.html?tk=rss_news