CA Inc v Independent Systems Integrators Pty Limited (No 2)
[2009] FCA 900
•18 August 2009
FEDERAL COURT OF AUSTRALIA
CA Inc v Independent Systems Integrators Pty Limited (No 2) [2009] FCA 900
CA INC and CA (PACIFIC) PTY LIMITED v INDEPENDENT SYSTEMS INTERGRATORS PTY LIMITED
NSD 1572 of 2008
PERRAM J
18 AUGUST 2009
SYDNEY
IN THE FEDERAL COURT OF AUSTRALIA
NEW SOUTH WALES DISTRICT REGISTRY
GENERAL DIVISION
NSD 1572 of 2008
BETWEEN: CA INC
First ApplicantCA (PACIFIC) PTY LIMITED
Second ApplicantAND: INDEPENDENT SYSTEMS INTEGRATORS PTY LTD ACN 003 152 225
Respondent
JUDGE:
PERRAM J
DATE OF ORDER:
18 AUGUST 2009
WHERE MADE:
SYDNEY
THE COURT ORDERS THAT:
1.The parties are to bring in short minutes of order reflecting these reasons.
2.Costs reserved.
3.The matter be stood over for further directions on Tuesday 25 August 2009.
Note:Settlement and entry of orders is dealt with in Order 36 of the Federal Court Rules.
The text of entered orders can be located using eSearch on the Court’s website.
IN THE FEDERAL COURT OF AUSTRALIA
NEW SOUTH WALES DISTRICT REGISTRY
GENERAL DIVISION
NSD 1572 of 2008
BETWEEN: CA INC
First ApplicantCA (PACIFIC) PTY LIMITED
Second ApplicantAND: INDEPENDENT SYSTEMS INTEGRATORS PTY LTD ACN 003 152 225
Respondent
JUDGE:
PERRAM J
DATE:
18 AUGUST 2009
PLACE:
SYDNEY
REASONS FOR JUDGMENT
Introduction
This is an application for preliminary discovery. The two applicants, who I will together call CA, conduct business as an international IT management software company. CA is a very substantial organisation with many software products and services amongst its various business lines. Amongst the products it delivers are two known as CA Datacom and CA Ideal. These software products are installed on mainframe computers and the clients who use them include very large organisations such as the US Customs Service. In this country they have included, as will become apparent, Macquarie Bank Limited.
CA Datacom is a program which manages large databases. It is installed by CA customers on mainframes. The programs operating on such systems can be visualised as working at different levels. At the highest level are those programs which interact directly with the customer’s own staff and users. These are generally known as applications. At the lowest level is a set of programs usually referred to as the operating system, which carry out the functions of running the mainframe at its most basic level. CA Datacom exists in between these two levels. It carries out the processes and steps which are necessary to manage the databases in its care. However, the staff and users of particular customers do not use it directly. Instead they interact with the customer’s own specifically designed applications which, in turn, deal with CA Datacom.
The customers’ applications can be written in any higher level computer language which runs on the mainframe such as COBOL. Any customer application written in these languages needs to be able to communicate effectively with CA Datacom itself. To that end the customers of CA Datacom are given access to proprietary information belonging to CA to permit their own programmers to design their applications in a way which fosters that communication. For those inclined towards total packages, CA also produces its own computer language which customers can use for writing their own applications. This product, or language, is called CA Ideal. Presumably, the advantage of using CA Ideal is that it is specifically designed for ease of interaction with CA Datacom.
The market for software that manages large databases on mainframes is not closed and CA Datacom is not alone in that market. It faces competition from a product made by IBM called DB2. CA Datacom and DB2 are both sophisticated products. However, the ways in which the two competing products structure and manage the data for which they are responsible are not the same and they are not compatible. Data stored in a form comprehensible to CA Datacom cannot be managed by DB2, or vice versa.
From time to time, organisations using one brand of database management software might wish to switch to another. Two obstacles lie in the path of an organisation in that position. First, it is necessary that all of the data managed by the first product be translated into a format compatible with the second. Secondly, all of the customer’s applications which formerly interacted with the first database product need to be re-written so that they can interact with the second. Both of these steps can be onerous; the first, often enough because of the sheer size of the databases in question; the second, because customers’ applications are often the result of many years of refinement. A further practical difficulty exists. Frequently, the databases in question are extremely large and of a kind whose unavailability can be tolerated only for very short periods of time. The time therefore for large scale data migration is generally very limited.
There are thus created the economic incentives for the coming into existence of the respondent’s suite of products called “2BDB2”. For present purposes, three elements of the suite are relevant. The first is a program called the 2BDB2 Datacom Data Converter. I do not apprehend this product to be in dispute and mention it only to increase the coherence of the present account. The Datacom Data converter program takes data managed by CA Datacom and, as the name suggests, converts it into a format which can be managed by IBM’s DB2 database management program. The conversion process may be extensive and the converter permits partial conversion or conversion in steps. This last quality should be noted as it is of particular significance.
The second element in the suite is the 2BDB2 Datacom Transparency product. It interposes itself within the customer’s mainframe in such a way that the customer’s applications communicate with it rather than with CA Datacom. Putting the matter somewhat loosely Datacom Transparency is a bilingual program with a “trick”. It is bilingual because it can understand the CA Datacom statements made by the customer’s applications and it can translate them into statements which can be understood by DB2 (and vice versa). The trick is that the program knows which parts of the customer’s databases have been converted by the Datacom Data Converter to DB2 format and which have not. When Database Transparency identifies that a request has been made by a customer’s application which relates to data still being managed by the CA Datacom software, it simply passes the request on to CA Datacom. When the CA Datacom software replies it passes that reply back to the customer’s application.
When CA Datacom Transparency detects that the customer’s application is dealing with data which has already been converted to DB2 format by the Datacom Data Converter, it translates the request – which originally assumes that the recipient is CA Datacom – into a request which will make sense to DB2. It then passes the request on. When DB2 responds CA Datacom Transparency reinterprets the output back into a format which emulates the response which would have come from CA Datacom.
Under neither scenario is the customer’s application “aware” of the presence of Datacom Transparency. Together, CA Datacom Data Converter and Datacom Transparency enable a customer to convert parts of its database to DB2 format without having to rewrite any of its applications. The partial conversion of the databases is desirable because it allows a cautious approach to be adopted to a large undertaking thus permitting ease of troubleshooting. It also allows database conversion to proceed in small steps which do not require the large scale shutting down of the system.
The third item in the suite is called 2BDB2 Ideal. This product is able to convert customer applications which have been written in CA’s Ideal language into COBOL applications which will operate in a DB2 environment.
Each of these three products facilitates migration of data from a CA Datacom environment to a DB2 environment. A customer whose applications are written in Ideal needs only the Datacom Data Converter and 2BDB2 Ideal to carry out the migration. A customer whose applications are written in any other language needs the Datacom Data Converter and Datacom Transparency programs.
The migration of customers from a CA Datacom environment to a DB2 environment is a state of affairs to which CA is naturally disinclined. That disinclination has provoked in CA a curiosity as to how 2BDB2 operates. The slaking of that curiosity gives rise to the present circumstances about which it is now necessary to say a few words.
Facts
2BDB2 is owned and marketed by the respondent ISI which is an Australian company specialising in the provision of information technology services. ISI acquired 2BDB2 from Macquarie Bank Limited (“MBL”) in 2002. Prior to that, ISI held a licence from MBL to use and market 2BDB2 and had done so since 1999. It would appear that 2BDB2 was created by MBL between 1996 and 1998. MBL developed 2BDB2 using its own staff and contractors. Those staff and contractors had extensive experience with CA Datacom and CA Ideal. The principal contractor to MBL in the development process was Mr Peter Richards. In evidence before me it was said that Mr Richards was the principal author of the original 2BDB2 code and had written or supervised all subsequent modifications of that code. The precise commercial relationship between ISI, which owns 2BDB2, and Mr Richards, who it would seem is the creative force behind it, was not laid bare by the evidence before me. Mr Richards did not himself give evidence but a copy of his curriculum vitae was in evidence. Three entries in it throw light, I think, on the progress and development of 2BDB2. They are:
Macquarie Bank Limited 1996-1997
Mr Richards returned to the Macquarie Bank to assist in the conversion of the Banks major MANTEC applications (Investment Services) from Datacom to DB2. This involved the conversion of more than 800 PL/1 application programs running in CICS and Batch via an automated workbench. The code then required testing, debugging and tuning. He was the main resource assigned to these three tasks as well as planning and implementing the cutover (and backout) strategy.
Macquarie Bank Limited 1997-1998
Mr Richards returned to the Macquarie Bank to assist in the conversion of the Banks remaining systems from Datacom to BD2 using an innovative technique that minimised the conversion effort by providing interface modules to transparently convert the access from Datacom to DB2. The bank successfully converted all remaining applications to DB2 using this interface in a fraction of the time that would have been required for source code conversion. This conversion encompassed seven application systems, several thousand application programs and hundreds of database tables.
2BDB2 Development 1999-2009
Mr Richards continued to develop the transparent database access routines which have now developed into the 2BDB2/Datacom product which is being installed in a number of sites in Australia and the USA and is being evaluated in various sites around the world. Development, installation and support of this product and the companion 2DBD2/VSAM product has occupied him full time since the end of 1998.
CA was not, at first, aware of 2BDB2 but became cognisant of it in about 2002 or 2003. At that time, one of ISI’s “customer advocates” sent an email to a number of CA clients indicating that it made sense to convert to DB2 because CA Datacom was “dying” and ISI’s 2BDB2 products would facilitate the necessary departure from a dwindling product. This was not well received by CA who required of, and obtained from, ISI a retraction.
During 2007 CA became aware of difficulties within a particular customer’s CA Datacom environment. Neither the identity of that client nor the nature of the problem encountered are presently material. What is material, however, is that 2BDB2 had been installed on the customer’s system and that the problem only arose whilst it was installed, vanishing when it was not. CA attended the customer’s premises and, inter alia, took a memory dump, a concept not explained in the evidence but which I take it to be a snapshot of the critical parts of the mainframe’s memory at the moment of the problem’s occurrence.
Analysis of these dumps by engineers within CA suggested that 2BDB2 was aware of a number of aspects of the ways in which CA Datacom operated which were either:
(a)explained only in documentation provided to CA’s licensees which were confidential and subject to copyright; or
(b)not documented anywhere outside CA and which were the subject of copyright.
CA’s suspicions
Evidence was given on CA’s behalf that it was very unlikely that those who put together 2BDB2 – that is, Mr Richards and MBL – could have done so either without directly accessing the source code or reverse engineering that code. CA accordingly submitted that there was reason to believe that it had, or might have, the right to obtain relief against ISI. There were two steps to this conclusion. The first was that it was the owner of the copyright in CA Datacom and CA Ideal and that the information associated with the functioning of those programs was a trade secret. The second was that an inference could be drawn that 2BDB2 had been created using CA’s confidential information or by infringing its copyright in the source code.
That submission requires, I think, a little explanation. No doubt, the direct copying by ISI (or MBL) of CA’s programs would infringe the copyright in those programs. It is less obvious that a reverse engineering of CA’s programs would constitute an infringement of CA’s copyright in those programs. This is not the occasion to resolve that debate but two propositions seem arguable. First, the effect of the extension of the definition of “computer program” in s 10 of the Copyright Act 1968 (Cth) brought about by the Copyright Amendment (Digital Agenda) Act 2000 (Cth) together with the High Court’s decision in Data Access Corp v Powerflex Services Pty Ltd (1999) 202 CLR 1 may mean that the reverse engineering of a source code can infringe copyright, although this is not clear. Secondly, there may, in any event, be an action maintainable for a breach of confidence in such circumstances, particularly where the reverse engineering takes place contrary to a contractual stipulation prohibiting it. The licence between CA and MBL appeared to contain such a stipulation. Clauses 2.1 and 2.2 of that licence provided:
2.1The Licensed Program and all related documentation are the trade secrets and proprietary property of CA and embody or contain useful and valuable information which is confidential to CA. The Licensee undertakes that it will use its best endeavours to keep the Licensed Program and all related documentation in safe custody and to restrict physical access to the media on which the Licensed Program is recorded and the related documentation to those of its employees who reasonably need such access in order to use the Licensed Program in accordance with this Agreement. Licensee will not remove or destroy any proprietary markings of CA. No disclosure of related documentation or of any other information relating to the operation of the Licensed Program shall be made by the Licensee or any of its employees to any third party not previously authorised to receive such information under written agreement with CA.
2.2The Licensee further undertakes that it and its employees will not change, disassemble, decompile or otherwise reverse engineer the Licensed Program in order to create or attempt to create or corresponding source code and, except as authorised by this Agreement, will not make or permit others to make copies or reproduce any part of the Licensed Program or related documentation in any form without the prior written consent of CA.
(emphasis added)
In any event, no argument was advanced to me that preliminary discovery should be declined on the basis that reverse engineering of software could not give rise to an action for breach of copyright.
Preliminary Discovery
Traditionally, discovery was not available against a non-party in order to determine whether to commence a proceeding against that party. However, this Court’s rules were amended over 20 years ago to insert Order 15A. Rule 6 of that order provides:
Discovery from prospective respondent
Where:
(a)there is reasonable cause to believe that the applicant has or may have the right to obtain relief in the Court from a person whose description has been ascertained;
(b)after making all reasonable inquiries, the applicant has not sufficient information to enable a decision to be made whether to commence a proceeding in the Court to obtain that relief; and
(c)there is reasonable cause to believe that that person has or is likely to have or has had or is likely to have had possession of any document relating to the question whether the applicant has the right to obtain the relief and that inspection of the document by the applicant would assist in making the decision;
the Court may order that that person shall make discovery to the applicant of any document of the kind described in paragraph (c).
This rule is capable of giving rise to a number of issues. However, the parties in this case joined issue only about three. These were:
(a) the reasonable cause question. ISI denied that there was reasonable cause to believe that CA had, or might have, the right to obtain relief from the Court;
(b) the reasonable inquiries question. ISI denied that CA had made all reasonable enquiries.
(c) the discretionary question. ISI submitted that the application should be refused because of delay. Even if the application were permitted, however, many of the categories sought were said to be overbroad.
First Issue: the reasonable cause question
ISI argued that there was no reasonable cause to believe that there had been any infringement of copyright or any abuse of confidential information for, broadly speaking, two factual reasons. The first was that the confidential information identified in the dumps was, in fact, publicly available on the internet. The second was that the information simply reflected certain well-known features of the mainframe environment in which CA Datacom operated.
The first point is unpersuasive. 2BDB2 is a fully operational piece of software which functions on the mainframes of large customers. As might naturally be expected, its development appears to have involved considerable time and effort on MBL and Mr Richard’s parts over a two year period. The software involved is not in a beta-testing phase as ISI’s promotional literature clearly shows. It follows, therefore, that the program is substantial and, no doubt, complex.
An appreciation of that complexity is only enhanced by a grasp of the sophistication of the function performed by 2BDB2. That function is the conversion of instructions destined for one database environment, with a particular structure and syntax, into instructions for a different database environment with a different structure and syntax. This is not to be thought a trivial undertaking. Whether the composition of 2BDB2 has proceeded from direct accessing of the CA Datacom source code or the CA Datacom manuals, or by their reverse engineering, or by collecting disparate elements of the CA Datacom source code from the internet, the process of composition as a whole is clearly a substantial one.
In that context, it is possible that every feature of CA Datacom’s functionality has found its way onto the internet and that Mr Richard’s team, through assiduous industry, has assembled each such part into 2BDB2, effectively reverse engineering it from public sources. Although I accept that this is possible, it strikes me as distinctly unlikely. It would require the conclusion that the whole of CA Datacom’s instruction set had found its way onto the internet, that Mr Richard’s team had found each such occurrence and that they also knew that that which they had found was all that there was and that they could cease searching. My lack of confidence that this is a plausible proposition is exacerbated by the fact that a number of the examples of publicly available information garnered from the internet and pointed to by ISI post-date by many years the time at which Mr Richards appears to have created 2BDB2. Of course, there may be explanations for those anachronisms. However, for present purposes I am satisfied that an inference could be drawn that Mr Richards and MBL did not construct 2BDB2 from bits and pieces of code found on the world wide web.
I do not think that the second group of matters put forward by ISI is persuasive either when properly grasped. To understand why, it is necessary to say a little about the operating environment in which CA Datacom and 2BDB2 both operate.
CA Datacom and CA Ideal execute on mainframe computers that run the IBM operating system, known as zOS and zVSE. Thus, customer applications and CA Datacom need to adapt themselves to the IBM operating system in which both dwell. That operating system, being an IBM product, is licensed by IBM to the user of the mainframe. Part of that operating system includes a “transaction manager” for online and interactive screen oriented processing with users. This object is called “CICS” or “customer information control system”. Any software running on the mainframe – and this includes customer applications and database management systems – needs to accommodate itself to CICS. Unsurprisingly IBM has produced a manual to assist programmers in writing software which will work in a CICS environment. This work revels in the title “SC 34 – 5989-01 CICS Customisation Guide”. The point made by ISI was that some of the material revealed in the dumps was merely information which could be found in this manual.
I am prepared to accept, of course, that the internal workings of CA Datacom proceed upon the basis that it must comply with the requirements of CICS. This proposition flows from the fact that it needs to work in a way which is compatible with the resident operating system. No doubt, too, 2BDB2 has to comply with the same regime. For that reason both programs are likely to reveal common elements springing from their shared need to exist in the zOS and zVSE environments and their joint burden of interacting with the CICS. The existence of such common elements is, therefore, unsurprising. More importantly, it is a phenomenon which says little about whether one program was copied from the other.
In those circumstances there are, so it seems to me, six conceivable explanations of how 2BDB2 can translate the CA Datacom oriented instructions coming from the customer’s applications into instructions which DB2 will understand. They are:
(a)direct accessing of the CA Datacom source code licensed to MBL by its agent Mr Richards;
(b)direct accessing of the CA Datacom manuals licensed to MBL by its agent Mr Richards;
(c)reverse engineering of 2BDB2 by intensive interrogation of MBL’s copy of CA Datacom in breach of MBL’s contractual obligations and possible breach of copyright (although note s 47D of the Copyright Act);
(d)composition of 2BDB2 by gathering from the internet all of CA Datacom’s instruction set and syntax;
(e)composition of 2BDB2 by examination of the IBM CICS manual; and
(f)composition of 2BDB2 by both of (d) and (e).
There is presently no evidence of (a). Mr Shuma’s evidence was that the dumps which had been examined did not suggest direct copying. Matters (b) and (c) are possible. Despite the submissions of Mr Finch SC and Ms Morgan on CA’s behalf I regard the chances of (d), (e) or (f) as vanishingly low. I conclude, therefore that one or more of (a), (b) or (c) is likely, indeed, on the preliminary information available thus far, probable.
In those circumstances, there is reasonable cause to believe that CA has or may have the right to obtain relief for damages for infringement of copyright by ISI (or MBL), equitable compensation for breach of confidence and injunctive relief to restrain further breaches. I hold that view because the evidence inclines my mind towards those conclusions: St George Bank Ltd v Rabo Australia Ltd (2004) 211 ALR 147 at 154 [26]. It follows that O 15A r 6(1) is satisfied.
Second issue: the reasonable inquiries question
O 15A r 6 requires as a pre-condition to the making of an order the conclusion that the applicant has made all reasonable inquiries. ISI submitted that CA had not complied with this requirement because:
(a) ISI had offered to provide a copy of the 2BDB2 source code to an independent third party so that the allegation of direct copying could be tested. This offer was, it was said, rejected.
(b) CA had failed to provide ISI with the content of the dumps until March 2009 thus depriving itself of the benefits of ISI’s analysis of those dumps.
I reject both of these arguments. As to the first, such an offer was indeed made on 3 June 2009 in a letter sent by ISI’s solicitors to CA’s solicitors. However, thereafter the parties were unable to agree upon the identify of the independent expert. CA suggested on 4 June 2009 that one of its former employees, a Mr Turgeon, would be suitable – a proposition rejected by ISI on 5 June 2009 on the basis of an insufficiency of independence. At the same time it nominated a Mr Melito of Dallas, Texas. It would seem that CA rejected Mr Melito on the basis of expertise.
It is not accurate, therefore, to say, as ISI submits, that the offer was rejected. Rather, the parties could not reach agreement on the identify of an independent expert. I see nothing especially unreasonable in the position of either party on that issue. What is apparent is not that CA has failed to make all reasonable inquiries, but rather, that the parties’ attempts to agree an access regime have failed. If CA’s part in that failure could be characterised as unreasonable then I might be prepared to conclude that it had eschewed an opportunity to examine the source code. But absent such a characterisation, it follows only that an impasse has been reached. In this case, whilst I can understand some sensitivity on the part of ISI to granting access to an ex-employee of CA, I do not think that CA’s nomination of that person was itself an unreasonable step to take. Indeed, having regard to the subject matter of the dispute – the CA software in question – it is readily conceivable that suitable experts must be difficult to locate. This is not to say that ISI’s position was itself unreasonable; rather, it is to emphasise that access was not obtained by reason of a failure by both parties to agree which was not unreasonable. ISI relied upon the decision of O’Loughlin J in CCA Beverages (Adelaide) Ltd v Hansford [1991] FCA 925. In that case, an offer to have documents inspected by an expert was rejected and his Honour found that this meant that there had been a failure to make all reasonable inquiries. That case may, I think, be distinguished because there was no suggestion that the offer in that case had been reasonably rejected.
As to (b), it is true that ISI only obtained access to the dumps in March 2009. It is plain enough that that occurred because the parties were not able to agree the terms of an appropriate confidentiality regime. When such a regime was finally agreed, the parties were unable to agree on the question of costs, which was then determined by me: CA Inc v Independent Systems Integrators Pty Limited (No 1) [2009] FCA 309. I found there that the confidentiality regime agreed by the parties had involved elements of compromise. For me to conclude that a failure by CA to give access to the dumps was itself the failure to make reasonable inquiries, I would need first to determine that the conduct was unreasonable. However, I do not think that the course of events I have outlined can be so characterised. It follows that the argument should be rejected.
Third issue: the discretion question
(i) Delay
ISI submitted that the power to order preliminary discovery was discretionary and that CA had delayed in bringing the application. Normally, when the requirements of O 15A r 6 are satisfied, there will be little scope for refusal of relief on discretionary grounds: Optiver Australia Pty Ltd v Tibra Trading Pty Ltd (2008) 169 FCR 435 at 445 [45] (“Optiver”). There were two elements of delay upon which ISI relied. These were:
(a) the fact that CA had first had access to the dumps in 2004; and
(b) the fact that access to those dumps was not given to ISI until March of this year.
I do not regard (a) as determinative. The precise manner in which the dumps were handled was the subject of evidence which was commercially sensitive and which need not be reproduced in these reasons. It suffices to observe that, whilst it is true that a CA engineer did have access to one of the dumps in 2004 (there were in fact, two dumps), this was in the ordinary course of assisting a customer with a technical issue. It was not until after April 2007 that CA began to countenance the possibility that 2BDB2 might have been created in inappropriate circumstances. It was only then, as part of the inquiries then set in chain, that the 2004 dump was retrieved and examined. CA submits that it attempted to meet with ISI to discuss its concerns in about April 2007. However, I do not think that the evidence directly demonstrates that. Mr Shuma, an executive of CA, gave evidence that CA was approached by ISI in April 2007 and that an attempt to convene a meeting subsequently occurred, but he does not say when that occurred. There is evidence which I accept that suggests that CA, from November 2007, sought to discuss its concerns with ISI. Those discussions were referred to in para 1.10 of a letter from CA solicitors to ISI’s then solicitors of 5 May 2008. In those circumstances, I am satisfied that CA became aware of the issue in, or shortly after, April 2007 and that it sought to engage with ISI from November 2007. I discern no substantive delay in that conduct.
I do not think (b) is a relevant species of delay. Whilst it is true that there was a delay in the provision of the dumps, I am satisfied that this was consequent upon reasonable disputation about the means of access to those dumps.
That makes it unnecessary to determine whether delay unaccompanied by prejudice to a respondent is by itself a sufficient matter to warrant the refusal of an order for preliminary discovery. The resolution of that debate would, I think, be likely to turn upon whether the rapid disposition of such an application was to be seen as an end in itself. There are some proceedings, such as applications for urgent injunctions, where that is so and there, as one would anticipate, delay is a disentitling factor even where no prejudice is shown: Carlton & United Breweries (NSW) Pty Ltd v Bond Brewing New South Wales Ltd (1987) 76 ALR 633 at 638-639 per Bowen CJ, Beaumont and Foster JJ. It may, perhaps, be doubted whether the current proceedings have that character: Optiver at 444 [41].
(ii) Overbreadth of proposed categories and oppression
It was only on the service two weeks before the hearing by ISI of the affidavit of Mr McGeorge that the role of MBL first became apparent. As a result CA altered the orders it sought. As finally propounded, the relief claimed was contained in some proposed short minutes of order.
Category (a) of those short minutes was as follows:
(a)a Document evidencing the standard terms of supply pursuant to which 2BDB2 is supplied and any warranties provided by ISI
ISI submitted that CA did not need this information to assist it in deciding whether to commence proceedings: cf. Alphapharm Pty Ltd v Eli Lilly Australia Pty Ltd (unreported 24 May 1996 at 27 per Lindgren J). I agree. I do not see how having the standard terms of 2DBD2 customer contracts could advance or impede an inquiry whose end point is the identification of copying, reverse engineering or breach of confidence. For completeness, I should record that I would not regard the standard terms as containing price information and, hence, being relevant to quantum.
Category (b) was as follows:
(b)in relation to each dump file obtained by ISI relating to 2BDB2 and relating to any of the following entities:
(i) Macquarie Bank Limited or a related entity (MBL);
(ii)ADP;
(iii) CA Stars;
any Documents containing or evidencing any analysis of the dump files;
The dumps are created to ascertain the state of the software environment. Analysis of these dumps could readily reveal discussion of integration difficulties which, in turn, may throw light on the means by which 2BDB2 was created and the manner of its operation. ISI submitted that it would take years to conduct the reviews that would be necessary to comply with this category. However, the evidence of Mr McGeorge did not support this contention. In his evidence, he gave an explanation of the steps which would need to be taken to comply with an earlier iteration of this category which referred not only to 2BDB2 but also to CA Datacom and CA Ideal. Mr McGeorge made the point that many of its clients which used CA Datacom and CA Ideal were not using 2BDB2. He estimated that it would take several man years to complete the necessary reviews of all such dumps. However, the present form of the category only refers to 2BDB2 and not to CA Datacom and CA Ideal. Of that matter, Mr McGeorge said there were about 1,000 opened and closed support requests relating to 2BDB2. An examination of those does not seem to me to be excessive.
Category (c) was as follows:
(c) … the following Documents:
(i)a copy of such of the source code and executable object code for 2BDB2 as are in the possession, custody or control of ISI, which ISI verifies to be only releases 1 and 2 of version 5 of 2BDB2; and
(ii)one copy of each version of the instructions, information, operating guide or other such Document, including the 2BDB2 user manual and 2BDB2 installation guide referred to a numbered paragraph 4 of the letter from Hicksons to Banki Haddock Fiora dated 5 June 2009, supplied to users or licensees of 2BDB2;
By the time of the hearing the parties had agreed that (c)(ii) should be granted. In my opinion (c)(i) should also be granted. It will reveal directly whether the code has been copied.
Category (d) was as follows:
(d) the following Documents:
(i)Documents embodying, evidencing or addressing the contractual arrangements between ISI on the one hand and any of MBL, ADP and CA Stars on the other hand, and including a copy of any such licence;
(ii)an accurate and complete list of ISI’s licensees in respect of 2BDB2 including the version and release number to which the licence relates;
(iii)Documents embodying, evidencing or addressing software engineering requests, support issues, or other client requests generated by MBL, ADP or CS Stars or any other person, company or organisation involving or related to actual or perceived problems arising from or caused by the interaction of ISI 2BDB2 and CA Datacom;
(iv)Documents identifying or tending to identify any of the persons referred to as the MBL staff and contractors in paragraph 11 of the first affidavit of David McGeorge sworn 27 May 2009;
(v)Documents identifying any of the persons (other than Mr Richards) who has provided development and support for 2DBD2 of the kind referred in paragraph 13 of the First McGoerge Affidavit; and
(vi)the agreements, licences and assignments referred to in paragraphs 12 and 13 of the First McGeorge Affidavit,
As to (i), I did not initially see why the contractual documentation with ADP and CA Stars would be relevant. They are both 2BDB2 customers but the terms on which they deal with ISI would not appear to bear upon the means by which 2BDB2 was created. However, the contractual documentation is likely to reveal the price of 2BDB2 and this is connected to the question of the quantum of any account of profits. It is established that material going to quantum is available on an application for preliminary discovery as it is rationally capable of bearing on the decision of whether to commence proceedings or not: Optiver at 443 [35]. For the same reason (ii) should also be allowed as it is likely to reveal the number of customers and hence – in combination with (i) – the likely quantum of any account of profits.
In the case of MBL, CA should have access to the material sought for the same reasons. Additionally, however, there is clearly a serious question about MBL’s role in the creation of 2BDB2 and the terms upon which it dealt with CA may lie at the heart of the matter. In its case, the documents sought go not just to quantum but to liability as well.
As to (iii), this material is directly necessary for gauging the question of reverse engineering. ISI submitted that it would take weeks to comply with. I do not regard that as excessive.
As to (iv)-(vi), these relate directly to the role of MBL (the licences in (vi) are the MBL licences). They will throw light on the reverse engineering allegation.
It follows that the applicant is entitled to the relief it seeks, except for category (a).
Timing and Access
ISI should have eight weeks to provide this material. Access, at this stage, is to be limited to CA’s external legal representatives. The parties agreed that if preliminary discovery was granted that access should also be granted to an independent computer expert who could assess the issues raised. CA suggested one of its former employees, a Mr Richard Turgeon. ISI object to the appointment of a person having connections with CA. I do not think that this is valid objection. Mr Turgeon does not have connections with CA. He used to have connections. He will be required to execute an appropriate confidentiality undertaking. It is, I suppose, exiguously possible that Mr Turgeon might feel moved to commit a contempt of court, having been overcome by nostalgia for his former employer, but I regard this risk as minimal. For practical reasons, the independent expert will need to have a deep knowledge of CA Datacom and CA Ideal, which tends to limit the pool of suitable persons. There have clearly been difficulties in identifying an appropriate expert as the correspondence between solicitors amply demonstrates.ISI made no direct submission to me about who the expert should be, confining itself to submissions about who it should not be.
In its written submissions, however, ISI did seek to make further submissions on the form of any orders made. The parties are to bring in short minutes of order reflecting these reasons. If there is to be any further debate I will resolve it at a time to be fixed. For the purposes of clarity, I indicate that if the identification of the appropriate expert is to be determined on the basis of the current evidence then it should be Mr Turgeon. That statement should not be taken as an invitation to re-open. In the meantime, I reserve the question of costs and stand the matter over for further directions on Tuesday 25 August 2009.
Rulings on Evidence
Objection was taken to paragraphs 63, 65, 66, 67-70, 71, 72, 74, 75, 95 and annexures E and F of the affidavit of Mr Shuma of 30 September 2008. I admit paragraphs 63, 66, 67, 68, 69, 70, 71, 72, 74 and annexures B, C, D, E and F. I reject paragraphs 65. Objection was also taken to paragraph 76-87 of confidential exhibit KPS-1. I admit those paragraphs. Objection was taken to paragraph 9 of Mr Shuma’s affidavit of 25 March 2009. I admit the paragraph.
I certify that the preceding fifty-five (55) numbered paragraphs are a true copy of the Reasons for Judgment herein of the Honourable Justice Perram. Associate:
Dated: 18 August 2009
Counsel for the Applicants: R. Cobden SC & R. M. Higgins Solicitor for the Applicants: Banki Haddock Fiora Counsel for the Respondent: S. Finch SC & K. Morgan Solicitor for the Respondent: Hicksons Lawyers
Date of Hearing: 10 June 2009 Date of Judgment: 18 August 2009
2
7
0