Worst realistic effect in the U.S. of JSLint license? The JSLint license specifies that code "shall be used for Good, not Evil". It's been a source of (what appears to be) alarmist and ridiculously overblown controversy for a while now. I've noticed this conversation tends to attract a lot of developers who really like open source, know next to nothing about the law, and reach the conclusion that this might have real legal implications. I'll freely admit I'm a developer who knows next to nothing about the law, but it seems obvious that since the license makes no attempt to precisely define either "good" or "evil", and they don't already have legal definitions (as far as I know), or even consistent definitions in common parlance, no sane judge would attempt to enforce that part of the license. Then again, my uninformed opinion is just as uninformed as all the uninformed opinions I'm disagreeing with, so I could be completely off base with my analysis. So what is the worst thing that could (realistically, legally) happen to someone using JSLint because of that specific section of the license?
Short Answer The entire license could be ruled invalid and therefore unenforceable. Explanation Two legal principles at play in jimsug's answer might be: Vagueness Doctrine Overbreadth Doctrine Either or both of which might be sufficient for a judge to waive enforcement of any provisions that relate to the terms "good" or "evil." An interesting side effect of this might be that unless the principle of severability were applied to the JSlint license, then the license could be considered completely invalid due solely to the addition of the words "good" and "evil." A judge would have to affirmatively impose severability because the license itself does not assert it.
Yep, you are. You still need to keep the LICENSE and NOTICE files in the repository, if there were any in your copy of the project. These files contain the terms and conditions for the project, and provide attribution to the original developers. If you're trying to attribute in the UI of your application, you probably should. It's considered courteous and in the spirit of open source as well. This is also related: Do I need to include the full text of the MIT license in the UI of my app?
It's possibe to cover auto-starting apps and cookies under the definition. I'm not convinced and could argue against that but I don't think it matters. The tiny extract you linked isn't a law. It is a definition. It does not say &quot;these things are illegal&quot;. For that, we have to zoom out a little. Section 43 includes the offense in question (emphasis mine): If any person without permission of the owner or any other person who is incharge of a computer, computer system or computer network... introduces or causes to be introduced any computer contaminant or computer virus... So back to the question. Could Steam be considered a virus? Maybe. Is it illegal? No. On the other hand, if I were to gain access to your computer and download Steam, yes that could be an example of breaking that law.
Yes, commercial use is allowed for the AGPLv3 license. You can charge for your use of the software so long as you provide a way for the public to download the source code in its entirety.
Per the comment, the applicable license term seems to be Licensee agrees to maintain in confidence the source code version of the Licensed Software by using at least the same physical and other security measures as Licensee uses for its own confidential technical information and documentation, but in no case less than reasonable measures. So if your own code is on a physically unconnected thumbprint-secured blah blah blah computer deep in a mountain, with files encrypted, so must theirs be. If yours is stored in &quot;the cloud&quot; with decent password protection, theirs must be as well. This seems to describe your Github use (I don't have any knowledge of the degree of hackability of private Github repositories). The legal judgment as to whether this is &quot;reasonably secure&quot; is based on whether a prudent person would know that it is practical to gain unauthorized access. Protecting a file with the password &quot;password&quot; would probably be found to be unreasonably insecure.
Just assuming for the sake of this particular answer that everything happens in the U.S.: I'm not sure about the particular example of Open ZFS. The registration in the USPTO Records is in Oracle's name. Using OpenZFS for distributing the same kind of software as the now closed-source ZFS would seem to be infringing to me absent a license. Maybe Oracle just tolerates the use of the "ZFS" component by third-parties since they decided at some point to license the software under an open source license. In that case, they may have a dilution (http://www.inta.org/TrademarkBasics/FactSheets/Pages/TrademarkDilution.aspx) problem and the mark may be invalid. If the mark is invalid, anybody can pretty much do whatever they want with it. That said, assuming for sake of discussion that the mark is valid, there is indeed such a thing that is similar to the copyright fair use in trademarks (in the U.S. at least). It's called "nominative fair use". You can read more about it here: http://www.inta.org/TrademarkBasics/FactSheets/Pages/FairUse.aspx Bottom line is that under the nominative fair use doctrine it's generally ok for party A to use party B's trademark to refer to whatever party B is doing, even to sell products and services related to whatever party B is doing. As per the INTA document I just linked above, its for example ok to "use “iPhone” in non-stylized form on packaging for phone cases to indicate that it is usable with iPhone 6." Having a website (even with third-party ads) that discuss ZFS-related matters is similar to the iPhone example in my mind. Having a domain name that contains the mark seems riskier, but it's not necessarily downright forbidden. See: http://itlaw.wikia.com/wiki/Toyota_Motor_Sales,_U.S.A._v._Tabari
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.
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.