My e-Discovery Team co-chair, Ed Foster, and I did a Webinar for Navigant last week entitled Emerging Standards for Metadata Production. A few astute listeners asked for a list of the most common objections to requests for production in Native format. Of course, this is the format where you are likely to receive the most original metadata. I say “most,” and not “all,” because metadata about a particular file that resides outside of the file itself, such as metadata maintained and stored in operating system files, would not necessarily be included in a production of that file in native format, or any other format for that matter. You would have to request production of the applicable operating files for that. The same holds true for the metadata of the folder structure for Outlook emails in a PST file. That information is only contained in the packing file that holds all of a user’s emails, the PST file, and is not contained in the individual email file itself. I wrote about this in my Blog entry of January 13, 2007 “MSG Is Bad For You“.
Production in “native” format means production of the computer files, or ESI, in the format in which they were originally created and maintained. Williams v. Sprint/United, 2006 WL 3691604 (D.Kan. 2006) (“Williams II“) (See my Blog entry of February 5, 2007, Play It Like It Lies and No Mulligans” for more on this case). Most of the time this means files are produced in the format of the software application used to create the ESI. Thus, for example, if you produce a file created by Microsoft Word, this typically means production in the Microsoft Word format, wherein the file ends with the .DOC extension.This is not necessarily always the case, however, because you can also use Microsoft Word software to save your documents in other formats, say for instance, HTML format. Some people might do that, say for instance to facilitate posting the document on the web.
The fundamental metadata case, Williams v. Sprint/United, 230 F.R.D. 640 (D.Kan. 2005) (Williams I), which I discuss at length in my META Page above (on metadata), mentions the four most popular objections to native file production. The fact that these objections all failed in Williams I is testament only to their weak inapplicability to the facts and circumstances of the particular motion presented, and the opinion of Magistrate Judge Waxse. The arguments and objections were good, and this is where any practitioner would want to begin their analysis. These same arguments may succeed with other facts, or even in similar facts with a different judge. This is a very new and evolving area of the law. In fact, these same defendants, Sprint/United, are still presenting these same arguments in other nearly identical cases in the same court, but with a different magistrate. Bolton v. Sprint/United, 2007 WL 756644 (D. Kan. March 8, 2007).
So, without further ado, presented in the order in which they were summarized in Bolton, here are the four basic objections to native format production (with my short comments in italics)
1. Native production destroys metadata. When you access native files you change their metadata. (This is true, it is also true that there are usually ways to guard against that.)
2. Native production can reveal privileges hidden in metadata, both attorney-client and work product. Metadata can for instance show such work product as when files were gathered, last opened, printed, etc., as opposed to the metadata existent pre-litigation during the relevant time period of the dispute. (This could be true if counsel was not careful to preserve the original files, and again, there are usually ways to protect against this.) As another example, metadata in the form of hidden comments to a word document could reveal privileged attorney communications. (Again true, but a privilege review of the metadata would show these comments, and so allow them to be withheld.)
3. The metadata in the native files is not relevant to plaintiff’s claims. (This is the strongest argument for objection to production of metadata and is in accord with Sedona Principle 12 commentary, which states that most metadata is useless and a waste of time to review. So, if the requesting party argues for native file format on the basis that it needs the metadata, challenge the relevance of the metadata. Unlike the plaintiffs in Williams I who made a strong showing that they needed the native spreadsheets, the requesting party may be unable to show any particular need for native file production. See Williams II supra, and Wyeth v. Impax Laboratories, Inc., 2006 WL 391331 (D. Del. 2006)).
4. It is difficult to ensure that native files have not been changed after production. (Judge Waxse destroyed that argument in Williams I when he pointed out that hash values guarantee authenticity. Williams I, Supra at 655. See my Blog Page above HASH. Still, if hash is considered, variations of this argument may still be persuasive.)
In addition, by far the best objection you can make, when the facts allow it, is that you have already made production in a non-native format and new Rule 34(b)(iii) protects you from a second production. See eg. Williams II and In re Payment Card Interchange Fee and Merchant Discount Antitrust Litigation, 2007 U.S. Dist. LEXIS 2650 (E.D. N.Y., Jan. 12, 2007).
Another good objection is found in new Rule 34(b)(ii), which states if format is not requested, a producing party may produce in either the form in which it is “originally maintained” (in other words, native form), or in a form that is “reasonably useable.” Thus if native is not specified, this allows any other form that is reasonably useable. Typically a format is reasonably usable if it is searchable, and other criteria are met, primarily related to functionality and the circumstances of the case.
Even if native is requested, under some circumstances you can object on the basis of burdensomeness, and argue for production in another reasonably useable format that would be less expensive and time consuming for you to accomplish for some reason. An example of this is the difficulty of partial redaction of many native files, or marking them as confidential.
You can, of course, object to the production of the ESI requested in general, at least on a category by category basis, and not just limit your objection to the format. This is what Sprint/United did in Bolton, where they were able to obtain protection against several categories on the grounds that the ESI requested was overly broad, irrelevant and unduly burdensome. These were the grounds that were successful in Bolton, not the four native format objections. In addition, in appropriate circumstances, you can object on the basis of the inaccessibility of the ESI requested under new Rule 26(b)(2)(B) because of undue burden or cost to restore or search.
