Articles about intellectual property litigation and technical expert witnesses.
Note: These articles offer practical guidance for attorneys engaging technical experts. They are general commentary, not legal advice. Discussion of specific litigation is drawn from publicly available court records and published reports. Consult counsel about any specific matter.
By Michael Barr
The easy software copyright case is the one where the files match. Somebody took the source, changed the header comment, and shipped it. An expert can put the two listings side by side and the argument is essentially over.
As a consultant, I think with the trial team. I can tell them a theory is weak, that a document cuts against us more than counsel realizes, or that the honest reading of the code doesn't support what someone hoped it would.
Breach cases have an unusual problem. In most technical litigation the evidence sits still and waits for you. In a breach, the evidence is a set of logs that were designed for operational troubleshooting rather than for proof, that were retained for as long as somebody's storage budget allowed, and that describe an event which the defendant was actively trying to stop while the record was being written.
The first safety-critical firmware I worked on had a watchdog timer, a set of self-tests, and a review process that felt, at the time, unusually strict. Years later I would spend a great deal of time reading other people's automotive firmware in litigation, and I learned something that surprised me: the strictness of a process tells you far less about the safety of the resulting product than most people assume, and the paperwork proving the process was followed is not the same evidence as the code itself.
My first engineering job was writing firmware for chips that other people had designed. I lived inside their datasheets, I built workarounds for their errata, and when a product misbehaved at two in the morning I had to settle one question before I could fix anything: was the fault in my code, or in the silicon underneath it?
In 2008 I wrote down a set of C coding rules because engineering teams kept arguing about the wrong things: a morning spent debating brace placement, and not one minute on the volatile keyword, which is the kind of omission that produces a field failure nobody can reproduce. The rules became the Embedded C Coding Standard, better known as BARR-C.
I have spent most of my career explaining embedded systems to people who did not grow up inside them: graduate students in my operating systems courses, working engineers who read the magazine I edited, and, eventually, jurors in courtrooms. Each audience taught me something, but the audience that concentrates the mind most is a single federal judge who is about to fix the meaning of the words in a patent claim, and who needs to understand your field before ruling.
By Michael Barr
I once spent the better part of two days on the witness stand in an Oklahoma courtroom, explaining to a jury what my team had found inside the engine control software of a Toyota Camry. The jurors were not engineers.
By Michael Barr
When two software companies collaborate on a joint venture, they inevitably share confidential technical information. What happens when that collaboration ends and one party's proprietary techniques turn up in the other's products? That is the central question in trade secret misappropriation cases involving software, and the answer increasingly depends on what a forensic analysis of the source code can prove.