Embedded designs continue to grow in complexity, and yet, embedded designs are becoming a mainstay in nearly every design – even systems that demand the highest quality, such as medical, automotive, and industrial equipment. Tim Cummins comments on the trend “by buyers to simply allocate the risks of failure to their suppliers through broad-brush application of ‘burdensome’ terms, such as onerous liability and indemnity provisions.” By definition, embedded designs are not the end device, so they are used by someone else in their final device – thus embedded developers always find themselves in the position of supplier to some end device manufacturer.
I find the request for onerous liability and indemnity provisions are not limited to embedded designs where there is the potential for significant unknowns, but also in more mundane spaces such as writing articles. My background in aerospace taught me that unlimited liabilities are never worth agreeing to. In fact, it is better to avoid indemnity and liability clauses where possible, but that kind of buyer seems to be a rarer and rarer beast to find. An approach I have taken is to explicitly describe and limit what liabilities I am willing to take on in a contract – specifically what I will warrant and guarantee about the product I deliver to the customer.
Warranties may explicitly identify limits for expecting the subsystem or product to work as specified – which means there is a growing amount of resources expended on specifying what the system is not designed to handle. Is this a best practice approach? What does your team do to address a buyer’s risk and liability concerns for your embedded components?
Tags: Acceptance, Liability
Processor Tracker
All Entries RSS Feed
In my experience most embedded developers are unaware of the legal implications of their work.
One peculiar aspect of liability I have encountered occurs with the adoption of open-soure code into an embedded system. In some cases a key reason to avoid open-source altogether is to gain indemnity from a supplier.
Interesting topic.
As much as I hate the insurance industry, it is imperative that embedded developers maintain some professional liability insurance. I’ve often been asked why my rates are higher than others. I always respond “For starters, have you asked the others if they are insured for errors and omissions? They probably aren’t, especially if they are small houses like me.”
Now comes the really difficult part for the developer: Finding an insurance agent and carrier who knows ANYTHING about embedded systems. Risk is a four letter word, and insurance carriers who don’t know much about a type of business (i.e., you don’t fit cleanly into a NAICS code) will add you to the high-risk bin resulting in cost-prohibitive premiums. I’ve suffered through this for years, and almost had to shut down a company over it a few years back.
The other thing a developer can do to limit risk is actually free to both parties: Require that the customer add them as a named-insured on their liability policy. This costs the customer nothing, and likewise costs the developer nothing. I learned this little gem from my father who used to do something similar in the trucking industry (apparently it’s not that unusual there). This only helps when a third party sues you and/or the customer, and does not help when the customer sues you directly.
If you can get the customer to sign your agreement (as opposed to you signing theirs), be sure it contains an indemnity clause of your own, requiring that they indemnify you.
Speaking of your agreement, I have a clause in mine that states (in not so many words) that the customer understands the risks associated with developing embedded systems, that no computing platform is impervious to failure, and that they are assuming the risks associated therewith. I’ve never had anyone complain about this clause.
Please note that I am not a lawyer and I am not dispensing legal advise. I’m only stating things that I have done in the past. Fortunately, I’ve never had to put any of these things to the ultimate test.
L., you do bring up an interesting problem with the open-source issue. I hadn’t considered that.
There are basically two distinct types of liability:
One has to do with the risk of a product malfunction, and any direct damages it may cause. This is partially mitigated with the various certifications (UL, HALT et al), and several safety standards for software and communications. Following a widely accepted standard or “accepted industry practices” is a good measure of protection, as well as the relevant insurance.
The other is related to the intelletual property within the product, and the risk of being sued for copyright or patent infringement. I do not know of any standard or insurance to cover for this type of liability, but some vendors will offer to indemnify their customer for the use of their software, and assume all reponsability related to their product.
Open-source seems the proverbial monkey-wrench in this respect, as it is quite impossible to know if someone did not steal a peice of software to redistribute it under GPL …
“Open-source seems the proverbial monkey-wrench in this respect, as it is quite impossible to know if someone did not steal a peice of software to redistribute it under GPL …”
I think it is possible to know whether GPL’d code was incorporated into a work; in fact, there are software companies that make a business of automating the process of detecting when GPL code has been incorporated into a source base.
There are actually fewer carriers/providers of professional liability insurance around, but I wouldn’t advise anyone to work in this field without it. As part of obtaining said coverage, you DO need to use written contracts – either yours or clients – with liability/indemnity clauses in most cases. I am not sure with insurance business the way it is if many clients will offer/allow to cover you under their policy these days for this type of work – the coverage is expensive and larger companies usually may be required to put up a substantial “bond” as collateral with their policy to cover permanent employees