Home > Articles > Software Development & Management

Bob Zeidman on Intellectual Property Issues, Source Code Correlation, and Testifying in Court

  • Print
  • + Share This
Michael Barr talks with Bob Zeidman, author of The Software IP Detective's Handbook, about how he started working with intellectual property issues, the development of source code correlation, and what it's like to testify in court.
Like this article? We recommend

Michael Barr: Give a little background on yourself.

Bob Zeidman: I grew up in Philadelphia, and I remember as a kid having dreams of being an astronaut, a stand-up comedian, and a theoretical physicist. After that I'd be a novelist, a movie director, and possibly a politician. My dad was a self-employed engineer and, as much as I thought he was the greatest guy in the world, I didn't want to be a self-employed engineer. Of course about 25 years ago I became a self-employed engineer. But it turned out to be a lot more fun, interesting, and profitable than I expected.

MB: What got you involved in intellectual property issues?

BZ: About 20 years ago I had a great idea for a company where you could back up all of your important data to a remote location in case of fire or theft. I started a company but no one wanted to invest or be a customer. This was in the early 90s, before Internet was popular, and people said no one would ever, ever send their critical data to an unknown location. What was I, nuts? I went to a Stanford professor I knew who said he wasn't interested in investing but he was working as an expert witness on a trade secret litigation and he needed someone to do the research. When he told me what I'd be paid, I thought I could quickly earn back all the money I'd invested in this stupid business venture of mine (remote backup eventually became a multibillion dollar business, but I was just too early).

MB: What kinds of intellectual property protection are available for software?

BZ: Software can be protected by copyrights, which protect the actual expression of ideas. In other words, copyrights protect software code and its organization, but not the concepts in the code. According to the US Patent and Trademark Office (USPTO), copyrights "protect works of authorship, such as writings, music, and works of art that have been tangibly expressed. The Library of Congress registers copyrights which last for the life of the author plus 70 years"

Software patents protect the implementation of unique, non-obvious software algorithms, regardless of the actual lines of code or organization of the code. According to the USPTO, patents "provide exclusive rights to make, use, import, sell and offer for sale the invention for up to 20 years."

Software trade secrets are like patents, but trade secrets are software functions that are secret (duh) and that give you an advantage over your competitors. You have the advantage of your trade secrets as long as you can keep them secret and your competitors don't discover them on their own.

MB: What is source code correlation and why is it useful?

BZ: Source code correction is a way to measure the similarity of the expression of two programs. It was developed specifically for software copyright cases, though it can be used in some types of software trade secret cases. I worked on some software copyright cases and found that the work of comparing two programs was dull and tedious. It was also easy to miss things. There were a few comparison programs available, but they claimed to show plagiarism. This isn't possible because programs can be correlated for a number of reasons, only one of which is copying. And if the copying was with permission, then it's not plagiarism. I wanted to create a quantitative measure for the similarity of two programs so I experimented and tested and came up with source code correlation.

MB: How did you develop source code correlation and the CodeSuite program?

BZ: Initially I worked in my spare time and created a program I called CodeMatch to measure source code correlation. I showed it to a lawyer friend and asked if he thought there was a market for it. He thought it might make $50K over its lifetime. At that point the program was complete, so I thought $50K wouldn't be bad. I started using it in my work and lawyers found out and started calling me to take on more software IP cases. I started charging for the program and licensing it to other experts. Eventually I spun the software out to a company I called Software Analysis and Forensic Engineering or S.A.F.E. Corporation. Other cases I worked on needed slightly different applications, so I turned each application—BitMatch, CodeCLOC, CodeCross, CodeDiff, and SourceDetective—into a new function in the program and called the new bundle of tools CodeSuite.

MB: What is the CLOC method of measuring source code and what are its advantages?

BZ: The CLOC method stands for "Changing Lines of Code." I was asked to work on a tax case involving transfer pricing. The important fact was that the tax owed by the company depended on how much code had been developed oversees versus how much had been developed in the U.S. over the ten-year life of a program. Originally I planned to use some kind of simple diff utility, but that turned out not to work. Diff utilities can get out of sync when there are large insertions or deletions or rearrangements of code, so it would erroneously report more changes than there actually were. Also, it was difficult to create statistics from diff programs. So I took some of the algorithms in CodeDiff and used them in a slightly different way to measure changes in the source code over time. It seemed to work because my client ended up saving over $500 million in back taxes based on the results (but that's not even the largest case I've worked on).

MB: Tell me about the first time you testified.

BZ: Like a lot of things in life, it's hard to get a testifying job without having already testified. I had worked on a few cases but never testified, when I was approached by an attorney to present an argument about a single important technical fact in a class action suit. The lawyer asked me if I'd ever testified before. I learned long ago that you never answer a question in the negative, but try to find something positive to start out with. So I said something like, "I've sat in on a few depositions where other people testified, so I understand the process, but I haven't yet testified myself." I was hired, did the research, prepped, and testified at a deposition. Afterwards the attorney said, "That went really well. Of course, you've done this before so it's nothing new." When I told him this was my first time, he was really shocked. "I thought you said you'd done this before," he said. I guess he hadn't been listening to my answer too well, but he was happy it went well and after that I could simply answer, "Yes, I've testified before."

MB: What is the most difficult thing about testifying?

BZ: I actually like testifying, though most people don't. I always figure I know more about the subject, having researched it and written a detailed report about it, than anyone else in the courtroom. And it's a fun exercise to see where the opposing counsel is trying to lead me and how to stay away from that area or lead him in a different direction. The hardest part for me, and the part that makes me the most nervous, is when I get questioned by my client's attorney. You'd think that would be easy because my client's attorney is trying to help me make my point and not trip me up. But I always worry I'm going to forget one of the important points that I need to bring up. When the opposing attorney cross-examines me, there's nothing to remember, just to tell the truth and watch where I'm going with my answers. When my client's attorney questions me, it feels more like a memory test, which I've never enjoyed.

MB: Do you think our legal system works for protecting intellectual property rights for complex technologies?

BZ: For the most part I do. If both sides get good attorneys to represent them and good experts to make their technical arguments, then the resulting judgments should be close to fair and just. Unfortunately, while this works out on the average I believe, it doesn't always work out for individual cases. Sometimes one side's expert is unscrupulous or, in rare cases simply a liar. Too often the judge or jury just doesn't understand the intricacies of the case and makes a judgment based on some semi-random factor. I have begun thinking that it might be good to require experts to pass a qualification test like a doctor or lawyer. It wouldn't stop these problems altogether, but could make sure that testifying experts really have expertise in their fields. Also maybe penalties for an expert providing wrong or harmful testimony should be stronger.

MB: Are you planning to write any more books?

BZ: When I wrote my previous book about 10 years ago I said no more books. However, I seem to still keep getting ideas that I just have to put down in writing to share with the rest of the world to make it a better place. Right now I'm thinking no more books. Except probably a novel. I've written two novels and I know I have a few more of them inside me yearning to breathe free.

MB: What are your next endeavors in high tech?

BZ: I plan to keep growing my consulting company and my software company. Both are doing well despite the poor economy, so I'm really thankful for that. I have lots of other tech ideas swirling around, but no time to implement them or write about them, and these companies are keeping me busy anyway.

  • + Share This
  • 🔖 Save To Your Account