Are Technological Standards bodies required to be approved by the government? In the interest of cross vendor compatibility, the method by which different technologies interoperate is often standardized. This means that a non binding agreement is made between multiple parties to abide by rules set forth in a documented standard. Examples of this include The USB Device Working Group, Jedec, The C++ Standards Committee, and PCI-SIG. While presumably in the public's interest, these groups appear to be a fragrant violation of antitrust laws. Do they require a special license to operate? If so, what would such a license look like and what agency would issue it?
Standards-setting by industry groups is not inherently anti-competitive and these groups do not require a licence from the government to operate. They are a prototypical example of &quot;private ordering&quot; (see David J. Teece &amp; Edward F. Sherry, &quot;Standards Setting and Antitrust&quot; (2003) 87 Minn. L.R. 1913, p. 1987). What can be anti-competitive is when a corporation advocates for an element to be included in a standard for reasons other than technical considerations. See e.g. the International Standards Organization's &quot;Competition Law Guidelines.&quot; An example violation is the behaviour of Rambus, Inc.: According to the FTC complaint, Rambus nonetheless participated in JEDEC’s DRAM standard-setting activities for more than four years without disclosing to JEDEC or its members that it was actively working to develop, and possessed, a patent and several pending patent applications that involved specific technologies ultimately adopted in the standards. ... In its liability opinion dated July 31, 2006, the Commission found that, “Rambus engaged in exclusionary conduct that significantly contributed to its acquisition of monopoly power in four related markets.” In another example, Dell Computer Corporation was alleged to have voted to approve the VL-bus standard and certified that the standard did not infringe its intellectual property. After the standard became very successful, Dell asserted an earlier-issued patent against several computer manufacturers using the standard. The FTC entered a consent agreement with Dell: prohibiting Dell from enforcing its patent against those who wanted to use the VL-bus standard. The FTC's order also prohibited Dell from enforcing patent rights in the future when it intentionally failed to disclose those rights upon request of a standards-setting organization.
The FCC has clarified their stance on this: ... were we mandating wholesale blocking of Open Source firmware modifications? We were not, but we agree that the guidance we provide to manufacturers must be crystal-clear to avoid confusion. So, today we released a revision to that guidance to clarify that our instructions were narrowly-focused on modifications that would take a device out of compliance. The revised guidance now more accurately reflects our intent in both the U-NII rules as well as our current rulemaking, and we hope it serves as a guidepost for the rules as we move from proposal to adoption. Essentially, Open Source firmware modifications are allowed, the modifications are disallowed are things like excessively increasing signal strength.
I see no reason to doubt your conclusion; since it's not allowed by the license it's forbidden by copyright. As you figured it, you gain the right to use these tools by obtaining one of those 3 Visual Studio licenses. A Visual Studio Code license is free, so it makes business sense that it doesn't include a license for Microsoft C++ Build Tools. I.e. you can't claim it's an "obvious oversight", as there's a justifiable business reason.
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 the details of your implementation are not disclosed by the previous patent, and more generally, if they are novel and non-obvious in light of the entire body of prior art (including the previous patent), then you could obtain a patent whose claims are limited to implementations that include (some of) those details. That said, your patent would not exclude the coverage of the previous patent—it is possible for something to be covered by the claims of multiple patents, even patents with different owners. If your implementation is a method that includes every step of a claim of the previous patent, then performing your implementation would still infringe that patent (regardless of the existence of your own patent or patent application). Analogously, if it is a device that includes all of the elements of a claim of the previous patent, it would infringe. Of course, the other patent may not be valid, and so you could seek to invalidate it if desired (but this can involve lengthy &amp; expensive legal proceedings).
The MIT license is non-exclusive. If S is the sole copyright holder, S can issue any other non-exclusive license in parallel, and can also stop offering the software under the MIT license. However, open source licenses such the MIT license are generally understood to be irrevocable, so S cannot prevent other people from using the software who already received it under the MIT license terms. But: only if S is the sole copyright holder. There is no particular reason to believe that S would be the sole copyright holder. One does not gain a copyright ownership just by supervising other people, although an employer might gain copyright ownership over works created by employees (e.g. the US “work for hire” doctrine). That the copyright notices only mention S's name is an indication that S might be a copyright holder, but that's neither sufficient nor necessary for showing that S holds sole or joint copyright in the software. This leaves three relevant scenarios: S might be the sole copyright holder, in which case, yes, S can effectively discard the MIT license. This might be the case e.g. if there was some other copyright assignment, outside of the MIT license. What copyright transfers or assignments are valid depends on the local laws, e.g. some jurisdiction do not recognize copyright as transferable and at most allow the assignment of economic aspects of copyright. S might not be the sole copyright holder, but have additional permissions to the work. For example, there might have been extra licensing agreements, outside of the MIT license. Or S might have special rights for a work of joint authorship, if and only if the jurisdiction recognizes such additional rights. S might not be the sole copyright holder and not have any agreements outside of the MIT license. Then S has no additional rights, and is bound by the terms of the MIT license. This doesn't have to be a problem: S can still pretty much do whatever S wants with the code, as long as S fulfils the license terms. These are pretty simple: just keep a copy of the copyright+license notice with any copies of the software the students created.
Software cannot be patented although it does have copyright. Hardware can be the subject of a patent, however, that would not cover any software aspects such as the programming built into a PROM. While it is possible to render any software into an integrated circuit, practically, anything simple enough to make this feasible is probably too simple to patent.
Choice 2 is what the writers of the license have in mind. You own the physical media on which the copy is delivered, such as a DVD or floppy disk (if there was physical media). But you do not own the copy of the software, you merely have purchased a license to use it, which may be revocable under specified circumstances. This is different from the law in the case of a book. Why you buy a book, you own a copy of the book, although you do not own the copyright to the book, and may not make additional copies. The license model was adopted by commercial software distributors for several reasons, but largely to avoid the "first sale doctrine". When you buy a copy of a copyrighted work, you have the right (under US law at least) to lend, rent, sell, or give-away that copy. You do not need the permission of the copyright holder to do any of these. Those in the commercial software business did not want customers to be able to do those things legally. By making the software subject to a license, which is a contract, they could write that license to restrict or prohibit those rights. Sellers also wanted to prohibit reverse engineering of the software, and to restrict use of the software. (For example, to limit the user to installing it on a single computer.) There was at first much dispute over the enforcability of such license agreements. But most US courts now accept them as valid and enforceable, and copyright law has been modified to take account of them. Specifically, 17 USC 109 (2)(b)(1)(A) seems to include a legislative acceptance of this rule.