Is the Benchmarking clause in VMware&#39;s EULA actually valid? The VMware End User License Agreement reads as follows: 2.4 Benchmarking. You may use the Software to conduct internal performance testing and benchmarking studies. You may only publish or otherwise distribute the results of such studies to third parties as follows: (a) if with respect to VMware’s Workstation or Fusion products, only if You provide a copy of Your study to benchmark@vmware.com prior to distribution; (b) if with respect to any other Software, only if VMware has reviewed and approved of the methodology, assumptions and other parameters of the study (please contact VMware at benchmark@vmware.com to request such review and approval) prior to such publication and distribution. My questions are: What happens, if you refuse to take your unapproved benchmark down? Can they sue you? How much leg does a clause like this stand on the courts? In the United States? In the rest of the world?
IANAL, but a EULA is a Contract of Adhesion https://www.law.cornell.edu/wex/adhesion_contract_contract_of_adhesion and restrictions against publishing benchmarking data about products is fairly common https://www.eff.org/wp/dangerous-terms-users-guide-eulas A contract is a contract, even a click-through, and is legally binding; there is plenty supporting case law. You sign when you click: http://smallbusiness.findlaw.com/business-operations/contracts-and-electronic-signatures.html Basically, VMware has lots more money than you do. If they are annoyed at your posting of benchmarks that don't make their products look as good as they feel they should, they can at very least send a DMCA to the site that posts the benchmarks. Whether that works could depend on where the website is hosted. At most, they could take you to civil court, if you are in their jurisdiction. What happens, if you refuse to take your unapproved benchmark down? Can they sue you? Yes. (In civil, not criminal court). How much leg does a clause like this stand on the courts? In the United States? A contract is a contract. And VMware and you (I assume) are in the US, so the contract is enforceable. In the rest of the world? Outside of the US, enforceability is variable; that is searchable in law databases for each country and agreements between countries. Consider your motives for posting benchmarks against VMware's EULA. Do you have good points to make? Or are you simply complaining about the product? Who has more money to spend defending or fighting the EULA? You or them? If you're seriously concerned about this, talk to a lawyer and don't take legal advice from the general public.
If you aren't including those libraries, then yes because it's entirely your own work. If you are publishing those libraries, then no because their licenses will limit how you can do that. GPL's and MIT's main features are restricting how you can distribute software that includes the licensed code, and they don't allow the &quot;do whatever you want&quot; of public domain.
could this mean my employer owns the idea and anything I develop --since I would use the same technology for my idea that I do at work? No, unless by &quot;technology&quot; you mean the employer's materials or resources (see condition 3 of the clause). Your remark that &quot;this is completely and utterly unrelated to [employer's] business model&quot; survives items 1 and 2. Likewise, working on your idea outside hours survives the corresponding part of item 3. Would this also mean that any open-source software I develop outside of work automatically belongs to my employer? No, unless the software you develop is &quot;based on [your] knowledge [etc.] of (COMPANY)&quot;.
Germany may be different, however in the United States this would be considered work-for-hire and the employer would be the rightful owner of the source code. Regardless of jurisdiction, and from a more practical point of view, you are better off not having a copy of the source code. Using it as reference or example in the future could easily turn into (unintentional) copyright infringement. If, in the future, you write code you would like to be able to freely keep and reuse in any project, make sure the owner/employer licenses it using something like the BSD, MIT, or ISC license.
You seem to assume that copyrights require paperwork such as registration. This is wrong, copyright is automatic. And it prevents the downloader from making the sort of change that you suggest. In fact, it prevents the downloader from using your template at all. The only reason the downloader can use that template is because you've granted him a specific license to ignore some copyright rules, but the default remains. And you did not grant the right to alter the template to free users.
The difference between commercial and non-commercial software use is about as clear as it gets, outlined by the definitions in the license above. One makes money, the other doesn't. There is no gray area. Your intent or expectations for a project may seem to alter the difference between the two and add a gray area in your mind, but they don't. Once you are a commercial user, buy a commercial license and/or upgrade the non-commercial license to commercial. That's the legal angle; and what is illegal and what is unethical are not always the same. If you still feel like your intent does make a difference and you feel unethical about using a non-commercial license - because you are building a community and hoping/planning on making money - buy the commercial license to begin with.
If you can accurately describe in one license what constitutes the conditions where you wish to let users freely copy the software, and forbid any other uses, then you can also offer a second license that allows specified commercial uses with a second license. Basically, it reduces to being clear (to yourself and to the world) on what you mean by &quot;service&quot;, and what you want to allow vs. prohibit. That SSPL has a section on &quot;Offering the program as a service&quot;, though it does not prohibit it, it just requires the user to make the source code available for free. You could rewrite that section, and then hire a lawyer to give an opinion as to whether your re-write does what you think it does. Pay attention to the fact that you are interested in restrictions on &quot;cloud servers&quot; but the SSPL permissions are broader.
South Park did the EULA gag, and such an agreement would be unenforceable as unconscionable. NDAs, on the other hand, are conscionable, but a EULA isn't an NDA. There isn't a specific statute that you can point to that either makes such a no-criticism agreement explicitly legal vs. illegal, so the case would have to be based on common law justice-style arguments. People v. Network Associates is a relevant case, where a clause requires permission to publish benchmarks or reviews of the software. The court found against the publisher. However, the restrictive condition was not part of the license agreement, which included a merger clause that declared the license agreement to be the whole agreement. The publisher had some hand-waving about mention of "rules and regulations" which they argued nullified the merger clause, where the court did not accept the argument. So for the moment, you need to decide whether disparaging a product is that important to you; or, become a legal pioneer and win a case in court. There is a bill, the Consumer Review Freedom Act under consideration (passed the Senate) which might change that, if it becomes a law. It pertains to a written, oral, or pictorial review, performance assessment of, or other similar analysis of, including by electronic means, the goods, services, or conduct of a person by an individual who is party to a form contract with respect to which such person is also a party and restricts a contract with standardized terms— (i) used by a person in the course of selling or leasing the person's goods or services; and (ii) imposed on an individual without a meaningful opportunity for such individual to negotiate the standardized terms. which says that that kind of contract with that kind of provision is void.