Bedrock Computer Technologies, LLC v. Softlayer Technologies, Inc. et al

Filing 241

SUR-REPLY to Reply to Response to Motion re #209 MOTION TO CLARIFY THE AGREED PROTECTIVE ORDER re #170 Protective Order MOTION TO CLARIFY THE AGREED PROTECTIVE ORDER re #170 Protective Order filed by Google Inc.. (Briggs, Todd)

UNITED STATES DISTRICT COURT EASTERN DISTRICT OF TEXAS TYLER DIVISION BEDROCK COMPUTER TECHNOLOGIES LLC, Plaintiff, v. SOFTLAYER TECHNOLOGIES, INC., CITIWARE TECHNOLOGY SOLUTIONS, LLC, GOOGLE INC., YAHOO! INC., MYSPACE INC., AMAZON.COM INC., PAYPAL INC., MATCH.COM, LLC., AOL LLC, and CME GROUP INC., Defendants. ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )

CASE NO. 6:09­CV­00269 Hon. Leonard E. Davis

JURY TRIAL DEMANDED

GOOGLE'S SURREPLY IN OPPOSITION TO BEDROCK'S MOTION TO CLARIFY THE AGREED PROTECTIVE ORDER

01980.51572/3546067.3

INTRODUCTION Bedrock styles its motion as one to "clarify" the Protective Order. But, in effect, what Bedrock seeks here is an order re-writing two provisions of the Protective Order governing the production of source code in this case. Bedrock negotiated and agreed to a Protective Order that prohibits making any "subsequent copies" of source code, and says that "no more than two (2) individuals [who qualify as experts] may have access to any one Defendant's source code." When Bedrock explained that it needed two additional copies of the source code and needed to show Google's source code to one additional expert, Google agreed to make reasonable accommodations and exceptions to the Protective Order.1 (Dkt. No. 223­1 at 2.) Instead of accepting Google's offer (or even responding to it before filing this motion), Bedrock filed the instant motion asking the Court for an Order that would completely eliminate both restrictions. The Court should reject Bedrock's overreaching. ARGUMENT I. A SECOND PRINTOUT IS A PROHIBITED "SUBSEQUENT COPY." The Protective Order plainly says that "no subsequent copies shall be made." Bedrock narrowly interprets this simple prohibition by grafting on its own narrow explanation ­ found nowhere in the Protective Order ­ that it only applies to photocopying or scanning the source code into electronic format. (Reply at 1-2.) But a "subsequent copy" is no less a "subsequent copy" because it was printed rather than photocopied or scanned. By Bedrock's logic, it would

Given that Bedrock and Google also had an ongoing dispute regarding source code production, Google limited its offer to source code that had already been produced, saying that "[b]ecause Google does not know the amount of source code at issue here, Google cannot agree to allow its code to be duplicated and sent all around the country." (Dkt. No. 223­1 at 2.) In the same breath, however, Google made clear than when, and if, it produced additional code, it would be willing to revisit the issue at that time. (Id.) Google never "attempt[ed] to force Bedrock to concede the non­discoverability of Non­Produced Source Code." (Reply at 4 n.1.)
01980.51572/3546067.3

1

-1-

be free to end­run around the "subsequent copies" prohibition by any number of creative means so long as it does not photocopy or scan it. For example, under any reasonable interpretation, Bedrock should not be allowed to transcribe the source code by hand into a new document or have a stenographer take down the source code that someone dictates to them orally. Both of these examples would be creating a subsequent copy. Bedrock's unduly narrow interpretation of "subsequent copies," however, would apparently allow it to employ these and other creative strategies so long as they do not involve photocopying or scanning. Such a narrow reading of the plain prohibition on "subsequent copies" cannot be countenanced. The Protective Order places many stringent restrictions on the production of source code ­ and for good reason. Although much of the source code at issue in this case is open source, Google has modified this code in its own way. Thus, Google's source code is a highly confidential, proprietary, and trade secret business asset. See, e.g., Adobe Sys. Inc. v. Macromedia, Inc., No. 00­743­JJF, 2001 U.S. Dist. LEXIS 18630, at *3 (D. Del. Nov. 5, 2001) (holding that source code is "of critical importance to [Defendant's] business and must be provided the highest form of protection a court can provide"). The parties negotiated the source code provisions of the Protective Order to ensure that such highly sensitive and valuable information would be easier to track and to minimize the risk of unauthorized use, copying and dissemination. Accord id. at *2-3 (acknowledging that production of source code in paper rather than encrypted electronic form "although possibly somewhat burdensome" was not "unnecessarily onerous"). To this end, the parties negotiated the two provisions at issue in the context of a necessarily rigid framework governing the production and handling of source code that requires, among other things, that: · Inspection is to occur on "two stand-alone, non-networked personal computers . . . in a secure room at a secure facility." ¶ 8(B)(i)-(ii).

01980.51572/3546067.3

-2-

· · · ·

"Proper identification of all authorized persons shall be provided prior to any access to the secure facility or the Source Code Computers." ¶ 8(B)(x). "The receiving party will limit its requests for paper copies of the source code to source code that is reasonably related to this case." ¶ 8(B)(xi). "All printed source code shall be logged by the receiving party to facilitate destruction certification." ¶ 8(B)(xi). "[A]ll printed copies of the source code maintained by the receiving party must be kept in a locked storage container when not in use." ¶ 8(B)(xi).

The totality of the restrictions demonstrate the parties' understanding that source code is a special sort of material that should be protected to the fullest extent possible. See, e.g., Rowan Companies, Inc. v. Wilmington Trust, 305 S.W.3d 698 (Tex. Ct. App. 2009) ("Contractual provisions are read in a manner that effectuates the contract's spirit and purpose, considered as a whole and interpreted so as to harmonize and give meaning to all of its provisions.") The Protective Order lays out a simple enough framework. Bedrock's counsel and experts can inspect Google's source code to determine which portions are reasonably related to this case. Once they identify the relevant parts, they can print out a copy. That copy is to be maintained by Bedrock's counsel in a locked storage container when not in use. Bedrock's counsel and its two experts can review the printed code as much or as frequently as they want at Bedrock's counsel's office. This agreed-upon framework is not unnecessarily onerous considering the crucial competitive importance of the information to Google. Bedrock fundamentally misunderstands the purpose of the Protective Order's source code provisions. It explains the prejudice it allegedly faces: its experts would have to share a single copy of source code. But that was the intended framework. Bedrock confuses inconvenience with prejudice. The parties agreed to the Protective Order source code provisions to safeguard against the inadvertent disclosure of Google's crown jewels ­ not for Bedrock's convenience. Thus, it is concerning to say the least, that Bedrock admits it has unilaterally allowed its experts

01980.51572/3546067.3

-3-

to "share via mail the single copy of the source code so far produced." (Reply at 5.) By its terms, the Protective Order does not allow Bedrock's experts to take the source code printouts into their possession or send them through the mail: "[A]ll printed copies of the source code maintained by the receiving party must be kept in a locked storage container when not in use." (Dkt. No. 170 at ¶ 8(B)(xi).) Now, after Bedrock agreed to this reasonable framework, it appears to be more concerned with its convenience than with adhering to the agreed procedure to protect Google's sensitive business assets. Bedrock should play by rules to which it agreed. II. BEDROCK CANNOT RECONCILE THE 14­DAY NOTIFICATION AND OBJECTION PROCEDURE WITH ITS READING OF PARAGRAPH 8(B)(IX). The fourteen day notification and objection procedure in Paragraph 8(B)(ix) was intended to limit Bedrock's experts' access to Google's source code. In its Reply, Bedrock goes through great pains to avoid addressing the incompatible notification and objection procedures that Google pointed out in its Response brief. (See Google's Response at 6.) Although Bedrock reproduces the first half of Paragraph 8(B)(ix) three times in just two pages of its Reply, it does not include the second half of Paragraph 8(B)(ix) nor explain how it can be reconciled with its interpretation. (Reply at 3­4.) The second half of Paragraph 8(B)(ix) goes on to state that: For each day that counsel for the receiving party requests a review of the Source Code Computers, it must give at least three business days (and at least 72 hours) notice to the counsel for the producing party that it will be sending individual(s) authorized to review the source code made available on the Source Code Computers. (Dkt. No. 170 at ¶ 8(B)(ix).) This sentence describes Bedrock's disclosure obligations prior to sending experts to access source code at the inspection site. But in addition to this notification requirement, Paragraph 8(B)(ix) goes on to require an additional fourteen day notification and objection procedure for any expert who will be given access to source code, regardless of whether they will access the physical Source Code Computers:

01980.51572/3546067.3

-4-

The receiving party shall identify all individuals who will be given access to the source code at least fourteen days prior to any inspection; after that identification, the producing party may object to providing source code access to any persons so identified. (Id. (emphasis added).) Bedrock cannot reconcile this procedure with its justification for restricting the reach of Paragraph 8(B)(ix) to access to physical source code computers. Bedrock does not rebut Google's observation that there is no reason to impose a fourteen day notification period if the intent were to minimize visitors to the inspection facility, as Bedrock has argued. Thus, the apparent purpose of the notification and objection procedure is to allow Defendants to know which experts will have access to their source code and object, if necessary. In short, Paragraph 8(B)(ix) provides an additional layer of security by providing a second opportunity to review and object to the two experts which Bedrock designates to review source code. Bedrock's argument that under Google's interpretation, "no one other than these two experts would be able to see the source code printouts, whether in Bedrock's counsel's offices, in motions practice, at depositions, or at trial" is inaccurate. (Reply at 3.) Google has never taken this position. (See Google's Response at 6­7.) And, paragraph 8(B)(ix) only places limitations on disclosure of source code to technical advisors, consultants, and testifying experts. It does not exclude other categories of persons authorized under the Protective Order from viewing source code. The Protective Order plainly limits the number of experts who can view Google's source code to two. Bedrock should be held to that plain language. CONCLUSION For the foregoing reasons, Defendant Google respectfully asks the Court to reject Bedrock's interpretations of the Protective Order and instead adopt Google's clarifications that 1) only permit Bedrock to print a single copy of source code, and 2) limits source code access to only two of Bedrock's technical advisors, consultants, and testifying experts.

01980.51572/3546067.3

-5-

Dated: June 28, 2010 Respectfully submitted, By: /s/ Todd M. Briggs Todd M. Briggs Claude M. Stern Todd M. Briggs Evette D. Pennypacker QUINN EMANUEL URQUHART & SULLIVAN, LLP 555 Twin Dolphin Dr., Suite 560 Redwood Shores, CA 94065 Telephone: 650­801­5000 Facsimile: 650­801­5100 Email: [e-mail] Email: [e-mail] Email: [e-mail] Michael E. Jones State Bar No. 10929400 POTTER MINTON 110 N. College Tyler, Texas 75702 Telephone: (903) 597­8311 Facsimile: (903) 593­0846 Email: [e-mail] Attorneys for Defendants Google and Match.com LLC

01980.51572/3546067.3

-6-

CERTIFICATE OF SERVICE The undersigned hereby certifies that counsel of record who are deemed to have consented to electronic service are being served with a copy of this motion, via the Court's CM/ECF system per Local Rule CV­5(a)(3) and electronic mail on June 28, 2010. Any other counsel of record was served via First Class Mail. Date: June 28, 2010 /s/ Todd M. Briggs Todd M. Briggs

01980.51572/3546067.3

-7-