Introduction
In March 2003, Caldera Systems Inc. doing business as ‘The SCO Group’ filed suit against International Business Machines (IBM) in Utah state court. Their complaint alleges, among other issues, misappropriation of trade secrets in variants of the UNIX computer operating system. What is emerging as a highly visible case, with relevance on the use of software beyond the computer operating systems in question, illustrates what will require a complex review of software source code.
While visible, it is not unique. The year 2002 saw the filing of approximately 2500 patent, 2000 copyright and 3000 trademark cases in US federal courts1. Many additional cases are filed in state courts in disputes over trade secrets and contractual issues. By rough estimate amongst these cases are possibly 250 where the core issue involves computer source code…and hence necessitates access to the source code for discovery, expert review and trial purposes.
Why would a case need to review software? It is software that ‘gives life to’, or ‘animates’ products based on hardware such as computers and chips. Like access to blueprints for a bridge, actual source code may reveal to the reader:
Functionality - What does the software do, and what does it do within the product in question
Method - How does source code do the function?
Authorship – Who wrote it and when?
Environment - What computer language is used? Was it written with specific hardware in mind, or is it multi-platform?
Quality and Technique – Does it reflect defined development protocols, or informal programmer design?
The importance of each of these aspects varies depending on the nature of the case, but the issues surrounding every intellectual property case requires answering at least one of these questions.
What are some of the issues facing the parties, attorneys and experts where the proof of a case requires examination of source software? An earlier article2 explores some of these issues from a technical perspective. As a result of the intervening years, experience and changes in technology, some practical issues emerge (and how to handle them) at every discovery request.
In what form should source code be produced?
This question asks ‘paper’ or ‘electronic’ form. Each has benefits and drawbacks. Paper is Bates-numbered for reference; electronic would be a CD-ROM of the source code text, and is searchable with computer tools.
File names and directory structure are important
If produced on a CD, it is preferable to copy all files in exactly the same directory structure, showing the file names, as would be available to a programmer working on the product. The reason for this is two-fold. The file name that identifies the code may be as important as the file contents itself. The contents of the source file may not have the file name within it as a ‘comment.’ Also, if there are multiple instances of the same file name (possibly with differing contents), producing the files without preserving directory and sub-directory order could overwrite like-named files.
Security
Software related litigation likely deals with sensitive proprietary information. A primary concern to the producing party when using electronic form, as opposed to paper, is security. The traditional mechanism of protective orders, elimination of exposure to parties with conflicts, and trust, works with both paper and electronic production. For electronic production, though, additional measures can be taken. The protective orders may restrict the number of experts exposed to the information, restrict the mounting of the CD to one computer, restrict the computer to one unattached to a computer network, or restrict the location of that computer to an attorney’s office or other secure facility such as an escrow service. The factors that affect this choice of security mechanism are quantity of information, the perceived importance of the information, ability to print, software tools available to assist in examination, convenience, and trust.
‘Paper’ as PDF
The Portable Document Format (PDF) used by Adobe Acrobat is now a routine method of exchanging documents in business and law. A ‘printed’ copy of source code too can be produced as a PDF file. This adds an element of security to thwart inclusion of the code directly in someone’s product, but is unwieldy for lengthy electronic reviews of code. As the PDF file grows, it is slower to find instances of key words, such as all instances of programs that use the ‘procedure.’
Clarity
Source code is written within a syntax and format, like natural languages. The method by which source code files are printed, either on paper or ‘electronically’ as PDF, can have a positive effect on ease of review and presentation. Specifically, this includes choice of font, line-wrapping, heading information in the margins, and line numbering. Source code may have been written assuming certain indentation, so using a fixed-size font simple font will present better than a proportional font, i.e., Courier or System is usually preferable than Times New Roman. Programmers are not necessarily restricted to the length of a line of computer code. This code may ‘wrap’ to the next line for review. There is a risk that not paying attention to this factor will cause code to truncate and be lost beyond the edge of a printed page.
Adding ‘header’ and ‘footer’ information documents what it is that is being produced. You can provide the directory path and file name to a header, the software version, a sequential page number of the file and date of printing.
All of these features are likely to be available when originals for production printing are printed from within software development utilities, such as ‘pretty printers’. The benefit is readability and documentation of the nature of the material produced. These printing techniques can also enhance the submittals for Copyright deposits and source code appendices in Patent applications.
Summary
The production formats and review mechanisms discussed above facilitate the important work required in software litigation and offer degrees of security. On the other hand some can have the consequences of inconveniencing or increasing costs of review.
What would be the ideal production format from the point of view of an expert reviewing code? This would be both Bates-numbered paper and CDROM, the CDROM containing an exact copy of the programmer’s source code directories. Anything produced on paper would be documented with the directory path, file name and product version or revision number. In addition, would have access to electronic review in convenient forms.
- Aggregated data available from the US Federal Courts
- See S.B. Soffer, "Effective Discovery in Software Litigation", The IP Litigator, Vol 3 No 1, January/February 1997
Stuart Soffer is President of IPriori, Inc., and is a consulting and testifying expert for attorneys in software litigation. Offices are at 1047 El Camino Real, Suite 202, Menlo Park, CA 94025. Telephone: (650) 566-0300. Web site: http://www.ipriori.com
The content of this article does not constitute legal advice and should not be relied on in that way. Specific advice should be sought about your specific circumstances.