|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at email@example.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
|For novel ideas about building embedded systems (both hardware and firmware), join the 39,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
On Expert Witness Work
March 26, 2019
We sat, both hunched over our computers, shivering. Christina wore three hoodies, but the server room was cold, and 12 hours a day there sapped our heat. Access to the room was strictly controlled, requiring passage through multiple locked doors. An armed guard stood outside.
National security? Nope. This was a patent lawsuit. Christina was the young associate and I the expert witness. Our mission: to find signs of infringement in the defendant's code, some 15 million lines of C.
In another case the code was on a computer which was inside a sealed box protected by multiple combination locks. Connections for a monitor, keyboard and mouse protruded, but that was it. A GPS inside the box let the defendant know if we had moved it from the conference room. No one responded to my objection that, being deep inside a towering skyscraper, the GPS was probably not getting a signal at all.
These sorts of precautions are routine in software patent disputes. There's never a connected printer. Generally we're allowed to identify small snippets of code which the lawyers will print and give to us at their discretion. Both sides feel their code is extremely valuable business information that can't be leaked in any form or fashion. I'm completely sympathetic to this as firmware is the most expensive thing in the universe.
The court always issues a protective order which specifies in detail how the code should be protected. All documents, including listings (such as they are) must be marked with a phrase like "Confidential business information – Source Code – Attorneys' eyes only." "Attorney" encompasses expert witnesses. In court, when discussions of the source code come up, a parade of lawyers and witnesses not cleared for that information parades out of the room.
I spent many years in the intelligence business. The protocols for securing information above Top Secret and for expert witness work are eerily similar. But working conditions in the spy biz are usually better than in patent disputes. For the latter often limits even what kind of notes we can take. With government work we could access computers, though they had to stay inside the SCIF – Secure Compartmentalized Information Facility. But with patent work the only computer in the code room is that with the code, and we can't store files or notes on it. Once, the court's protective order did allow me to bring a laptop into the room, but only one without a camera. You know how hard it is to find even a used camera-less machine?
Comments in national security code, at least in the USA, are in English. I've done several expert witness projects where they were in Chinese pinyin. In one case all variables were three characters long, and the first was always "m".
Gaining access to the code room involves negotiations between teams of lawyers; you can't just waltz in and start working.
A defendant in a patent dispute reasonably wants to make it as hard as possible to find infringement, so toss up whatever legal blocks they can. Hence the PCs in the cold server room. Aids to understanding are few. I've never seen code that was modified via a comment stripper, but in one case several million lines of VHDL probably averaged one comment per thousand lines.
While opposing counsel does make it hard to make sense of what is sometimes a big ball of mud, I have never seen an attorney do anything remotely illegal. Those I've worked with all stayed scrupulously on the right side of the law, though might get right up to that line.
Despite the hassles, it is fascinating to dig deeply into an unknown code base with limited time to see how a particular device works. I have seen code that is so well thought out, so carefully implemented that one wants to pin a medal on the developers. More common is a mess that should never see the light of day.
I get a lot of questions about expert witness work. As mentioned, the technical part is completely absorbing. There's a lot of writing, which I enjoy; other engineers might not. I've filed several 700+ page reports. A lot of time gets spent in meetings with lawyers to find new meanings of individual words, which, it becomes clear, is necessary, but is not my cup of tea.
Then there's testifying, which some experts love. Here's my expert witness page.
Feel free to email me with comments.
Back to Jack's blog index page.
If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."
Recent blog postings:
- A 72123 beats per minute heart rate - Is it possible?
- Networking Did Not Start With The IoT! - Despite what the marketing folks claim
- In-Circuit Emulators - Does anyone remember ICEs?
- My GP-8E Computer - About my first (working!) computer
- Humility - On The Death of Expertise and what this means for engineering
- On Checklists - Relying on memory is a fool's errand. Effective people use checklists.
- Why Does Software Cost So Much? - An exploration of this nagging question.
- Is the Future All Linux and Raspberry Pi? - Will we stop slinging bits and diddling registers?
- Will Coronavirus Spell the End of Open Offices - How can we continue to work in these sorts of conditions?
- Problems in Ramping Up Ventilator Production - It's not as easy as some think.
- Lessons from a Failure - what we can learn when a car wash goes wrong.
- Life in the Time of Coronavirus - how are you faring?
- Superintelligence - A review of Nick Bostrom's book on AI.
- A Lack of Forethought - Y2K redux
- How Projects Get Out of Control - Think requirements churn is only for software?
- 2019's Most Important Lesson. The 737 Max disasters should teach us one lesson.
- On Retiring - It's not quite that time, but slowing down makes sense. For me.
- On Discipline - The one thing I think many teams need...
- Data Seems to Have No Value - At least, that's the way people treat it.
- Apollo 11 and Navigation - In 1969 the astronauts used a sextant. Some of us still do.
- Definitions Part 2 - More fun definitions of embedded systems terms.
- Definitions - A list of (funny) definitions of embedded systems terms.
- On Meta-Politics - Where has thoughtful discourse gone?
- Millennials and Tools - It seems that many millennials are unable to fix anything.
- Crappy Tech Journalism - The trade press is suffering from so much cost-cutting that it does a poor job of educating engineers.
- Tech and Us - I worry that our technology is more than our human nature can manage.
- On Cataracts - Cataract surgery isn't as awful as it sounds.
- Can AI Replace Firmware - A thought: instead of writing code, is the future training AIs?
- Customer non-Support - How to tick off your customers in one easy lesson.
- Learn to Code in 3 Weeks! - Firmware is not simply about coding.
- We Shoot For The Moon - a new and interesting book about the Apollo moon program.
- On Expert Witness Work - Expert work is fascinating but can be quite the hassle.
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.