Barr Group CTO Michael Barr talks about the source code review process and tips on how attorneys can best streamline the code review process.

Transcript

Andrew Girson: Hi. I'm Andrew Girson, CEO of Barr Group and I'm here with Michael Barr our CTO. We're here to talk about source code review. So Mike, I guess the best place to start is what is source code review?

Michael Barr: Well, let's take a step back. Source code is something associated with software – and I'll talk about that in a minute. But the important thing to realize is we're talking about review of software. And software increasingly is inside everything. We don't think about it and the microphones around us, and the cameras around us, the medical devices around this, cars sometimes have dozens or even over a hundred microprocessors in a car these days, and all of those kinds of devices have software inside them. Software has two forms. It has a form that some people know the word binary which is something that only the computer can read. And that would be like programmed into the cars processor and the engine for example. But there's also a source code part, which is the human readable part. Engineers write source code and then it gets compiled into the binary. So when we're talking about source code review, we're talking about having experienced software developers read the source code for a device. Say, for example, talking about litigation. I'm talking about maybe a medical device that’s accused of causing an injury has software inside it. The source code could be reviewed by one or more experts.

Andrew: Okay. And that leads to the question of why. Why is source code review important? Why do we do it?

Michael: Well, in the legal context, source code review comes up in a couple of different kinds of cases. So, one like I just alluded to with a medical device is what's called product liability. So, if you have some sort of a product and somebody's been injured by that product or alleged to be injured by that product, there might be a lawsuit for financial damages. And it might be the case that the source code that was originally, you know, built the device, medical device say, comes out and is examined at discovery by the two legal teams with their experts. But there are other contexts as well for getting software source code. There's a lot of intellectual property disputes. For example, you know one company might accuse another company of infringing on its patents or infringing on copyrights that it holds in the software-- there's something called a software copyright that applies to the source code. And as well, there's something called trade secrets litigation where companies trying to keep a secret of how the source code works so that nobody else in the world can know it, but sometimes an employee might leave with the source code. Then there would be a trade secrets dispute. The one other kind of case where we see source code is sometimes what's just a general class of lawsuits business contract disputes. For example, if Company A paid Company B to develop some software and Company B didn't finish on time or never got the software to work there could be a dispute where they're looking to get back damages and might be necessary to look at the source code in that as well.

Andrew: So that's interesting. So, let's say you've been hired or someone's been hired as a software expert. What's the process? How does it work in terms of doing source code review?

Michael: Okay, well the super short version is that each side -- typically the plaintiffs and the defense -- would retain their own experts. And the source code would be produced by the party that owns it to the other side. And then the experts would take some time looking at the source code, forming opinions about the issues of the case, and writing a report. It's called the expert report, which gets filed in the case.

Andrew: Filed with the court?

Michael: It might be filed with the court. Might be because it's a related to something that's a trade secret. It might be confidentially -- but officially a part of the case between the parties. And then following the expert report typically would be a phase of depositions where the other side's lawyers are able to ask questions in a videotaped deposition. And then finally, if the dispute is not settled, then there could be trial testimony before a judge or before a judge and a jury. But just circling back for a minute, you know one of the things that is important in terms of having the most impact on a case is if the parties bring the experts in earlier, it's usually better.

Andrew: Earlier in the process?

Michael: Earlier in the legal process, that's right. Not waiting until the last minute when the source code’s already been produced. We often get involved in helping lawyers to frame the request for production to make sure they get all the stuff around the source code that they need. Things like design documents, if there's electronics involved, exemplars of that and design documents for that, and making sure they get all the versions of the source code. For example, there might be that there's one version that infringes a patent and then later, there's another version that doesn't infringe the patent. That might be relevant to the issue of the case. So, the long and the short, that's how the process works.

Andrew: And where does this actual source code review process take place physically? Where does it happen?

Michael: Well, like I was talking about about source code being often considered a trade secret, judges are generally deferential in my experience to that aspect and making sure that the code that's produced by one of the parties is not just made available on the internet for all to see. For example, a car company certainly doesn't want its engine code to be released for everyone to see. So, the typical scenario that we see the most is that the source code is produced in a computer with no network connection in a law firm conference room, for example. So the experts have to do their source code review in that room. But we've started to certainly also seen some exceptional circumstances. As you know when we worked on the Toyota case with the Toyota engine code, there was actually a custom-built room with no internet and no connections for cell phones or other things for security purposes of the code.

Andrew: And I guess lastly, who does this review? Who does these reviews?

Michael: Sure. Well the reviewers.. there's a couple different models. Sometimes it's just a single expert and sometimes it's a team of experts. Let's take the single expert model first. Typically, there would either be a testifying expert with experience testifying before. It could be a professor or someone with a master's degree or PhD in computer science or related field. And they're also what's called consulting experts. So, consulting experts work with the lawyers behind the scenes. Testifying experts work upfront writing expert reports, being deposed, and trials. And as you know, we supply experts of both types. We also put together teams often. And in a team environment, that’ll typically be one or maybe two testifying experts on a bigger project dealing with different aspects, but they would have a supporting cast. They might have people who helped them with software testing, they might have engineers who are working with them who've never testified before, but are experts in their subject areas.

Andrew: Okay. And finally, anything else that we should know about the source code review process?

Michael: Well I think just generally we should make clear that one of the services that Barr Group provides is helping lawyers connect with software experts. And actually, software and electronics experts. So, the source code review is something we do and have a lot of experience doing – putting together teams and individual reviewers. But it's just one of the things that we provide -- one of the types of services we provide to lawyers in litigation.

Andrew: Okay. Great thanks.

Michael: Thank you.