Tag Archives: trade secret theft

The Report Generator (RPG)

The Report Generator (“RPG”) is a new program from SAFE that automatically generates draft expert reports and declarations for litigation. Reports have several generic sections such as an expert’s experience and descriptions of the technologies involved in the examination, which can be shared amongst reports. By automating the compilation of the generic information into a formatted and structured draft report, the expert can focus on performing the analysis and writing the case-specific arguments.

When using the RPG, an expert selects the type of case, type of report, types of technologies involved, types of tools used, and expert background profiles from a GUI. Then a Microsoft Word draft report is generated that includes all of the selected generic information intermixed with blank sections where case-specific information should be filled in manually.

Currently, many experts either dig through their prior works to find specific descriptions or write them from scratch each time. Maintaining a library of generic report elements is a challenge, especially when multiple experts are involved. RPG acts as a version control system between multiple experts who can upload and download detailed descriptions of experts, technologies, and tools from a central server. The reports are generated according to specific formats, so an entire team of experts can easily produce reports that are consistently formatted with the most up-to-date descriptions.

RPG also keeps synced descriptions of CodeSuite, so it can include the most up-to-date descriptions and pricing of the tools without having to search the S.A.F.E. website or CodeSuite help files.

If you’re interested in trying out RPG, contact our Sales Department.

Interesting software IP cases of 2009

Here is my list of the most interesting software IP cases of 2009,
in chronological order:

What to look for in an expert?

I recently came across a study in the Journal of the American Academy of Psychiatry and Law out of the The University of Alabama entitled “Credibility in the Courtroom: How Likeable Should an Expert Witness Be?” To be honest, I’m not sure I understand their conclusion:

The likeability of the expert witnesses was found to be significantly related to the jurors’ perception of their trustworthiness, but not to their displays of confidence or knowledge or to the mock jurors’ sentencing decisions.

Reading the paper doesn’t make it a whole lot clearer for me, and I think their mock trial setup is a bit contrived, particularly since the jury consisted of psychology students, a demographic that you’d be unlikely to find on a real jury. Also there were only two expert witnesses for the comparison. To their credit, they discuss these potential shortcomings. I do think, however, that the paper points out something (that may have already been obvious)—there is more to being an expert witness than just being correct. Personality and presentation are strong factors.

On the other hand, I feel that this subjective aspect should be minimized. Experts need standards and measurable quantities whenever possible. Before I began developing the concept of source code correlation, the way software copyright infringement and trade secret theft cases were resolved was to have two experts give contrary opinions based on their years of experience. The judge or jury would tend to get lost in the technical details, a strategy purposely employed by some experts and attorneys, and a judgment would depend on which expert appeared more credible.

Instead, I decided to expand the field of software forensics and made it my goal to bring as much credibility to the field as DNA analysis, another very complex process that is well accepted in modern courts. I still believe that an expert’s credibility and likeability will always be factors in IP litigation, but that the emergence of source code correlation and object code correlation provide standard measures that bring a great deal of objectivity to a lawsuit’s outcome.

SAFE Corporation is looking for great ideas

There are a lot of unanswered questions about source code, and we want to work with you to figure them out. We realize that currently accepted algorithms for analyzing, comparing, and measuring source code leave a lot to be desired in many cases. Also, there are a lot of techniques that have never been studied on large bodies of modern code. For example, measurement techniques developed in the 1970s were probably tested on assembly languages and older programming languages like BASIC, FORTRAN, and COBOL. Do they still hold on modern object oriented languages like Java and C#?

If you have a research idea relating to code analysis, and you can use the SAFE tools, let us know. Email Larry Melling, VP of Sales and Marketing with your ideas. If they pass our review process you’ll get free licenses to our tools, free support, and help getting your results published. This could be the beginning of a beautiful friendship.

Software trade secrets

The precise language that legally defines a trade secret varies by jurisdiction, as do the particular types of information that are subject to trade secret protection. In the United States, different states have different trade secret laws. Most states have adopted the Uniform Trade Secrets Act, and those that don’t, have laws that only differ by subtle differences.

There are three factors that are common to all definitions; a trade secret always has these three specific characteristics:

  1. It is not generally known to the public.
  2. It confers some sort of economic benefit on its holder, where the benefit is due to the fact that it is not known to the public.
  3. The owner of the trade secret makes reasonable efforts to maintain its secrecy.

With regard to software trade secrets, algorithms that are known to the public usually cannot be trade secrets, though some jurisdictions require not only that the information be public but that it be “readily ascertainable,” meaning easily to find. For example, a sorting algorithm found in a well known textbook or in an application note on a high traffic website is, or can be, known to the public and easily ascertained.

There must be an economic benefit, so a sorting algorithm that can be easily replaced with a well-known sorting algorithm with comparable results is not a trade secret. Similarly if your company develops a program, perhaps as a side project, but does not sell it or incorporate it in any products, then it’s not a trade secret.

If the owner of the source code allows programmers to share code, or does not put notices of confidentiality in the source code, or does not take reasonable steps to insure that employees do not take the code home with them, then that source code cannot be a trade secret. This third point is a particularly important reason to take precautions to ensure your software does not go somewhere it shouldn’t. Make sure your employees, investors, and partners sign nondisclosure agreements (NDAs). Make sure you have written policies about how to handle source code. And make sure you treat all individuals and companies equally. You don’t want to be in court, defending a trade secret, and have to explain why one “trusted employee” or “trusted friend” was allowed to take home source code while others were not. That doesn’t look like “reasonable efforts to maintain secrecy.”

This is my blog on software intellectual property

Welcome to my blog. I’m the founder and president of SAFE Corporation. I’ll be regularly updating this blog with useful and interesting information about software intellectual property and software analysis. I’ll be posting facts and current events relating to IP litigation, software plagiarism detection (also known as copyright infringement), trade secret theft, and patent infringement. At SAFE Corporation we’re developing unique ground-breaking tools for analyzing, measuring, and comparing software — of course I’ll be updating you on all the cool new tools.

So stay tuned and feel free to comment.