CA, Inc. v ISI Pty Limited

[2012] FCA 35

FEDERAL COURT OF AUSTRALIA

CA, Inc. v ISI Pty Limited [2012] FCA 35

Citation:

CA, Inc. v ISI Pty Limited [2012] FCA 35

Parties:

CA, INC. and CA (PACIFIC) PTY LIMITED
ACN 001 146 345 v ISI PTY LIMITED
ACN 003 152 225

File number:

NSD 242 of 2010

Judge:

BENNETT J

Date of judgment:

3 February 2012

Catchwords:

COPYRIGHT – subsistence – whether applicants’ database management system identified with sufficient precision to be classified as a “computer program” and/or a “literary work” under the Copyright Act 1968 (Cth) – applicants’ database management system product contains macros – whether applicants’ macros are a “computer program” and/or a “literary work” under the Copyright Act

COPYRIGHT – infringement – respondent develops product to enable users of applicants’ database management system to convert to another database management system – respondent’s product includes macros to replace applicants’ macros – whether respondent’s macros reproduce substantial part of applicants’ database management system – whether respondent’s macros reproduce substantial part of applicants’ macros – relevance of functionality

COPYRIGHT – defences – whether defence in s 47D(1) of the Copyright Act available to respondent – whether respondent acting “on behalf of” applicants’ licensees for purposes of s 47D(1)

CONFIDENTIAL INFORMATION – respondent develops product to enable users of applicants’ database management system to convert to another database management system – applicants allege respondent’s product developed using applicants’ confidential information – whether allegedly confidential information identified with sufficient specificity

CONFIDENTIAL INFORMATION – whether information has quality of confidence – whether certain alleged disclosures of information destroy quality of confidence

CONFIDENTIAL INFORMATION – respondent develops product while working as independent contractor at premises of licensees of applicants’ database management system – whether applicants’ information imparted to respondent in circumstances importing duty of confidence – whether respondent bound by equitable obligation of confidence

CONFIDENTIAL INFORMATION – whether unauthorised use of allegedly confidential information

EQUITY – laches – alleged delay by applicants in commencing proceedings – whether inequitable for applicants to gain relief for breach of confidential information

TRADE PRACTICES – whether alleged representations contravene ss 52 and 53 of Trade Practices Act 1974 (Cth)

Words & phrases:

“computer program”, “on behalf of”

Legislation:

Copyright Act 1968 (Cth) ss 9(3), 10(1), 13(2), 31(1)(a)(i), 32(2)(d), 32(4), 36(1), 47B(3), 47D(1), 47H, 134(1) and 184
Copyright Amendment Act 1984 (Cth)
Copyright Amendment (Computer Programs) Act1999 (Cth)
Copyright Amendment (Digital Agenda) Act 2000 (Cth)
Copyright (International Protection) Regulations1969 (Cth) reg 4
Trade Practices Act 1974 (Cth) ss 52 and 53

Cases cited:

Ansell Rubber Co Pty v Allied Rubber Industries Pty Ltd [1967] VR 37 cited
Australian Medic-Care Co Ltd v Hamilton Pharmaceutical Pty Ltd (2009) 261 ALR 501 applied
CA Inc v Independent Systems Integrators Pty Ltd (No 2) [2009] FCA 900 applied
Campomar Sociedad, Limitada v Nike International Ltd (2000) 202 CLR 45 cited
Coco v AN Clark (Engineers) Ltd (1968) 1A IPR 587 cited
Computer Edge Pty Ltd v Apple Computer Inc (1986) 161 CLR 171 cited
Commonwealth v John Fairfax & Sons Ltd (1980) 147 CLR 39 cited
DaisStudio Pty Ltd v Bullet Creative Pty Ltd (2007) 165 FCR 92 applied
Dart Industries Inc v David Bryar & Associates Pty Ltd (1997) 38 IPR 389 cited
Data Access Corporation v Powerflex Services Pty Ltd (1999) 202 CLR 1 applied
Del Casale v Artedomus (Aust) Pty Ltd (2007) 73 IPR 326 cited
Deta Nominees Pty Ltd v Viscount Plastic Products Pty Ltd [1979] VR 167 cited
Franchi v Franchi [1967] RPC 149 cited
Kalamazoo (Aust) Pty Ltd v Compact Business Systems Pty Ltd (1985) 5 IPR 213 cited
IceTVPty Ltd v Nine Network Australia Pty Ltd (2009) 239 CLR 458 applied
Moorgate Tobacco Co Ltd v Phillip Morris Ltd (No 2) (1984) 196 CLR 414 cited
O’Brien v Komesaroff (1982) 150 CLR 310 cited
Owners of Ship “Shin Kobe Maru” v Empire Shipping Co Inc (1994) 181 CLR 404 cited
Re Ross, ex parte A-G for Northern Territory (1980) 54 ALJR 145 applied
Retractable Technologies v Occupational & Medical Innovations Ltd (2007) 72 IPR 58 cited
Saltman Engineering Co Ltd v Campbell Engineering Co Ltd [1963] 3 All ER 413 cited
Smith Kline and French Laboratories (Aust) Limited v Secretary, Dept of Community Services and Health (1990) 22 FCR 73 cited
SW Hart & Co Pty Ltd v Edwards Hot Water Systems (1985) 159 CLR 466 cited
University of London Press Ltd v University Tutorial Press Ltd [1916] 2 Ch 601 cited

Date of hearing:

18, 20, 21, 25-28 July and 1-3, 5, 9 August 2011

Date of last submissions:

25 November 2011

Place:

Sydney

Division:

GENERAL DIVISION

Category:

Catchwords

Number of paragraphs:

708

Counsel for the Applicants:

Mr R Cobden SC with Mr J Cooke

Solicitor for the Applicants:

Banki Haddock Fiora

Counsel for the Respondent:

Mr J Ireland QC with Mr B Kremer

Solicitor for the Respondent:

Hicksons

IN THE FEDERAL COURT OF AUSTRALIA
NEW SOUTH WALES DISTRICT REGISTRY
GENERAL DIVISION	NSD 242 of 2010

BETWEEN:

CA, INC.
First Applicant

CA (PACIFIC) PTY LIMITED ACN 001 146 345
Second Applicant

AND:

ISI PTY LIMITED ACN 003 152 225
Respondent

JUDGE:	BENNETT J
DATE OF ORDER:	3 February 2012
WHERE MADE:	SYDNEY

THE COURT ORDERS THAT:

1.These reasons be kept confidential to the legal advisers for the parties until further order.

2.Counsel consult as to any matters within these reasons for which confidentiality is asserted, and to notify my Associate of any proposed redactions on or before 5 March 2012.

3.The parties attempt to agree on proposed orders to give effect to these reasons and to submit such proposed orders on or before 5 March 2012. Failing agreement, each party is to submit proposed orders on or before 5 March 2012. 

4.The matter be stood over to 9:30 a.m. on 9 March 2012.

Note: Entry of orders is dealt with in Rule 39.32 of the Federal Court Rules 2011

IN THE FEDERAL COURT OF AUSTRALIA
NEW SOUTH WALES DISTRICT REGISTRY
GENERAL DIVISION	NSD 242 of 2010

BETWEEN:

CA, INC.
First Applicant

CA (PACIFIC) PTY LIMITED ACN 001 146 345
Second Applicant

AND:

ISI PTY LIMITED ACN 003 152 225
Respondent

JUDGE:	BENNETT J
DATE:	3 February 2012
PLACE:	SYDNEY

REASONS FOR JUDGMENT

1. These proceedings commenced on 11 March 2010 following a successful application made by the applicants (CA) filed on 7 October 2008 for preliminary discovery (see CA Inc v Independent Systems Integrators Pty Ltd (No 2) [2009] FCA 900) (CA v ISI (No 2)).

2. CA conducts business as an international software company.  CA raises three causes of action against the respondent (ISI).  They are that:

   ·Pursuant to s 36(1) of the Copyright Act 1968 (Cth) (the Act), ISI has infringed CA’s copyright in certain works comprising or included in CA’s proprietary software product known as Datacom.

   ·ISI has breached an equitable duty of confidence owing to CA by accessing and using certain confidential information in respect of Datacom.

   ·ISI has contravened ss 52 and 53 of the Trade Practices Act 1974 (Cth) (the TPA) by making certain misrepresentations in respect of both Datacom and ISI’s software product known as 2BDB2.

3. Issues of liability and quantum (including whether additional damages are to be awarded pursuant to s 115(4) of the Act in the event of infringement) are to be determined separately. These reasons address the issue of liability.

4. I confess that, having read Jessup J’s reasons in DaisStudio Pty Ltd v Bullet Creative Pty Ltd (2007) 165 FCR 92, in particular [54], I had a sense of sympathy. There were a number of matters in these proceedings that were either not addressed or addressed most perfunctorily by the parties to the extent that, rather than being provided with assistance I was left to work these matters and competing evidence out for myself. I sought refuge in a series of questions posed after the completion of the hearing as to some major areas left untouched or minimally traversed at the hearing. However, I was still left to determine some matters largely for myself, without significant assistance. If I found myself unable to discern a party’s position, I have, of necessity, been unable to take it into account.

5. The structure of these reasons is as follows:

BACKGROUND........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[6]
Database management systems........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[7]
Datacom........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[12]
DB2........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[23]
2BDB2........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[25]
Chronology of Creation........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[30]
WITNESSES........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........	[39]
CA witnesses........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[39]
Richard Turgeon........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[39]
Joseph Lynn........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[40]
Kevin Shuma........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........	[41]
Gerald Clayton........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[43]
Michael Milliken........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[44]
ISI witnesses........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .....	[45]
Carl Melito........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[45]
Peter Richards........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[46]
Mark Granger........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[47]
Ralph Slaber........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[49]
Wayne Bickerdike........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[50]
John Holliday........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[51]
Observations about the witnesses........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[52]
FURTHER BACKGROUND........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[56]
Functioning of Datacom........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[56]
URTs........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .....	[56]
RAAT and SAAT........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[67]
CA URT Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[73]
2BDB2’s operation........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[82]
Operation in batch and CICS modes........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[90]
Use of ISI Replacement Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[94]
COPYRIGHT........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[102]
Subsistence........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[107]
Is Datacom a “computer program” or otherwise a “literary work” without resort to the definition of “computer program”?........ ........ ........ ........ ........ ........ ........ ........ .......	[109]
CA URT Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[116]
Are the CA URT Macros a “computer program”?........ ........ ........ ........ .......	[116]
Are the CA URT Macros a “literary work” without resort to the definition of “computer program”?........ ........ ........ ........ ........ ........ ........ ........	[149]
Authorship........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[158]
Originality........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .....	[163]
Datacom........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[164]
CA URT Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[166]
Conclusion........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[172]
Infringement........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[173]
Has ISI reproduced a substantial part of Datacom in the ISI Replacement Macros?........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[181]
Evidence and submissions on whether the 1999 Macros reproduce a substantial part of the R9 CA URT Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[186]
Evidence and submissions on whether the 2004, 2009 and 2011 Macros reproduce a substantial part of the R9 CA URT Macros........ ........ ........ ........ ........ ........ ........ .....	[192]
Functionality and role of the ISI Replacement Macros........ ........ ........ .	[201]
2004 Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[235]
2009 Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[260]
2011 Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[273]
Conclusion on whether the ISI Replacement Macros reproduce a substantial part of the R9 CA URT Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[304]
Defences........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[328]
Section 47D(1) of the Act........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .....	[328]
Section 47B(3) of the Act........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .....	[360]
Conclusion........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........	[363]
CONFIDENTIAL INFORMATION........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[364]
Identification of the confidential information – has it been identified with sufficient precision?........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[368]
Conclusion........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[374]
The first element: does the information have the necessary quality of confidence?	[376]
The evidence on the quality of confidence........ ........ ........ ........ ........ ........ ........ ........ ..	[378]
CA witnesses........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[378]
ISI witnesses........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[396]
General submissions on quality of confidence........ ........ ........ ........ ........ ........ ........ ....	[402]
The Key CA Manuals........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[405]
CADRE-L disclosure........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[415]
ReadRXX........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[427]
CADRE-L disclosure........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[432]
The source code of the CA URT Macros........ ........ ........ ........ ........ ........ ........ ........ .....	[442]
RQA........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[451]
Disclosure of RQA........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[453]
Conclusion........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[461]
The second element: was the information imparted in circumstances of confidentiality?........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........	[465]
Evidence........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........	[467]
Submissions........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[478]
General........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[478]
CA URT Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[480]
Conclusion........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[486]
The third element: was there an unauthorised use of the information?........ ........ ....	[493]
Mr Richards’ evidence........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[497]
trouble shooting application programs........ ........ ........ ........ ........ ........ .......	[504]
Operation of DBNTRY, DBINFPR and DBCSVPR........ ........ ........ ........ ........ .	[509]
Macquarie (1990 to 1994)........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[515]
Work at Macquarie (from 1996 to 1998) and Beta........ ........ ........ ........ .......	[519]
Creation of 2BDB2........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[540]
Role of 2BDB2........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[545]
Understanding of SAAT and RAAT requests and the RQA........ ........ .......	[548]
RQA........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[550]
AMODDY and B2BRQA........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........	[553]
Creation of 2BDB2 Interface........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[567]
Creation of ISI Replacement Macros........ ........ ........ ........ ........ ........ ........ ....	[569]
Creation of 2011 Macros........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[571]
Involvement of others in creation of 2BDB2........ ........ ........ ........ ........ .......	[575]
Other evidence........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[577]
The Key CA Manuals........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[594]
Programmer Guide........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[595]
Database and System Administrator Guide........ ........ ........ ........ ........ ........ ..	[604]
Datadictionary DSF Programmer Guide........ ........ ........ ........ ........ ........ .......	[612]
Datadictionary Batch Guide........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[618]
Memory dumps and traces........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ...	[622]
Examining traces/dumps........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .....	[623]
Capturing RQA........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .....	[637]
Determining the TRUEs in CICS........ ........ ........ ........ ........ ........ ........ ........ .......	[644]
Determining Datacom commands........ ........ ........ ........ ........ ........ ........ ........ .....	[651]
The source code of the R9 CA URT Macros........ ........ ........ ........ ........ ........ ........ .......	[654]
Conclusion on AMODDY and B2BRQA........ ........ ........ ........ ........ ........ ........ ........ .....	[665]
Laches........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .......	[669]
Evidence........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........	[670]
Submissions........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ..	[686]
Conclusion........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[689]
Conclusion on confidential information........ ........ ........ ........ ........ ........ ........ ........ ........	[692]
TRADE PRACTICES........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ .	[694]
The Third Representation........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ......	[695]
The Fourth Representation........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[701]
CONCLUSION........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....	[705]

BACKGROUND

1. It is convenient to set out some uncontroversial background material.  The subject matter is reasonably complex, in particular, when it is understood that questions arise as to copying and identity of form and function, and lack thereof.  Mnemonics are common, as is shorthand terminology.  The parties have not been totally consistent in their references to matters such as tools, products, parameters, manuals and defined areas.  I have attempted to refer to such matters uniformly and to understand the various references in evidence and submissions.  It has not always proved possible and some multiplicity may have resulted.

   Database management systems

2. A relational database management system is software which allows users to store and retrieve data.  Data are stored inside a “table”.  A table has “fields” (also called “columns”) which define the structure of the data that may be put in it, for example a 12 character field called “phone” for telephone numbers or a six character field called “zip” for post codes.  An empty table (containing no data) consists of the information about this structure. Data are stored inside a table as “records” (also called “rows”).  Each record can contain information under each defined field.  Depending on the underlying program and client requirements, database tables may contain many millions of records.

3. The kinds of database in the present case are those that run on IBM mainframe computer systems known as MVS or z/OS.  They tend to be used by larger corporations to store large volumes of data.  Customers usually write their own application programs in a programming language (such as COBOL, PL/1 or IDEAL) which issues commands to the database, for example, to get or save information in it.

4. Relational database management systems enable a user to relate data from one table to data in another table using a common “relation”, for example, “find a row in the PAYROLL table and using an employee number (or name) obtained there find all entries in the SICK LEAVE table with the same employee number (or name)”.  In large organisations the potential relations between databases can be very complex.

5. It is convenient at this point to explain the difference between batch and CICS applications.  A “batch application” refers to a computer program that consists of one or more “batch jobs”.  A “job” is a task to be carried out by a mainframe computer consisting of one or more job steps, with the word “batch” referring to jobs that are scheduled by the user to run independently of any intervention or involvement by the user.  “CICS” applications overcome the necessity of having to leave batch programs to run overnight.  Their purpose is to enable mainframe users to store, retrieve and manipulate data online.  CICS is an operating system provided by IBM which enables transaction management for online interaction with software and data running in IBM mainframe computers.  It is designed for high volume online processing with multiple users and applications interacting with multiple software products.

6. Both CA’s Datacom and IBM’s DB2 are database management systems.  Datacom and DB2 are installed on licensees’ mainframe computers.  It is relatively common for Datacom licensees also to maintain a DB2 licence.  Datacom is typically used by organisations with very large data processing requirements.  Datacom licensees include very large organisations around the world such as banks, insurance companies and various government departments.  Examples include the US Customs Service (US Customs) and, at one time, Macquarie Bank Limited (Macquarie).

   Datacom

7. CA acquired Datacom from Applied Data Research (ADR) in 1988, which was prior to the relevant events of these proceedings.  Since CA’s acquisition of Datacom, CA has made the following new releases of Datacom available to clients:

   ·release 8.0 in March 1990;

   ·release 8.1 in August 1993;

   ·release 9.0 in October 1996;

   ·release 10.0 in July 2001;

   ·release 11.0 in February 2004; and

   ·release 12.0 in May 2009.

8. Some of Datacom’s licensees may defer taking, or may not take, new releases of Datacom.

9. There are over 30 core manuals for Datacom (Datacom Manuals).  Each release is accompanied by updates and additions to the applicable Datacom Manuals.  The Datacom Manuals sent to each licensee explain how the licensee must use Datacom and the programming language that must be used by the licensee in writing application programs that operate Datacom.  They also tell the licensees how to define, set up and manage data tables used by Datacom.  The key Datacom Manuals for the purposes of the present proceedings are the Datacom:

   ·Datadictionary DSF Programmer Guide;

   ·Datadictionary Batch Guide;

   ·Database and System Administrator Guide; and

   ·Programmer Guide,

   (collectively, Key CA Manuals).

10. The parties have referred to the Key CA Manuals by different names and I may also do so.  Nothing turns on that for the purposes of these proceedings.  It is understood that they are all manuals prepared and issued by CA to licensees of Datacom for the purposes of using Datacom.

11. The central concept of Datacom’s management of data tables is associating a key field with a data pointer.  In order to extract data from, use or change the Datacom data tables, the program must use the special language provided by Datacom.  Datacom uses the vocabulary in the Programmer Guide provided to licensees.  All elements of Datacom are subject to a naming system that requires the element to have the prefix “DB”.  

12. Dataquery is software that enables users to access, retrieve, report and update information in a Datacom database without the need to write a special application program for this purpose.  This enables users to interrogate a Datacom database on an ad hoc basis without special programming skills.

13. In order for the Datacom database to carry out specific business purposes on a regular basis, a user must write an application program for that purpose.  Typically, Datacom licensees write computer applications that populate, interact with and interrogate data in data tables.  These computer applications are generally written by the Datacom licensee’s programmer or database administrator (DBA) and can be written in any general purpose high level computer language, such as COBOL, or in specialised software development programs, such as CA’s IDEAL, which is a fourth generation “language” specially designed for use with Datacom.

14. CA gives Datacom licensees access to certain information that it claims is confidential so that the Datacom licensees’ programmers can write application programs. 

15. Using Datacom, databases can be created with a number of different forms of organisation, from the most complex to very simple layouts.  Once the Datacom licensee has created the application programs that define its business processes with its data and the data tables in which the required data are stored, Datacom can handle very large databases, containing a very large amount of data, with great speed, accuracy and stability, both in CICS and batch mode processing.  Datacom carries out processes and steps which are necessary to manage, for example, the interaction between applications written by Datacom licensees’ DBAs and data tables in which their data are stored.  

16. Mr Lynn, currently a Principal Software Architect at CA (see further at [40] below), has been involved in changes to Datacom over time, many of which are customer driven. As he describes it, Datacom consists of ‘thousands of tightly interwoven processes’.  This means that changes to a part of Datacom are, according to Mr Lynn, a very serious issue.  While changes are needed and required, there is, Mr Lynn says, a countervailing pressure to ensure that Datacom maintains “backward compatibility” so that changes do not adversely impact the ability of the customer to run application programs written for an earlier release on a later one.

17. Datacom has undergone and continues to undergo continuous development such as:

    ·adding functionality to improve performance.  The addition of URT generation macros to replace the former system of creating database access modules for application programs, which I will describe later, is an example; 

    ·responding to changes to the mainframe operating environment, such as the introduction of CICS.  Mr Lynn says that once IBM introduced CICS it was necessary to introduce ‘significant additions’ to Datacom to enable licensees to exploit CICS;

    ·responding to requests from licensees for new functionality.  An example of this is the introduction of the ReadRXX utility; and

    ·the correction of “bugs” which emerge over time.

    These changes can result in the issue of “service packs” to update the product.  However, if a substantial rewrite of Datacom takes place, a major release is required.

    DB2

18. In the early to mid 1980s, IBM released DB2, a competing database product.  It uses a different method to store and retrieve data from that used by Datacom.  The ways in which Datacom and DB2 structure and manage data, the databases created and managed by each of them and the applications written for each of them are not the same and are not compatible.  The database table format for Datacom tables is different from that for DB2 tables, although both employ the concept of a named table with fields and records.

19. Relevantly, each of Datacom and DB2 has different commands.  Datacom has a number of individual commands to get or update records, either one at a time (which is called record-at-a-time (RAAT)) or set-at-a-time (SAAT).  Both RAAT and SAAT are proprietary application program interfaces.  DB2 uses queries written in a language called Structured Query Language (SQL), which was adopted by IBM as the database language for DB2 in the mid 1980s.  SQL allows multiple tables to be accessed together in a single query whereas SAAT is limited to one table per request.

    2BDB2

20. Without the introduction of an appropriate product, if an organisation were to seek to convert its databases and applications from use with one brand of database management software (Datacom) to a form suitable for use with another brand (DB2), all of the data managed by the first product would need to be translated into a format compatible with the second product. In addition, all of the customer’s applications which interacted with the first database product would need to be rewritten so that they could interact with the second database product. Apart from being extremely costly and time consuming, this may also result in data and application errors. Another difficulty is that because of the size of the databases and the nature of the organisations using them, unavailability of the databases can only be tolerated for very short periods of time. The time therefore available for large scale data migration is generally very limited. The conversion process requires “painstaking effort” and is long and expensive. Mr Shuma, the Vice President of Research and Development at CA (see further at [41] below), gives eight years as an example.

21. If a Datacom licensee wishes to convert to the use of DB2 for its application programs and data tables created for Datacom, there is the potential for errors and the risk that the use of the data tables or the translation into SQL (which is not necessarily straightforward) will result in errors or yield incorrect data.  Where an error in data or program conversion is made, the program may abend, that is, it may cease functioning and display an error message indicating the likely cause, and enable a “dump” of the mainframe’s memory to be taken to identify the cause.  Alternatively, the program may continue to work with data errors unnoticed. 

22. ISI developed the product 2BDB2.  It was designed for the sole purpose of facilitating a switch from Datacom to DB2.  The chronology of 2BDB2’s development is discussed below. 

23. For present purposes, there are two versions of 2BDB2:

    ·5.1 (usually called “R5.1”, for “release 5.1”) which is only used by a company called Beta Systems (Beta) in Wisconsin; and

    ·5.2 (or “R5.2”, for “release 5.2”), which is the version supplied by ISI to all other customers.

24. 2BDB2 provides an alternative solution to rewriting application source code in the process of converting from Datacom to DB2.  It allows the customer’s application to be left unchanged, but it lets the user remove Datacom (as fast or as gradually as it wants) and use DB2 to do everything that Datacom used to do.

    Chronology of Creation

25. In 1996, ISI was engaged by Macquarie to assist in converting its database from Datacom to DB2.  Macquarie was using release 8.1 of Datacom at the time.  In undertaking the conversion, ISI used contractors including Messrs Richards, Holliday and McLennan.  The conversion was complete by November 1998.  ISI worked on the creation of 2BDB2 in this period.

26. In 1999, ISI was engaged by Beta in the United States to convert its database from Datacom to DB2.  Mr Slaber, who was working at Beta as a DBA at the time, was the project leader for the conversion.  When Mr Slaber joined Beta in 1996, its existing databases were mostly in Datacom format but all new databases were being created using DB2.  During the conversion process, existing applications were written using RAAT commands and new applications were written in SQL. 

27. At the time of the conversion, Beta was using release 9.0 of Datacom.  It continued to do so until at least 2004.  Beta’s Datacom application programs had been written in COBOL and had a mixture of CICS and batch programs.  Beta’s Datacom applications had been written using RAAT commands.  

28. In undertaking the conversion at Beta, ISI used contractors including Messrs Richards, Holliday, McLennan, Granger and Worboys, the latter of whom was a contractor to ISI who died in January 2008.  ISI provided the software for the conversion.  The project involved retaining the original application program source code rather than attempting to rewrite the application programs to use DB2 calls directly in place of Datacom calls.  Mr Slaber says that a rewrite of all Beta programs would have been both too large to consider and too risky.  It is not clear when the conversion finished – Mr Slaber says that he believes the conversion finished in approximately 2001 or 2002 but that Beta was only ready to cease using Datacom in 2007.  ISI worked on the creation of 2BDB2 while it was engaged by Beta.

29. In 1999, ISI also commenced a “proof of concept” at US Customs.  This involved ISI using 2BDB2 on US Customs’ systems and demonstrating that it worked.  It also involved ISI making updates to 2BDB2 to address problems encountered, including adding support for aspects of Datacom that had not previously been encountered because they had not been used by previous clients.

30. On 27 August 1999, ISI licensed the 2BDB2 code from Macquarie.  The agreement acknowledged that Macquarie owned copyright in the underlying code but that ISI owned copyright in the improvements. 

31. At some point towards the end of ISI’s proof of concept at State Street Bank (which took place in July 2000), 2BDB2 was “packaged” and turned from a tool into an installable product.  The version in use at Beta was called R5.1 and the new version was called R5.2.  

32. In May 2001, ISI entered into a licence agreement with Beta which stipulated that ISI owned the copyright and confidential information in 2BDB2. 

33. On 22 November 2002, ISI and Macquarie terminated their licence agreement.  ISI acquired the 2BDB2 source code from Macquarie; Macquarie conveyed all rights, titles and interests (including copyright) to ISI.  That is, ISI acquired all rights to 2BDB2.

    WITNESSES

    CA witnesses

    Richard Turgeon

34. CA adduced expert evidence from Mr Turgeon, who has been a programmer and developer of computer software in the mainframe sector of the computer industry since 1976.  Mr Turgeon graduated with a Bachelor of Science in Computer Science in 1975 and a Master of Science in Computer Science in 1976, both from Northern Illinois University.  Mr Turgeon has worked for companies including International Harvester Company, SKK Inc, Computer Associates International Inc, Transaction Management Technologies, Quest Software and JME Software LLC in roles including systems programmer, software developer and development manager and team leader in software development management.

    Joseph Lynn

35. Mr Lynn is a computer programmer who has worked as such throughout his employment with CA and its predecessors, continuously and exclusively on the Datacom software and related software products.  Mr Lynn has been a writer for every major release and service pack of Datacom since 1974 and has supervised the work of the other, identified, writers of Datacom and its service packs.

    Kevin Shuma

36. Mr Shuma is the Vice President of Research and Development at CA for the set of products known as the “Datacom and Ideal product family”.  This set of products includes Datacom.  Since 1995, Mr Shuma’s responsibilities have included managing the development of Datacom and Datacom products.

37. In general, where Mr Shuma gives evidence of his knowledge and belief, it is accepted that such evidence forms the knowledge and belief of CA.

    Gerald Clayton

38. Mr Clayton is a Senior Vice President and the Regional Chief Counsel for CA.  In this role, he is responsible for all legal matters arising in the Asia Pacific and Japan region, among others.  Mr Clayton indicated at the hearing that he has given notice that he is leaving CA.

    Michael Milliken

39. Mr Milliken is the Manager of Technical Information at CA, which involves responsibility for all Datacom documentation, including the Datacom Manuals.

    ISI witnesses

    Carl Melito

40. ISI adduced expert evidence from Mr Melito, a Registered Patent Attorney in the United States of America who deals principally with software, electrical, mechanical and microprocessor applications.  Mr Melito has a Bachelor of Science in Computer Science and a Masters Degree in Business Administration from the University of Denver and a Juris Doctorate from the University of Iowa.  Mr Melito has worked in the computer industry since 1981 at companies including Software AG of North America Inc, ADR, Electronic Data Systems Inc and GTE Directories Inc.  Mr Melito has over twenty years experience as a database systems programmer and DBA.  Since 1994, he has been an independent contractor in the computer industry.

    Peter Richards

41. Mr Richards is a director of Long Grass Systems Pty Limited, a company which contracts for his services as a systems programmer.  Mr Richards has been involved with 2BDB2 from about 1996, since the development of the original concept while he was working at Macquarie.  He also worked at Beta as a contractor to ISI.  However, Mr Richards has never been employed by ISI, nor is he a director or shareholder of ISI.  His involvement with ISI has always been as a consultant.  He says that he has been paid by ISI for his services and that he also receives royalties in respect of sales of 2BDB2.   

    Mark Granger

42. Mr Granger is a computer programmer who was contracted with ISI to work at Macquarie as a contractor in Macquarie’s IT department for several months in 1999.  Mr Granger was contracted by ISI to work at Beta intermittently from 1999 to 2001.

43. Mr Granger was experienced with DB2 and worked at Beta in the United States as part of his employment with ISI, in converting Beta’s systems from Datacom to DB2.  To a limited extent, he was involved in writing some parts of the code to be used at Beta, after discussions with Mr Richards and/or Mr Worboys of ISI.

    Ralph Slaber

44. Mr Slaber is presently working as a Senior Technical Consultant at ISI.  From 1996 until he commenced work with ISI in about November 2003, Mr Slaber was employed by Beta as a DBA. 

    Wayne Bickerdike

45. Mr Bickerdike has worked in the computing industry since 1975, with Datacom since about 1984 and with DB2 since about 1990.  He has been employed by ISI since about May 2008 in the capacity of technical consultant for 2BDB2.

    John Holliday

1. Mr Holliday is a DBA and has worked in the computing industry since 1984.  Mr Holliday worked at Macquarie as a DBA, between 1991 and 1994 as an employee and between 1998 and 2000 as a contractor.  From late 1999 or early 2000, Mr Holliday worked at Beta on behalf of ISI.  After working at Beta, Mr Holliday accepted a position with ISI, where he remained until 2007, engaged in marketing and technical support.

   Observations about the witnesses

2. Generally, and subject to observations below with regard to Messrs Turgeon, Melito and Richards, I formed the view that each of the witnesses made every effort to give objective evidence, subject to the normal difficulties of memory over time.  In particular, Mr Lynn clearly had detailed knowledge of Datacom and gave his evidence in a straightforward and objective manner.  I was also impressed by Mr Shuma as a witness.  Again, he was objective and forthright.  He had detailed knowledge of the development of Datacom.  I formed the view that he answered questions honestly and to the best of his ability and recollection. 

3. Mr Richards’ memory was notably inconsistent in the giving of his evidence.  I formed the view that Mr Richards was consciously relying on a somewhat convenient memory, as demonstrated in the manner in which he gave evidence in cross-examination (where he said that his memory was frequently lacking) and re-examination (where his memory for detail was suddenly much better) to attempt to ensure that his evidence assisted ISI’s case.  He says that he can remember the mnemonics and collection of things typically written in capital letters that he has used but that he has ‘a very poor memory at the moment for people and places’.  However, this does not explain the manner of his giving evidence or the different content of his answers in cross-examination and in re-examination. 

4. I formed the view that Mr Richards was very conscious of the effect of his answers on the case that ISI advanced and that he tried very hard to avoid giving answers that might, in his mind, not assist ISI’s case and to proffer answers that would assist.  In this regard, his evidence was not completely reliable.

5. Generally, I do not accept Mr Richards’ evidence unless it relates to matters not in issue or is supported by other evidence in the proceedings.

   FURTHER BACKGROUND

   Functioning of Datacom

   URTs

6. Mr Lynn explains that every application program written by a licensee of Datacom for use in batch needs to have attached to it a special attaching program called a “User Requirement Table” (URT).  A URT is a small piece of information that contains information about a Datacom database.  The URT is used by a user’s application program when that application program accesses or changes information that the user has stored in a Datacom database.  The name ‘URT’ is, as Mr Melito put it, ‘just the name CA gave to such an object module generated using particular macros’.

7. The choice to use a URT was a design decision by the Datacom development group to enable user application programs to access Datacom databases. 

8. URTs provide the communication link or key that “opens the door” into the database region (often referred to as the “Multi User Facility” or MUF).  According to Mr Lynn, the purposes of the URT are:

   ·to “enter” Datacom at the correct point – referred to as an “entry point”;

   ·to identify the correct Datacom resources required to operate the Datacom licensee’s application program and how the Datacom licensee’s application program will use them; and

   ·to identify the data tables that will be required by the Datacom licensee’s application program.

9. Some applications and data tables may share a URT while other applications and data tables use different URTs.

10. There are two aspects to a URT:

    1.It may contain a piece of DBNTRY “stub code” (DBNTRY stub); and

    2.It may have information about a Datacom database and the data tables stored therein.

11. The URT may or may not contain an executable program.  If the URT contains a DBNTRY stub then, and only then, is it an executable program.  DBNTRY stands for “database entry”.   DBNTRY is not a common term but is unique to Datacom.

12. When a Datacom licensee writes an application program, at the point that the user needs to use data from a Datacom data table, the programmer must “call” Datacom, by using the words “CALL DBNTRY”.  In batch, the URT, which is included in the application program, resolves this call; in CICS, a module included with the CICS program resolves the call.   In each case the call takes the licensee’s application program to the right place to carry on setting up the online processing required by the application program.  The application program only calls DBNTRY and is unaware of the difference in the way in which the request is processed and the result returned.

13. In batch, the URT manages the process of preparing and transporting the request to the database and handling the response that is returned to the application program.  The DBNTRY code in the URT locates and starts the Datacom database interface program (DBINFPR) which is stored in the mainframe computer’s memory.  DBINFPR creates and manages the connection to the database.  DBINFPR is not documented in the Datacom documentation provided to licensees because, according to Mr Turgeon, they do not need it.

14. In CICS, the DBNTRY call is resolved by the CICS module DBCSVPR.  It is through this module that the Datacom CICS Services Facility code running in the mainframe provides the URTs required.  The Datacom CICS Services Facility Program and the CICS system then manage the interactive process between the application program requesting data from the database as well as handling the database response that is returned to the application program.

15. The Programmer Guide provides instructions:

    ·to use “CALL DBNTRY” in order to “communicate” with Datacom; 

    ·to create a URT as described in the Database and System Administrator Guide;

    ·for batch programs, to include the URT via the various mainframe “linkage” techniques to the application program (this refers to a process whereby the licensee’s application is “assembled” and attached to the URT and made into a single, machine executable form which can be stored for later use by the licensee); and 

    ·for CICS, to include the module DBCSVPR as part of the program linkage. 

16. The URTs, and DBCSVPR in CICS application programs, are part of every application program created to access the Datacom database.

    RAAT and SAAT

17. The request area is a piece of memory which is set aside for the user’s request and for the return of the response to that request, as well as certain other information, such as the current location in the data table, that is required for the carrying out of subsequent program instructions. 

18. In RAAT requests, the Datacom URT attached to the licensee’s application program specifies the unique database ID number in which the data sought reside, obtains it, places it in the request area, does what it wants with it and then returns the data (that is, updates the original record) and completes the activity before moving on to the next item.  These activities are carried out using a specific lexicon developed by Datacom. 

19. Mr Lynn explains the development in the 1980s of the IDEAL fourth generation programming language and the development of the SAAT interface for Datacom.  It was in releases 7.3 and 7.4 of Datacom that ADR introduced the SAAT request area.  Mr Lynn’s evidence is that this was a much more complex way of interacting with Datacom data tables than had previously been offered.  The SAAT request area is much larger than its RAAT predecessor, because it allows for the user’s request to be in the form of a complex Boolean query.

20. Under a SAAT interface, the combination of the specific criteria is entered into the request area created by the licensee’s application program.  This results in a “set definition” that defines the data in the Datacom data tables that would be returned to the application program.  The addition of SAAT provided the benefit of flexibility in accessing data by the program.  In order to implement SAAT processing, substantial changes were made to the database engine and to the existing application programming interface (API).  The request qualification area (RQA) was added to allow the programmer to specify all of the additional information needed in order to define the set of rows that would be requested.  The RQA was not needed or used for the previous RAAT API. 

21. The IDEAL programming language was particularly suitable for a SAAT call.  Datacom continued to support the SAAT requests used in IDEAL, as well as continuing to work with application programs using RAAT queries written for previous releases of Datacom.

22. In about 1987 or early 1988, Mr Lynn and those working with him at CA began making changes to Datacom to be competitive with other relational database management systems driven by SQL.  Mr Lynn had the responsibility of managing the “taskforce” for the development of Datacom release 8.0.  Datacom release 8.0 introduced an SQL implementation, which heavily utilised SAAT processing in the data access layer.  Datacom release 8.0 and later releases allowed programming using standard SQL queries. 

    CA URT Macros

23. Datacom contains five URT Macros, namely, the DBURINF Macro, the DBURSTR Macro, the DBURTBL Macro, the DBUREND Macro and the DBURGEN Macro (collectively, CA URT Macros).  Each of the CA URT Macros includes varying numbers of parameters and a wide variety of possible values.  The CA URT Macros are an important part of CA’s copyright claim.

24. The CA URT Macros have been part of each release of Datacom since release 7.4 and are provided to Datacom licensees as part of the Datacom software.  The names of the CA URT Macros and their parameters were created specifically for Datacom.  As can be seen, all contain the “DB” prefix.

25. To create the specific URT required by each application program of a Datacom licensee, CA provides the CA URT Macros for the licensee to load into its mainframe program libraries.  The CA URT Macros are provided to licensees in source code, so that DBAs can write programs that can interact with Datacom.

26. Without the CA URT Macros, the licensee would have to create the URTs required by its application program on each occasion from first principles.  They are provided to the licensee to make the programming task of creating the URTs less tedious and error-prone, as they contain the details necessary for the user application to function.

27. As stated above, CA requires its licensees to follow a certain protocol to allow their application programs to interact with Datacom.  This protocol requires the licensee (usually through a programmer or DBA) to write small assembler language source code programs in which the names of the CA URT Macros are placed.  This is called the SYSIN.  The Datacom licensee may also include next to the names of the CA URT Macros the names of parameters and values for the CA URT Macros depending on what database tables it wants the application program to access and the manner in which its application program should access them.  The Datacom licensee’s programmer or DBA writes the SYSIN source code program and then runs an assembler in order to assemble it.  This process, in which an assembler converts assembly language source code into a piece of object code, is called “assembly”.  The piece of object code that is produced by assembling the SYSIN is the URT. 

28. After writing its application program (for example in the COBOL programming language) the Datacom licensee will then compile that program to produce a piece of object code.  This involves using a COBOL compiler, supplied by an entity other than CA or ISI.  The Datacom licensee will next use an IBM program called a “link editor” to process the object code produced by compilation of the Datacom licensee’s application program and also the URT into what is known as an “executable load module”, which is a program that can be “run” on the mainframe.

29. It is necessary to outline briefly the role of each of the CA URT Macros.  Of the CA URT Macros:

    ·The DBURINF, DBURSTR, DBURTBL and DBUREND Macros are considered “external” or “first level” macros (the External Macros).  The External Macros are given to Datacom licensees.  Their purpose is to collect information.  The External Macros lead the application programmer through the process of creating the URT by answering a series of questions.  The External Macros use parameter specifications designed to collect specific information about the Datacom licensee’s application program and its intended Datacom database processes, its requirements for database resources and the various actions that are to be taken if there is a failure in the application or database processing.  Each of the External Macros includes a number of parameters, each with a number of different possible values.  For example, the External Macros for release 9.0 of Datacom include 38 different parameters with a wide variety of possible values, while the External Macros for release 12.0 of Datacom include 50 different parameters.  The External Macros, including their parameters and parameter values, are specific to applications written to access the Datacom database environment. 

    ·DBURINF stands for Datacom User Requirements Interface.  This makes available to the Datacom licensee’s programmer or DBA several options for the URT when DBNTRY is present, that is, for use in batch programs only.  This is skipped if the DBA has specified that the program is an online application using CICS.

    ·DBURSTR stands for Datacom User Requirements Start.  This macro starts the process whereby the DBA will answer a series of questions and based on those answers the macro will take the programmer to the next relevant question.

    ·DBURTBL stands for Datacom User Requirements Tables.  This macro enables the programmer easily to identify the Datacom data tables required by reference to each table’s unique ID, as well as specifying a number of other important database handling operands (or “instructions”).

    ·DBUREND stands for Datacom User Requirements End.  This macro signals the end of the URT generation process and issues the command to the embedded DBURGEN Macro to generate the URT in assembly language ready for use by the Datacom licensee.

    ·DBURGEN stands for Datacom User Requirements Table Generation.  The DBURGEN Macro is an “internal” or “second level” macro.  It is not documented by CA in the introduction given to licensees.  Datacom licensees do not need to name it in the process of using the CA URT Macros to generate the required URT.  As stated above, the DBURGEN Macro is internally invoked by the DBUREND Macro during the assembly process.  The DBURGEN Macro takes the input collected by the External Macros and creates the final URT output.

30. For application programs that are written to be used in batch mode, all four of the External Macros are required to be used in the creation of the required URTs.  The URT object modules generated by the CA URT Macros are used in the batch environment to remove the need for the application process to have the complex knowledge necessary to communicate to, and navigate in, the database region.

31. For application programs that are written to be used in CICS, the DBURSTR, DBURTBL and DBUREND Macros are used in the generation of URTs but the DBURINF Macro is not used.  In CICS, the URT object modules are not linked as part of the user application code written for CICS.  Instead, DBCSVPR is linked with every one of the user’s CICS programs that accesses Datacom.  This module provides a pathway to the CICS Services processes that use the URTs to define and control the resources within the database that will be available for use by the application programs connected to the CICS Services process.  As with the batch URTs, the URT object modules used in the CICS environment remove the need for the CICS region to have the complex knowledge necessary to communicate to the database regions in the mainframe complex.

    2BDB2’s operation

32. The term “2BDB2” is a reference to a suite of computer software products offered by ISI, some or all of which might be employed in connection with the conversion by a customer from use of a Datacom database system to a DB2 database system.  In broad terms, 2BDB2 comprises three parts.  The first element is known as “2BDB2 Datacom Data Converter”. The second element is known as “Transparency”.  The third element is known as “2BDB2 Ideal”. 

33. In opening, CA made no complaint about the use of its alleged copyright works and confidential information in respect of the 2BDB2 Datacom Data Converter or 2BDB2 Ideal.  However, CA later contended that ISI used its confidential information in creating parts of the 2BDB2 Datacom Data Converter.  CA also claims that ISI has used certain information confidential to CA in creating Transparency. 

34. 2BDB2 Datacom Data Converter performs the function of migrating Datacom licensees’ data managed by Datacom to DB2.  It does this by converting the data from their Datacom format into a format that is understood by DB2.  2BDB2 can migrate the data one data table at a time.

35. 2BDB2 Ideal is a code conversion engine that performs the function of converting Datacom licensees’ applications that have been written in CA’s IDEAL language into COBOL applications which will operate in the DB2 environment.

36. Transparency is designed to allow existing applications programs to be run against either Datacom or DB2, depending upon in which of those two databases the required information is located.

37. Transparency interposes itself within the Datacom licensee’s mainframe in such a way that the Datacom licensee’s applications communicate with it.  It is “bilingual” because it can understand the Datacom statements made by the Datacom licensee’s applications and can translate them into statements that can be understood by DB2.

38. When Transparency identifies that a request has been made by a Datacom licensee’s application that relates to data still managed by Datacom, it simply passes the request on to Datacom.  When Transparency identifies that a request made by a licensee’s application relates to data now managed by DB2, it passes that request on to DB2 but it does so in statements understood by DB2.  As the Datacom licensee’s application is only written in statements that Datacom understands, Transparency translates the application’s request to a statement that DB2 understands and passes the request on.  When DB2 responds, Transparency translates the output back into a statement that the application understands and places it into the area of the computer’s memory where the application expects that answer to be, as if the response has come from Datacom.

39. The attraction of 2BDB2, made possible by Transparency, is that a customer is able to migrate data from Datacom to DB2 one data table at a time, while ensuring that the database continues to operate.  While the conversion process is taking place from Datacom to DB2 (which can take years depending upon how large the database is), 2BDB2 allows part of the database to continue operating in Datacom and part of it to operate in DB2.  Once the conversion is complete, the database will only operate in DB2 but the Datacom licensees’ applications, which remain written in statements native to Datacom, will be translated by Transparency and understood by DB2.

    Operation in batch and CICS modes

40. In batch, 2BDB2 intercepts (at the IBM operating system level) the request made by the stub within the URT for the location of the Datacom module – that is, the position in the computer’s memory where that module has been loaded – and instead, causes the operating system to send the address of a 2BDB2 module.

41. ***** REMOVED BY REASON OF CONFIDENTIALITY *****
    

1. ***** REMOVED BY REASON OF CONFIDENTIALITY *****
   

2. ***** REMOVED BY REASON OF CONFIDENTIALITY *****
   
   

   Use of ISI Replacement Macros

3. If a customer has completed all conversions from Datacom to DB2 and has removed Datacom, 2BDB2 requires URT macros to replace the CA URT Macros.  With the exception of the 1999 Macros (which I define below), these were/are included in 2BDB2 (ISI Replacement Macros).  The ISI Replacement Macros are linked with the customer’s original application program object code to create a new program that accesses DB2 exclusively via Transparency.

4. However, the ISI Replacement Macros cannot be used in the time between the installation of 2BDB2 and the completion of the migration of all data tables to DB2 format.  During this period, only URTs produced using the CA URT Macros can be used.  This is because URTs produced using the ISI Replacement Macros can only route calls to DB2 tables; if they are link edited with the original application program object code, no calls can be made to any tables in Datacom format.

5. The purpose of the ISI Replacement Macros is, therefore, once conversion from Datacom to DB2 is complete, to generate new URTs to replace the original CA URTs. 

6. Without the ISI Replacement Macros, the objective of 2BDB2 to eliminate the need for Datacom would fail.  This is because the customer’s applications following the conversion from Datacom to DB2 would still have their original URTs, which include Datacom elements. 

7. The following versions of the ISI Replacement Macros are relevant:

   ·1999 ISI URT Replacement Macros (1999 Macros);

   ·Release 5.1 and release 5.2 ISI URT Replacement Macros (2004 Macros), the latter of which were first supplied to all ISI customers as part of a quarterly service pack for R5.2 of 2BDB2 in June 2004 and the former of which were later supplied to Beta;

   ·Release 5.2 ISI URT Replacement Macros (2009 Macros), which were sent by Mr Bickerdike to 2BDB2 R5.2 customers as part of a quarterly service pack in 2009; and

   ·2011 ISI Macros (2011 Macros), which were supplied to Beta and other 2BDB2 customers in around May/June 2011.

8. Four of the corresponding ISI Replacement Macros (that is, the External Macros) are also identically named DBURINF, DBURSTR, DBURTBL and DBUREND.  The internal macro, DBURGEN, was named identically until the 2011 Macros. 

9. ISI accepts that it created the 2004, 2009 and 2011 Macros.  As to the 1999 Macros, ISI’s position is not clear.  Mr Richards says that the ISI Replacement Macros were, to his knowledge, originally written by Mr Worboys.  CA says that ‘it is accepted by both parties, whether or not Mr Worboys created them, that the 1999 Macros were created at Beta’.  ISI did not initially seem to reject CA’s assertion, nor did it contradict Mr Richards.  However, various of ISI’s submissions seem to reflect a non-admission of its creation of the 1999 Macros, in particular, its repeated assertion of suffering detriment in being unable to call Mr Worboys.  I did not understand ISI initially to reject or deny the assertion that it, through Mr Worboys at the least, took ownership of the 1999 Macros.  Rather, ISI’s position seems to be related to a lack of knowledge on the part of ISI of the circumstances in which the 1999 Macros, and perhaps the 2004 Macros, were created. 

10. In submissions filed in response to the questions directed to the parties after the completion of the hearing, ISI seized upon some of Mr Turgeon’s evidence as to the provenance of the 1999 Macros and submitted that it was not certain that ISI was involved in the creation of those macros, or that they were created at Beta. 

    COPYRIGHT

11. CA contends that each version of Datacom and the CA URT Macros is a copyright work and that each version of the ISI Replacement Macros infringes its copyright in these works.

12. ISI denies that Datacom and the CA URT Macros are copyright works and contends that even if they are copyright works, ISI has not reproduced a “substantial part” of each of them. ISI also relies on the defences to infringement available under ss 47B(3) and 47D(1) of the Act.

13. The copyright issues for determination are, in summary:

    · whether CA has identified Datacom with sufficient precision for it to be classified as a “computer program” as defined in the Act and/or as a “literary work” without resort to the “computer program” definition;

    ·whether the CA URT Macros collectively are a “computer program” as defined by the Act;

    ·whether the CA URT Macros, individually or collectively, are “literary works” without resort to the definition of “computer program” in the Act;

    ·whether each of the different versions of the ISI Replacement Macros constitutes the reproduction of a substantial part of Datacom;

    ·whether each of the different versions of the ISI Replacement Macros constitutes a substantial part of the CA URT Macros; and

    ·whether the defences in ss 47B(3) and 47D of the Act apply to ISI’s conduct.

14. The authorship and originality of the CA URT Macros and Datacom are not in dispute.  Mr Lynn and Mr Shuma’s evidence establishes both, as set out below. 

15. To the extent that it is found that copyright subsists in the CA URT Macros and Datacom, it is not in dispute that CA owns that copyright.

    Subsistence

16. CA contends that the CA URT Macros and Datacom are “literary works” and that, accordingly, copyright subsists in these works pursuant to s 32(2)(d) of the Act.

17. Section 10 of the Act states, relevantly, that a "literary work" includes ‘a computer program or compilation of computer programs’. Section 10 of the Act also provides that “computer program” means ‘a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result’.

    Is Datacom a “computer program” or otherwise a “literary work” without resort to the definition of “computer program”?

18. ISI disputes the classification of Datacom as a “computer program” or “literary work”.  ISI submits that CA cannot base a claim on Datacom as a copyright work because the work has not been properly put into evidence.  ISI points out that:

    ·CA has not tendered the full source code of any version of Datacom.

    ·CA has only tendered (by way of tape) what it says is the object code of release 9.0 of Datacom.  Mr Shuma agreed that the form in which Datacom is contained on that tape is not the form that is actually run by a customer.

    ISI says that the source and object code are the expression of what is said to constitute the work and it is that expression which must be compared with any work said to infringe it. 

19. CA submits that, given the impracticality of putting into evidence and tendering vast amounts of source code, the tendering of:

    ·object code;

    ·samples of the source code in CA’s affidavit evidence; and

    ·the Key CA Manuals describing what Datacom does;

    is ample evidence identifying Datacom.

20. I am satisfied that Datacom has been sufficiently identified in the evidence.  The evidence of Mr Lynn and Mr Shuma supports its characterisation as a work.  It is clear that Datacom (including release 9.0) is a “computer program or compilation of computer programs”.  It exists as a set of statements or instructions in source code that are used directly and indirectly in a mainframe computer to bring about certain results.  Accordingly, Datacom is a “literary work”.

21. It is worth noting at this point that although the evidence is sufficient to enable identification of Datacom as a “computer program”, the evidence is insufficient to enable analysis of whether ISI has reproduced a substantial part of Datacom, as I will explain below.

22. CA also contends that Datacom is a “literary work” without resort to the definition of “computer program”. 

23. The adjective “literary” is a generic term that is descriptive of the way in which the work is made, not its quality (University of London Press Ltd v University Tutorial Press Ltd [1916] 2 Ch 601). A literary work is one that gives “information, instruction or pleasure in the form of literary enjoyment” and that is not a question of literary merit (Computer Edge Pty Ltd v Apple Computer Inc (1986) 161 CLR 171 at 192; Kalamazoo (Aust) Pty Ltd v Compact Business Systems Pty Ltd (1985) 5 IPR 213 at 232).

24. There is no suggestion by CA that Datacom itself was taken. Instead, CA asserts that what was taken from Datacom constitutes a substantial part of it. This is the context in which the classification of Datacom as a “computer program” or otherwise a literary work becomes relevant. As is set out at [178] below, analysis of whether a substantial part of a “computer program” has been reproduced necessarily involves consideration of functionality. This is not the case for analysis of whether a substantial part of a “literary work (other than computer program)” has been reproduced. If a work is classified as being both a “computer program” and a “literary work (other than computer program)” and the finding is made that there has not been a reproduction of a substantial part of the work when the work is considered as a “computer program”, it will not necessarily always follow, in my view, that there has not been a reproduction of a substantial part of the work when the work is considered as a “literary work (other than computer program)”. However, it would follow in this case. This is because, in its evidence and submissions on the reproduction of a substantial part of Datacom, CA relies on the importance of functionality. Therefore, in light of:

    ·the different approaches to the consideration of substantial part based on whether the work is classified as a “computer program” or a “literary work (other than computer program)”;

    ·my conclusion that Datacom is a “computer program”;

    ·CA’s reliance on functionality in its evidence and submissions on substantial part; and

    ·the fact that the evidence on the functionalities of Datacom is itself limited,

    it is unnecessary for me to determine whether Datacom is a “literary work” apart from its characterisation as a “computer program”.

    CA URT Macros

    Are the CA URT Macros a “computer program”?

25. In Data Access Corporation v Powerflex Services Pty Ltd (1999) 202 CLR 1 at [99], Gleeson CJ, McHugh, Gummow and Hayne JJ described a macro command as one which, when executed, causes a sequence of other functions to be executed, so that the overall effect of performing a more complex function is achieved.

26. Mr Turgeon says that, in general, a macro can be described as ‘a block of source code’ that can be used to generate data in the form of machine instructions and data areas in an object module.  The object module can be linked in a variety of ways to produce a load module that may contain executable machine instructions.  In the CICS environment, the macro’s function is confined to a contribution to the table generated; the module is not generated by the macros.

27. As set out in an IBM manual, a macro ‘provides a convenient way to generate a sequence of assembler language statements many times in one or more programs… a macro definition is written only once; thereafter a single statement, a macro instruction statement, is written each time you want to generate the sequence of statements’.

28. Mr Turgeon says that the name of a macro is a mnemonic that represents a collection of macro assembler source statements that are contained in a corresponding text file.  A macro name is inserted into a source file and the macro file’s contents are then pasted into that referencing source file.  An assembler can “call” (in the sense of copy and paste) a macro and copy in the macro statements or modify them.  According to Mr Turgeon, macro expansion is not a trivial process.

29. The experts agree that the CA URT Macros are not a “computer program” as the term is understood in the industry. However, this is irrelevant to the construction of “computer program” as defined in the Act (Owners of Ship “Shin Kobe Maru” v Empire Shipping Co Inc (1994) 181 CLR 404 at 419-421).

30. Mr Turgeon’s evidence is that the CA URT Macros are predominantly used during the initial development and testing of new applications.  It is not in dispute that the CA URT Macros are not involved in the processing of user applications that access Datacom or while Datacom is executing.  Mr Turgeon says that the CA URT Macros play no part in the day-to-day processing of a customer’s application. 

31. However, the evidence of Messrs Turgeon, Shuma and Lynn explains the involvement of the CA URT Macros in creating the URT, which Mr Turgeon refers to as ‘the object code URT’. 

32. Mr Lynn’s evidence is that the CA URT Macros, the parameters and other assembler language statements, taken together, comprise a single assembler language source input file which becomes a URT by the process of “assembly”.  Assuming that all of the parameters and CA URT Macros are correctly specified, the assembler will produce an object module.  Mr Lynn says that the object code produced utilising the CA URT Macros is an integral part of the application program and is used on every Datacom function call.  Mr Lynn says that that the content of the URT sets the way in which the associated user application program accesses or updates the user’s Datacom data tables.  He says that a typical user application may contain hundreds of programs, many of which will share the same URT.

33. CA contends that the evidence indicates that the CA URT Macros are used indirectly in a mainframe computer in order to bring about a certain result as follows:

    ·The External Macros use parameter specifications designed to collect specific information about the Datacom licensee’s application program and its intended Datacom database processes, its requirements for database resources and the various actions that are to be taken if there is a failure in the application or database processing.  The first part of the assembly process in respect of the CA URT Macros is to include the names of the External Macros in a “URT Assembly”, a SYSIN.  The form of this file is determined by IBM’s High Level Assembler Language conventions.  The SYSIN is part of the assembly process.  In whatever environment one is assembling assembly language source code (using an assembler), a SYSIN is required.  The CA URT Macros perform a particular function within the SYSIN.  Without the CA URT Macros, the SYSIN could not produce the URT object module. 

    ·The first phase of the assembly process is called “expansion”. All of the names of the External Macros are “expanded” (wherever the name of those macros appears in the SYSIN) so as to include the source code for each of those macros in the SYSIN.

    ·The source code for the DBUREND Macro then issues a command to the assembler to invoke internally the DBURGEN Macro, which is the only “second level” macro and by far the largest of the CA URT Macros, in the SYSIN.  The source code for the DBURGEN Macro is then inserted into the SYSIN.

    ·The second phase is where the assembler assembles the source code of the CA URT Macros so that the DBURGEN Macro produces the URT object module, that is, object code.  In effect, the DBURGEN Macro takes the input collected by the External Macros and produces the object code, in the form of the final URT object module. 

    ·It is in the process of “assembly” that the source code is converted (assembled) into object code. 

    ·The URT object module is capable of directly affecting the physical capabilities of a computer.

34. This summary omits Mr Lynn’s evidence that once the URT has been assembled, it must be “linked” into a program library, using IBM’s link editor to convert the object code URT into a form that can be referenced directly by the application program (in batch) or by other Datacom/2BDB2 interface programs (in CICS).  The link editor combines object code and/or load modules to form new load modules, that is, a form of the user’s application programs capable of being executed in a computer.

35. Mr Shuma says that the CA URT Macros are provided to Datacom licensees in source or source library in an installation tape.  He says that they are provided as a readable file that is not in itself executable.  Mr Lynn agrees that the CA URT Macro definitions cannot be assembled on their own.  He says that if one tried to do so there would be an error message and no object code produced.

36. CA submits that the facts that:

    ·the CA URT Macros are part of a larger program, Datacom, and may be used as part of the Datacom licensee’s SYSIN; and

    ·the URT object module, which is the result of the CA URT Macros being assembled, needs to be “link edited” in order to make the object code executable,

    do not disqualify the CA URT Macros from being a “computer program” within the meaning of the Act. CA points out that the process of “link editing” is to gather object code together; in order to make any object code executable in the mainframe environment, the object code needs to be “link edited”, a process which does not change the object code.

37. Mr Richards does not accept that a macro is a block of source code.  He says that it is ‘a piece of data’.  Mr Richards likens the CA URT Macros to a recipe on the basis that they will be read and things will be done based on their content.  Mr Richards says that when source code is compiled or assembled, that is, the set of instructions is written by a programmer, object code will be produced.  He says that the object code can be link edited to produce executable code and it is that executable code that produces “a certain result” in the computer.  The collection of codes that “run” the program produce the result “directly”.  Mr Richards explains that the object code can be said “indirectly” to produce the “result”, as this takes account of the link editing which produces the executable code.  The source code can also indirectly produce the result.  Mr Richards says that all three would commonly be termed “a program”.  In the case of a URT, the “source” contains the names of the macros and any parameters specified for them – the source code.

38. Mr Richards says that if a URT when assembled contains executable code (that is, a DBNTRY stub) then the URT would be called a program.  However, if it only contained a data table, then it would not be so called. 

39. Mr Richards also points out that macros are not written in assembly language.  Mr Richards says that the directives used to construct a macro are read by the assembler in the process of constructing object code but are not executed.  He says that that the assembler reads the contents of a macro when it encounters the macro’s name in the source code being assembled and that the assembler may place into the source code portions contained in the macro. 

40. Mr Melito adds that, in his opinion, a URT is not a program unless it contains executable instructions which require assembler language instructions; this only occurs when the URT contains the DBNTRY stub.  When the DBURGEN Macro is expanded, the assembler generates object code and, in certain instances, executable code, if a DBNTRY stub is included in the result.

41. ISI submits that the CA URT Macros do not meet the definition of “computer program” because they are not the complete “set of statements or instructions” that brings about the “result”, given that considerable participation by other elements is required to accomplish that result.  ISI says that the CA URT Macros play such a limited part in the Datacom licensee’s activity with the SYSIN in creating the URTs, which themselves are required to call and receive a response from Datacom, that they cannot even be said to have indirectly brought about the result.  In this respect, Mr Turgeon says that the construction of the URT module into executable code is a ‘division of labour’.  He agrees that both the customer’s and Datacom’s “labour forces” contribute to this outcome.

1. ISI submits that this is an impermissible new claim that is not supported by any evidence.  ISI also adds that CA resiled during the course of the hearing from a claim for confidence in Datacom commands.

2. There is no evidence directed to this particular claim. The information has not been identified with any particularity. For the same reasons as stated at [603] above, this claim should not be considered.

   The source code of the R9 CA URT Macros

3. CA contends that ISI used the source code for the R9 CA URT Macros in developing each of the ISI Replacement Macros, including the 2011 Macros.  CA relies upon:

   ·the fact that the R9 CA URT Macros and the 1999 Macros are, as accepted by the experts, almost identical; and

   ·the use of the 1999 Macros in creating the subsequent 2004, 2009 and 2011 Macros.  In particular:

   ·the 1999 Macros and the 2004 Macros are objectively similar and contain the same ISI copyright notifications except for a change of date;

   ·Messrs Turgeon and Melito both note the presence of common sequence line numbers and Mr Melito concedes that he thinks that the 1999 Macros were probably the starting point for the 2004 Macros;

   ·Mr Richards says that Mr Worboys informed him that he was ‘updating’ the 2004 Macros, the product of which was the 2009 Macros.  The author of the 2009 Macros is identified as Mr Richards, the same identified author of the 2004 Macros; and

   ·Mr Turgeon expresses the opinion that the 2009 Macros were used to create the 2011 Macros.  Mr Turgeon says that the mechanics of the implementation in the 2011 Macros are ‘consistent with the evolution of these macros starting with the 1999 [Macros]’.

4. ISI contends that the 2011 Macros are in a different position to the 2004 and 2009 Macros and that there is no case open to CA in respect of the 2011 Macros.  ISI points to Mr Richards’ unchallenged evidence that he created the 2011 Macros afresh by starting with the desired output and worked backwards. ISI asserts that CA has failed to show that, in creating the 2011 Macros, Mr Richards had resort to any confidential information, let alone the CA URT Macros or that his conscience should be affected.

5. I accept CA’s submissions in relation to the 1999, 2004 and 2009 Macros.  The identity of the 1999 Macros and the R9 CA URT Macros leads inescapably to the conclusion of copying.  The 1999 Macros were, in turn, effectively copied into the 2004 and 2009 Macros, as has been illustrated in the section of these reasons on copyright.  In each case, that use was unauthorised use by ISI of the source code of the R9 CA URT Macros. 

6. I accept ISI’s submissions in relation to the 2011 Macros.  I accept that the 2011 Macros were created with knowledge of the purpose of Datacom in accordance with the requirements of a user who wishes to convert to DB2.  CA has not established use of the source code of the R9 CA URT Macros in the writing of the 2011 Macros. 

7. It is necessary to deal with several other submissions made by ISI.

8. First, ISI says that simple reproduction of parts of a macro file is not a “use” of confidential information.  ISI submits that use made of information said to be confidential is not actionable where it is little different in substance from use of information that is in no way confidential (Del Casale v Artedomus (Aust) Pty Ltd (2007) 73 IPR 326 at [147]). ISI points out that the CA URT Macros contain lines which, when consulted by an assembler, allow it to arrange the information entered by the user as “parameters” for the CA URT Macros into a particular form and, where a DBNTRY stub is required in the URT, to paste in the appropriate sections of lines that will then be assembled as source code and turned into that stub. ISI places reliance on the fact that the use is by way of reference and that it is the user who produces the URT. Simply reproducing part of a file does not, ISI says, involve any “use or disclosure” of anything for the purposes of a confidential information action (Medic-Care at [632]).

9. I do not accept ISI’s contention.  ISI used the source code of the R9 CA URT Macros in order to create the 1999, 2004 and 2009 Macros.  The fact that the source code of the R9 CA URT Macros was generally used by Datacom licensees in a different way (and in a way authorised by CA) is not to the point.  The source code of the R9 CA URT Macros was not used by ISI in accordance with the use for which it was disclosed or enabled, that being the access that was granted under the regime of confidentiality to licensees, their employees and contractors in order to create URTs.

10. Secondly, ISI also submits that any question of “use” must be viewed against the role the ISI Replacement Macros and the CA URT Macros play in 2BDB2 and Datacom respectively.  ISI contends that ‘the macros are but an ancillary part of Datacom and an even less important part of 2BDB2’.  ISI points out that:

    ·The CA URT Macros were not part of Datacom at all for over a decade until Mr Lynn created them.

    ·Once CA chose to use the CA URT Macros, the consequence was that licensees would have SYSINs that contain references to them and therefore ISI must support those existing SYSINs. 

    ·The CA URT Macros are not part of the day-to-day operation of Datacom but are only used once to produce a URT that is added to (or referred to) by the customer’s application.  Thereafter, the URT is used but the macros are not.  They are not, as CA alleges, the ‘keys to the kingdom’. 

    ·The ISI Replacement Macros do not form part of Transparency or 2BDB2 Datacom Data Converter.  As stated by Mr Holliday, the ISI Replacement Macros play no part in Transparency or the utilities to convert data in Datacom database format into DB2 format.  The ISI Replacement Macros would only be needed if someone had completely converted all Datacom tables to DB2 and wanted to remove Datacom from the system.  No confidential information could have been used by ISI in the creation or maintenance of Transparency, which was completed prior to the creation of the 2004 Macros.  That product does not use or reference any output from the ISI Replacement Macros; that is done by the customer’s application program.

    ·The original URTs produced using the CA URT Macros must be used with a mix of Datacom and DB2 tables.  The ISI Replacement Macros can only be used once the customer has converted to DB2, after which, since 2004, the customer may switch to using the ISI Replacement Macros and create new URTs.  Once the ISI Replacement Macros are used to create URTs, those URTs cannot access Datacom tables.  However, the customer may continue to use existing linked applications and not use the ISI Replacement Macros.

    ·ISI did not distribute any ISI Replacements Macros with 2BDB2 R5.1 and R5.2 until five years after it first distributed 2BDB2. It distributed the 2004 and 2009 Macros to be used with 2BDB2. In fact, the evidence suggests that those macros contained errors which would have meant that they could not have been used.

11. In response to this and in contending that the ISI Replacement Macros are an important part of 2BDB2, CA points to evidence of notices sent to ISI customers stipulating that the ISI Replacement Macros must be used when the conversion of the customer’s applications from Datacom to 2BDB2 has been completed.

12. This submission may be relevant to any damages award and to the orders to be made in accordance with these reasons, but it is not relevant to whether there has been an unauthorised use of the source code of the R9 CA URT Macros, which, as I stated above, has been made out in relation to the creation of the 1999, 2004 and 2009 Macros.

13. CA did also contend that ISI used the CA URT Macros in the creation of the ISI 2BDB2 interface.  However, as this claim was only raised briefly in CA’s closing written submissions and was not addressed further in response to my request for the parties to provide further submissions on the relevance of the CA URT Macros to CA’s breach of confidential information case, I consider it to be abandoned.  In any event, CA has not discharged its onus of proof in supporting this conclusion.

    Conclusion on AMODDY and B2BRQA

14. As to AMODDY, I conclude that:

    ·AMODDY is a part of 2BDB2.  

    ·It was written at least in part by Mr Richards. 

    ·Mr Richards denies and CA has not established that Mr Richards wrote the relevant sections of AMODDY of which it complains or that he was the sole author. 

    ·Mr Richards was quick to disclaim knowledge of, or memory of, parts of AMODDY that were relevantly identical to the relevant Key CA Manuals. 

    ·CA has not proved by evidence that Mr Richards himself used the Key CA Manuals during his involvement in creating AMODDY or that any other writer of AMODDY used the Key CA Manuals.

    ·However, of the list of 17 parameters in the RQA parameter sections of AMODDY, seven were the same as in the Programmer Guide and all 17 were the same as in the Database and System Administrator Guide. 

    ·I do not accept that the precise correlation of the parameters is likely if there had been truly independent creation of AMODDY.  ISI has not established that Mr Richards or another ISI contractor or employee independently created the parameters. 

    ·Based on the similarity in content between the parameters in the RQA parameters section in AMODDY and those listed in the Database and System Administrator Guide, I conclude that this guide was used in the creation of AMODDY.  Whether the information in the Database and System Administrator Guide was used by Mr Richards, Mr Worboys or another ISI programmer, it was incorporated into 2BDB2, an ISI product, for and on behalf of ISI.  

    ·As I have concluded that the Database and System Administrator Guide was used, I am not prepared to draw the inference that the Programmer Guide, which contained only seven of the 17 parameters used by ISI, was also used in creating AMODDY. 

15. As to B2BRQA, ISI submits that the mapping of the RQA contained in B2BRQA did not involve the Programmer Guide and was by a legitimate process of reverse engineering by drawing conclusions from authorised observations and that use of such information is not unauthorised use.

16. I make the following findings about the creation of B2BRQA:

    · Mr Richards accepts that B2BRQA maps with complete precision the specifications in the Programmer Guide apart from the complete list of parameters and the E section but still asserts that he was the “author” of this section. 

    ·Mr Richards was quick to disclaim knowledge of, or memory of, the comment block, a part of B2BRQA that was relevantly identical to the Programmer Guide, had the Programmer Guide as its original source and could not have been produced by Mr Richards’ claimed method of utilising storage dumps. 

    ·Despite the fact that ISI adduced evidence from other programmers involved in 2BDB2, none asserted authorship of that part of B2BRQA.

    ·Mr Richards accepts that the Programmer Guide was the source of the comment block.  That concession was inescapable and undermines Mr Richards’ original evidence about his method of creating B2BRQA.

    ·ISI maintains that there was no copying of the pages before and after the page containing the text in the Programmer Guide that was used in the comment block and relies on Mr Richards’ evidence of independent creation.  I do not accept Mr Richards’ evidence in this respect.  I do not accept that storage dumps used by Mr Richards were the source of the content of B2BRQA.  When faced with objective evidence that was inconsistent with his original assertions, Mr Richards simply disclaimed knowledge or changed his evidence.  Once it was established that the Programmer Guide was copied in part, the inference is clearly open, and I draw it, that it was consulted and copied, probably by Mr Richards, at least to the extent of creating B2BRQA.

17. ISI used the Database and System Administrator Guide in creating AMODDY.  ISI used the Programmer Guide in creating B2BRQA.

    Laches

18. ISI submits that CA’s conduct, in particular, its ‘deliberate delay… in bringing or even threatening proceedings’, has made it inequitable for CA to obtain the relief it seeks.  CA disputes this.

    Evidence

19. Mr Shuma gives evidence about his past knowledge of ISI, 2BDB2 and CA’s decision to commence legal proceedings.  The parties have both proceeded on the basis that Mr Shuma’s knowledge and belief was the relevant knowledge and belief of CA.

20. Mr Shuma says that he first heard about 2BDB2 in or around October 2001.  He agrees that he first became aware of it prior to an email of 19 October 2001 sent by Dale Russell and copied to him.  It was noted in that email that 2BDB2 ‘apparently let’s [sic] clients convert from VSAM programs using CA-Datacom/VSAM Transparency to VSAM programs using their transparency to DB2’ and that Datacom and DB2 could coexist during the conversion.  Mr Russell’s email attached a PowerPoint presentation (the Presentation).

21. Mr Shuma agrees that, in the Presentation, the claim was made that 2BDB2 was able to convert Datacom application programs to DB2.  Mr Shuma agrees that 2BDB2 was, to his knowledge in about 2001, the first product that emerged which might have the capability of doing so.  He agrees that the contents of Mr Russell’s email were a matter of interest to him and says that he assumes that he viewed the Presentation at the time.  He says that, if 2BDB2 was able to do what ISI claimed and if the statements made in the Presentation were true, this would have been of significant concern to CA.  However, he says that he ‘felt the Presentation was confused’ and that he ‘did not believe the statements that were made.’  He points to the references to VSAM in the Presentation, which, he says, detract from the suggestion that 2BDB2 could convert Datacom applications to DB2.  Although the Presentation listed two existing customers, State Street Bank and Beta, as customers of ISI, Mr Shuma says that he did not know whether ISI’s claim that State Street Bank and Beta were ISI customers was correct or not.

22. On 23 October 2001 Mr Shuma replied to Mr Russell’s email, noting that ISI had been attempting to market solutions to convert people from Datacom and IDEAL to DB2 for a while but that attempts had not been successful.  Mr Shuma said that ISI had a different “back-end” but that the “front-end” working was ‘fishy’.  He noted that the ISI descriptors could be used to describe CA’s VSAM-T front end (VSAM call interceptors) and that some of the same terms were used.  He queried whether there had been some ‘borrowing’ by ISI to build their product but described this suggestion as ‘just my two cents’.  At that stage, Mr Shuma maintains, it was not clear to him how it was claimed that 2BDB2 worked. 

23. Mr Shuma says that, in undertaking inquiries subsequent to Mr Russell’s email, he was informed about the difficulties that a customer experienced with 2BDB2, which led him to believe that the product was not of concern to CA. 

24. Mr Shuma continued to receive information from licensees during 2002.  That included information about the way in which 2BDB2 worked.  Mr Shuma concluded that the program centred on a rewrite of the calls to Datacom. 

25. Mr Shuma examined the ISI website in about July 2002.  He says that the information on that website did not concern him as he did not take the assertions there made seriously.

26. On 2 August 2002, Mr Russell asked Mr Shuma whether to pursue further the use of 2BDB2 by Beta.  He had no specific information about the source of 2BDB2 and Mr Shuma told him not do anything further. 

27. On 3 August 2002 Mr Shuma sent an email containing information with respect to ISI’s activities at Corp Systems.  This information was to the effect that ISI’s product catches the Datacom call and then routes it to Datacom or DB2 depending on the placement of data.  At that stage, the information was that there was no DB2 table in production.

28. In a series of emails around 5 February 2003, it is apparent that Mr Shuma was aware that ISI had partnered with IBM to try to convert Datacom clients to DB2 but that 2BDB2 had problems.  There was recognition that the ISI code intercepts the Datacom calls and then executes them against a DB2 table.  This solution was noted to work but was said to be ‘very resource expensive’.  Mr Shuma noted that the final step in the conversion would be conversion of the IDEAL/Datacom code to COBOL/DB2.  It is apparent that, at that stage, CA personnel including Mr Shuma were aware of problems with 2BDB2 and did not view it with concern as a competitor.  There was no understanding at that time of the means by which 2BDB2 was produced or the precise way in which it worked.

29. Mr Shuma says that during 2004, 2005 and 2006 he heard about Datacom licensees being approached by ISI.  Mr Shuma says that when trials or implementations of 2BDB2 occurred, CA encountered support difficulties with such use.  He maintains, however, that there was no information that caused CA to be concerned that there had been use of CA’s confidential information or copyright works in the creation of 2BDB2.

30. In an email in January 2006, Mr Shuma noted that:

    ·ISI was focusing on moving clients from Datacom to DB2;

    ·‘some of their products go very close to have reversed [sic] engineered our code’; and

    ·some ISI products seemed to “mirror” Datacom.

31. Mr Shuma agrees that, as at 2006, he regarded ISI in combination with DB2 as a source of commercial rivalry and that his view was that ISI offered products that went ‘very close to’ having reverse engineered CA’s code.

32. Mr Shuma says that ISI made an approach to CA for a commercial partnership in 2007.  He says that ISI ‘approached our senior people here in Australia and wanted help to convert Datacom clients’.  Mr Shuma says that in April 2007, ISI approached CA but that approach did not result in further discussion.  Another approach, initiated in December 2007 for discussion in January 2008, also came to nought following a cancellation and then a lack of response from ISI.

33. Towards the end of 2007, CA became aware of several production database crashes which CA research reported as involving internal aspects of Datacom, inside the database region and resulting from the activation of 2BDB2.  Mr Shuma formed the view that for 2BDB2 to insert itself into the middle of the flow of Datacom demonstrated a deep knowledge of how the internals of Datacom work, for which ISI must have had access to and used information about Datacom that, in Mr Shuma’s belief, was and is confidential to CA, including the CA URT Macros and the URT module, DBINFPR and the Datacom CICS TRUE.  Previously, Mr Shuma had been of the view that ISI was front-ending the Datacom applications by changing the CALL DBNTRY statements in the program to call SQL statements (by replacing the DBNTRY point in the program).  By the end of 2007, Mr Shuma formed the view that 2BDB2 allowed the Datacom application program to continue to issue the CALL DBNTRY and pass control via the URT (or DBCSVPR) to the DBINFPR program, which 2BDB2 had replaced with its own DBINFPR module, effectively placing 2BDB2 in the middle of two parts of the Datacom processing flow. 

34. Although Mr Shuma recognises that CA knew of the existence of 2BDB2 from late 2001, he says that CA was not aware of how the product was developed or how it functioned until late 2007/early 2008, when it came into possession of information that caused it to be concerned about a potential use of CA’s confidential information and copyright works.  That information was not sufficient to commence proceedings but was sufficient to commence preliminary discovery proceedings, which CA did on 7 October 2008.  Mr Shuma accepts that the perception of 2BDB2’s commercial success affecting CA’s future business, coupled with ISI’s previous approach to CA to act as a partner in selling ISI technology to displace Datacom, motivated the current legal proceedings. 

    Submissions

1. ISI says that by waiting until the end of 2008 to bring proceedings, CA intentionally delayed bringing any claim against ISI.  ISI says that the emergence of 2BDB2 was a matter of commercial concern to CA from as early as 2001 and that by at least 2002, through Mr Shuma, CA knew enough about how 2BDB2 worked to commence proceedings or at least proceedings for preliminary discovery.  ISI contends that CA made a conscious decision not to commence proceedings against ISI for at least six years because CA was of the view that 2BDB2 would not be a commercial threat as a result of what CA perceived as inefficiencies with it; CA only commenced proceedings when it realised that its commercial assessment was wrong. 

2. ISI submits that the passage of time has prejudiced ISI in the presentation of its case.  ISI identifies the prejudice it has suffered as follows:

   ·As a result of Mr Worboys’ death in January 2008, ISI has lost the benefit of his testimony, particularly in regard to B2BRQA and the 2004 and 2009 Macros.  If CA had not ‘sat on its hands’ until after that time, Mr Worboys would have been able to provide evidence on these aspects of CA’s case.

   ·Witnesses’ memories of what they did going back to 1996 have affected ISI’s proper defence of its case.

   ·ISI has lost the ability to identify some material located on the internet at the relevant times that is no longer accessible.

   ·If ISI had innocently come into possession of information that could be proved to be confidential, it would have known of this before it used it.

3. CA submits that the issue of laches was determined by Perram J in CA v ISI (No 2) because CA, in being granted preliminary discovery, made out the ground that it had insufficient information upon which to commence a proceeding. 

   Conclusion

4. CA’s evidence is that it only became aware of the likely nature of 2BDB2 when it was notified of problems with the running of Datacom when 2BDB2 was run concurrently with it, in about 2008.  I accept Mr Shuma’s evidence that prior to 2007 he did not have reason to believe and did not form a belief that CA’s copyright and confidential information had been used by ISI.

5. The question of laches and CA’s delay was an issue before Perram J in CA’s application for preliminary discovery in CA v ISI (No 2).  His Honour accepted that, in 2007, CA became aware of difficulties within a particular customer’s Datacom environment.  It was only then, his Honour concluded at [37], that CA began to countenance the possibility that 2BDB2 might have been created in inappropriate circumstances.  It was, his Honour said, only then that CA made inquiries and attempted to meet with ISI to discuss its concerns.  Justice Perram said that he discerned no substantive delay in CA’s conduct.

6. I agree with and accept Perram J’s conclusion.

   Conclusion on confidential information

7. CA relied upon identified misuses of the CA Information in contending that all of the CA Information was misused in the creation of 2BDB2.  I have found that CA has established the following unauthorised uses of the CA Information:

   ·ISI’s use of the Database and System Administrator Guide in creating AMODDY; 

   ·ISI’s use of the Programmer Guide in creating B2BRQA; and

   ·ISI’s use of the source code of the R9 CA URT Macros in creating the 1999, 2004 and 2009 Macros.

8. Even though I have identified these misuses of the CA Information, I am not prepared, based on the unauthorised uses that CA has established, to draw the broad inference that all of the CA Information was used in an unauthorised manner.  The evidence is insufficient to establish how much of the CA Information was otherwise used in 2BDB2 and Transparency.  CA has not established that the whole of the CA Information was used.

   TRADE PRACTICES

9. CA no longer presses what it had identified in its statement of claim and at trial as the First Representation and the Second Representation made by ISI.  It continues to claim that what it identifies as the Third Representation and the Fourth Representation made by ISI contravene ss 52 and 53 of the TPA.

   The Third Representation

10. The Third Representation is said by CA to be that Datacom will operate correctly when 2BDB2 is used.

11. Mr Shuma refers to statements made by ISI on it’s website as at 1 June 2010: 

    (a)‘2BDB2 provides a secure and low risk alternative [to Datacom]’;

    (b)‘enable your existing applications access that data in DB2, typically without changes to the application portfolio.  Your existing programs continue to access data via DATACOM access interfaces, but the underlying 2BDB2 code intercepts that access and processes the requests against DB2.  You gain all the reliability, maintainability and functionality of DB2 without the cost and risk of rewriting your applications’;

    (c)‘greatly reduce conversion schedule, resource requirements and costs’; and

    (d)‘our approach significantly reduces the risk of conversion-introduced errors and requires much less testing to ensure that no logic has been corrupted.  Due to application/data interdependencies, conversions are normally Big Bang with the complete portfolio being cutover into production at one time.  With 2BDB2, the conversion is done on a table by table basis’,

    (collectively, the Statements).

12. Mr Shuma contends that, based on his analysis of the WebCiss Report, the Statements are incorrect.  While his conclusions have been objected to and have been admitted only as to his opinion or subject to an objection as to weight, they are based on matters set out in his evidence that are not really in dispute.  Those matters include:

    ·problems that can be experienced and, Mr Shuma says, have been experienced in the implementation of 2BDB2 by Datacom licensees;

    ·2BDB2 dealing with undocumented changes as Datacom products change with new releases, with the consequence that the SQL translation processes and data table conversion processes face continual challenges;

    ·the complexities of dealing with and converting from a query language (Dataquery) and programming language (IDEAL) into another query language and programming language;

    ·the necessary processing resources to implement and utilise both Datacom and DB2; and

    ·the necessity of the licensee maintaining both Datacom and DB2 licences or undertaking the work necessary to remove all Datacom components fully (such as the URT) and rewrite all application programs (IDEAL) and queries (Dataquery)) in order to terminate the Datacom and IDEAL licences.

13. The WebCiss Report, in Mr Shuma’s view, demonstrates problems with Datacom applications when the 2BDB2 code is inserted into the environment.  CA relies on evidence from the WebCiss Report and Mr Shuma’s analysis of it (which relates to the initial problems encountered with Datacom by the use of 2BDB2 at Beta and CS STARS) in submitting that Datacom does not operate correctly when 2BDB2 is used.  CA points to specific items in the WebCiss Report which it says lead to the overarching conclusions that:

    ·For some of the items, an application that worked perfectly well with Datacom did not work at all after the conversion.

    ·Problems persisted over an extended period.

    ·Some of these failures are very serious.

    ·Some of the problems with Datacom persisted over an extended period.

14. ISI submits that there are a number of deficiencies with CA’s claim:

    1.The words of the Statements do not bear the meaning that CA seeks to place on them.

    2.CA has not identified any person who acted upon the Third Representation so as to cause any loss or damage to accrue to CA.  It is incumbent upon CA, in bringing a case of the kind identified by the High Court in Campomar Sociedad, Limitada v Nike International Ltd (2000) 202 CLR 45 at [101] as ‘representations to the public at large or to a section thereof’, to isolate the ordinary or reasonable members of that class so that an inquiry can be made with respect to this hypothetical individual (Campomar at [103]). CA has adduced no evidence concerning the effect of the Third Representation on any person.

    5.CA has not adduced sufficient evidence to sustain the Third Representation.  There is no sufficient evidence comparing the operations of Datacom for any particular customer before and after that customer acquired 2BDB2.  CA’s case rests entirely upon the subjective evidence of Mr Shuma, which was admitted as opinion or assertion only and not as evidence of the facts asserted.  There is no objective basis upon which the Court can judge whether the alleged problems for Datacom with the operation of 2BDB2 are any more or less frequent or severe than problems ordinarily associated with the installation of new software at any site or, indeed, until the normal operation of Datacom without 2BDB2.

    6.It does not follow, and has not been established, that any reasonable recipient of the Third Representation, that is, a customer large enough to use an expensive mainframe and have a program it wishes to migrate away from Datacom, would be misled by a generic statement of the kind of the Third Representation.

    7.CA has not established the likelihood that a customer would discontinue Datacom as a result of the Third Representation.  CA has not demonstrated a likelihood of loss or damage, or any actual loss or damage. 

15. I accept ISI’s submissions in (2) to (5) above. In particular, CA has not adduced evidence of the meaning of the Third Representation as understood by the ordinary and reasonable member of the class of recipients. Even accepting Mr Shuma’s analysis, CA has not established a contravention of ss 52 and 53 by reason of the Third Representation.

    The Fourth Representation

16. The Fourth Representation is said to be that ISI has represented that Datacom is “dying”.  CA’s statement of claim particularises the content of emails sent by ISI to CA licensees on 21 April 2004, as well as a statement allegedly present on the ISI website up to at least 18 July 2008.

17. ISI denies making the statement on its website.  ISI admits, however, that it made the Fourth Representation on one occasion in an email sent by a customer advocate of ISI, John Hammill, on 21 April 2004 but says that the Fourth Representation was withdrawn on 30 April 2004 in an email of that date from Kim Pinkerton, a director of ISI.  Nevertheless, CA says that ISI repeatedly made the Fourth Representation from 2007 to March 2011.  By an undertaking to the Court filed on 9 June 2011, ISI permanently undertakes not to make the Fourth Representation.

18. ISI submits that there are a number of deficiencies with CA’s claim:

    ·The representation made on 21 April 2004 was made to identified individuals and was later retracted.  CA did not call any of the recipients to establish that they acted in any way upon the Fourth Representation, in the context of the retraction, so as to cause any loss or damage to CA.

    ·CA’s case on the Fourth Representation made after 21 April 2004 appears to be a representation made to the public at large.  As with the Third Representation, CA has failed to isolate the ordinary or reasonable members of that class so that an inquiry can be made with respect to this hypothetical individual as is required by Campomar.

    ·CA has made no attempt to demonstrate that it suffered any loss and damage by the making of the Fourth Representation.

    ·The words relied on by CA do not bear the meaning that CA wishes to place on them.

    ·To the extent that the Fourth Representation is made to the effect alleged, it is accurate.

    ·The matter is historical: the email dated 21 April 2004 was withdrawn nine days later; there is an undertaking to the Court not to make any representation to the effect of the Fourth Representation; and there is no evidence to support that the Fourth Representation has been repeated.

19. Even if the Fourth Representation has been repeated after it was withdrawn in 2004, as to which there is no direct evidence, CA has not established the effect or likely effect of such a representation on a recipient. Nor has it established any loss or damage flowing from such a representation. CA has not established a contravention of ss 52 and 53 of the TPA by reason of the Fourth Representation.

    CONCLUSION

20. By reproducing the R9 CA URT Macros in the form of the 2004 Macros and the 2009 Macros, ISI has infringed CA’s copyright in the R9 CA URT Macros.  The 1999 Macros and the 2011 Macros do not infringe CA’s copyright in the R9 CA URT Macros.  The ISI Replacement Macros do not infringe CA’s copyright in Datacom.

21. The breaches of confidence that CA has established are:

    ·the use of the Database and System Administrator guide in creating AMODDY;

    ·the use of the Programmer Guide in creating B2BRQA; and

    ·the use of the source code of the R9 CA URT Macros in the creation of the 1999, 2004 and 2009 Macros.

22. CA has not established that ISI has contravened ss 52 and 53 of the TPA.

23. These reasons are to be published in draft form.  I will give the parties the opportunity to consider any proposed redactions for confidentiality.

I certify that the preceding seven hundred and eight (708) numbered paragraphs are a true copy of the Reasons for Judgment herein of the Honourable Justice Bennett.

Associate:

Dated:       3 February 2012