What is the legality of implementing an unrevealed killswitch in software? In this hypothetical, the poster describes the following: during employment with his/her employer, the poster invents and patents a method (in his/her free time) that it turns out, is useful for his/her employer he/she presents the invention to his employer, and after receiving a $10000 bonus he/she implemented it for the company there was no signed agreement giving permission for the company to use the application and source code the invention, patent, and implementation included a kill-switch that would cause the program to self-delete along with all of its output if the program's author did not check in every month the employer is unaware that there is a kill-switch in the software the author was laid off, and now expects the kill-switch to engage, causing financial loss to the employer In the hypothetical, the software author claims: the employer "has no legal ownership claim to the application or code or their use" the employer assumes all liability for damages since it did no third party testing Are these two claims true? Is this hypothetical, is the program author free from liability?
If your friend was a salaried W2 full time exempt employee hired by the company to, among other things, write software like this, then the fact that it was developed "off the clock" with the employee's own resources means nothing once he gives it to the company. I mean if I give you a present and it blows up and breaks your arm, I'm still liable even if we didn't have a "contract" - especially if I knew it would blow up. Your friend's position is even worse since the relationship entails the employee's having the employer's best interests in mind. If I were your friend, I'd either figure out how to fix this or take gnasher729's advice from the comments and find a country where it's easy to hide from parties public and private. Maybe buy a bunch of canned food and go live on a boat?
Invasion of privacy and false light torts would probably not be applicable here. Very few states have adopted the false light tort because of its conflict with First Amendment principles and there was no agreement or even request to keep the text private. The copyright issue is trickier. First all, the TOS may provide that the copyright belongs to the text service provider or that there is a license. But, even in the absence of an express license, sending someone a message which is equivalent to sending them a letter, probably gives rise to an implied license that the person to whom it is sent can use the message that arises merely from the act of sending it without restriction or qualification. Implied license and fair use also heavily overlap. Publishing the text exactly as it was sent to you protects you from defamation liability because it is true. On the whole it would be extremely unlikely for there to be any legal liability for publishing a text from someone that they sent to you. Of course, one can imagine exceptions. If the person receiving the text was in an attorney-client relationship, or priest-parishioner making confession relationship, or was communicating regarding classified national security matters, or there was a non-disclosure agreement in place, among other possibilities, an evidentiary privilege and duty of confidentiality could apply and disclosing the material without the permission of the privilege holder could breach a duty of confidentiality and give rise to liability. If the picture was a nude picture of a minor, there could be a criminal and/or civil liability issue, and some states have also made posting "revenge porn" a criminal offense and/or a basis for civil liability. If the disclosure was effectively a way to facilitate insider trading that could be a problem. If the contents of the text were accurately transmitted but known to be false and were disseminated without disclosure of its falsity for the purpose of defrauding a third party, that could be a problem. But, no facts that obviously flag any exception are identified in the question. The mere fact that the posting may be embarrassing, or hurt someone's reputation, or was made without someone's express consent, in general, would not be a basis for liability.
IANAL, just a programmer with an interest in legal rules. Due to the very permissive nature of the MIT license, no, it does not appear that anything illegal has been done. Specifically, the section to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software (emphasis mine) grants everyone the right to modify your code and share those modifications, provided one includes the license. Since this person has included your license (including your copyright notice), they have followed the conditions of the license and are able to share your stuff. Legally. Ethically, I still think its ****. This might be a good starting point in selecting a license (note the Modification column). https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses The CC-BY-SA license family, as mentioned by Ron Beyer in comments is on this list, for example. TL;DR: You unfortunately granted a more permissive license than what you wanted/needed to. This was a BadThing(TM), analogous to giving too broad of access rights to a method or class. Determine your desired permissions, then select a license that matches what you'd like to grant.
Unless the game is out of copyright, e.g. chess, snakes and ladders, Go, or checkers, your software would probably be considered a derivative work of the copyrighted game and an actionable infringement. The fact that you do not monetize it is not a defense. You would need written permission in the form of a license agreement from the copyright owner to do this legally. The penalties for violating copyright laws in this way could be punishingly serious.
The companies really need to speak to an IP lawyer as this question is seeking specific advice which this site is loathe to give out for fear of compouding issues. The answer would depend on the license agreements and enforceability in various jurisdictions. According to https://social.msdn.microsoft.com/Forums/vstudio/en-US/0368d7ee-0eb3-4e3e-a143-4410969a15bb/eula-for-vs2010?forum=vssetup Microsoft says you cant rent out the software - but this applies to the "Pro" version - I could not find anything on the "Premium" version - so most likely Microsoft to have some clam. The flipside is how enforceable this EULA is - and this would probably vary from jurisdiction to jurisdiction. It would be a very, very good idea to speak to a lawyer before letting Microsoft come onto the premises - as "inviting them" to do this is almost certainly not going to improve the Asians company's case and will allow Microsoft to go fishing further and make it easier for them to expand on and collect evidence should they decide to pursue the matter.
With respect to the first question, discussing an idea in a non-encrypted email is not a publication that forfeits the right to patent an idea, even though it is not 100% secure. In the same way, talking about an idea for a patent with your patent lawyer in a secluded booth of a coffee shop in person does not constitute publication of the idea for this purpose, even if someone is secretly spying on you at the time. Since I am at the moment employed by a company, even though the idea originates from myself, it seems that I should quit my job first not to have my current company have any claim over my idea. It is possible that the contract makes even ideas that you come up with yourself while employed by the company the property of the company. If so, you are legally in the wrong and the idea belongs to the company. But, proving the reality that you are stealing the idea from the company is harder if there is nothing in writing. An email discussing an idea while you are employed would have to be disclosed in litigation with your employer over whether the patent applied for belongs to you or to your employer under an employment agreement. If you didn't put it in an email, it wouldn't exist to turn over in litigation.
On the one hand, there are statutes that prohibit the delivery of instructions which distort or circumvent the official/intended use or safety of a device. For a somewhat related example of this, see MCL 750.540c(1)(3). On the other hand, the company/manufacturer is unlikely to prevail under contract law no matter how clearly and conspicuously its EULA prohibits the disclosure of discovered weaknesses. That is because the prohibition in the EULA is outweighed by the severe vulnerability to which all other unsuspecting customers are subjected. From the standpoint of public policy, people's awareness of the discovered vulnerability is certainly in the public's best interest. The disclosure will warn both (1) potential customers not to purchase a product that fails or misses its primary purpose, and (2) current customers to adopt precautions now that the product's reliability has been disproved. Thus, the effectiveness of broadcasting the discovery of such weakness is in stark contrast with the technical deficits and managerial politics that typically hinder a company's ability (or its will) to respond to the issue. If the weakness was known to the manufacturer prior to the disclosure, the release of that product would constitute fraudulent misrepresentation. The details of the demonstration in the video supports the argument that the manufacturer knew --or should have known-- about that weakness, since a padlock design is supposed to pass all kinds of tests of breakability and not be disabled by a screwdriver. It is hard to deny that the notion that "the padlock is secure" induces customers to purchase the product. As such, the misrepresentation violates the contract law principle that a contract --such as a purchase-- be entered knowingly. See Restatement (Second) of Contracts at § 161-167. With respect to the publisher of the weakness, that misrepresentation renders the EULA-prohibition void. See Restatement at § 164(1). Regardless of whether or not the manufacturer incurred misrepresentation, the manufacturer's decision to sue the publisher is only likely to backfire by bringing more attention to the poor design of the product. In all, the manufacturer's best option is to do a product recall ASAP and enhance the design.
It does mean that you cannot reuse any parts of the source code, even small simple ones. You would have to rebuild the code from scratch. There is a significant chance that the code would be "substantially similar" to the code that you were hired to build, also that if anybody else were to write a bubble sort or 24-to-am/pm conversion routine, it would look the same, where even variable names (which should describe function) are the same or very similar. In case of an infringement lawsuit, you would have to defend yourself by showing that there are only a few ways to code a given function. Copyright protects only the "expression", not the abstract idea. A linked list is an idea, which can't be protected by copyright; same with recursion, pointers, stacks, object-oriented programming... Anything that involves copy and paste is infringement. If you re-read the copyrighted code and then try to reconstruct it, you probably crossed the infringement line. If you remember the problems and solutions and accidentally write somewhat similar code, that is probably on the safe side. From the perspective of the programmer not wanting to always reinvent the wheel, it would be most useful to make a distinction in the contract between "the essentials of the customer's program" versus "incidental utility work". The difficulty will arise in saying specifically what is essential vs. incidental. For instance, I know that if I were to hire you to develop a speech-recognition system, low-level audio-acquisition and encoding would not be essential to my purpose, whereas DSP parsing routines would be the center of my interest. The programmer would then want to retain recycling rights to all non-essential code.