Open Source Software and Legal Responsibility for Software Content I'm working with a few folks on updating some serious software for mechanism design. Engineered mechanisms have existed in the world now for a few hundred years or so. The science here isn't really new. We're debating bringing out some software for mechanism design and synthesis. We are using really smart algorithms based on physics in the natural world. No magic, just brilliant use working with the existing laws of nature. One of our concerns is the potential for lawsuits by users of the software. We're not sure if we should share our algorithms openly or if we should seek to profit from them. For example: Joe Cheap Carnival company invents a new wild ride using our awesome cool mechanism synthesis software. They have Podunk Assembly Company manufacture it with cheapest materials possible with really poor quality control. The ride goes up at a local carnival and oops it fails, and someone gets seriously hurt. Here are my questions: If our software was used by Joe Cheap Carnival's design team to synthesize a mechanism used in the faulty carnival ride, and our software encompassed the use hidden and encoded algorithms, could we be held liable for the failure? If our software was absolutely open source (github), with all algorithms and logic flow in full public view, could we be sued? (Does this change the nature of "responsibility"? ) My questions relates to: Can the open source process be used as a legal protection against a potential lawsuit for a software company? Update (post DaleM response): I'm not sure I fully understand the "duty of care" description. We make software that tells engineers how machines move. Its a similar function to what you might read in an academic text, albeit in a much easier intuitive form to use. (Drag and drop is much easier than reading a chapter of text then doing mathematical problems, even though exactly the same concepts are being used.) The function of our code is to accurately represent the laws of physics. We don't tell somebody what to design, we tell them if you want this particular output, here are a variety of ways to achieve that output. Hmmm... Lets say someone wants to design a six bar mechanism to move an object in a 720 degree circle and deliver it as fast as possible we can help with that. Fancy Machine works uses that model to deliver bolts to an assembly line for rapid manufacturing. Max g forces observed on the bolt is 8 G's. Joe's Cheap Carnival decides to use that exact same mechanism to create an exciting ride for its customers. Its ten times the scale of the bolt delivery machine, but its the same basic mechanism design. Again, Max g forces observed on the customer sitting in the ride is 8 G's. Is our design unsafe? The bolts seem to get there just fine, people, no so much. We profess no responsibility (same as an academic text book author on mechanism design.) In fact that might be a better question. Have any academic folks been sued for academic publications providing "how-to" instructions? If Joes Cheap Carnival team designs a unsafe ride with a mechanism design textbook as a reference, can the university who published that textbook be held liable? Apologies if I'm not using the correct language in the legal arena. And many thanks to you for your responses.
Sources of Liability Liability can come from: Statute law Contract law Common law Statute Law There may be (almost certainly are) laws in the jurisdiction where Joes Cheap Carnival are operating relating to Work Health and Safety. In general, these laws will impose a non-delegable duty (i.e. one you cant get out of) to comply with certain minimum standards. If operating your software as instructed with reasonable assumptions gives results that lead to an unsafe design then you would be liable in both cases. Contract Law If you are selling this software then you can limit your liability in any way you like providing that the limitation is not unlawful. For example, under Australian Consumer Law (which covers B2B transactions up to AUD$40,000 - how much are you selling for?) you have a non-excludable warranty that the software is fit-for-purpose; so, again, if operating your software as instructed with reasonable assumptions gives results that lead to an unsafe design then you would be liable in both cases. Common Law Only parties to a contract can take action under a contract; anyone you owe a duty of care to can sue your for negligence. A person injured by a machine your software helped design need to demonstrate: You had a duty of care; it would be hard to argue you didn't, You breached that duty; the software was not "fit-for-purpose", There was a factual cause in a "cause and effect" sense; 'but for' your software there would have been no loss, There was a legal (proximate) cause; you may be able to raise something here, if your software was used incorrectly by an engineer, your breach may be too distant Harm; the person must suffer real loss. The only plausible advantage of making your software open source is that you are showing a greater amount of care by allowing your algorithms to be sort-of peer reviewed. This is not a legal shield I would really like to depend on. TL;DR Nothing can stop someone suing you - if they want to sue you they can sue you. Your best defence to a lawsuit is to demonstrate that you did everything a reasonable person could do without the benefit of hindsight Do you really think publishing your code is "everything a reasonable person could do"? You would be far better off: Taking out professional indemnity insurance Validating you algorithms thoroughly Engaging an independent third-party to validate your algorithms Developing proper and thorough testing procedure for your software Testing it in-house Engaging an independent third-party to test it Thoroughly documenting your software including all the assumptions along with the domains where they are valid and invalid.
I finally found the actual transcript of the voir dire part of the case mentioned in the question. http://www.groklaw.net/articlebasic.php?story=2012090614295190 As can be evidenced from the transcript, the judge has specifically instructed the two jurors working as engineers at the local tech companies that they'd have to &quot;forget&quot; what they know about both the software engineering and the patent law itself, too, starting their work on the whole case with a completely clean sheet, using a very simple criteria for making decisions: One side or the other is going to have the burden of proof on -- one side has the burden of proof on some issues, the other side has the burden of proof on other issues. When you go into the jury room to deliberate after you've tried your hardest to understand the evidence, if they haven't educated you on it or if they haven't persuaded you, the party with the burden of proof loses. It's that simple. You don't have to -- you have to make a good faith effort to understand it, but if the party with the burden of proof has failed to do that, the party with the burden of proof loses. That's the standard. You have to -- you, the jury, decide. Now, what you cannot do is bring to bear something that you've learned in some other case, some other patent case, about how some piece of equipment works or something like that. You can't do that. It has to be based on the record here. Then, after a short break and a consultation with the lawyers, where Oracle seems to have expressed some concern to having the computer experts be on the panel, which subsequently prompted the judge to declare the following to the two potential jurors who worked at Cisco and HP: So this is really going to be directed at both of you, but, you know, you come to the party, so to speak, with some prior training that bears upon the subject matter we're going to be hearing a lot about here. That's okay. That's not disqualifying, but you -- it's okay to use your common sense when you render a verdict, but you cannot add to the record in court something that you know about the way software programming works that the witnesses didn't actually testify to. You see what I'm saying? You've got to decide the record -- the case based on the record made here as opposed to adding into it what else you may have known about the way programming and software works. Since both jurors had so much software and patent experience that they couldn't disregard it easily, they were thus both excused (page 95 of 224). All right. I think it would be too hard for you to sit in this case and sort out what you knew already against what is proven or not proven here, and itwould not be fair to the parties to have that extra burden even though you two actually know something about the subject. It's in a way too bad, but it's for the best. So you two are excused to go back to the jury assembly room. Thank you. The other instructions that the judge gives to the potential jurors is also worth reading (starts on page 36 of 224) The full transcript is at http://www.groklaw.net/pdf3/OraGoogle-942.pdf. In summary -- jurors are only allowed to talk to one another when the deliberation process starts, and, no, they are not allowed to bring any &quot;baggage&quot; to the case at stake.
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.
I'm posting an answer hoping it is not the final answer, but rather in the hopes that it inspires a better answer itself. The open source or "public domain" exception cited in my question has some constraints placed on it. For example, software that falls under 1-1.E.2.e, 1-1.E.2.f, 1-8.E.2.a and 1-8.E.2.b are not covered by the exception. So, here is a summary of every one of those sections, and the sections that those sections reference: Section 1-1.E.2.e - "Technology" for the installation, maintenance or repair of materials specified by 1-1.C.1. Section 1-1.C.1 covers Materials specially designed for use as absorbers of electromagnetic waves, or intrinsically conductive polymers, as follows: ... Not included because my software has absolutely nothing to do with materials of any kind. Entire section is about qualifying a type of material this rule applies to. 1-1.E.2.f - "Technology" for the repair of "composite" structures, laminates or materials specified by 1-1.A.2., 1-1.C.7.c. or 1-1.C.7.d. Section 1-1.A.2 covers "Composite" structures or laminates, having any of the following: ... Not included because my software has absolutely nothing to do with materials of any kind. Entire section is about qualifying a type of material this rule applies to. Section 1-1.C.7.c covers Ceramic-ceramic "composite" materials with a glass or oxide-"matrix" and reinforced with fibres having all of the following: ... Not included because my software has absolutely nothing to do with materials of any kind. Entire section is about qualifying a type of material this rule applies to. Section 1-1.C.7.d covers Ceramic-ceramic "composite" materials, with or without a continuous metallic phase, incorporating particles, whiskers or fibres, where carbides or nitrides of silicon, zirconium or boron form the "matrix"; Section 1-8.E.2 Other "technology" defined as follows: a. "Technology" for the "development", "production", repair, overhaul or refurbishing (re-machining) of propellers specially designed for underwater noise reduction; b. "Technology" for the overhaul or refurbishing of equipment specified by 1-8.A.1., 1-8.A.2.b., 1-8.A.2.j., 1-8.A.2.o. or 1-8.A.2.p. I've omitted copying quite a bit of text, but I kept the title/summary portions to illustrate that all of the exceptions to the open source or "public domain" exception have something to do with software related to restricted physical materials. There are some other exceptions to the general exception, notably the "Information Security" constraint, but note that the "Information Security" constraint applies specifically to Entries 1 and 3, and the open source or "public domain" exception is defined in entry 2. Just for fun, the definition of "Information Security": "Information security" - Cat 5P2 All the means and functions ensuring the accessibility, confidentiality or integrity of information or communications, excluding the means and functions intended to safeguard against malfunctions. This includes "cryptography", "cryptographic activation", cryptanalysis, protection against compromising emanations and computer security. Technical Note: 'Cryptanalysis': the analysis of a cryptographic system or its inputs and outputs to derive confidential variables or sensitive data, including clear text. (ISO 7498-2-1988 (E), paragraph 3.3.18). After reviewing each of the constraints placed on the various exceptions, I believe the spirit of the law here is to control: Closed source "Information Security" software that defines or uses cryptography, regardless of whether the linked crypto software is open source or not. Closed source or open source software that is even remotely related to the study or production of physical materials that you require an export permit for. Basically, if the program even mentions a material that you'd need an export permit for, you probably need an export permit for the software, regardless of whether it's open source or not. Again this is not meant to be a final answer. I'm simply posting more information about the question and my thoughts on it, hoping to assist in creating a better answer than this. Plus, a whole lot of rep is going to go down the toilet without another answer. :)
Generally, this question is not a singular inquiry as its wording may suggest on its face. What typically tends to come up as the subject of dispute is rooted in the urban legend that one cannot obtain a patent (utility) on software. This is substantially incorrect, and any patent attorney asserting to the veracity of this makes a substantially false conclusory statement of law knowingly and willfully controverting the actual state of law in, at least, all Western jurisdictions as it omits to assert to the fact that one is not barred to obtain a patent on any system that comprises of non-obvious software, and hardware to run on is entitled to a patent — except in the U.S. where one must also comply with the Alice decision requiring that at least one hardware component in addition to the hardware of a generic computer be necessary for the utility of the system. However, in the U.S., one may obtain a software-centered patent through a (i) method or (ii) a computer program product in addition to (iii) systems or apparatuses which are available avenues for patents everywhere else. When disputes around IP and software come up, this is typically at the crux of the debate: May one obtain a software patent? The answer is: One is not barred merely because the non-obvious aspect of an invention is software. For example, if one uses hardware that are prior art, in fact, patented to someone else, but by the use of software a system, method and/or computer program product achieves a different objective (since utility patents, axiomatically, must have a utility objective) one may obtain a patent, and a layman may very well consider their invention of the system as that particular component that appears to them as having required any inventive steps, encompasses the inventive novelty (understandably) which, in many cases may be software. So the advice from a patent attorney that “you can’t patent software” is simply malicious (or wide and far disbarringly incompetent). One may patent software so long as it is an invention, and the administrative (or at times judicial) process requirements are complied with. Nevertheless, since the question inquired about “IP”, below is the answer to other avenues of intellectual property. Copyrights The software code written to make this operable could be the subject of copyright as long as it is not substantially identical with another solution (or such to give reasons to believe it to be a derivative thereof) that also put buttons in the four corners. The visual design may possibly also enjoy copyright protection, but that is less plausible to imagine since not only the copyrighted work of art is protected, but anything that may objectively be deemed a derivative work (regardless of whether the “re-author” actually knew about the copyrighted material that it may be deemed the derivate of). Design patents It is possible that one could get design patents for the actual graphical design of the layout provided there isn’t something substantially similar already out there protected by a design patent. Utility patents This would most certainly not overcome obviousness, that is, the requirement for one to obtain a patent which needs that a presented invention not be obvious for anyone “with ordinary skill in the art” (an ordinarily knowledgable person in the field of the specific area of tech). Trademark I have a hard time stretching my imagination to see how this could be applicable.
The legal issues are too black and white to have any meaningful impact on an ethics discussion. The IP belongs to A and B can't use it. A's not planning to build a product around the patent is irrelevant to the law and I do not see it bring up any ethical issue, but some people who do not understand patent law might. There might be ethics issues if A hired Josh with the specific plan to fire him as soon as the application was filed and intentionally misled him about these plans. Another issue might be Josh's duty to not disclose A's confidential information (the application does not become public right away), and Josh's duty to not draw B into developing an infringing product.
If you have released software under the LGPL license, you have given all recipients the right to modify this software for any purpose, including removing or adding features in a manner that you don't like. If you don't want that, you should not release your commercial features under the LGPL. Things you could consider doing: Publish the software under a different license. This is what you're thinking about. But note that you can't just add such license terms. Either, the license is still the LGPL with some extra terms. But then, the terms of the LGPLv3 allow recipients to remove the additional restrictions. Or, this is an entirely separate license. But then it would no longer be the LGPL, and no longer be an Open Source license. Whether such additional terms create a separate license or can be removed from the license is currently being litigated in the US in the context of the Neo4J database, which added the &quot;Commons Clause&quot; restrictions to the AGPLv3. See a discussion of the case from the Software Freedom Conservancy here: https://sfconservancy.org/blog/2022/mar/30/neo4j-v-purethink-open-source-affero-gpl/ Remove the restricted features from the LGPL version and maintain a separate commercial version, or implement the commercial features as a plugin. This is sometimes known as an “open core” business model. Due to the limited copyleft effect of the LGPL, you can still combine the proprietary parts and the LGPL-covered parts into a single program, but doing so may be confusing for users. It should be absolutely clear which parts are LGPL-covered, and which are your proprietary parts that cannot be modified. However, you would not be able to prevent recipients from using the LGPL-covered parts without your proprietary components, i.e. they would always be able to remove any licensing checks etc. More generally, it could make sense to think about why you want to publish any part of the software as Open Source. Sometimes, Open Source licensing is a good business decision, sometimes it isn't. If you want to control what users can do with the software, Open Source licensing is not a good fit for your goals.
The second paragraph is an invitation for people who don't want to follow the terms of the GPL (e.g. who want to incorporate it into a larger closed-source work, or make closed-source modifications) to contact XXX for a less onerous (but more expensive) license. That would require that XXX have full rights to the software, that they did not for instance incorporate others' GPLed code. It would be a stretch to read the second paragraph as attempting to limit the first paragraph, particularly given the &quot;please&quot;.