Are open-source developers protected to a greater extent from liability in the event of security breach involving their software? I'm studying for the Certified Cloud Security Professional (CCSP) exam and am confused by some statements that were made regarding cloud application security. Specifically a statement on proprietary software vs open source: Perhaps one of the main points in favor of proprietary options is the possibility that liability will map back to the vendor -- that breaches or other impact due to failures in the program can be blamed on the vendor, who may be help accountable (although it's difficult to think of examples where this has occurred). I don't understand -- if I'm using opensource software to protect some asset in my organization, how does that completely absolve the developer? Are open source use licenses that good? Or is this predicated on the assumption that I'm not paying anything for open source software? Or perhaps it's based on the assumption that as a customer who had the opportunity to review the source code for security issues, I did? Don't get me wrong, I'm not implying that everyone should have the means to sue open source developers (certainly not!!) but I want to understand why the cloud application security material in this course seems to have a blanket statement essentially saying "if you're using open-source security software, you can't hold the developer liable."
There is no contract between you (the licensee) and the licensor of the software. The creator of the open source software just says "here's the software, you may use it if you like, as long as you fulfil some conditions. ". No contract, no liability. I think the developer would only be liable if they intentionally created software that causes damage. (Which has happened, some open source browser plugins have recently been modified to run bitcoin mining software, or worse. I suppose the miscreants could follow all the GPL rules or whatever license is used).
If the lawyer has legitimate concerns, his first port of call would be the ICO https://ico.org.uk/. Before the ICO will take his complaint further he'll have had write to you expressing his concerns and received a written response that presumably he is unhappy with, and wants to take the issue further. Most companies have a data compliance team who will have policies and procedures to log breaches like this and decide what course of action to take in response. Not every breach needs to be brought to the attention of the ICO, and they have a handy self assessment tool to see if you should report the breach. https://ico.org.uk/for-organisations/report-a-breach/ In your situation, I don't think this constitutes a serious breach which will require investigating. It's simply an admin error. If it is unlikely to pose a risk to any of the individuals they will say something like: You should keep an internal record of the breach as detailed in Article 33 (5) of the GDPR, including what happened, the effects of the breach and remedial actions taken. The definition of risk according to the ICO is: "This risk exists when the breach may lead to physical, material or non-material damage for the individuals whose data have been breached". So in this case I'd assume a simple apology (Bcc'd :) ) and a record of what happened, how it happened, and the action taken to prevent it happening again should suffice.
If it's patented then it doesn't matter that you independently came up with it. Most software is not patented, though. Most developers do not even think about patents when writing code. In theory you could spend your time keeping up to date on software patents so that you avoid infringing. But this probably only makes sense for specialists who would want to read the latest patents in their field anyway. All software is protected by literary copyright, though. In this case they will try to prove that you did not independently created it, and did copy it. Whelan v. Jaslow in 1986 ruled that structure, sequence and organization of a computer program were protected by copyright. So you could be liable even if you did not just copy and paste sections of code. But even if you're worried the court would get things wrong and think you copied a program when you never even saw it in the first place, there is really nothing you can do about it.
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.
You can write anything you want (basic First Amendment protections): the question is whether one would be liable for damage that arises from what you're written, or whether you can distribute what you've written. Distribution may be restricted, thanks to the Commerce Clause (hence FDA regulations, which figure prominently in the analysis). Most software writers are not medical practitioners, and vice versa, and what the software writer does is implement something described by a competent medical practitioner. It is logically possible that a med. practitioner might also try to write software (no problem) and distribute it (possibly a problem); or, a software writer might read up on something on Wikipedia and try to implement it (again, no problem) or distribute it (possible problem). Damages can be sorted into two categories, implementation errors and scientific errors, and having ruled out deliberate sabotage, we are left with negligence. If the software writer failed to use suitable care in writing code that sums a set of numbers, the software writer has been negligent. If the person purporting to have the qualified scientific knowledge mis-states the formula, that person has been negligent. It is possible for many parties to be negligent (the programmer failed to be diligent in understanding the software requirements; the medical professional failed to adequately explain what was required of the program). The FDA does regulate medical devices, and "device" is construed pretty broadly (condoms are non-exempt class 2 medical devices). There is FDA guidance on medical software which makes it clear that the device manufacturer shoulders the regulatory burden. Anytime you manufacture a tangible thing (which is within the scope of FDA regulation for medical devices), you have to have the thing approved. Many (most?) medical devices implement software, and are thus within the scope of FDA scrutiny. It is not illegal to write software that ends up being implemented in an unapproved medical device, but the unapproved medical device itself is illegal. It is reasonably likely that purported medical software (not a gadget with software build in) would be held to be a non-exempt device. To know if something is exempt, you would look at the exemptions list, and determine that your program (or thing) is not on or implied by anything on that list. The visual acuity eye chart is a class 1 exempt item, as is the manual toothbrush. There is no way to specifically look for things that are only software, or that contain software, so the search through the list would have to be guided by knowledge of the subject area. Canada is helpful in explaining when software is a regulated medical device. This is non-probative w.r.t. US law but gives you an idea what is likely to be considered a "device". Under Canadian law, the software would be clearly a regulated medical device. The FDA has a power-point that attempts to say something about the matter which warns you that you are on your own and "You will need to go back to study and use the source regulatory documents" to make the determination. Eventually, slide 13, they hint that if you intend the software to be used in diagnosis, prevention, or treatment, then it is a device (so, yes, the aforementioned software would be a device, and probably not exempt from regulations). General purpose software (word processors, web browsers, communications software, etc.) are not indented to be used for a regulated purpose, although they can be so used, and thus they are probably not subject to FDA regulation. There is a murky relationship between regulatory approval and liability. Being approved by the government does not convey immunity to negligence suits (see Wyeth v. Levine), but being approved can have weight in determining whether a party was negligent, since regulatory scrutiny ostensibly filters out errors that could have been caught. Federal approval does not preempt state tort law, as the court ruled. Regulations pertaining to medical devices hold for anything that qualifies as a device, and is not defined (negatively) in terms of disclaimers. If you sell a medical device but label it saying "this is not a medical device, it is not created by a competent medical practitioner", that doesn't make it not a medical device. Unfortunately, what counts as a regulated device is based on intended use, and there is an obvious connection between disclaimers and intentions. Taking MS Word as an example, MS does not as far as I know say that "Word is not intended to be used as a medical device". It can certainly be used to diagnose, teat, and prevent medical conditions, but so too can a screw driver or pretty much anything else. The number of non-medical uses vastly outweigh the medical uses, so it would be deemed not to be a regulated device. A program which prescribed a set of prayers to be uttered in case of illness would be subject to First Amendment override of any FDA regulations. Quack medical devices are prohibited (that's why there is regulation of devices in the first place), but discerning the fine line between permitted actions based on nutty beliefs and forbidden actions is not easy. The FDA also has guidance on the distinction between "Complementary and Alternative Medicine", which does not clearly state that, for example, a software reading of your cakra-energies based on a computer program's questions is not a medical device. They do say of mind-body medicine (mentioning yoga, biofeedback and tai chi as examples) that "CAM practices in this domain would not be subject to our jurisdiction under the Act or the PHS Act", but then say "any equipment or other products used as part of the practice of mind-body medicine may be subject to FDA regulation, depending on the nature of the product and its intended use" (hence a yoga-enabling program may be subject to regulation).
The GPL does not forbid you from charging money for software, nor does it require you to provide source code to the general public. What the GPL requires is that your software be free software, with "free" used in the sense of "free speech" rather than the sense of "free beer." According to the Free Software Foundation (authors of the GPL), the right of users to sell software is a requirement for it to be free software. If you receive a GPL license for software, you can give it to whoever you want provided you also ensure that person can get the source code. You don't need to make the source code available to the public, only to the people you actually distribute the binaries to. The GPL is structured along the lines of "if you distribute the software to someone, you must give them these rights;" it is not structured along the lines of "you must distribute the software." Of course, if users have the right to distribute copies for free, it's hard in practice to charge money (all it takes is one user distributing copies). But that doesn't mean you can't try. Some companies make substantial money selling free software through various models (e.g. Red Hat, which charges money for support). Others might bank on the fact that plenty of people are willing to pay to get it from the official site, and aren't interested in finding a free copy somewhere. It doesn't matter; as long as they license the software to you under the GPL and give purchasers access to the source code on the same terms, they're in the clear (if you want to redistribute binaries, it's your job to redistribute the source code as well).
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?
&quot;Wholly unconnected with your employment&quot; means exactly that. Anything that is not connected to your functions or processes that you use in the course of your employment that your employer would have an interest in either protecting or marketing. Writing a book about software development If you are just a software developer, this would be fine unless you were talking about a process unique to your employer. If you worked in a publishing house that wrote software development books, this would be connected and must be disclosed to your employer. Releasing an open source piece of software not specifically aimed at the industry the company is in Again, this probably fine not to disclose since it would not be something you would develop as part of your employment, or under the umbrella of your company focus market. Release a commercial piece of software not specifically aimed at or competing with the industry the company is in Same as above. Honestly though the best policy is being open. If you come to your company with your idea and tell them that it doesn't have any applications in your industry and would like to develop it in your own time, they would have a much harder leg to stand on in a court case when they finally figured out how to apply it.