The title of Paul Gauguin’s famous primitivist painting of Tahiti above is: “Where Do We Come From? What Are We? Where Are We Going?” These are perennial questions of past, present, and future that all humans face. In the world of e-discovery at least, the answer to these questions is clear. We come from paper, we are now in “Tiff and load,” and we are going native.
Right now most of us in e-discovery live in the safe, well established world of “Tiff and load.” (By this I am referring to converted static image files of all types, including Tiff, and corresponding load files with indexes and other information on the original pre-converted files, usually including select metadata.) We have heard that some in e-discovery, from time to time, leave the familiar comfort of Tiff review and production to try to handle raw computer files that have not been converted, that still live in their untamed native state. There are tales of others who have completely “gone native” and now only review and produce in original forms. They promote a total return to the native, much like Paul Gauguin, and Henri Rousseau (whose painting “The Dream” is shown below) did in the world of Art in the late Nineteenth Century. They tempt us with primitive visions of a wild unfiltered world; a new landscape overflowing with all types of strange exotic metadata.
These nativists brag of cost savings by eliminating steps and keeping it simple. They no longer even try to convert the masses of ESI found in the wild. They instead leave them in their first forms. They openly taunt the converted, the static image. They even abandon the security and well defined order of the sacred Bates stamp. Instead, they babble on about hash, algorithms, authenticity, and dreams of digital fingerprints.
These wild native lovers appear to be brainwashed by over exposure to IT culture. They have succumbed to a classic, incurable case of Clientitus. Those who have lived long in the world of e-discovery, and still profit from the old ways of static image conversion and blowback, will not quickly give in to these new, unproven methods. As even Henri Rousseau once said: “I cannot now change my style, which I acquired, as you can imagine, by dint of labour.” Thus, a mighty battle is set. A war of ignorance and half-truths is in play between the old and new approaches to e-discovery.
This clash of cultures can be seen in four new cases decided in the last two months. There have been many cases like this before and no doubt many more will follow. See eg. Aguilar v. Immigration and Customs Enforcement Div. of U.S. Dept. of Homeland Sec., 2008 WL 5062700 (S.D.N.Y. Nov. 21, 2008) (Opinion by Magistrate Judge Frank Maas includes a scholarly review of many cases battling over metadata and an observation at *9 that “Metadata has become ‘the new black,’ with parties increasingly seeking its production in every case”). The appearance of four more cases on the issue in the past sixty days suggests that the conflict is escalating. Tiff and load is still the dominant colonial culture, but, as these cases show, the wild ways of native production are beginning to make their mark, hash mark that is.
In Re: ClassicStar Mare Lease Litigation
The first new case examining this conflict comes out of Kentucky. In Re: ClassicStar Mare Lease Litigation, 2009 WL 260954 (E.D.K.Y. Feb. 2, 2009). In ClassicStar, Magistrate Judge James B. Todd considered whether a defendant should be required to produce financial data in its original, native format after it had already been produced in Tiff and load. One of the defendants in this multi-district litigation, GeoStar, produced 273,000 pages of financial records to all parties. GeoStar converted the information from their original format to a Tiff, with DII load files and OCR “so that the documents could be readily loaded into the parties Summation or Concordance (both litigation document management software) databases for ease of searching.” Id. at *1. In footnote two, GeoStar contends that all prior productions in the case have been made in this same format and no one had complained before.
In spite of the fact that this production of 273,000 of financial records was searchable and in accord with prior practice in this case, a group of plaintiffs had succumbed to the lure of native for reasons that will be explained below, and demanded that all of these documents be produced again in their original native format. GeoStar objected, and its Chief Financial Officer testified at a hearing on the issue that a second production in original native format would be unduly burdensome:
He identified three reasons that the production of the financial information would be extremely difficult and burdensome on GeoStar: (1) GeoStar would have to redact all financial information pertaining to Gastar Exploration, Inc., pursuant to a confidentiality agreement between those companies; (2) GeoStar would have to redact information outside the requested time period; and (3) GeoStar would have to review older data and repair any corrupted data.
Id. at *2.
Judge Todd correctly begins his analysis of this “Tiff v. Native” dispute by reviewing Rule 34, Federal Rules of Civil Procedure. It provides that, if the requesting party fails to specify a format, “a party must produce it in a form or forms in which it is ordinarily maintained or in a reasonably useable form or forms.” Rule 34(b)(2)(E)(ii), Fed.R.Civ.P. The Court also correctly referenced the related Rule 34(b)(2)(E)(iii): “a party need not produce the same electronically stored information in more than one form.”
Defendant GeoStar took the position that its production of financial records in Tiff format, with DII load files, satisfied the requirement under the Rule to produce the ESI “in a reasonably useable form.” GeoStar argued that the conversion to Tiff with a load file did not “significantly degrade” the searchability function of the documents. GeoStar relied upon United States v. O’Keef, 537 F.Supp.2d 14, 23 (D.D.C. 2008) where Judge Facciola held:
[P]roduction of the electronically stored information in PDF or TIFF format would suffice, unless defendants can show that those formats are not ‘reasonably usable’ and that the native format, with the accompanying metadata, meet the criteria of ‘reasonably usable’ whereas the PDF or TIFF formats do not.
In response to this position, the plaintiffs’ group argued that production in native format would make the information “more usable.” Judge Todd commented that the “nativeists” did not address the core issue in the rule as to whether or not the Tiff and load file was “reasonably useable.” To support their argument as to greater usability, the plaintiffs referred to a particular financial report as an example. The report contained 18,000 rows and 13 columns of data. As the Court said, “these materials contain an extraordinary amount of data.” In my experience, this type of report is not unusual for financial institutions these days and the situation here addressed by the Court is becoming quite common.
The plaintiffs went on to argue that unless these reports are produced in their original native format, and not just Tiff and load, that they will be forced “to manually sort through tens of millions of rows of densely formatted financial data.” Yes, they said millions! Conversely, the plaintiffs argue that if the data is produced in its native format, as it is maintained in the ordinary course of GeoStar’s business, “plaintiffs could query various search reports and extract the desired information in a fraction of the time.” Id. at *3. Nothing like facing the costs involved in reviewing millions of rows of data to open the mind to new alternatives like native file review.
Still, if these plaintiffs had wanted it in native, why didn’t they ask for it that way to begin with, before the producing party went to all of the expense of conversion to Tiff? Apparently, it took them a quite a while to understand the benefits of native file review. Plus, as we will see, the producing party maneuvered them into acceptance of Tiff with scary tales of proprietary software.
The Court resolved this fairness quandary by holding that:
GeoStar has not necessarily erred by producing the documents in .pdf and .tif formats. Indeed, GeoStar apparently produced the documents in a format which was most likely to be usable-to some extent-by any of the parties to this lawsuit, none of whom had the necessary software for the native format data at the time of the production. In other words, the West Hills Plaintiffs have received, to the best of the Court’s knowledge, the production that their Request sought.
Id. at *3.
After making this ruling, the Court went on to say that it was, however, “very concerned” with a written exchange between counsel concerning this production. In the written exchange, GeoStar’s attorneys basically stated it would not be appropriate to produce the financial information requested because it could only be read if the plaintiffs purchased the two specialty software programs in which they were created. Defense counsel also indicated that they thought this would cost in excess of $50,000.00 to purchase these programs and, for that reason, they were going to produce them in the Summation or Concordance database formats instead, namely Tiff and load files. The letter did, however, indicate that if they chose to buy the software, then they would produce the data in its native format.
The Court seized upon this throwaway remark as a clever way around the issue of whether the Tiff and load here was “reasonably useable” as required under the rules. The Court basically held that the offer in the letter superseded the rules requirements and obligated the defense to produce the financial database in its native format, assuming that the plaintiffs in fact purchased the “specific software necessary to read the native data format so that they might use its imbedded metadata to better understand the data and the information that it represents.” Id. at *4. The Court did, however, shift the costs of this second native production onto the requesting plaintiffs group, holding:
Finally, as GeoStar has already produced the data once and as the original document request did not specify a native format production, it is only fair to shift the reasonable cost of copying and delivering this second production to the West Hills Plaintiffs.
Id. at *4. This ruling reminds me of a famous quote by Paul Gauguin: “A compromise is the art of dividing a cake in such a way that everyone believes that he has got the biggest piece.”
The obvious moral to this case is that if you are a requesting party, and you want native files, then you should specifically request the native files at the get-go. Do not wait until after you are slammed with Tiff and load to find religion. Do your homework up front. This case also stands for the proposition that if you want native format, you may also have to purchase special, sometimes quite expensive software on which the files were created. This depends on many facts and circumstances, including the export capacities of the original software. These are the kind of technical details that should be worked out by the parties. See Sedona Conference Cooperation Proclamation; Aguilar v. Immigration and Customs Enforcement Div. of U.S. Dept. of Homeland Sec., supra at *9 (metadata issues are an inherently “party-oriented process”).
Finally, it is significant to note that, in this particular case, the confidentiality issues raised by GeoStar were found to be without merit. The court held that there was no confidential data. In other circumstances where bona fide confidential or privileged information is involved, these concerns can raise serious issues about going native. It is impossible to redact a native file in the same way you can redact a Tiff or other image file. The only way that I know of to protect confidentiality in a native file is to alter the native file by deletion or encryption of the protected data. Thus, for instance, if the native file is an Excel spreadsheet, and only one page of the 30-page spreadsheet is relevant and not confidential, then the redaction of the native file takes place by removing the confidential and irrelevant sections of the spreadsheet. This act of removing the confidential information, of course, completely changes the file and in effect creates a new file. Thus, in the context of native file production, redaction is accomplished through alteration and creation of new files. This can be an extremely time consuming process which will often result in cost-shifting to the requesting parties, especially if native format is demanded in order to maintain the full functionality of file.
As an aside, a new case recently considered what types of information can be redacted before production. Lapin v. Goldman, Sachs & Co., 2009 WL 222788 (S.D.N.Y. Jan. 23, 2009). This is an interesting short opinion by Manhattan Magistrate Judge Douglas F. Eaton that is definitely worth reading. It primarily concerns keyword search terms. The plaintiff class took the incredible position that all of the emails of 39 past and current employees of Goldman Sachs during a certain time period should be produced without any filtering for relevance at all. Had this position been adopted, the defense would have had to review over 300,000 emails of these employees to search for privilege. They would have had to produce all of them, no matter how irrelevant they were. This appears to be a classic case of using e-discovery as a weapon, not a tool of truth. Judge Eaton agreed with the defense on this issue and ordered the parties to meet to attempt to agree upon keywords to cull out irrelevant information. He also rejected plaintiffs related extreme position that all of the emails found should be produced without any redaction at all. If this position had been adopted, the defendant’s privacy rights, and the privacy rights of its employees, including attorney client privilege, would have been trampled. Once again, Judge Eaton saw through this “e-discovery as weapon” tactic and held that information could be redacted by defendant if:
(1) the information is proprietary and would adversely affect Goldman Sachs’s competitive position even at this late date; (2) the information would invade the analyst’s privacy rights and is entirely irrelevant to the issue of whether the analyst perceived any pressure to slant a report to please anybody in Goldman Sachs’s investment banking division; or (3) the information is protected by the attorney-client privilege.
I applaud Judge Eaton here for recognizing and providing some protection to the privacy rights of Goldman Sachs employees. As I have discussed before, these rights are often ignored and innocent people are unnecessarily harmed or embarrassed by having private emails made public in litigation, even when they are completely irrelevant. There was no discussion in this opinion as to form of production, but I assume it was the standard Tiff and load.
Kingsway Financial Services, Inc. v. Pricewaterhouse-Coopers, LLP
A second case examining the “Tiff v. Native” conflict comes out of New York. Kingsway Financial Services, Inc. v. Pricewaterhouse-Coopers, LLP, 2008 WL 5423316 (S.D.N.Y. Dec. 31, 2008). Here Magistrate Judge Henry Pitman addresses a plaintiff’s request for the defendant’s production of metadata from documents the defendants have previously produced in Tiff. It seems to me that this request for native was not really serious. It looks more like a “strategic tactic” because, in the Court’s words:
Plaintiffs do not identify the types of metadata they seek nor do they explain why metadata is relevant in this matter. In addition, plaintiffs do not raise any questions about the authenticity of any documents produced by PwC nor do they claim that any document has been improperly “doctored” or modified.
Id. at *6.
The opinion of Judge Pitman cites to Aguilar:
As Aguilar points out, there are three different types of metadata: (1) substantive metadata; (2) system metadata, and (3) embedded metadata. 08 WL 5062700 at *3-*4. In general, metadata is relevant when the process by which a document was created is in issue or there are questions concerning a document’s authenticity; metadata may reveal when a document was created, how many times it was edited, when it was edited and the nature of the edits. In the absence of an issue concerning the authenticity of a document or the process by which it was created, most metadata has no evidentiary value. 2008 WL 5062700 at *5.
Kingsway at *6.
I must point out that Judge Pitman in Kingsway omits another important reason for obtaining metadata; namely to improve the functionality of the file. There is much more to this “back to native” movement than the pursuit of authenticity. The added functionality of native files arises from the “embedded metadata” mentioned in the Aguilar three-fold type differentiation. The classic example of this is seen in spreadsheets, wherein the embedded metadata allows formula studies, as well as functional assortment and other internal search capabilities. This is also well demonstrated in In Re: ClassicStar Mare Lease Litigation, 2009 WL 260954 (E.D.K.Y. Feb. 2, 2009).
The requesting party here (plaintiff) did not include the functionality argument. The responding party, PwC, stated that it was not possible to produce the metadata because it had been deleted from their computer system prior to the commencement of the action–it no longer existed. Apparently, they were referring to system-type metadata in making this argument.
In any event, the Court would not compel the production of metadata in this case without a showing of good cause, and none was given. In the Court’s words:
In light of the dubious value of metadata and plaintiffs’ total failure to explain its relevance to the claims and defenses in this action, plaintiffs’ application to compel its production is denied. Given the advanced stage of discovery in this litigation and the absence of any showing that production of metadata would serve any useful purpose, I am left with the strong sense that ordering the production of metadata would not shed any light on any of the claims or defenses in this action.
Kingsway at *6.
Although I am obviously a “native sympathizer,” I completely agree with Judge Pitman’s holding. In some cases metadata is important, in others it is not. In most cases the producing party should not be required to make a second production of metadata where the requesting party failed to request it in the first place, especially when, as here, they cannot show good cause.
Armor Screen Corporation v. Storm Catcher, Inc.
The next case arises in West Palm Beach, Florida. Armor Screen Corporation v. Storm Catcher, Inc., 2008 WL 5262707 (S.D.Fla. Dec. 17, 2008). Here Magistrate Judge Ann E. Vitunac considered a situation where defendants received a production in native format of reports used by plaintiff’s experts. The defendants complained that this production in native format was not “reasonably usable” under the rules, and demanded that plaintiff reproduce the information again in “hard-copy print-outs of the electronic SPSS data, including all ‘metadata’.” Id. at *2.
This kind of request has to put a smile on any experienced e-discovery professional, even a die-hard Tiff and load type. The defendants object to a native production and ask for a paper print-out of all of the computer files, including even a paper print-out of all metadata! They did not even ask for Tiff and load. They asked for paper and more paper! Electronic discovery, much like a wild jungle, can be a very scary place for some. They want everything made into paper.
Here is the Court’s, I think, very correct analysis of this bizarre request:
Defendants ask the Court to compel Plaintiff to produce hard-copy print-outs of the data relied upon by Dr. Cowan in his expert report. In an affidavit by Dr. Cowan, attached to Plaintiff’s Response, Dr. Cowan states that he conducted his survey electronically, no paper copies were ever generated, and the electronic survey data was produced in the same format in which he received and analyzed it, i.e. *.sav files. [Footnote omitted.] Dr. Cowan represents that hard-copy print-outs of the data would be an expensive, time-consuming process prone to error.
* * *
[T]he Court finds that the production to Defendants of the survey data relied upon by Plaintiff’s expert Dr. Cowan in the form of electronic SPSS data files complies with the requirements of Rule 34 and this Court’s prior Order (DE 153) requiring Plaintiff to produce such data in “a reasonably accessible format.” Consequently, the Court will not compel Plaintiff to produce hard-copy print-outs of the electronic data relied upon by Dr. Cowan and already produced to Defendants in the form of electronic SPSS files.
Id. at *3.
The plaintiffs argued, and I am inclined to agree, that the defendants’ motion was frivolous and they should be awarded their costs. The Court was obviously also concerned about the defendants’ motion here as it held that it would reserve ruling on the plaintiff’s request for an award of fees:
The Court will hold a hearing at the close of discovery to determine whether the Motion “was substantially justified or other circumstances make an award of fees unjust.” Fed.R.Civ.P. 37(a)(5)(B).
Id. at *3.
By the way, Judge Vitunac here showed strong research resourcefulness and analytic skills to understand the technicalities of what was going on here. Footnote 1 of her opinion shows that she did an Internet search to determine what a “.sav” data file means. This was information that, by all appearances, completely eluded the defendants. Judge Vitunac correctly found a file extension resources website and was able to confirm Dr. Cowan’s testimony that “.sav” data files are a common data format utilized by many statistical packages for social sciences programs (SPSS) and can be opened by various standard statistical computer packages. Kudos to Judge Vitunac and her research clerks for that one!
Superior Production Partnership v. Gordon Auto Body Parts Co., Ltd.
The last case comes out of Ohio. Superior Production Partnership v. Gordon Auto Body Parts Co. Ltd., 2008 WL 5111184 (S.D.Ohio Dec. 2, 2008). Magistrate Judge Terence P. Kemp considered a motion by plaintiff, PBSI, to compel the defendants to produce documents in native format. Once again, the defendants here had already produced the documents in hard-copy, even though the parties agreed that they were maintained by defendants in some sort of electronic format.
The defendants responded to the request for a second production in native format by claiming that the computer system “does not maintain ‘metadata’ that would provide additional information about the document beyond that shown in the hard-copy.” Id. at *1. The court notes that defendants did not address the secondary issue as to “the relative ease or difficulty of producing in native format.” Id.
Unlike the other cases discussed here, the opinion nowhere mentions whether or not native file format was requested by PBSI, so I assume the request was silent as to form. This, of course, triggers the provisions of Rule 34(b)(2)(E)(ii), which allow a responding party to produce its ESI in either “ordinarily maintained” form, in other words, “native,” or in a “reasonably useable” form. The question here is easy to decide because the defendant produced in paper, not in Tiff and load, where at least some metadata would be included and search capacity preserved. Here is how Judge Kemp dealt with PBSI’s belated request for native production:
Federal Rule of Civil Procedure 26, as amended, expresses a preference for the production of electronically stored information in its native format. As PBSI points out in its reply brief, the utility of having documents produced in this format is not limited to being able to view any metadata which might be embedded in the electronic document but not visible on the hard copy. It is often more convenient for the requesting party to receive the documents electronically in order to be able to store them and manipulate them during the litigation process. Here, there do not appear to be any obstacles to the production of the documents in native format, and PBSI has articulated at least one good reason to have them produced in that fashion. Under these circumstances, the Court will direct Gordon to produce documents in their native format.
Id.
The court here did not consider cost shifting and did not criticize PBSI for not specifically requesting native to begin with. Other courts may not be so kind. Thus it remains a good idea to specifically request native with metadata, if that is what you want, and do so at the earliest opportunity. As Judge Mass correctly noted in Aguilar:
There is a clear pattern in the case law concerning motions to compel the production of metadata. Courts generally have ordered the production of metadata when it is sought in the initial document request and the producing party has not yet produced the documents in any form. (citations omitted) … On the other hand, if metadata is not sought in the initial document request, and particularly if the producing party already has produced the documents in another form, courts tend to deny later requests, often concluding that the metadata is not relevant.
Aguilar v. Immigration and Customs Enforcement Div. of U.S. Dept. of Homeland Sec., supra at *7.
Conclusion
So we come back to the original question, should you go native? My view remains a emphatic yes! The reason is simple: native is usually the most efficient and costs effective manner for ESI review and production. Usually the best, but not always. The colonialists are right, there are still many obstacles to full native review of all types of ESI in all circumstances, but these obstacles can be overcome with better technology and collaboration.
The polestar here, as always, is the balance between cost and risk management. If native saves you time and money, and improves functionality to boot, then why not request it? We have seen one negative answer to this question in ClassicStar Mare Lease Litigation. You might not have the software needed to read the native files. The cost to purchase the software might well exceed the potential cost and functionality savings of native. Other reasons to resist the move to native might be limitations built into your own systems. You may be setup for Tiff review, but not at all for native. Even if set up for native, the review in Tiff might be faster and thus make up for any conversion costs and delays. These limitations are, however, fast becoming obsolete. Most review software now includes dual modes, both native and Tiff. Still, an economic analysis may show that in some cases today, Tiff review and production is cheaper than native. But I predict this will change as the industry, which is still heavily invested in Tiff and load, bows to the inevitable and moves its focus to native. As vendors change, and new products develop, the circumstances where Tiff is cheaper will be fewer and farther between.
Even though a native format production may often be better for the requesting party, in some circumstances a native production may still be too burdensome to the responding party, or altogether impossible. For example, in the case of some custom software or databases, it might be impossible for an export of the relevant data requested, or if possible to export, impossible for any other party to read. The producing party may be the only one in the world with the software or systems needed to read the information. The only solution may be a non-starter from the producing party’s perspective, allowing the requesting party to use the producing party’s own proprietary systems. See eg. Aguilar v. Immigration and Customs Enforcement Div. of U.S. Dept. of Homeland Sec., supra at *14-*15 (government ordered to provide a demonstration of confidential law enforcement database to plaintiffs’ attorneys and expert).
Another more common example concerns confidential and privileged information. How do you stamp an electronic document with a confidentiality legend? How do you redact information contained in an electronic file? As mentioned in the discussion of the ClassicStar Mare Lease Litigation case, in essence you now have to alter the file and create a new file with the confidential data omitted. The alternative is adding legends, but that also changes the file and is often not an acceptable solution for a variety of reasons, especially where sensitive information is involved. Depending on the circumstances, the native file redactions may be too expensive and burdensome upon the responding party. Since the Tiff and load alternative to native is now usually an easier and less expensive setup for partial redaction of files and thus protection of confidentiality, if a requesting party wants to stay native with confidential files, they may well have to pay for the added expense. Still, even here, I predict new software innovations will arise to meet this challenge.
Aside from these few caveats, in most projects there is no need for the extra busywork of converting native to image files and creation of load files. The wise words of Paul Gauguin apply to this situation: “Stressing output is the key to improving productivity, while looking to increase activity can result in just the opposite.” Yes, our past may be paper, and our present a confused mess, but the future more productive world belongs to native.
Hmm…
To redact in a paper paradigm, I create a copy and black out privileged content – in effect creating a new paper document. To redact in the ‘TIFF & Load’ paradigm, I have to create a new file by printing the native to a TIFF image. Why is it objectionable to perform a digital redaction that creates a new file? At some level, it is all the same thing… Redaction is always something different and less than the original.
Excellent article – from both an update and educational point of view – and one our team will most certainly use as a reference in answering questions on the oft considered topic “Should I Go Native”.
Thanks.
[…] e-discovery) extensively analyzed this opinion and three others involving native format issues in this post. Hearkening to the native-art motif of his post, he quoted Gauguin to summarize the ruling: “A […]
I agree with Mr. Kellerman … once you redact you change the original so does the format really matter? A key takeaway for me here was the idea that firms must invest in some type of “specialized” software to review and produce native files. It seems to me this barrier can be overcome by leveraging a SaaS solution to review and redact.
I recently wrote a white paper that talks about how to spec out a web based solution (you can find it at http://www.anacomp.com/pdf/wp/Hosted_Lit_Support_whitepaper.pdf. It’s not a sales pitch: the folks at Anacomp have posted it on their web site since they have a product that they feel fits the criterion I set out)
I’m curious, Ralph, what you think about that as an alternative to specilaized software?
[…] 25, 2009 Filed under: 1 | Ralph Losey has an excellent post this week on native files called Should You Go Native ? As always, Ralph has a very thorough, scholarly approach to the issue and focuses in on […]
Glad this Blog provoked a lot of comments as it was difficult to write. SaaS, by which you are referring to “Software as a Service,” can be a viable solution for some things, sure. Why not? Whatever works within the budget. Of course, there is still a cost for renting software by the project too, iw – SaaS is not freeware.
“Going native” has been a touchy subject for years, even when metadata was generally thought not to be discoverable such that “native application, native review” was not such a big deal as it is now as a source for spoliation.
My earlier comment also probably failed to reflect that it is a great article – native redaction is a minor issue in many ways once you get past the FUD and the fact that the tools are currently limited to non-existance.
Specialty software will continue to be a trend – licensed, hosted or SaaS’d but it is not the only answer. The most difficult problems with respect to “going native” are the process discipline and infrastruture necessary to support the effort. It is a constant struggle for law firms and even old-school EDD vendors across the board to keep up and adapt to the rapidly developing business necessity of keeping evidentiary data sequestered, managed and unspoiled.
The time and cost considerations for redactions don’t always favor the TIFF approach. For example, large spreadsheets with responsive and confidential data interspersed can be incredibly time-consuming to redact in an imaged format. Working in a native format, it would be possible to extract any responsive information that’s indexed in the spreadsheet (perhaps by product ID or invoice number) but not grouped together in the original document. Whether this produces significant time savings over the whole project depends on the quantity of these kinds of documents, but I’ve seen clients who regularly use Excel spreadsheets as the functional equivalents of medium-sized databases.
A new case has come out exemplifying the transition from past to present, where the court required the producing party to convert paper documents to Tiff and load. Proctor & Gamble Co. v. S.C. Johnson & Son, Inc. 2009 WL 440543 (E.D.Tex., Feb. 19, 2008).
The district court rejected the producing party’s argument that when it agreed to produce in Tiff, that it did not also agree to OCR the paper records. In other words, it tried to separate the Tiff from the load file. The OCR index in the Tiff file is what makes the Tiff files searchable. Without that, the Tiff files are no better than paper. The producing party did not really argue that point, but did seek to have the requesting party pay for the OCR load file creation expense. The court made short work of the cost-shifting argument using the seven factors of Zubulake v. UBS Warburg LLC, 217 F.R.D. 309 (S.D.N.Y.20030. The producing party made a poor showing here and so this decision does not rule out possible cost-shifting in other cases.
It is stories (and cases) like this that make me cringe. Lawyers and judges have got to learn the difference between EXTRACTED text and OCR text. Taking perfectly good digital content, printing it to a computer ‘picture’ and then asking the computer to read it and turn it back into searchable content is LUNACY!
I don’t think there is a vendor or conversion software out there that doesn’t write the extracted text to an intermediate Access or SQL database for use ‘just in case’ two years down the road.
Hey Ralph, Great Article. Keep them coming. I hope you and your family are doing well. Love the video of John Cleese.
Nice topic Ralph. Just when everyone thought it was safe to get back into the water!
[…] producing 200,000 unsearchable Tiff files. See Story of the Poor Bunny and my prior article Should You “Go Native”? These actions forced the court to have two evidentiary hearings concerning what was supposedly […]