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

CA, Inc. v ISI Pty Limited [2012] FCA 35 | Case summary | Zoe

[2]

Database management systems 7 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. 8 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. 9 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. 10 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. 11 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).

[3]

Datacom 12 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. 13 Some of Datacom's licensees may defer taking, or may not take, new releases of Datacom. 14 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). 15 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. 16 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". 17 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. 18 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. 19 CA gives Datacom licensees access to certain information that it claims is confidential so that the Datacom licensees' programmers can write application programs. 20 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. 21 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. 22 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.

[5]

2BDB2 25 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. 26 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. 27 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. 28 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. 29 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.

[6]

Chronology of Creation 30 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. 31 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. 32 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. 33 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. 34 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. 35 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. 36 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. 37 In May 2001, ISI entered into a licence agreement with Beta which stipulated that ISI owned the copyright and confidential information in 2BDB2. 38 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.

[19]

URTs 56 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'. 57 The choice to use a URT was a design decision by the Datacom development group to enable user application programs to access Datacom databases. 58 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. 59 Some applications and data tables may share a URT while other applications and data tables use different URTs. 60 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. 61 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. 62 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. 63 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. 64 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. 65 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. 66 The URTs, and DBCSVPR in CICS application programs, are part of every application program created to access the Datacom database.

[20]

RAAT and SAAT 67 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. 68 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. 69 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. 70 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. 71 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. 72 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.

[21]

CA URT Macros 73 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. 74 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. 75 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. 76 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. 77 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. 78 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. 79 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. 80 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. 81 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.

[22]

2BDB2's operation 82 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". 83 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. 84 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. 85 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. 86 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. 87 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. 88 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. 89 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.

[24]

Use of ISI Replacement Macros 94 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. 95 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. 96 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. 97 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. 98 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. 99 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. 100 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. 101 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.

[27]

Is Datacom a "computer program" or otherwise a "literary work" without resort to the definition of "computer program"? 109 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. 110 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. 111 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". 112 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. 113 CA also contends that Datacom is a "literary work" without resort to the definition of "computer program". 114 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). 115 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".

[28]

Are the CA URT Macros a "computer program"? 116 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. 117 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. 118 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'. 119 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. 120 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). 121 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. 122 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'. 123 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. 124 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. 125 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. 126 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. 127 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. 128 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. 129 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. 130 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. 131 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. 132 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. 133 ISI says that it is the Datacom licensee's requirements that design the URTs; the CA URT Macros are merely consulted where appropriate. However, Mr Lynn explains that the URTs are created by the CA URT Macros to conform to the Datacom licensee's requirements. Once the Datacom licensee's programmer or DBA works out how he or she wants to store and retrieve the Datacom licensee's information based on the Datacom licensee's requirements, the CA URT Macros are used as a 'shorthand resort' by the programmer/DBA to create the interface between the Datacom licensee's own application and Datacom itself. Mr Lynn confirms that that it is the programmer/DBA's choice whether or not to put the DBURINF, DBURTBL and DBUREND Macros into the SYSIN and, if so, the programmer/DBA can choose what options to put in the parameters for these macros. 134 ISI contends that the interface between the Datacom licensee's own application and Datacom itself is the product of the use of the CA URT Macros but that the CA URT Macros are not a working part of that interface. ISI points out that the CA URT Macro definitions consulted in the process of creating the URT in object code cannot be "run" and are not "executable" on the mainframe; the macros' definitions are not assembler source code and cannot of themselves be assembled or turned into object code. ISI emphasises that the CA URT Macro definitions are merely a block of text that is consulted by the assembler during the process of assembly; the assembly is of assembler source code, which is written by the customer. 135 ISI says that the CA URT Macros constitute no more than a point of reference for a Datacom licensee to construct a load module of the licensee's design, which in turn, once assembled and link edited, allows the Datacom licensee's application to bring about a certain result, which is the making of a call to Datacom to provide particular information from the Datacom licensee's database presented in a way designed by the Datacom licensee. ISI emphasises that it is the Datacom licensee's application that makes the call to Datacom and that the CA URT Macros are only involved 'by consultation'. This is the basis for ISI's contention that the CA URT Macros on their own do not constitute a complete "set of statements or instructions" which themselves bring about any relevant "result". 136 ISI further submits that the CA URT Macros are not a "set". Copyright in a computer program is, ISI says, to be found in the entirety of a computer program and not in part of it, otherwise 'every snippet of code that was ever written' could potentially be a computer program because each takes a necessary and inexorable part in some particular function. According to ISI, it is the whole process involving the CA URT Macros, the building of the URTs, the process of assembly and the link editing that could conceivably be described as a "set", as this produces something that is executable. ISI emphasises that the set needs to be taken "together" to constitute the population of things, items or steps necessary to achieve the result. 137 CA contends that ISI's argument ignores the proper meaning of "set", which it says is inclusive rather than exclusive. All that is required, CA says, is that the statements or instructions in issue relate to one another; there is no requirement that they be independent of other statements or instructions not in issue. 138 In this respect, the understanding of what constitutes a "set of instructions" involves an understanding of the manner in which a computer executes the computer programs. In Data Access, the High Court considered a previous definition of "computer program" inserted into the Act by the Copyright Amendment Act 1984 (Cth), which included the phrase 'expression … of a set of instructions'. Chief Justice Gleeson, McHugh, Gummow and Hayne JJ emphasised the importance of the fact that a computer operates because of the expression of complex problems in terms of a sequence of a larger number of simple operations. As stated at [34]-[36]: A "set of instructions" will not cause a computer to execute a particular function unless that set of instructions can be ultimately expressed in terms of a sequence of the logical operations which are hard wired into the computer... [The set of instructions is to be perceived at] a high level of abstraction. Such a level of abstraction is required in order to express what are millions of simple logical operations in terms of a manageable number of more complex instructions which themselves are reducible to these simple logical operations. 139 At [53] their Honours noted that the meaning of the phrase "expression… of a set of instructions" was referred to in the Explanatory Memorandum to the Copyright Amendment Act 1984 (Cth) as follows: the phrase "expression… of a set of instructions" is intended to make clear that it is not an abstract idea, algorithm or mathematical principle which is protected but rather a particular expression of that abstraction. The word "set" indicates that the instructions are related to one another rather than being a mere collection. (emphasis added) 140 In Dais, Jessup J concluded at [36] that the phrase "set of instructions" has the same meaning in the current definition of the Act, which was inserted by the Copyright Amendment (Digital Agenda) Act 2000 (Cth), as in the previous definition. His Honour stated: I can think of no reason why the concept of a "set", which was utilised by the 1984 definition, should be differently viewed in the 2000 definition. As the explanatory memorandum for the 1984 amendment stated, the word "set" indicated "that the instructions are related to one another rather than being a mere collection". It is, therefore, the fact of interrelation, rather than the ability, unaided, to bring about the result, that should be treated as giving a practical connotation to the concept of a "set" in any particular case. What should be the nature of the relationship? Clearly, the use to which the statements or instructions are put. If the statements or instructions are co-operatively used to bring about a certain result, that should be regarded as sufficient to satisfy the definition. That they require also the participation of other components of software, be they statements, instructions or otherwise, should not, in my view, be regarded as disqualifying. 141 With respect, I agree with Jessup J. 142 The fact that the CA URT Macros require the participation of other components in order to bring about a result in the mainframe computer does not disqualify the CA URT Macros from being a "computer program" (Dais at [31], [35] and [39]). ISI's approach would, as CA contends, exclude from the definition of "computer program" a "set of statements or instructions" that require other components in order to bring about a result. It seems that this would, in effect, exclude all sets of statements or instructions written in any code other than object code because all source code requires another program to compile or assemble the source code into object code before producing any result. The definition of "computer program" does not exclude such statements or instructions, as is evident from the words 'to be used… indirectly in a computer in order to bring about a certain result'. 143 The definition of "computer program" provides that the set of statements or instructions is to be used in order to bring about a certain result. This result can be brought about either directly or indirectly. The inclusion of the word "indirectly", unconfined as to scope, in the definition of "computer program" is critical. The Shorter Oxford English Dictionary (5th ed, Oxford, 2002) defines "indirectly" to mean 'by indirect action, means, or connection; through an intervening person or thing'. In effect, ISI's submission is that the involvement of the CA URT Macros in bringing about a certain result in the mainframe computer is too withdrawn and too removed from the result even to come within the word "indirectly". However, this incorrectly seeks to read into the definition of "computer program" a threshold requirement for the word "indirectly" that is not reflected either in its ordinary meaning or in the way in which it is used in the definition. 144 The evidence indicates that the DBURGEN Macro alone could not produce the URT object module without the assistance of all of the External Macros in the batch environment and the DBURSTR, DBURTBL and DBUREND Macros in the CICS environment. The External Macros lead the application programmer through the process of creating the required URT by answering a series of questions. The DBUREND Macro invokes the DBURGEN Macro. This evidence establishes that the CA URT Macros are 'related to one another rather than being a mere collection' and are 'co-operatively used to bring about a certain result' (Dais at [36]). The CA URT Macros therefore constitute a "set" of statements or instructions. 145 The CA URT Macros are used to create the URT, which brings about a result in the Datacom licensee's mainframe computer. 146 The fact that the CA URT Macros require the use of several other components in order to reach that result, including both of what Mr Turgeon describes as the Datacom licensees' and Datacom's "labour forces", does not preclude the CA URT Macros from being a "computer program". The participation of these other components simply means that the result attributable to the CA URT Macros is brought about "indirectly" in this case. 147 ISI submits that it is only the whole process involving the CA URT Macros, the building of the URTs, the process of assembly and link editing that could conceivably be described as a "set" given that it is the combination of these components that produces something executable. This submission again overlooks the effect of the word "indirectly" in the definition of "computer program". The fact that a larger group of statements or instructions of which the identified set of statements or instructions forms part may also bring about that result does not preclude the identified set of statements or instructions from being a "computer program", provided that it meets all of the requirements of the definition. As Jessup J observed in Dais at [31], '[a]s a matter of ordinary language, a thing might be used to bring about a certain result notwithstanding that it is but a component in a collection or sequence of things which together bring about the result'. 148 The CA URT Macros are a "computer program" within the meaning of the Act. It follows that they are a "literary work" within the meaning of the Act. Nevertheless, I will also briefly make some observations on whether the CA URT Macros can also be classified as a "literary work" without reliance on the "computer program" definition.

[29]

Are the CA URT Macros a "literary work" without resort to the definition of "computer program"? 149 As mentioned above, s 10(1) of the Act defines "literary work" to include: (a) a table, or compilation, expressed in words, figures or symbols; and (b) a computer program or compilation of computer programs. 150 CA apparently only presses for a finding as to "literary work" if I find that the CA URT Macros are not a "computer program". 151 CA submits that as "literary work" is defined broadly in s 10(1), the CA URT Macros, whether taken individually or collectively, qualify as "literary works" apart from their characterisation as "computer programs" for 'the reasons advanced by Mr Turgeon'. 152 ISI submits that the lack of evidence adduced by CA to allow the Court to determine how the CA URT Macros relate to Datacom means there is no merit in attempting to dissect what would appear to be a 'tiny piece' of a larger literary work and recognising it as a literary work by itself. ISI also contends that it is inappropriate for the CA URT Macros to qualify as a literary work if they do not fall within the definition of computer program. 153 CA's legal submissions in support of its "literary work (other than computer program)" case are scarce. CA cites the authorities outlined above at [114]. In addition, CA points out that the CA URT Macros are legible and can be 'read down'. CA says that the fact that the CA URT Macros contain a plethora of abbreviations and symbols does not prevent them from being a literary work. 154 CA has not provided useful or meaningful submissions on the basis for classifying the CA URT Macros, either individually or collectively, as "literary works (other than computer programs)". Notwithstanding the evidence of authorship and originality detailed below, CA did not explain why the CA URT Macros, individually or collectively should be considered as a literary work. Mr Turgeon's evidence summarises the function and contents of each of the CA URT Macros. His evidence is not to be taken as legal submission on whether the CA URT Macros, individually or collectively, are literary works. Nor has it been explained by CA why his evidence supports such a submission. 155 I concluded above that the CA URT Macros are a "computer program". The evidence and submissions as to the taking of a substantial part of the CA URT Macros by ISI were premised on the CA URT Macros being a "computer program", with accompanying full functionality, and not on their characterisation as a "literary work (other than computer program)". For the reasons outlined at [115] above, it is unnecessary for me to determine whether, taken collectively, the CA URT Macros are a "literary work" apart from their characterisation as a "computer program" and, based on the present state of the evidence and submissions, I am not in a position to do so. 156 Although CA does not contend that the CA URT Macros, taken individually, are "computer programs", it apparently contends that each is a "literary work" apart from any characterisation as a "computer program". However, CA: did not make submissions on why each of the CA URT Macros should be classified as a "literary work"; and did not attempt to explain the basis for dissecting a small part of a work, be it Datacom or the CA URT Macros collectively, and recognising it as a separate and distinct "literary work". 157 For these reasons, CA has not established that any of the CA URT Macros, taken individually, is a "literary work".

[35]

Infringement 173 Under s 13(2) of the Act, copyright in relation to a particular work is the exclusive right to do certain acts in relation to the work. 174 CA alleges that ISI has contravened s 36(1) of the Act by reproducing both the CA URT Macros and Datacom in a "material form" which, under s 31(1)(a)(i) of the Act, is an exclusive right of the copyright owner. Section 10(1) of the Act defines "material form" to include a "substantial part" of the work. It is necessary for CA to show that ISI has reproduced the whole or a substantial part of each copyright work. 175 A work is "reproduced" if there is a sufficient degree of objective similarity between the copyright work and the work said to infringe and there is "some causal connection" between the form of the allegedly infringing work and the form of the copyright work (SW Hart & Co Pty Ltd v Edwards Hot Water Systems (1985) 159 CLR 466 at 472 per Gibbs CJ, with whom Mason and Brennan JJ agreed). 176 In order to qualify as a "substantial part", the part taken must be an original part of the original whole (IceTV Pty Ltd v Nine Network Australia Pty Ltd (2009) 239 CLR 458 at [30]-[32] per French CJ, Crennan and Kiefel JJ and at [154]-[171] per Gummow, Hayne and Heydon JJ). In respect of literary works generally (and subject to the qualification below in respect of computer programs), attention is directed to the originality in the expression of the part of the work taken (IceTV at [39] per French CJ, Crennan and Kiefel JJ). 177 As noted by Gummow, Hayne and Heydon JJ in Ice TV at [157], the statutory requirement that the part of the work taken must be substantial assumes that there may be some measure of legitimate appropriation. 178 It is apparent from IceTV and Data Access that special considerations may arise when considering whether or not a substantial part of a "computer program" has been taken. In IceTV, Gummow, Hayne and Heydon JJ referred to the importance of function in the determination of substantial part for "computer programs". Although the current definition of "computer program" introduced by the Copyright Amendment (Digital Agenda) Act 2000 (Cth) does not expressly refer to "function", unlike the former definition introduced by the Copyright Amendment Act 1984 (Cth), their Honours observed at [158] that the current definition nevertheless has a functional aspect. 179 In order to determine whether a substantial part of a computer program has been reproduced, the question is not whether one necessary integer of a computer program is present (IceTV at [159] per Gummow, Hayne and Heydon JJ; Data Access at [85]-[87] per Gleeson CJ, McHugh, Gummow and Hayne JJ). In IceTV, their Honours said at [159] that what is required is 'the need for some process of qualitative abstraction of the material features of the computer program in question'. This was in the context of a reaffirmation that what is entitled to protection is not the idea of the author but the fixed expression of that idea. 180 I now turn to consider whether the ISI Replacement Macros are a reproduction of a substantial part of Datacom and/or the CA URT Macros. For the purposes of the latter comparison, the parties' evidence and submissions concentrated on the CA URT Macros of release 9.0 of Datacom (R9 CA URT Macros).

[37]

Evidence and submissions on whether the 1999 Macros reproduce a substantial part of the R9 CA URT Macros 186 Mr Melito accepts that the 1999 Macros appear to have been based on the R9 CA URT Macros and agrees that, textually, 'they are very close'. Mr Turgeon agrees with Mr Melito and adds that in his view, the 1999 Macros are a copy of the R9 CA URT Macros and provide the base from which the 2004 and 2009 Macros were derived. The 1999 Macros even include reference to CA and contain the same misspelling of the word "occurrence". Mr Turgeon expresses the opinion that the 1999 Macros are the R9 CA URT Macros, renumbered and then subjected to routine maintenance. However, he also speculates, in evidence seized upon by ISI, that ISI 'took a copy of earlier "release 9" [CA URT Macros] that, not exactly, but closely, match the source code [of the R9 CA URT Macros]'. 187 CA accepts that the 1999 Macros were never supplied in Australia as part of any product. Accordingly, as noted by ISI, CA faces two barriers to a finding that the 1999 Macros have infringed CA's copyright in the R9 CA URT Macros. First, there is no direct evidence to support CA's contention that the 1999 Macros were actually a "reproduction" of the R9 CA URT Macros in material form (s 31(1)(a)(i) of the Act), which means that there is no evidence that ISI has done an act comprised in the copyright in Australia, as is required by s 36(1) of the Act. Secondly, s 134(1) of the Act relevantly provides that 'an action shall not be brought for an infringement of copyright… after the expiration of six years from the time when the infringement took place'. These proceedings commenced on 11 March 2010. 188 At the time that ISI was present at Beta converting Datacom to DB2, Beta was using release 9.0 of Datacom. Based on Mr Richards' evidence, ISI accepts that Mr Worboys was likely the creator of the 1999 Macros. However, ISI does not accept CA's assertion that Mr Worboys created the 1999 Macros at Beta, nor that ISI took "ownership" of the 1999 Macros. 189 CA submits that, given the role of the 1999 Macros in the creation of the 2004 Macros (as will be detailed below), the Court should draw the inference that the 1999 Macros were available to Mr Worboys in Australia on the ISI mainframe or source code repository in 2004 when he was creating the 2004 Macros. It is therefore more probable than not, CA says, that the 1999 Macros were on ISI's mainframe in June 2004 and, accordingly, infringed CA's copyright in the R9 CA URT Macros. In particular, CA relies upon Mr Richards' evidence that he had access to the 2BDB2 source code library from 2004 by a terminal emulator that runs on Windows and that he found the 2004 Macros on ISI's server when he and Mr Worboys worked on the 2009 Macros. 190 ISI says, in summary, that: It is likely that Mr Worboys obtained the 1999 Macros in the USA, outside the territorial reach of the Act. As indicated by Mr Turgeon, the 1999 Macros correspond to a pre-release version of the R9 CA URT Macros, which themselves were released in October 1996. If the creation of the 1999 Macros occurred in 1996, this was prior to the creation of 2BDB2. There is no evidence that any Datacom licensees who were ISI's customers received the pre-release R9 CA URT Macros. There is therefore no evidence that Mr Worboys obtained these macros via ISI or an ISI customer. CA has not established that it is more likely than not that ISI made the reproduction rather than its contractor, Mr Worboys, acting on his own behalf. The evidence is that the first time that ISI received any macros that may be correlated with the 1999 Macros was when Mr Worboys supplied ISI with the 2004 Macros in June 2004. CA has delayed any action in respect of the CA URT Macros for almost 10 years, which has deprived ISI of the chance to call Mr Worboys, and means that CA is asking the Court to draw inferences from nothing more than mere conjecture. ISI is not liable for what Mr Worboys did in the process of creating the 2004 Macros for ISI. It follows that the only possible reproduction by ISI was by way of its supply of the 2004 Macros and the 2009 Macros to ISI's customers. 191 I reach conclusions on this aspect of the case commencing at [308] below.

[38]

Evidence and submissions on whether the 2004, 2009 and 2011 Macros reproduce a substantial part of the R9 CA URT Macros 192 This section of the reasons involves an outline of the evidence and submissions on whether each of the remaining versions of the ISI Replacement Macros, that is, the 2004, 2009 and 2011 Macros, constitutes a reproduction of a substantial part of the R9 CA URT Macros. The experts, Messrs Turgeon and Melito, gave evidence based on a comparison of the R9 CA URT Macros with the ISI Replacement Macros. Both parties addressed their submissions to these comparisons. Substantial submissions were also directed to whether the 2011 Macros even amount to a reproduction (let alone of a substantial part) of the R9 CA URT Macros. 193 The evidence on substantial part was extensive and involved detailed technical comparisons that were used to support the conclusions drawn by Messrs Turgeon and Melito. It is sufficient, in general, to focus on the experts' conclusions based on their respective comparisons. Those comparisons deal with the degree of objective, textual similarity between the 2004, 2009 and 2011 Macros and the R9 CA URT Macros, in addition to considering the functionalities of the different macros. 194 Much of the evidence focused on a comparison of the individual macros of the R9 CA URT Macros and the individual macros of the different versions of the ISI Replacement Macros. Although the individual macros were analysed in the parties' submissions, the submissions were generally directed to the CA URT Macros as a "set of instructions". 195 In the course of these reasons, where I refer to an individual macro from either the R9 CA URT Macros or the ISI Replacement Macros, I will first include an identifier, followed by the name of the macro. For instance, the DBURGEN Macro from the R9 CA URT Macros is referred to as the R9 DBURGEN Macro, while the DBURSTR Macro from the 2004 Macros is referred to as the 2004 DBURSTR Macro. 196 The assessment of whether the ISI Replacement Macros reproduce a substantial part of the CA URT Macros involves a consideration of both qualitative and quantitative elements. As stated earlier, a qualitative assessment involves consideration of functionality, while a quantitative assessment involves consideration of textual similarity. 197 In a very general sense, the qualitative assessment of what has been reproduced is the same for each version of the ISI Replacement Macros where the base function is maintained, while the quantitative assessment of what has been reproduced is different for each version of the ISI Replacement Macros, as each version is textually different from the previous version. Accordingly, the structure of the reasons in these sections involves a general discussion of the evidence and submissions on the qualitative comparison between the R9 CA URT Macros and the ISI Replacement Macros, followed by a discussion of the evidence and submissions relating to each version of the ISI Replacement Macros, which incorporates both quantitative and qualitative elements. Following this, I reach conclusions on whether each version of the ISI Replacement Macros constitutes the reproduction of a substantial part of the R9 CA URT Macros. 198 Before undertaking the assessment, it is necessary to make some observations on the experts' approach to the assessment of substantial part. 199 CA contends that Mr Melito's approach to the comparison of the CA URT Macros and the ISI Replacement Macros is 'fundamentally flawed' because Mr Melito evaluates the form, function and differences between the two sets of macros, when instead he should have been focusing on the similarity between them. Accordingly, CA submits, Mr Turgeon's evidence is to be preferred over Mr Melito's evidence. 200 Generally and except where noted below, where there is a difference of opinion between Messrs Turgeon and Melito, I prefer the evidence of Mr Turgeon, which is more focused, of greater clarity and more objective. Also, I find it more helpful, in view of the issues in the case and the ongoing need for 2BDB2 to be able to access the URTs, to consider the similarities (Mr Turgeon) rather than the differences (Mr Melito) between the sets of macros. This is particularly relevant where lines of data in the R9 CA URT Macros were retained in the ISI Replacement Macros despite their lack of any utility in the functioning of the ISI Replacement Macros. There are, however, matters which Mr Turgeon does not consider or does not explain and as to which Mr Melito gives evidence. I generally accept Mr Melito's evidence except where it conflicts with that of Mr Turgeon. Nevertheless, Mr Melito gives detailed consideration to the 2011 Macros, while Mr Turgeon's evidence on this topic is more perfunctory. He states a conclusion but does not support it with detailed analysis, unlike Mr Melito. As to the 2011 Macros, I prefer the evidence of Mr Melito.

[39]

Functionality and role of the ISI Replacement Macros 201 Mr Richards explains his understanding of the role of the CA URT Macros in generating the URTs. He says that when using Datacom, a URT is generated by writing a short assembler language program using macros supplied as part of Datacom (the CA URT Macros). The names of the CA URT Macros have to be included in a specific order and given specific parameters that set out all necessary information about the relevant database. It is, he says, necessary to follow exact syntax for assembler language for the URT to operate properly. The URT must be turned into a URT module that is capable of being linked into the application programs written to run on the MVS operating system. It is in this process that the CA URT Macros play a role. Parameters that appear alongside the particular CA URT Macro are also substituted into the relevant positions defined within the particular CA URT Macro. The DBA uses the CA URT Macros as part of Datacom and specifies the parameters that are needed to define the use that the resulting URT needs to perform. If this is done correctly, a URT is produced and then supplied to the application programmer. In Mr Richards' experience, URTs could remain in use for years without updating or change. 202 The user's URT and DBNTRY subroutine are part of the means by which the user's application program accesses the data tables. Mr Richards refers to the fact that Datacom uses "common and generic" names such as "stub". He says that in defining an "entry point" for the stub code labelled DBNTRY, Datacom uses "standard MVS assembly language". This seems to contrast with the evidence that DBNTRY was a term unique to Datacom. 203 Mr Richards explains the role of the ISI Replacement Macros in replacing the CA URT Macros. He says that the intent for creating the ISI Replacement Macros was to allow 2BDB2 clients to reassemble their existing source URTs once they removed Datacom from their system in the event that the existing assembled URTs had to be removed as part of removing Datacom. Mr Richards also says that: The intent was to provide macros that produced the minimum amount of functionality in the URT module format, which was formerly used and still expected by an application originally written to access Datacom, that would be needed to allow all calls to be sent to DB2 instead. In short, a URT of some description was required because the application programs expected it and it had to be in the expected format. 204 Mr Richards says that in order for the ISI Replacement Macros to be able to be used with the client's existing URTs, they had to have the identical names to the CA URT Macros and had to be defined to "accept" all of the parameters that clients used in their URTs. They had to replicate the result of any logic performed by the CA URT Macros and had to produce a DBNTRY stub in the URT to which control could be passed. They had, in effect, to mimic the CA URT Macros to make 2BDB2 efficient and less expensive and to maximise compatibility for customers' existing application programs. Mr Richards' understanding is that the majority of the parameters supported by the CA URT Macros and hence required to be defined for the ISI Replacement Macros were ignored by the ISI Replacement Macros. Mr Richards says that the replacement stub generated by the ISI Replacement Macros called the 2BDB2 replacement module and not Datacom's DBINFPR. 205 Mr Melito also says that each of the ISI Replacement Macros must have the same names as the corresponding CA URT Macro it is replacing in order to replace it. 206 Mr Melito expresses the opinion that CA chose to use macros to make the addition of new features in new releases of the software and the installation process easier for its customer base and that the use of URTs and the CA URT Macros was a "standard" set by CA. He also says that, in his view, the use of the five macros was "arbitrary". This accords with the evidence of Mr Lynn outlined at [169]. 207 Mr Melito gives his opinion on how one would go about creating a set of macros that could operate with Datacom to perform similar functions to the existing CA URT Macros. He says that a developer would initially 'err on the side of caution and include more rather than less functionality, like error checking and setting global variables'. With experience and confidence, there may be more removal. This is how Mr Melito explains how the ISI Replacement Macros evolved until the 2009 Macros. 208 According to Mr Melito, the purpose of the ISI Replacement Macros is to replace the CA URT Macros once there has been complete migration from Datacom to DB2; that is, when all data have been migrated and the customer no longer has any Datacom data tables in production. Until that time, 2BDB2 relies on the fact that any new URTs will be generated by the CA URT Macros. Accordingly, the Datacom URTs must remain until complete migration in order that the user's application program will continue to run properly after Datacom is removed. Mr Melito says that a URT generated by the ISI Replacement Macros will not work with Datacom tables. 209 The ISI Replacement Macros generate replacement URTs to be used instead of the URTs generated with CA URT Macros when the latter have been removed. The ISI Replacement Macros must maintain compatibility and therefore mirror, to that extent, the URTs generated by the CA URT Macros. This enables the application program to be used in its existing form without changing its source code or having to recompile it. 210 Mr Melito says that the ISI Replacement Macros only need to support those parameters that are needed for compatibility with application programs and with DB2, unless the customer wishes to retain Datacom as well as DB2. It follows that the ISI Replacement Macros need only accommodate what is actually required by a particular application program that is already in production and do not need what Mr Melito describes as the 'myriad of scenarios that were encountered during initial development and testing of the URT[s]'. 211 Although Mr Melito's view is that, ideally, the ISI Replacement Macros should support all parameters that the CA URT Macros support, neither the 2004 Macros nor the 2009 Macros support every such parameter. He speculates that some are ignored because ISI customers do not use those parameters in their SYSIN, or their original function in Datacom is not relevant to DB2, or both. He also observes that if 2BDB2 did not support Datacom parameters, application programs using the CA URT Macros would not work as expected. 212 Mr Melito also points to variables in the ISI Replacement Macros that are not present in the R9 CA URT Macros. 213 ISI contends, based on the above evidence, that only those parts of the CA URT Macros that are necessary in order for the ISI Replacement Macros to operate to generate a URT are identical, and that only those parts of the URT that are needed to allow the URT to operate with existing Datacom based application programs are identical. 214 CA approached the question of the taking of a substantial part as a question of examining the functional aspects of the CA URT Macros and the ISI Replacement Macros, relying primarily on Mr Turgeon's evidence. 215 Mr Turgeon notes that at the time that the ISI Replacement Macros are to be used to create new macros for Datacom application programs, Datacom is no longer in the customer's system. Datacom compatibility arises because 2BDB2 code is architecturally reliant on that format. 216 Mr Turgeon says that the ISI Replacement Macros accept exactly the same operands as the CA URT Macros. 217 Mr Turgeon maintains that both the CA URT Macros and the ISI Replacement Macros have as their purpose the creation of a URT for a Datacom application program and that, apart from error checking, they 'do so by exactly the same means'. Mr Turgeon says that the 'certain result' brought about by the source code comprising the CA URT Macros collectively is the URT object code module (BEGIN) which contains the URT and the DBNTRY stub. CA relies upon Mr Turgeon's conclusion that the ISI Replacement Macros, collectively, perform the identical function to the CA URT Macros, that is, they create BEGIN which contains the URT (with the same basic format as the Datacom URT) and the DBNTRY stub. The 2BDB2 replacement URT is generated in this manner, Mr Turgeon says, so that the code originally used to parse the Datacom URT still functions properly after Datacom is removed. 218 In summary, Mr Turgeon's evidence is that the CA URT Macros and the ISI Replacement Macros are not identical but that they operate identically. 219 ISI strongly contends that Mr Turgeon's approach to the assessment of substantial part is flawed in this respect. Bearing in mind that the ISI Replacement Macros produce a stub containing only DBNTRY and BEGIN programs, ISI points to Mr Turgeon's concession that although the stub code contained in a URT produced by the R9 CA URT Macros contains functionality in addition to the DBNTRY and BEGIN programs, he did not undertake an evaluation of it in his expert reports. He accepts that he did not look at or compare 11 of the 13 entry points that occur in the Datacom stub. That is, Mr Turgeon's substantial part comparison, for example, is only between the portions of the R9 DBURGEN Macro dealing with the DBNTRY and BEGIN programs and the ISI Replacement Macros dealing with those two programs. 220 ISI points to Mr Melito's evidence that there are at least 11 other programs that may potentially be placed into the Datacom stub upon assembly using the R9 CA URT Macros, all of which have function. It is worthwhile examining the evidence of Mr Melito cited by ISI on this topic more closely. 221 In his first affidavit, in discussing the R9 DBURGEN Macro, Mr Melito states: The lines between 74 and 1130 contain macro statements that define the different varieties of DBNTRY STUB that may be present. There appear to be numerous different varieties of DBNTRY STUBs. However, the detail between… lines 74 and 1130 does not require more discussion, because this functionality is not replicated by the… 2004 DBURGEN [M]acro. There is extensive logic and many statements that are not in the [2004 DBURGEN Macro]. 222 In his second affidavit, in comparing the DBNTRY stub produced by the 2011 and R9 CA URT Macros, Mr Melito states: One must consider that the [R9 CA URT Macros] are used to produce a DBNTRY STUB employing multiple entry points into [Datacom]. The CA DBNTRY STUB has entry points named BEGIN, DBNTRY, DATACOM, CBLDBMS, DATCOM, DFLSUB, DBSQLE, ADRSQE, DBSQLC, DBRXXIN, READRXX. All of those have some function, and some are very significant (e.g. READRXX). The [DBNTRY STUB from the 2011 Macros], on the other hand, has only two entry points, DBNTRY and BEGIN. The macro definitions that produce these two stubs reflect the differences (i.e. the lines in the [R9] DBURGEN [Macro] that produce those other 11 entry points are simply not in the [2011 Macros]). This alone suggests a lack of substantial part. 223 The experts differ in their emphasis on the significance of those other entry points. However, it is not in dispute as between them that some part, represented by the lines of the R9 DBURGEN Macro, corresponds to these functions. The ISI Replacement Macros do not contain these 11 entry points and there are no lines in the ISI Replacement Macros relating to them. CA accepts that ISI has not reproduced the functionality of these 11 entry points, nor the lines associated with them. ISI relies upon the fact that this represents 85% of the functionality of the stubs produced using the CA URT Macros. Accordingly, ISI contends, Mr Turgeon has not undertaken the necessary examination of the entirety of what CA identifies as the copyright work. 224 In its additional submissions filed after the hearing, CA contends that the appropriate inquiry involves a consideration of the functionality of the computer statements comprising the copyright work and determining how those statements function to produce a certain result. CA emphasises that the "certain result" identified by Mr Turgeon (see [217] above) is the central purpose and most significant result of the R9 CA URT Macros. CA says that the fact that the R9 CA URT Macros may have also produced some other less significant results that are not present in the ISI Replacement Macros does not change that conclusion. CA adds that it not appropriate to consider the functionality of the result. 225 The evidence and submissions on this aspect of the case are not particularly helpful. In his evidence, Mr Melito uses words such as 'extensive logic' and 'significant', but there is no proper analysis of the importance of the remaining functionalities. Apart from submitting that the ISI Replacement Macros have not taken 85% of the functionality of the CA URT Macros, ISI has not made submissions as to the importance of those remaining functionalities. 226 Taking into account the whole of Mr Turgeon's evidence, including his discussion of what was removed during the course of the development of the ISI Replacement Macros and the extent to which his evidence was supported by Mr Melito, it is reasonable to conclude that what was not reproduced by ISI were those parts of the CA URT Macros that were not necessary for ongoing functionality with respect to Datacom but were, for example, related to the setting up and testing of the CA URT Macros. That is, those parts not taken are not necessary to enable the URTs to work with Datacom. 227 There is no dispute that there are differences between the ISI Replacement Macros and the R9 CA URT Macros and that they each contain lines absent in the other. The question is whether the ISI Replacement Macros contain a substantial part of the R9 CA URT Macros. Mr Turgeon's conclusion is that, in effect, the ISI Replacement Macros include that part of the R9 CA URT Macros that enables entry into Datacom. That represents what might be termed the base functionality of the R9 CA URT Macros. 228 The approach adopted by both parties has been to analyse the instructions in the CA URT Macros that enable the request to enter into Datacom and not to analyse the processes inside Datacom. To that extent, Mr Turgeon's analysis with respect to DBURGEN seems to deal with so much of the DBURGEN Macro that is necessary to respond to the call from the DBUREND Macro, to generate the URT and to enable entry into Datacom and not to other aspects of the DBURGEN Macro that apparently operate in the Datacom "cloud". CA's case, based upon Mr Turgeon's evidence, is to analyse so much of the DBURGEN Macro that is necessary for working with the External Macros. Mr Turgeon's conclusion is that ISI has taken so much of the DBURGEN Macro as is necessary to fulfil that base functionality. ISI says that there are remaining functionalities but has not explained whether or how they are relevant to that task. I do not accept ISI's submission that Mr Turgeon's approach to substantial part is flawed. 229 ISI says that although the names of the ISI Replacement Macros are the same, they produce a different object code containing different statements, in different order, with different logic and different function except, as ISI puts it, where the constraints of assembly language dictate otherwise. This, ISI says, is because the corresponding lines contained in the ISI Replacement Macros that are "pasted in" during the assembly process by "expanding" the macros are different and independently created. 230 ISI contends that the fact that the ISI Replacement Macros and the CA URT Macros are each used to produce a piece of object code and the fact that the two entry points in the stub produced by the ISI Replacement Macros have the same names as two of the 13 entry points in the stub produced by the CA URT Macros 'goes nowhere'. ISI relies upon the differences in the lines in the respective sets of macros that are pasted into the SYSIN to produce (upon assembly of the SYSIN) the object code associated with those entry points. ISI submits that the relevant analysis concerns the similarity, copying and substantiality of those lines. 231 Mr Melito points out that the stub produced by the ISI Replacement Macros does not perform identical functions to those of the R9 CA URT Macros or, where the function is similar, it does it differently. Some additional lines in the ISI stub relate to 2BDB2 or DB2. There is no dispute that the DBNTRY stub produced by the R9 CA URT Macros is over twice as long as that produced by the ISI Replacement Macros. However, Mr Melito agrees that the format of the URTs as between Datacom and 2BDB2 is the same and that the format avoids the user having to recompile program. ISI says that, fundamentally, many of the commands are mandated by the IBM framework and that similarities are to be expected because, as Mr Melito comments, 'anything accessing information that is stored in [the URTs] would be expecting to find the information in a particular position within the [URT]'. Mr Turgeon's response is that not only is the position the same but also the URT is the same length and format as that used by Datacom. 232 Mr Turgeon also gives evidence that the ISI Replacement Macros, individually, perform the identical function to the individual R9 CA URT Macros. CA refers to Mr Turgeon's evidence as to the 'certain result' brought about by the source code comprising each of the individual CA URT Macros. In summary: the DBURINF Macro is the interphase macro; the DBURSTR Macro is the start macro; the DBURTBL Macro is the entry macro; the DBUREND Macro issues the DBURGEN Macro to generate the assembler source code; and the DBURGEN Macro, the inner macro, contains the logic that generates the object code. 233 Mr Turgeon demonstrates this by way of an analysis and a comparison of each of the R9 CA URT Macros with the corresponding ISI Replacement Macro, in form 'subject to cosmetic or typographical variances' and function. 234 As a general observation, there are similarities and differences between the R9 CA URT Macros and the ISI Replacement Macros. Each set of macros reflects partial differences in function. However, there are similarities, necessitated by the purpose and function they have in common. The common functions are in common language and names. That is, the ISI Replacement Macros contain so much of the R9 CA URT Macros as is necessary to fulfil those functions. The functions concern the access to and entry into Datacom. This part mirrors that part of the R9 CA URT Macros with minor and inconsequential differences.

[40]

2004 Macros 235 The 2004 Macros were first supplied to all 2BDB2 R5.2 customers in June 2004, which is within the limitation period prescribed by s 134(1) of the Act for an action brought for infringement of CA's copyright. 236 The 2004 Macros contain a statement that they were written by Mr Richards. Despite this, Mr Richards denies writing any of the ISI Replacement Macros before 2009 and says that to his knowledge the 2004 Macros were written and developed by Mr Worboys. Mr Richards says that he was aware that there were macros to enable the generation of URTs but that, generally, he would not have had much reason to deal with URT generation as that was the work of the DBA. Rather, he says, his job was to monitor and create databases. 237 Mr Richards accepts that he was aware that Mr Worboys was creating macros in 2004 and agrees that he was involved in at least a supervisory and review function over Mr Worboys in relation to the 2004 Macros. Mr Richards denies the suggestion put to him in cross-examination that he concealed his involvement in authorship of the 2004 Macros by removing his name from material provided to the Court for these proceedings. 238 In CA v ISI (No 2), Perram J referred to Mr Richards' curriculum vitae, which referred to his role in the development of 2BDB2 between 1999 and 2009. It is there stated that Mr Richards 'continued to develop the transparent database access routines which have now developed into the 2BDB2/Datacom product… Development, installation and support of this product and the companion 2BDB2/VSAM product has occupied him full time since the end of 1998'. 239 Bearing this in mind, together with Mr Richards' acceptance that he was involved with the 2004 Macros in a supervisory capacity and the statement in the 2004 Macros that he is the author, I find that Mr Richards' role in the creation of the 2004 Macros extended to an involvement in their actual writing and development, or at least supervision of those processes. 240 I formed the view that Mr Richards was not frank in his evidence in this regard. 241 I now turn to the evidence and submissions on substantial part. 242 Mr Turgeon says: So moving forward to the 2004 Macros [from the 1999 Macros], they get smaller. The ISI folk certainly didn't need the whole [of the R9 CA URT Macros], because most of it they're not interested in. 243 Based on an Araxis Merge comparison, Mr Turgeon notes the different sizes of each of the 1999 and 2004 Macros after the deletion of non-functional comment blocks in both versions. Mr Melito indicates the different sizes of the R9 CA URT and 2004 Macros based on numbers inserted into the macros by ISI's solicitors to enable comparisons to be made. These figures appear to include comment blocks. Both sets of measurements are in terms of the number of lines of each macro: R9 CA URT Macros - Melito 1999 Macros - Turgeon 2004 Macros - Melito 2004 Macros - Turgeon DBURINF 164 267 102 127 DBURSTR 215 175 70 48 DBURTBL 318 175 152 48 DBUREND 113 95 51 27 DBURGEN 1231 1088 594 424

[41]

Mr Turgeon's measurement for the 1999 DBURINF Macro is longer than Mr Melito's measurement for the R9 DBURINF Macro. Further, Mr Turgeon's measurement for the 2004 DBURINF Macro is longer than Mr Melito's measurement for that macro. There was no explanation given for this. 244 Mr Turgeon accepts that the changes from the 1999 Macros to the 2004 Macros are 'quite significant'. However, he describes the changes, in summary, as follows: 1. Code that supported function in Datacom but was not relevant to 2BDB2 was removed, resulting in a decrease in size, measured by the number of lines. 2. Commentary that includes the name, author, date and macro function was added. The 2004 DBUREND and DBURGEN Macros added a comment section, also known as a change log. 3. The names of global and local macro variables were changed. 4. Sequence symbols were renamed. 5. Comment blocks were changed with comments added and existing comments reworded. For example, the section entitled "edit the macro sequences" was changed to "check the macro sequences" or "verify the macro sequences" and "edit the parameters" became "validate the parameters". 6. The comments describing the purpose of the macro operandi that are needed by Datacom only were replaced by the comment "ignored by 2BDB2". 245 According to Mr Turgeon, only the first of these modifications affects the functionality of the macro. 246 Mr Shuma compares the R9 and 2004 DBURSTR Macros and draws attention to: the identical parameter names and parameter values for DBURSTR; the alphabetical listing of the parameters in the corresponding macros. The 2004 DBURSTR Macro includes parameters not used by that macro; and the fact that two parameters that had not been used in Datacom for years, which were disabled in release 8.0 of the CA URT Macros but had been left in the R9 DBURSTR Macro for historical reasons, were present in the 2004 DBURSTR Macro. 247 Mr Turgeon made typographical changes to copies of both of the 1999 and 2004 Macros that did not change the function of either in order to focus on the functional changes between the 1999 and 2004 Macros. He concludes that the differences for each of the 2004 DBUREND, DBURINF, DBURSTR, DBURTBL and DBURGEN Macros compared to their equivalents in the 1999 Macros involved: as the dominant change, the deletion of Datacom logic not required by 2BDB2; routine maintenance; and a number of non-functional or cosmetic changes that changed the style and naming conventions of comments, variables and sequence symbols. 248 Mr Turgeon compares each of the R9 CA URT Macros and the 2004 Macros. Turning to the comparison of the R9 and 2004 DBURSTR Macros, Mr Turgeon observes that sequence numbers are commentary unless the assembler utility is specifically directed to validate them. Because some sequence numbers are missing and others duplicated and out of order in both the CA URT Macros and ISI Replacement Macros, he says that the conclusion must be that neither CA nor ISI enabled that assembler option in the R9 CA URT Macros and the 2004 Macros. That is, errors in the CA URT Macros are repeated in the ISI Replacement Macros. As does Mr Melito, Mr Turgeon comments that to maintain compatibility with existing Datacom URT source programs, the macro names and operand names must agree, so that parameter names arbitrarily chosen by Datacom, such as "&ABEND", are retained in 2BDB2. Mr Turgeon examines and compares the macros and concludes that the 2004 DBURSTR Macro of the 2004 Macros is the R9 DBURSTR Macro: subjected to (1) trivial changes to commentary, (2) trivial and systematic replacement of variable and sequence symbol names, (3) the deletion of Datacom code not required to support 2BDB2 functions and (4) insertion of 2BDB2 specific commentary including a copyright statement. 249 Mr Turgeon comes to the same conclusion with the 2004 DBURINF, DBURTBL and DBUREND; he says these individual macros are the R9 DBURINF, R9 DBURTBL and R9 DBUREND Macros respectively subject to the minor changes set out in [248]. 250 Mr Turgeon concludes that the 2004 DBURINF Macro is a literal copy of a version of the R9 DBURINF Macro predating that version of that macro. It is not an exact copy of the R9 DBURINF Macro. In comparing the 2004 DBURINF Macro with the 1999 DBURINF Macro, Mr Turgeon concludes that the 2004 DBURINF Macro was derived directly from the 1999 DBURINF Macro with, as a dominant change, the deletion of Datacom logic not required by 2BDB2 as well as routine maintenance and a number of non-functional or cosmetic changes that altered the style and naming connections of comments, variables and sequence symbols without affecting the macro processing logic. 251 In his consideration of the 2004 DBUREND and DBURTBL Macros, Mr Turgeon gives the opinion that they were derived directly from the 1999 DBUREND and DBURTBL Macros respectively and, consequently, directly from the R9 DBUREND and R9 DBURTBL Macros respectively. He notes, in regard to the 2004 and R9 DBUREND Macros, that there are differences in error handling but says that, in his opinion, they are 'typical of minor technical changes that occur in a maintenance cycle and not evidence of independent creation'. He says that any other differences between the 2004 and R9 DBUREND Macros represent minor changes that do not affect macro processing logic, or represent the removal of Datacom logic and variables not needed by 2BDB2. In regard to the 2004 and R9 DBURTBL Macros, he says that, with the exception of one change, the differences are cosmetic and typographical and do not affect macro processing logic. He accepts that a difference involving the use of error handling flags is non-cosmetic, but says that it is 'not evidence of independent creation' and that he would characterise it as routine maintenance. 252 Mr Turgeon observes that, unlike the other of the CA URT Macros, the DBURGEN Macro generates code in the form of data areas, data area mappings and executable assembler language statements. He notes that the 1999 DBURGEN Macro is 1088 lines long and that the 2004 DBURGEN Macro is 424 lines long. He says that the large scale renaming of data areas and data area mappings that occurred in the changes between the 1999 and 2004 DBURGEN Macros made it particularly challenging to differentiate non-functional, cosmetic changes from those that are functional. However, despite 'what appears to be vast differences', Mr Turgeon concludes that the two data structures and the fields that follow are structurally identical. After a detailed analysis, he comes to the same conclusion as that reached for the other macros; that is, that the changes between the 1999 and 2004 DBURGEN Macros involved, as a dominant change, the deletion of Datacom logic not required by 2BDB2, routine maintenance and a large number of non-functional, cosmetic changes. 253 Mr Turgeon concludes that the 2004 DBURGEN Macro is a literal copy of a version of the R9 DBURGEN Macro predating that version of that macro. Mr Turgeon says that the 2004 DBURGEN Macro is not an exact copy of the R9 DBURGEN Macro because the latter has a small number of changes to implement new features that do not appear in the former. Otherwise, the differences relate either to deleted Datacom logic not required by 2BDB2 (which forms the major difference), routine maintenance, non-functional changes and altered style and naming conventions. Mr Turgeon says that 'at some point, the 2BDB2 developers copied the [version of the R9 DBURGEN Macro] and called it their own' and then 'reworked it more or less mechanically into its 2004 form'. This was done by making 'trivial changes' to commentary, 'trivial and systematic replacement of variable and sequence symbol names', the deletion of Datacom code not required by 2BDB2, the insertion of 2BDB2 specific commentary (including a copyright statement) and routine maintenance. 254 CA relies on the evidence of Mr Turgeon to submit that, in combination, the 2004 Macros are, in effect, the R9 CA URT Macros subjected to: trivial changes to commentary; trivial and systematic replacement of variable and sequence names; deletion of Datacom code not required to support 2BDB2 functions; insertion of 2BDB2 specific commentary including a copyright statement; and routine maintenance, but retaining the function of the CA URT Macros in the creation of the URTs. 255 Rather than concentrating on the similarities between them, Mr Melito concentrates on the differences between the 2004 Macros and the R9 CA URT Macros. He acknowledges that there are 'several things' that they have in common, including common names. I take the reference to common names as meaning "names in common" rather than to label as "common names" the "DB names" arbitrarily chosen by Mr Lynn. Mr Melito points out that it is necessary to use the same macro name or the customers' URTs would not work in some cases when reassembled. Mr Melito says that common names and the same parameter list of the corresponding macro are necessary for compatibility, even if a particular parameter is not used by 2BDB2. He says that the extent of the similarity is affected by the function that the macro performs, the limitations of assembly language and the requirements of compatibility. 256 According to Mr Melito, as the result of assembling a URT using macros produces a table for use with both Datacom and DB2, the 2004 Macros only need to support, or accommodate, the parameters that are relevant when accessing a DB2 table using SQL. Macro parameters that are necessary to Datacom but irrelevant to DB2 are present but can be and are 'ignored'. 257 Mr Melito considers, as an example, the 2004 DBURSTR Macro, which bears an assertion of ISI's copyright. It states that the author is Mr Richards and that its function is that it 'provides a replacement for the Datacom URT generation macro DBURSTR'. Mr Melito points out that the 2004 DBURSTR Macro accepts 14 of the 15 parameters of the R9 DBURSTR Macro, of which 12 are ignored. He observes that the parameters are only specified in the 2004 DBURSTR Macro for 'compatibility reasons'. Mr Melito records the differences between the two macros, some of which he describes as 'fundamental differences'. He notes that other than the MACRO and MEND statements and the name of the macro, DBURSTR, there is only one line that is identical and, at most, 27 of the 70 lines that are similar in function to the R9 DBURSTR Macro of the R9 CA URT Macros. A further analysis is that 17 lines are the macro definition, 26 lines are new and, of the 27 remaining lines, one is identical of necessity and the remaining lines 'show independent creation'; they are also the practical way of performing the functions. His conclusion is that the 27 lines are constrained by their function. Mr Melito expresses the opinion that the 2004 DBURSTR Macro produces the minimum structure necessary to allow it to operate with Datacom and that it ignores the majority of parameters in the Datacom version. 258 Mr Melito carries out a similar analysis for the other macros, looking at the numbers of lines that are identical or similar and the necessary functionality for 2BDB2 to support existing application programs. He concludes that each of the 2004 Macros does not contain a substantial part of the corresponding version of the R9 CA URT Macros at both a numerical and a functional level and says there is evidence of independent creation for each of the 2004 Macros. 259 ISI points to Mr Melito's evidence, which it says establishes that: there are significant numbers of lines in the 1999 Macros that have no counterpart in the 2004 Macros; there is significant new and original material in the 2004 Macros; and the aspects that are identical as between the 1999 Macros and the 2004 Macros are identical either because of the constraints of compatibility and interoperability or because there are no or few other ways to write the relevant lines, owing to the constraints of assembly language.

[42]

2009 Macros 260 Mr Richards says that he worked on the 2009 Macros but was not "responsible for" them. However, Mr Richards accepts that he determined in September 2009 that the 2009 Macros, on which Mr Worboys had worked in around 2007, should be promoted to production. I accept that Mr Richards, in working on the 2009 Macros, had a role in the writing and development of those macros. 261 Mr Slaber says that in 2007 he made some 'relatively minor' changes to the 2004 Macros. These involved changes to the 2004 DBUREND Macro to accept parameters ignored by 2BDB2 but necessary to avoid an error message and to the 2004 DBURGEN Macro to allow that macro to be passed a seven character URT name, as well as to allow other changes to the URTs. 262 Mr Richards agrees that the 2004 Macros resemble the R9 CA URT Macros more than do the 2009 Macros. 263 Mr Melito measures the number of lines of the 2009 Macros as follows: The 2009 DBURSTR Macro is 44 lines. The 2009 DBURINF Macro is 42 lines. The 2009 DBURTBL Macro is 81 lines. The 2009 DBUREND Macro is 29 lines. The 2009 DBURGEN Macro is 341 lines. Mr Turgeon apparently agrees with these measurements and uses them (along with Mr Melito's measurements of the size of the 2004 Macros) to compare the 2004 and 2009 Macros. 264 Mr Turgeon also compares the R9 CA URT Macros and the 2009 Macros and concludes that the 2009 Macros "evolved" from the 2004 Macros, which "evolved" from the R9 CA URT Macros. He gives a detailed analysis of what he describes as 'systematic typographical changes' to the variable names and sequence symbols of the 2004 Macros to support that conclusion. 265 In comparing the 2004 and 2009 DBURGEN Macros, Mr Turgeon says that the 2009 DBURGEN Macro decreased in size from the 2004 DBURGEN Macro. According to Mr Turgeon, the 2009 DBURGEN Macro contained more documentation or comments but provided the same function and scope as in its predecessors. Specifically, it processed global variables posted by the other macros and it generated: the BEGIN routine; the DBNTRY routine; logic to load external URTs when DBURINF specifies URTABLE=LOAD; and the construction of the URT data area header and table entries. 266 Mr Turgeon concludes that, in comparison to the 2004 DBURGEN Macro, the 2009 DBURGEN Macro involved: the consolidation of OPEN=DB and OPEN=USER code in a single stub, as validation logic was deemed no longer necessary; routine maintenance, specifically the removal of a number of unreferenced variables; and a number of non-functional, cosmetic, changes to the names of macro and sequence systems. 267 Mr Turgeon also compared each of the 2004 and 2009 DBURSTR, DBURINF, DBURTBL and DBUREND Macros and concluded that the changes to these macros only involved: the deletion of validation logic deemed no longer necessary, which is the dominant change; routine maintenance; and a number of non-functional (typographical) changes to the names of macro variables and sequence symbols 268 CA relies on Mr Turgeon's conclusion that the 2009 Macros are derived from the R9 CA URT Macros by way of the 2004 Macros and his evidence on the changes to each of the 2009 Macros from the 2004 Macros in contending that the 2009 Macros constitute a substantial part of the R9 CA URT Macros. 269 Mr Melito compares the R9 CA URT Macros with the 2009 Macros. He notes that many of his observations in relation to the differences between the R9 CA URT Macros and the 2004 Macros also apply to the differences between the R9 CA URT Macros and the 2009 Macros. He also identifies differences between the 2004 Macros and 2009 Macros. 270 As part of his analysis, Mr Melito examines the structure and logic of the portion of the 2009 DBURGEN Macro that created the statements that would become the DBNTRY stub. He notes that there is both commonality and difference. In some cases, the line entries make it apparent that pre-existing lines were duplicated and some rewritten or moved around. He says that the underlying assembler statements are the same but put to different functions. The functional portion of the 2009 DBURGEN Macro is 184 lines long, compared to 1301 lines in the R9 DBURGEN Macro. 271 Mr Melito concludes that each of the 2009 Macros does not contain a substantial part of the corresponding version of the R9 CA URT Macros at both a numerical and a functional level and says there is evidence of independence creation for each of the 2009 Macros. 272 ISI repeats its submissions outlined at [259] above in contending that the 2009 Macros do not reproduce a substantial part of the R9 CA URT Macros.

[43]

2011 Macros 273 Mr Richards says that he was the sole author of the 2011 Macros. He says that he had assistance from Messrs Bickerdike and Slaber in testing. 274 Mr Slaber says he was not involved at a level of detail of the writing of the 2011 Macros. He says that Mr Richards rewrote the 2011 Macros but that he was involved in testing the changes. Mr Slaber accepts that in testing and analysis of the 2011 Macros he looked at the 2004 Macros and 2009 Macros. 275 I accept Mr Richards' evidence that he rewrote the 2011 Macros, which is supported by the evidence of Messrs Slaber and Melito. 276 The 2011 Macros contain the DBURSTR, DBURINF, DBURTBL and DBUREND Macros. They do not contain the DBURGEN Macro. However, they do contain an additional macro called B2BURT (B2BURT Macro). 277 In analysing whether the 2011 Macros reproduce a substantial part of the R9 CA URT Macros, there are two issues to be determined: 1. At a threshold level, are the 2011 Macros a reproduction of the R9 CA URT Macros? Is there a causal connection and objective similarity between these macros? CA submits that causal connection and objective similarity have been established and that, accordingly, the 2011 Macros are a "reproduction" of the R9 CA URT Macros, both individually (in terms of the corresponding macro) and collectively. ISI submits that there has been no reproduction within the 2011 Macros of any of the CA URT Macros or any part thereof. 2. If there is a reproduction, did the reproduction involve a substantial part of the R9 CA URT Macros? CA submits that it did. ISI disputes this. 278 I will first outline the parties' submissions on the issue of causal connection. 279 As the issue of whether there is objective similarity between the R9 CA URT Macros and the 2011 Macros involves, in this case, much of the same evidence and submissions as the issue of whether the 2011 Macros reproduce a substantial part of the R9 CA URT Macros, I will deal with these issues together. Causal connection 280 In support of its submissions on causal connection, CA relies on Mr Turgeon's evidence that the basic form and function of the 2011 Macros remain the same as that of the 1999, 2004 and 2009 Macros and that the same functions are implemented. CA relies on Mr Turgeon's conclusions that the 2011 Macros are, in turn, the same or substantially the same in function as the statements comprising the earlier versions of the ISI Replacement Macros. That is, CA contends, the functionality of the statements comprising the 2011 Macros remains the same as the functionality of the statements comprising the 2009, 2004 and 1999 Macros which in turn all functioned in the same way as the R9 CA URT macros; that is, all produce an object code module containing the URT and DBNTRY. I will examine the evidence on this further below. For present purposes, CA submits that as the 2011 Macros contain the same or substantially the same functionality as the other versions of the ISI Replacement Macros, these objective similarities are sufficiently great to lead to a proper inference of causal connection in the absence of a displacement of that inference by evidence. 281 In any event, CA submits that the causal connection can be established between the R9 CA URT Macros and the 2011 Macros by tracing a path through the previous versions of the ISI Replacement Macros. In summary: There is objective similarity between the R9 CA URT Macros and the 1999 Macros, as accepted by both experts. The 1999 Macros were used in creating the 2004 Macros. In support of this, CA points to the agreement between the experts that the 1999 Macros were probably the starting point for the 2004 Macros as well as the objective similarity between these macros. ISI used the 2004 Macros in creating the 2009 Macros. CA says this is supported by the objective similarity between those two versions together with Mr Richards' evidence that Mr Worboys informed him that he was "updating" the 2004 Macros, the product of which was the 2009 Macros. ISI used the 2009 Macros in creating the 2011 Macros. In particular, CA relies upon Mr Turgeon's evidence that the basic form and function of the 2011 Macros remains the same as the 2009 Macros. 282 ISI says that when all proper analysis is made, the evidence shows no objective similarity between the 2011 Macros and the R9 CA URT Macros in form or function (as will be detailed further below), which means that this does not support any copying or causal connection. 283 ISI submits that the inference relied on by CA at [280] cannot be made and that there is direct evidence as to a lack of causal connection. ISI points to Mr Richards's evidence that he created a new means to perform a similar function, executed differently (locating and loading the URT) and a new means to perform a different function (calling the ISI module B2B0003), which was also executed differently. ISI relies on Mr Richards' evidence that he first created the stub that needed to be present in the URT and then created lines in the B2BURT Macro that would produce this stub when pasted into the SYSIN upon assembly. ISI points out that it was not put to Mr Richards that he based the B2BURT Macro upon any R9 CA URT Macro. It was not, ISI says, 'suggested to him' or 'established that he copied any aspect of his B2BURT Macro from any earlier CA or ISI macro'. ISI also relies on Mr Melito's evidence that the stub in the 2011 Macros is entirely different from the Datacom DBNTRY stub. Objective similarity and substantial part 284 Mr Turgeon expresses the opinion that as 'as [the ISI Replacement] Macros became more and more recent more is pulled out of them… The 2011 Macros… [are] really the bare bones [of the R9 CA URT Macros]'. However, the objective similarity must, CA submits, address functional, not literal, similarity. CA relies on Mr Turgeon's conclusion that the basic form and function of the 2011 Macros remain the same as those of the earlier ISI Replacement Macros and that unnecessary parts, or those parts not necessary to functionality, have been removed. CA says that although the mechanics of the 2011 Macros are simpler than the 2009 Macros, the critical factor, based on IceTV at [158], is that the basic form and function remain the same. 285 CA says that the 2011 DBURSTR, DBURINF, DBURTBL and DBUREND Macros call the B2BURT Macro and, collectively, the statements comprising the 2011 Macros produce the same results as the R9 CA URT Macros, namely, to produce a URT object code containing the URT and DBNTRY stub. CA points out that both of the parties' experts agree that the format of the URT is the same. 286 ISI maintains that there is no or no sufficient evidence of any objective similarity between any of the 2011 Macros and any of the R9 CA URT Macros. 287 ISI relies upon Data Access and submits that it is not a question of whether both sets of macros produce an object code module containing the URT and DBNTRY. ISI equates the comparison CA seeks to make in determining objective similarity or functional similarity as being equivalent to saying that because two authors produce a book containing a chapter headed "introduction", the two books are objectively the same. ISI also points to some of the differences that it relied on with respect to the earlier ISI Replacement Macros, in particular: the fact that the 2011 Macros do not contain 11 of the 13 entry points of the CA URT Macros; and that the lines that are in common between the macros are constrained by function. 288 Additionally, ISI contends that the 2011 Macros produce a different "result" from the R9 CA URT Macros. ISI points to: the fact that, although both may be used to produce a URT (which ISI accepts), the information table in the URT produced by the 2011 Macros contains much less information and is arranged in a different format from the information table in the URT produced by the CA URT Macros; and the fact that the stub in the 2011 Macros is different from the stub produced using the R9 CA URT Macros. ISI says that the ISI produced stub performs the two identically named functions (DBNTRY and BEGIN) differently from the Datacom produced stub because it locates and loads the URT differently and also loads and invokes the B2B0003 transparency module following which there is a return of control. In contrast, the Datacom produced stub only calls DBINFPR, which the ISI produced stub does not do. 289 ISI places particular emphasis on its argument that Mr Turgeon's evidence concerning the 2011 Macros is flawed as he did not undertake the essential task of comparing the 2011 Macros to the R9 CA URT Macros. ISI says that the comparison of the 2011 Macros with the 2009 Macros undertaken by Mr Turgeon does not prove anything and that the lack of copying of the R9 CA URT Macros is clear when it is observed that the only similar parts between the 2011 Macros and the 2009 Macros are those parts that were new to the 2009 or 2004 Macros, that is those parts of the 2009 and 2004 Macros that were independently created and have no counterpart in the R9 CA URT Macros. For example, ISI contends that evidence which establishes that the 2009 Macros produce DBNTRY routines that use a similar technique in locating a URT as the 2011 Macros is irrelevant if that technique is not used by the stub produced using the R9 CA URT Macros. ISI contends that this aspect of the 2009 and 2011 Macros, which involves a "communication vector table", could not have come from the R9 CA URT Macros. 290 ISI relies upon Mr Melito's comparison between the 2011 Macros and the R9 CA URT Macros and his conclusion that they were dissimilar. Mr Melito's evidence is divided into a comparison between the B2BURT Macro and the R9 DBURGEN Macro and a comparison between the External Macros of the 2011 Macros and those of the R9 CA URT Macros. 291 ISI submits that CA has failed to establish any copying or reproduction relevant to the B2BURT Macro and points to the absence of objective similarity between that macro and the R9 DBURGEN Macro. ISI relies on Mr Melito's evidence that there is no relevant similarity between the B2BURT Macro and the R9 DBURGEN Macro in form or function. 292 ISI sets out in detail Mr Melito's unchallenged evidence as to the differences between the B2BURT Macro and the R9 DBURGEN Macro. As summarised by ISI they are (evidentiary references omitted): (a) the B2BURT [Macro] had only five trivial lines in common with the … R9 DBURGEN Macro, three of which had to be in there, and two of which were commonly used lines that happened to be in both; (b) the B2BURT Macro has parameters, but [the R9] DBURGEN [Macro] does not; (c) the parameters for the B2BURT Macro are different from any CA [URT Macros]; (d) the B2BURT Macro has 4 global variables, none of which is in… [the] R9 DBURGEN [Macro]; and… [the] R9 DBURGEN [Macro] has 44 global variables, none of which is in [the] B2BURT [Macro]; (e) the branching logic in the two macros is different; (f) the B2BURT Macro has "entirely different" logic and structure; (g) the handling of standard linkage conventions in [the] B2BURT [Macro] is different from any other [CA URT Macro or ISI Replacement Macro]; (h) the … [R9] DBURGEN Macro uses variable arrays and looping logic, while [the] B2BURT [Macro] does not, and is expanded in a simple manner; (i) as Mr Turgeon observed, the … [R9] DBURGEN Macro manages multiple table definitions using parallel arrays of global variables shared between the two, but in [the] B2BURT [Macro] table entries are defined as each DBURTBL Macro is encountered; the outer macros maintain no state information and [the] B2BURT [Macro] maintains very little; (j) the B2BURT Macro uses a CVT technique that the [R9 DBURGEN Macro] does not, and which is more "future-proof"; (k) the B2BURT Macro is pasted into the SYSIN multiple times to form the source code that is then assembled into the URT, unlike [the R9] DBURGEN [Macro] which is expanded once. This is both new and functionally different from the [CA URT Macros or the other ISI Replacement Macro]… 293 Mr Melito concludes that the B2BURT Macro is a work of independent creation. 294 ISI relies upon the fact that the lines in the B2BURT Macro that correspond to the stub are different and do not correspond with any of the lines in any of the R9 CA URT Macros, in particular the R9 DBURGEN Macro. ISI says that this is expected, given that Mr Richards designed the different stub. 295 Mr Turgeon notes some similarity between the lines of the B2BURT Macro when compared with the 2009 DBURGEN Macro. In response, ISI points to Mr Melito's opinion that this portion of the 2009 DBURGEN Macro was independently written. In his evidence, Mr Melito gives an explanation for his conclusion that the portions of the 2009 DBURGEN Macro that are said by Mr Turgeon to be similar to the B2BURT Macro were independently created and not reproduced or copied from the R9 DBURGEN Macro. Mr Melito is of the view that where groups of lines in the 2009 DBURGEN Macro are similar to those within the R9 DBURGEN Macro, it is because they are constrained by function. However, ISI emphasises that they are few in number; they represent only 36 lines as compared to the 1,231 lines in the R9 DBURGEN Macro. This is in the context that the evidence is that between four and seven lines of assembly language are needed to do basic standard prologue/epilogue "housekeeping". 296 ISI submits that, based upon the evidence and the fact that Mr Turgeon did not compare the B2BURT Macro with the R9 DBURGEN Macro, Mr Melito's detailed comparison of the 2011 Macros with the R9 CA URT Macros should be accepted and preferred to Mr Turgeon's broad conclusions respecting the 2009 and 2011 Macros. 297 ISI submits that the evidence demonstrates that there has been no reproduction relevant to the B2BURT Macro and that every part of that macro is 'new, distinct and original'. ISI contends that 'the overwhelming conclusion is that the… B2BURT Macro is functionally distinct from all of the other macros'. 298 As to the 2011 DBURSTR, DBURINF, DBURTBL and DBUREND Macros, ISI maintains that there is no quantitative similarity between these macros and their corresponding versions in the 2004 and 2009 Macros. Nor, ISI says, is there anything similar between these forms of the 2011 Macros and any of the R9 CA URT Macros or, indeed, the 1999 Macros. 299 ISI relies upon Mr Melito's evidence that the only similarities in these macros are in respect of names and things that must be present in the macros because of the demands of the IBM system and conventions, including: the word "MACRO", which Mr Melito says must be present to define a macro definition according to the IBM convention for defining macros; the word "MEND", which Mr Melito says must, according to IBM convention, end the macro definition file; the name of the macro itself, which Mr Melito says must be identical to the macro it is replacing; and the names of the macro parameters, which Mr Melito notes must, according to IBM convention, be listed in order to be "accepted", that is, able to be specified. However, as Mr Melito explains it, the parameters are listed but the vast majority are ignored. 300 Otherwise, Mr Melito says, all of the remaining material in the 2011 DBURSTR, DBURINF, DBURTBL and DBUREND Macros is new material. This is supported by Mr Richards' evidence that he created this material independently. ISI relies on this evidence and submits that every part of the 2011 DBURSTR, DBURINF, DBURTBL and DBUREND Macros other than the parts that have to contain identical words used in the R9 CA URT Macros is new, distinct and original and does not amount to a reproduction of any part of the R9 CA URT Macros. 301 Turning to a comparison of the output of the macros, ISI says that the functionality of the 2011 DBURSTR, DBURINF, DBURTBL and DBUREND Macros is different from the equivalent macros in the earlier versions of the ISI Replacement Macros and the R9 CA URT Macros. In the 2011 Macros, these macros do nothing other than invoke the B2BURT Macro. They are, ISI contends, 'utterly distinct'. 302 CA maintains that analysing the functionality of the External Macros of the 2011 Macros and the equivalent External Macros of the R9 CA URT Macros separate from the functionality of the B2BURT Macro and the R9 DBURGEN Macro is not the correct analysis. They must, CA says, be compared collectively and when they are, the function of the 2011 Macros is the same or substantially the same as that of the R9 CA URT Macros and, in turn, the same as the 1999, 2004 and 2009 Macros. That is, as stated earlier, each of the sets of macros produces the URT object code containing the URT and DBNTRY stub. 303 In addition to referring to its earlier submissions on the differences between the functionality of the 2011 Macros and the R9 CA URT Macros (see [292] and [301] above], ISI submits that it is not a question of the results to be achieved by these macros but rather how the result is achieved by use of these macros. Put another way, ISI says that what must be compared are the parts of the alleged copyright work and the alleged infringing work that contribute to each relevant function. When that is done, ISI contends, the 2011 Macros perform different functions to the R9 CA URT Macros, which, ISI says, is established by the evidence that the 2011 Macros produce a stub inside the URT that loads and calls B2B0003 and creates an information table, whereas the R9 DBURGEN Macro produces a stub that loads and branches, without returning, to DBINFPR and produces an information table in a different form. In addition, ISI says that even if attention is directed to the functions said to be similar, there is a difference in how they are achieved.

[44]

Conclusion on whether the ISI Replacement Macros reproduce a substantial part of the R9 CA URT Macros 304 It is helpful to repeat some of the facts set out above. 305 There are a number of features of Datacom and the CA URT Macros that are distinctive: The naming system commences with DB. The URT contains information about a Datacom database. The name was coined at CA. The choice to use a URT was a Datacom design decision to enable access to Datacom databases. The URT enables entry to Datacom at the correct "entry point", which it determines. CA says that it "opens the door" to Datacom. The URT may contain a DBNTRY stub. To enter Datacom, the programmer calls Datacom by using "CALL DBNTRY". The application program only calls DBNTRY and is not concerned with the way in which the request is processed and the result returned. DBNTRY locates or uses DBINFPR in batch and DBCSVPR in CICS. Every licensee batch application is attached to a URT. The URTs and DBCSVPR in online programs are part of every application program created to access Datacom. The URT specifies a unique database ID number, obtains the data (which it places in the RQA) and then returns the data. This is done using a specific Datacom lexicon. A set of the CA URT Macros is provided to the licensee to enable the specific URT required by each application program. The SYSIN is produced following a protocol that CA requires its licensees to follow to allow their application programs to interact with Datacom. Without the CA URT Macros, the SYSIN could not produce the URT object module. The names of the CA URT Macros and their parameters were created specifically for Datacom. The CA URT Macros were designed to replace the former system in Datacom of creating a URT using a single macro. It was Mr Lynn's idea to have the four External Macros and one internal macro, a decision that he says was arbitrary. The External Macros are given to Datacom licensees by CA and are used to create the required URT. Each includes a number of parameters with a number of different possible values. They are specific to applications written to access the Datacom database environment. The DBURGEN Macro is an internal macro. It is not documented in the introduction given to licensees, who do not need to name it in the process of using the CA URT Macros to generate the required URT. It is internally invoked by the DBUREND Macro during the assembly process. It is necessary to create the final URT output. Application programs may be written in IDEAL, a language specially designed for use with Datacom. RAAT and SAAT are CA proprietary application program interfaces. 306 The ISI Replacement Macros must correspond sufficiently with the CA URT Macros in order to interact with them and the URTs generated by them. This correspondence is necessary first to enable diversion to DB2 or a passing to Datacom and then, ultimately, to replace the CA URT Macros while still enabling use with the client's existing URTs. In order to fulfil these objectives, certain parameters must be included in the ISI Replacement Macros. Certain parameters which do not need to be used in the ISI Replacement Macros, such as parameters concerned with the initial testing of the CA URT Macros, do not need to be present in the ISI Replacement Macros and can be discarded. There may be additional parameters relevant to interaction with DB2. 307 The ISI Replacement Macros may have additional functions but each of them must function as the corresponding CA URT Macro, in particular the External Macros, and must have identical names (again, referring to the External Macros). This, as Mr Turgeon says, is because both sets of macros have as a purpose the creation of a URT for a Datacom application program. ISI accepts that there are parts of the ISI Replacement Macros that are identical and says that this is limited to those parts of the CA URT Macros that are needed to allow the URT to operate with existing Datacom based application programs that are identical. 308 The 1999 Macros are, it is accepted by the experts, virtually identical to the R9 CA URT Macros. Bearing in mind the way in which the CA URT Macros were created and the arbitrary decisions of Mr Lynn as part of that process, the facts that the 1999 Macros when compared with the R9 CA URT Macros: are so textually similar; have identical names; act to create URTs; utilise the four External Macros and the DBURGEN Macro; and contain parameters that are the same, including those not utilised by 2BDB2 or for the purposes of DB2, means that the clear conclusion is that the 1999 Macros are a reproduction of a substantial part of the CA URT Macros, notwithstanding any minor differences. 309 The evidence is sufficient to establish that the 1999 Macros were created at Beta and that ISI took ownership of them. ISI adduced no evidence of its own to deny that proposition and it seems inconsistent with Mr Richards' evidence and with CA's submission made during the hearing. 310 Accordingly, if it can be proven that the 1999 Macros were reproduced in Australia within the limitation period, they would constitute the reproduction by ISI of a substantial part of the R9 CA URT Macros for the purposes of the Act. 311 As stated above, CA accepts that the 1999 Macros were never supplied in Australia as part of any product. CA asks the Court to draw the inference that the 1999 Macros were available to Mr Worboys in Australia on the ISI mainframe or source code repository in 2004 when he was creating the 2004 Macros. Such availability would amount to a reproduction of the R9 CA URT Macros as follows: Pursuant to s 31(1)(a)(i) of the Act, copyright in a literary work includes the exclusive right to "reproduce the work in a material form". Section 10(1) of the Act defines material form, in relation to a work or an adaptation of the work, to include 'any form (whether visible or not) of storage of the work or adaptation, or a substantial part of the work or adaptation, (whether or not the work or adaptation, or a substantial part of the work or adaptation, can be reproduced).' This definition would encompass presence on the ISI server. 312 There are, however, a number of assumptions bound up in the inference sought by CA. They are that: 1. The 2004 Macros were created (or at least stored during part of the creation process) on ISI's server in Australia. 2. The 1999 Macros were used in the creation of the 2004 Macros. 3. The 1999 Macros were therefore present on ISI's server in Australia during the creation of the 2004 Macros. 4. The 1999 Macros were present on ISI's server at a date on or after 12 March 2004. 313 I accept (2) on the basis of Mr Turgeon's evidence, as I will detail further below. However, CA has adduced no evidence in support of (1), (3) and (4). Although the evidence indicates that the 2004 Macros were released in June 2004 and that they were available on the ISI server at some stage later, CA has adduced no clear evidence as to how the 2004 Macros were created (that is, whether the ISI server was used), when the 2004 Macros were created, where the 2004 Macros were created or when the 2004 Macros (let alone the 1999 Macros) were placed on the ISI server. The evidence is insufficient to enable the inference sought by CA to be drawn. 314 CA has not established that ISI used the 1999 Macros in Australia within the limitation period in a manner that infringed CA's copyright in the R9 CA URT Macros. 315 As to the 2004 and 2009 Macros, CA submits that bearing in mind the causal connection between the R9 CA URT Macros and the 1999 Macros, there is a causal connection between the R9 CA URT Macros and the 2004 and 2009 Macros because each release of these macros derived directly from the previous release of the ISI Replacement Macros and consequently derived indirectly from the R9 CA URT Macros. Mr Melito conceded that the 1999 Macros were probably the starting point for the 2004 Macros and this causal connection is evident, CA says, from the similarities in the successive releases of the ISI Replacement Macros. I accept this submission. 316 I accept Mr Turgeon's analysis of the 2004 and 2009 Macros when compared with the R9 CA URT Macros. I accept that, on the basis of this analysis, there is objective similarity between the 2004 and 2009 Macros and the R9 CA URT Macros. 317 Mr Turgeon's evidence establishes not only that the 2004 and 2009 Macros, as written, perform the identical function to the R9 CA URT Macros, but also the textual similarity that enables that to occur is evident. That is, both relevant form and function have been retained. 318 Mr Turgeon's evidence supports the conclusion that the changes made to the relevantly functional part of the R9 CA URT Macros via the 1999 Macros, the part necessary to interact with the CA URT Macro generated URTs, were not functional changes and not changes of substance. The operative part of the R9 CA URT Macros for that purpose formed part of the 2004 Macros. 319 That is, the 2004 Macros retained the functions of the R9 CA URT Macros necessary to correspond with the CA URT Macros in order to interact with Datacom. There was deletion of material not necessary for this function and addition of material relevant to 2BDB2 but not to Datacom. Some of the changes were stylistic rather than functional. The fact that material was added to the 2004 Macros does not prevent what was taken from the R9 CA URT Macros from being a substantial part of those macros. That is consistent with the textual correspondence of the two sets of macros. 320 For these reasons, the 2004 Macros are a reproduction of a substantial part of the CA Macros. By making that reproduction, Messrs Richards and Worboys, on behalf of ISI, infringed CA's copyright in the R9 CA URT Macros. 321 On the basis of Mr Turgeon's analysis and for the same reasons that apply to the 2004 Macros, the 2009 Macros are a reproduction of a substantial part of the R9 CA URT Macros and also infringe CA's copyright in the R9 CA URT Macros. While there were further changes so that the degree of correspondence with the R9 CA URT Macros overall is less than applies to the 2004 Macros, the 2009 Macros nevertheless also involve the reproduction of a substantial part, functionally and textually, of the R9 CA URT Macros. 322 As to the 2011 Macros, I accept that they were the result of original work by Mr Richards, albeit with his knowledge of the necessary function of the 2004 and 2009 Macros and the need to use the names of the CA URT Macros, except in the case of DBURGEN. While part of the function of the 2011 Macros was, again, essentially the same as the function of the R9 CA URT Macros, I accept that the parameters were rewritten by Mr Richards. 323 Although there is a connection between the R9 CA URT Macros and the 2011 Macros, this is not a causal connection; there is no evidence to suggest that Mr Richards wrote or was part of the creation of or consulted in the creation of the 1999 Macros. I accept: that Mr Richards contributed to the creation of the 2004 Macros; Mr Turgeon's evidence that the 2004 Macros are the R9 CA URT Macros, subject to the changes noted above; Mr Turgeon's evidence that the 2009 Macros derive from the 2004 Macros; and that, in his testing and analysis of the 2011 Macros, Mr Slaber looked at the 2004 Macros and 2009 Macros. 324 However, I also accept that: Mr Richards, like any DBA, could understand the way in which the CA URT Macros worked; and Mr Richards rewrote the 2011 Macros into a different form, albeit to fulfil the same function, using his knowledge as a computer programmer and his knowledge of the desired outcome. 325 Based on the preceding two points, CA has not established a relevant causal connection between the R9 CA URT Macros and the 2011 Macros. CA has not established that Mr Richards used the form of the 2004 and 2009 Macros in that creation. 326 The 2011 Macros are not objectively similar to the R9 CA URT. I accept Mr Melito's evidence on the comparison of the R9 CA URT Macros and the 2011 Macros. Mr Turgeon's evidence concerning a comparison of the 2009 Macros and the 2011 Macros is not helpful; the Act requires a comparison between the reproduction and the copyright work. 327 Although the function of the 2011 Macros with respect to the creation of URTs created is the same, the fact that two programs perform the same function is not sufficient to amount to copyright infringement or the taking of a substantial part of the R9 CA URT Macros. There must also be sufficient similarity of what may be described as expression, form or parameters, such that the 2011 Macros can be said to be a reproduction of the R9 CA URT Macros. This is not the case here. CA has failed to demonstrate that the 2011 Macros are a reproduction of the R9 CA URT Macros or a reproduction of a substantial part of those macros.

[45]

Section 47D(1) of the Act 328 In answer to any finding of infringement of copyright, ISI relies on the interoperability defence available in s 47D(1) of the Act, which provides: Reproducing computer programs to make interoperable products (1) Subject to this Division, the copyright in a literary work that is a computer program is not infringed by the making of a reproduction or adaptation of the work if: (a) the reproduction or adaptation is made by, or on behalf of, the owner or licensee of the copy of the program (the original program) used for making the reproduction or adaptation; and (b) the reproduction or adaptation is made for the purpose of obtaining information necessary to enable the owner or licensee, or a person acting on behalf of the owner or licensee, to make independently another program (the new program), or an article, to connect to and be used together with, or otherwise to interoperate with, the original program or any other program; and (c) the reproduction or adaptation is made only to the extent reasonably necessary to obtain the information referred to in paragraph (b); and (d) to the extent that the new program reproduces or adapts the original program, it does so only to the extent necessary to enable the new program to connect to and be used together with, or otherwise to interoperate with, the original program or the other program; and (e) the information referred to in paragraph (b) is not readily available to the owner or licensee from another source when the reproduction or adaptation is made. (original emphasis) 329 ISI relies on the defence in s 47D(1) in respect of any alleged reproduction of the R9 CA URT Macros or Datacom by way of the ISI Replacement Macros. I will consider the defence with respect to the 2004 and 2009 Macros, which, as I found above, reproduce a substantial part of the R9 CA URT Macros. 330 A determination of the availability of s 47D(1) is based on the findings of fact that I have made or make below with respect to the work reproduced (the CA URT Macros), its use in the creation of the ISI Replacement Macros and the fact that the reproduction is, in the case of the 2004 and 2009 Macros, otherwise an infringement of CA's copyright in the CA URT Macros. 331 There are a number of matters relevant to the application of s 47D(1): The subsection applies to each reproduction or adaptation. The original program referred to in the subsection is the R9 CA URT Macros. It cannot be Datacom for present purposes, because the "reproduction" in question, that is, the "reproduction" for which ISI seeks to establish the s 47D(1) defence, involves the reproduction of the R9 CA URT Macros. The reproduction or adaptation of the 1999 Macros was made at Macquarie and/or at Beta, each of which was the licensee of a set of programs that included the R9 CA URT Macros. Mr Richards says, but CA challenges, that he had no intention of producing a "product" while at Macquarie or at Beta but was performing a service for them as an independent contractor working on their Datacom systems in order to enable them to transfer to DB2. 2BDB2 was developed, reproduced or adapted to be used by Datacom licensees who wished to convert from Datacom to DB2. Once the customer has completed all conversions from Datacom to DB2 and has removed Datacom, the customer may use the ISI Replacement Macros to replace the CA URT Macros. Without the ISI Replacement Macros, the objective of 2BDB2 to eliminate the need for Datacom would fail. This is because the customer's applications would still have the original URTs, including Datacom elements. 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 Datacom URTs. 332 I now turn to the application of s 47D(1)(a) of the Act. 333 ISI submits that it was acting "on behalf of" Macquarie, Beta and later customers for the purposes of making the reproduction of the R9 CA URT Macros. 334 The question is whether the 2004 and 2009 Macros were made, by or on behalf of, the owner or licensee of the R9 CA URT Macros. 335 The Shorter Oxford Dictionary relevantly defines "on behalf of" as follows: As the agent or representative of (another); in the name of. On the part of, proceeding from. In the interest or for the benefit of (another person, a cause, etc); for the sake of. 336 The Macquarie Dictionary (rev 3rd ed, Macquarie, 2003) relevantly defines "on behalf of" as follows: As a representative of. In the interest of; in aid of. 337 In Re Ross, ex parte A-G for Northern Territory (1980) 54 ALJR 145, Stephen, Mason, Murphy and Aickin JJ said at 149: The phrase "on behalf of" is, as Latham CJ observed in R v Portus, ex parte Federated Clerks' Union of Australia [(1949) 79 CLR 428 at 435] "not an expression which has a strict legal meaning", it bears no single and constant significance. Instead it may be used in conjunction with a wide range of relationships, all however in some way concerned with the standing of one person as auxiliary to or representative of another person or thing. In what is perhaps its least specific use, "on behalf of" may be applied to someone who does no more than express support for persons or for a cause, as with one who speaks on behalf of the poor or on behalf of tolerance. It may be used when speaking of an agency relationship, but also of some quite ephemeral relationships, such as that which exists between a party to litigation and the witness he calls, a witness "on behalf of" the defence. Again, it may, as the Northern Territory here contends, be used where the relationship is that of trustee and cestui que trust. It was of such a use that Lord Cairns LC spoke when he said, in Gillespie v City of Glasgow Bank (1879) 4 App Cas 632; that the phrase could describe a relationship of trustee and cestui que trust "if the circumstances of the case are consistent with that interpretation" (at 640). Context will always determine to which of the many possible relationships the phrase "on behalf of" is in a particular case being applied; "the context and subject matter" (per Dixon J in the Federated Clerks' case, at 438) will be determinative. 338 That is, there is no strict legal meaning for the expression "on behalf of". Its meaning will depend on the context in which it is used. 339 Beta is the relevant licensee of the R9 CA URT Macros for the purposes of s 47(1)(a). It may be arguable that the 1999 Macros were created by or on behalf of Beta. However, as I found above, the 1999 Macros are not an infringement of CA's copyright under the Act. 340 ISI submits that it made the 2004 and 2009 Macros "by or on behalf of" its existing customers, all of whom are licensees of the CA URT Macros (presumably by being licensees of Datacom). 341 CA submits that the fact that 2BDB2 was transformed into a marketable product means that the reproduction of the ISI Replacement Macros cannot have been done "by, or on behalf of, the owner or licensee of [a] copy of" the "original program", whether that is Datacom or the R9 CA URT Macros. Once the copy was brought back to Australia, worked on and made into a product for the purpose of sending out to all 2BDB2 licensees, the copy made at Beta was, CA says, no longer being used on behalf of Beta but was actually being used on behalf of ISI. Further, CA points to the licence agreement between ISI and Beta, which, it says, indicates that 2BDB2 could not have been created "by or on behalf of" Beta, as 2BDB2 was being licensed back to Beta. In addition, CA points out that ISI did not repeat the process engaged in at Beta with the licensed copy of other Datacom licensees because ISI relied on what it had done already. 342 The 2004 and 2009 Macros were created by ISI for the purposes of updating 2BDB2 for its own commercial purposes, for distribution. They were sent to ISI's customers, not just Beta. The effect of ISI's submission is that any product used by a customer would have been made on behalf of that customer for the purposes of s 47D(1)(a). Section 47D(1)(a) does not contemplate a defence to infringement of copyright in a computer program in circumstances where an independent third party reproduces a computer program and then for commercial purposes provides that reproduction to a licensee of the computer program. This is the case even if the third party has an ongoing commercial relationship with the licensee of the computer program. I reject ISI's submission. 343 To the extent that ISI submits that "on behalf of" means, in effect, "to the benefit of" or "for the use of", that in my view extends beyond the proper application of s 47D(1) and should also be rejected. 344 The 2004 and 2009 Macros do not come within s 47D(1)(a). Accordingly, the defence in s 47D(1) does not apply. The same would apply for the 2011 Macros if they constituted an infringement. I will, however, make some observations on ss 47D(1)(b)-(e) of the Act. 345 The parties' submissions on s 47D(1)(b)-(e) do not address the various aspects of those subsections in sufficient detail or, in respect of some aspects, at all. 346 Although the parties' submissions briefly address the concept of "interoperability" as it applies to s 47D(1)(b), they do not address in sufficient detail the other components of that subsection, such as whether the ISI Replacement Macros were made "for the purpose of obtaining information". Further, the parties did not address the operation of ss 47D(1)(c)-(e). 347 It is for ISI to establish that the defence applies. 348 CA submits that the creation and testing of the ISI Replacement Macros was not done "for the purpose of obtaining information necessary to enable the owner or licensee, or a person acting on behalf of the owner or licensee" (that is, the owner/licensee of the CA URT Macros) to "make independently another program" (that is, the ISI Replacement Macros). 349 I agree, for the reasons given above. The reproduction of the R9 CA URT Macros by ISI through the 2004 and 2009 Macros was not made for the purpose of obtaining information to enable CA or a Datacom licensee to make another program. In that regard, it can be said that for the purpose of this subsection ISI was acting on its own behalf. 350 Section 47D was inserted into the Act by the Copyright Amendment (Computer Programs) Act 1999 (Cth). The following parts of the Explanatory Memorandum to the Copyright Amendment (Computer Programs) Act 1999 (Cth) (the EM) relate to s 47D(1): The effect of the Bill is that copyright in a computer program is not infringed if a copy is made in the course of finding out how the program interoperates with (ie, connects to or works with) other programs so as to make a new program to interoperate with any or all of those programs (decompilation is a commonly used process to discover this information)… The exceptions allowing copying for the purposes of interoperability [included that] the information, and the copy itself, must not be used or passed on to others for purposes other than those allowed by the exceptions, without the copyright owner's consent… New s.47D exempts from infringement the reproduction of a program in the course of finding out how it interfaces with other programs, if done for the purpose of independently creating an interoperable software or other product and if the information is not already available... New s.47D allows reproduction or adaptation of a computer program, without infringing copyright, to the extent reasonably necessary to find out how the program interoperates with other programs, so that the person reproducing or adapting the program can make a new program, or other computer product, to connect with it or with those other programs. The processes used in which a reproduction or adaptation is generated include decompilation and disassembly, and the information which s.47D allows such processes to be used to discover is often called interface specifications. The use of the term "interoperability" has a precedent in the European Communities Directive on the Legal Protection of Computer Programs. To come within this exception to infringement, the process resulting in the reproduction or adaptation of the program must be carried out by or on behalf of the owner or licensee of the copy of the program used in the process (new s.47D(1)(a)). The exception will not apply if the new program for the making of which the interface specifications have been sought is essentially a copy of the original program. That is, it must be an independently created program (new s.47D(1)(b)) and it must not reproduce the original program beyond the extent of its interfaces with other programs (new s.47D(1)(d)). Nor can the exception be relied on if the interface specifications of the program were readily available to the owner or licensee when carrying out the process resulting in the reproduction or adaptation of the program (new s.47D(1)(e)). Finally, the copy used in the process must not be an infringing copy (new s.47D(2))… (emphasis added) 351 The emphasis of s 47D(1), as can be seen by: the words 'for the purpose of obtaining information' in (b); the words 'only to the extent reasonably necessary to obtain the information' in (c); the repeated emphasis of the words 'in the course of finding out how' in the EM; and the statement 'to the extent reasonably necessary to find out how' in the EM, is on the acquisition of information from the reproduction in the quest to find out how the original program interoperates with other programs. In light of the EM and the words of s 47D(1), the purpose of s 47D(1) appears to be to allow a person to make a reproduction or adaptation of a computer program in order to obtain information necessary to make independently a new program or article that is to be used to interoperate with that program or another program. That is, certain copying is permitted in circumstances where it is necessary to obtain information to create interoperability. This is a very limited exception. 352 When the whole purpose of the reproduction is to enable the removal of the original program (the CA URT Macros), this does not seem to meet the "obtaining information" purpose of the section. Again, this was not fully addressed by the parties. 353 Further, subsection (b) requires that the new program be used together with, or interoperate with, the original program or any other program. 354 In this regard, ISI submits that the word "independently" means independently of the copyright owner's program, here Datacom and contends that 2BDB2 is a "new program" because it is made independently of Datacom. ISI submits that there is no difference under the terms of s 47D(1) between something that is interoperable because it is made externally to the original program and something that is interoperable because information in the original program is used to "deviate" from the original program. ISI says that the words "or any other program" indicate that the defence is available not just for the interoperability of the program devised (2BDB2) with the original program (Datacom) but also with other programs, which would include DB2. 355 However, the relevant reproduction or adaptation was not of Datacom but of the R9 CA URT Macros, which are the original program. Datacom and DB2 are therefore in the category of "any other program". 356 As the ISI Replacement Macros are designed to make 2BDB2 operate in an entirely Datacom free environment by replacing the CA URT Macros, 2BDB2 does not reproduce the R9 CA URT Macros "to connect to and be used together with, or otherwise to interoperate with" the R9 CA URT Macros ("the original program"). Indeed, 2BDB2 replaces the CA URT Macros. However, it could be said that ISI reproduced or adapted the R9 CA URT Macros to make independently 2BDB2 to be used together with or to interoperate with Datacom or DB2 ("any other program"). However, again, ISI did not explain precisely how it contends the subsection operates and, accordingly, CA did not respond. 357 Further, for s 47(1)(d) to apply, the ISI Replacement Macros would only be permitted to reproduce the R9 CA URT Macros to the extent necessary to enable 2BDB2 to connect with and be used together with, or otherwise to interoperate with Datacom or DB2. Again, ISI did not explain how it relied on this subsection. 358 Even if it could be said that the reproduction or adaptation of the R9 CA URT Macros in the 2011 Macros was done only to the extent reasonably necessary to obtain information to enable interoperation as referred to in (b), ISI has not addressed how this applies to the 1999, 2004 or 2009 Macros, which contained information unnecessary for such interoperation. Much of the information in the 1999 Macros related only to Datacom and to the early testing of the CA URT Macros. These parts were not substantially removed until the 2011 Macros. 359 Given that I have found that ISI has failed to establish the defence in s 47D(1)(a), which reasoning also applies to s 47D(1)(b), I do not propose to consider further ss 47D(1)(c)-(e). ISI has not established that those subsections apply.

[48]

Confidential Information 364 The legal principles concerning a claim for breach of confidence are not in dispute. The claim requires the establishment of three elements (Coco v AN Clark (Engineers) Ltd (1968) 1A IPR 587; Commonwealth v John Fairfax & Sons Ltd (1980) 147 CLR 39 at 51): the information must have the necessary quality of confidence; the information must have been imparted in circumstances identifying an obligation of confidence; and there must be an unauthorised use of that information to the detriment of the person who claims the confidence. 365 CA's case on confidentiality is broad. There seems to be a general case based on any information connected with Datacom and a more specific case directed to certain aspects or particular subject matter. 366 CA contends that while engaged by Macquarie and Beta (and other licensees) to assist in the conversion of those companies' databases from Datacom to DB2, ISI had access to information which was (and is) confidential to CA. CA accepts that use of that information merely to assist with those conversions was a proper use of that information. However, CA says that in using the information to develop and commercialise 2BDB2, ISI breached an alleged equitable duty of confidence owing to CA. 367 ISI contends, as a threshold issue, that CA has failed to identify the claimed confidential information with the necessary degree of specificity. ISI also disputes that CA has satisfied each of the three elements outlined above at [364]. In summary, ISI's response to CA's allegations is to accept that Mr Richards and other ISI employees and contractors derived information about the workings of Datacom while working with licensees but to say that the information to which they had access was not confidential. ISI submits that even if it was confidential, that confidentiality had been lost either because it was not maintained or because the information was publicly available. ISI also contends that the information was not imparted in circumstances importing an obligation of confidence. Further, ISI says that such information as was used was either obtained as a necessity and part of the work that Mr Richards was required to do in the ordinary course of his consultancies or was obtained by reverse engineering after arranging a "dump" that enabled him to view information in the source code of the customer's applications, that being information to which he did not need to have access but which he was able to access by this means. Finally, ISI submits that even if CA can establish a breach of confidential information, the defence of laches applies.

[52]

CA witnesses 378 Mr Shuma explains that the primary site for all development activities in respect of Datacom and the writing of the Datacom Manuals is CA's facility in Texas. According to Mr Milliken, until release 11.0 in February 2004, the Datacom Manuals were created, stored and edited on the CA mainframe computer and, since release 11.0, on a server. Both the mainframe computer and server are located at CA's headquarters in New York and can only be accessed through the CA intranet. According to Mr Milliken, access to the CA intranet, which also includes archived Datacom Manuals, is only available by means of employee passwords, which change every 45 days. Mr Shuma says that individual support engineers and developers within the Datacom group sometimes have personal copies of Datacom Manuals at work or at home, when doing work from home. Mr Shuma says that those of the Datacom Manuals classified as user manuals, which includes the Key CA Manuals, may not be altered by anyone other than the technical writers under Mr Milliken's management. For many changes to Datacom and the corresponding Datacom Manual, CA personnel involved in those changes use a problem-tracking program called STARTRAK, to which each of the Development, Support and Documentation teams working on Datacom within CA has access. 379 Messrs Shuma and Milliken give evidence of the process for the release of updated Datacom Manuals. Each of the Key CA Manuals is updated for each release of Datacom, after what seems to be a rigorous system of decision-making within CA, and then released to licensees. Over time, the means of provision of the Datacom Manuals has changed. Before release 8.1 they were delivered in hard copy. From release 8.1, they were delivered in hard copy and in CD format. From release 9.0 and for subsequent releases, Datacom and the Datacom Manuals have been made available online. Once complete, the revised set of Datacom Manuals is placed on the secure CA Support website for download by licensees of the particular Datacom release. 380 According to Mr Shuma, the online releases are made available to licensees by means of secure, password-controlled access over the internet by a secure transmission to the secure part of the CA website. However, certain licensees continue to require or to request that service packs and new releases be supplied on tape and in the form of hard copy or CD. 381 Mr Milliken agrees that electronic Datacom Manuals can be sent or forwarded at the click of a mouse. Accordingly, the practical protection of confidentiality in those manuals depends upon enforcement of security or contractual arrangements restricting their distribution. Mr Milliken says that he is unaware of any technology which restricts an internet user sending such material to another user. However, although there is no CA mechanism that controls the dissemination of the information in Datacom Manuals once those manuals have been issued to customers, he says that those working on Datacom, whether they be employees or independent contractors of licensees, would have understood those manuals to contain information confidential to CA. 382 Evidence adduced by ISI indicates that manuals in respect of CA's IDEAL language (not to be confused with the Datacom Manuals) were publicly accessible on CA's public File Transfer Protocol (FTP) server in 1999. Mr Shuma expresses surprise that this occurred, as he has always held the belief that all of CA's manuals should be on a restricted server for clients' use only. However, Mr Shuma draws a distinction between the Datacom Manuals and those particular IDEAL manuals on the basis that, in 1999, the IDEAL manuals were probably not under his control. 383 Mr Shuma admits that the two digit return codes, which are information contained in the Key CA Manuals, have been broadcast in public as far back as 2002 and that he has not taken any steps to stop information of that character being exchanged and discussed on the internet. However, he does not accept that other information in the Key CA Manuals is available from sources other than CA and Datacom licensees. 384 Mr Shuma says that the development of the source code for Datacom takes place using a mainframe system located in the CA facilities, which are secure premises with monitored and restricted entry. Mr Shuma gives details of the control of the entitlement to access the mainframe system, which is in place to ensure that there is no unauthorised access and that access to source code is limited to employees authorised to access and modify source code. Mr Shuma, who has worked with CA and ADR since 1985, says that, to his knowledge, CA has never used contractors in the development or support of Datacom, nor has it allowed contractors to access Datacom source code. 385 Mr Shuma says that requests from licensees of Datacom to provide them with a part or parts of the source code of Datacom have been accommodated in exceptional circumstances. However, he says that CA does not provide source code to licensees in the ordinary course. 386 Messrs Shuma and Milliken give evidence that CA has in place a system of induction and training of its employees which includes compliance with confidentiality requirements. All employees sign a confidentiality undertaking and receive training in areas of confidentiality and conflicts of interest. 387 Mr Shuma says that each employee at CA's premises (and before that, those of ADR), as well as each contractor working on the premises has been and still is issued with a security badge on which is his or her photograph. The security badge is programmed at time of issue so that it permits entry only to those zones at which that person is expected to work. CA's policy is that all visitors without badges must sign in and require an escort on the premises until outside the security area. 388 Mr Clayton says that in his experience it has always been CA's policy in every software licensing transaction to require a licence agreement for its products and to include in that agreement detailed provisions regarding CA's confidentiality in the relevant software. It is CA's practice in respect of licensing Datacom that, when a licensee first licenses Datacom, a full Software Licence Agreement (SLA) will be signed. CA's standard SLA includes the following clause (which was used in the SLA between CA and Macquarie signed in 1996): 2. CONFIDENTIALITY 2.1 The Licensed Program and all related documentation are the trade secrets and proprietary property of CA and embody or contain useful and valuable information which is confidential to CA. The Licensee undertakes that it will use its best endeavours to keep the Licensed Program and all related documentation in safe custody and to restrict physical access to media on which the Licensed Program is recorded and the related documentation to those of its employees who reasonably need such access in order to use the Licensed Program in accordance with this Agreement. The licensee will not remove or destroy any proprietary markings of CA. No disclosure of related documentation or any other information relating to the operation of the Licensed Program shall be made by the Licensee or any of its employees to any third party not previously authorised to receive such information under any written agreement with CA. 2.2 The Licensee further undertakes that it and its employees will not change, disassemble, decompile or otherwise reverse engineer the Licensed Program in order to create or attempt to create a corresponding source code and, except as authorised by this Agreement, will not make or permit others to make copies or reproduce any part of the Licensed Program or related documentation in any form without the prior written consent of CA. 2.3 i) Each party acknowledges that in connection with its duties hereunder it may be provided with or have access to written information data and/or other confidential material which is proprietary and/or confidential to the other and which is so marked as proprietary and or/confidential or which it would be reasonable to assume was proprietary or confidential due to its nature. Both parties agree to keep confidential all such information and shall not disclose the same either in whole or in part to any third party without the party's prior written consent. ii) Information which is already in the public domain or which is known to the receiving party without a breach of this or any other agreement or any other obligation of confidentiality shall not be treated as confidential for the purposes of this Agreement. 2.4 The Licensee shall furnish to CA such documentation and access to its facilities as CA may request from time to time in order to verify compliance with the provision of this Agreement. 389 The parties agree that Datacom constitutes a Licensed Program for the purposes of this SLA. 390 Mr Clayton admits that there has been no attempt to list in the SLA matters specifically treated as confidential. He relies on the general wording of the confidentiality clause. He says that the confidentiality clause cannot be removed, although CA lawyers may agree to make minor or cosmetic changes to it. 391 Mr Clayton says that CA employees are taught, in the frequent compliance training that he gives them, that there is to be no departure from the standard form of the SLA unless a modification has first been approved by a member of CA's Law Department. This includes any change to the confidentiality provisions. Mr Clayton can only give that evidence from his own experience but he says, and it was not challenged, that he would expect to know of any lapse in these requirements by CA employees and that he does not know of any failure to comply. 392 The opening pages of the Key CA Manuals also include further relevant material. Each of the Key CA Manuals for release 9.0 of Datacom relevantly states: THIS DOCUMENTATION MAY NOT BE COPIED, TRANSFERRED, REPRODUCED, DISCLOSED, OR DUPLICATED, IN WHOLE OR IN PART, WITHOUT THE PRIOR WRITTEN CONSENT OF CA. THIS DOCUMENTATION IS PROPRIETARY INFORMATION OF CA AND IS PROTECTED BY THE COPYRIGHT LAWS OF THE UNITED STATES AND INTERNATIONAL TREATIES… THE USE OF ANY PRODUCT REFERENCED IN THIS DOCUMENTATION AND THIS DOCUMENTATION IS GOVERNED BY THE END USER'S APPLICABLE LICENSE AGREEMENT. 393 In Mr Clayton's opinion, CA treats matters of security in respect of Datacom and the Datacom Manuals as being of the utmost importance and essential to its business. It is his belief, which is supported by letters in evidence, that, up until June 2008, upon the termination of a licence of Datacom, the procedure followed by CA was that the licensee was reminded of obligations of confidentiality with respect to Datacom software and the documentation. Further, an effort was made to ensure the erasure of digitally recorded copies and the return to CA or destruction of all hard copy manuals. Mr Clayton notes that in June 2008 the process of inquiry and correspondence for terminated licences was streamlined significantly but says that it is his belief that the confidentiality provisions by which CA binds its licensees remain in place notwithstanding the revised termination procedure. 394 Other than licensees, certain third parties may be given access to Datacom, primarily to object code and the Datacom Manuals. Mr Shuma says that the only examples of such access with which he is familiar are: where a contractor provides services to a Datacom licensee. Mr Shuma acknowledges that from time to time customers will engage consultants independent of CA to help them support and deal with operations of Datacom and that sometimes problems arise in the operation of Datacom, which means that the services of programmers or consultants are required to establish what has gone wrong. Mr Shuma says that in these cases CA requires the contractor to execute a non-disclosure agreement; where a third party needs information regarding Datacom, or to use Datacom to develop its own products or services that may be supplied to licensees of Datacom. In that case, CA requires the third party developer to execute a form of confidentiality agreement; and where the ultimate end user of Datacom is an outsourcing company's customer but where Datacom is operated on the computer mainframe platform belonging to the outsourcing company. In that case, CA requires the outsourcing company and the end user to enter into a licence agreement. 395 Mr Clayton rejects the suggestion put to him by counsel for ISI that 'the procedures of CA have never involved confidentiality commitments from consultants who might be working as independent contractors to software licensees'. He says that the outsourcing/consulting industry is run by 20 or 30 'big players' and that CA has global agreements with all of these companies, which include access to and use of CA licence programs globally by these companies' "people". This, Mr Clayton estimates, covers 90-95% of the "field". In relation to the remaining 5-10%, those being independent consultants, Mr Clayton describes a three way agreement called a Facility Management Supplement that is signed between CA, the licensee and the consultant. He says that CA monitors these agreements and, in general, records and holds documents in relation to consultants engaged in the support or trouble shooting of Datacom, although he concedes that not every Datacom licensee signs such an agreement. Mr Clayton accepts that CA could delegate to licensees the ability to enter into written agreements with consultants and thereby remove the need for a Facility Management Supplement obligation for the 5-10% of consultants not covered by CA's global agreements. In such a scenario, enforcement of that confidentiality would, he accepts, depend upon the customer's compliance and CA would not be involved in policing that compliance.

[53]

ISI witnesses 396 Mr Richards says that when he worked at Macquarie there was no control over physical access. The lifts were not key carded and people regularly visited within the application programming area. He says that if somebody 'had come dressed in a white coat with a trolley and loaded up a bookshelf [of the Key CA Manuals], no one [at Macquarie] would have said anything'. On the other hand, Mr Richards admits that he cannot say that he ever saw somebody come in and take a manual off the shelf. He simply maintains that he cannot say that someone could not have done it. However, in my view, the fact that the Key CA Manuals in work environments such as Macquarie were not kept under lock and key but were available to those who needed to use them does not of itself negative a conclusion that they retained the character of CA's confidential information. Much depends upon the systems put in place by CA and the understanding of those persons who used the Key CA Manuals. 397 Mr Melito gives evidence of his access to Datacom materials. From 1983-1984 Mr Melito performed installation and training for Datacom when he worked for ADR, the then owner of Datacom. In that capacity he received course materials under a confidentiality agreement as an employee. He says that he was not asked to return those materials when he left. 398 Mr Melito attended four CA World Conferences. He attended three of those conferences in his capacity as an employee representing companies that used CA products. Prior to 1999, Mr Melito did not sign anything in the nature of a confidentiality agreement in order to attend sessions and receive materials. However, he was subject to confidentiality restrictions at the 1999 CA World Conference, which is the only conference he attended as a CA Certified Systems Provider. 399 Mr Bickerdike attended a number of CA World Conferences between 1997 and 2004, his invitation first being extended through his employer, Shell Australia. His later attendances were while he worked for Charles Schwab. Each of Shell Australia and Charles Schwab was at the relevant times a Datacom licensee. Mr Bickerdike agrees that he had to register at CA World Conferences and that he had a badge that identified him by name and the particular organisation for which he was working at the time. Mr Bickerdike says that when he received CA handouts and a CD at one of the CA World Conferences, he was not required to sign a confidentiality or non-disclosure undertaking. He was also provided with materials by CA in order to present courses about the IDEAL programming language, which, as I have noted, is used with Datacom. He was not asked to sign a confidentiality agreement nor asked to return the materials. However, it is not clear whether these materials extended beyond information that would, in the ordinary course, be supplied to licensees and DBAs. 400 Mr Slaber says that he was given a hard copy of Datacom Manuals when he was at Beta which CA did not want returned. He does not recall which manuals he was given but says that they may have been a full set. He speculates that they are at his house, 'probably in my basement somewhere'. Further, Mr Bickerdike gives evidence that in late 2010 he located a CD containing Datacom Manuals in his possession. In neither case is there sufficient evidence to enable any conclusion to be drawn as to loss of confidentiality or whether and what information has lost the protection of confidentiality. 401 Mr Melito says that, as a consultant, he has had access to manuals for a number of products including DB2 and has never signed a confidentiality agreement pertaining to obligations to third parties before being allowed access to the manuals of those third parties. Mr Bickerdike also says that, as a contractor, he does not recall being required to sign a confidentiality agreement before being allowed access to computer manuals, including Datacom Manuals, at clients' premises. Mr Granger says much the same. However, he adds that in his dealings with clients and other contractors, 'it has been generally accepted that manuals are part of the licensed product like Datacom' but are available to staff working at the site, both permanent staff and contract employees.

[54]

General submissions on quality of confidence 402 CA's evidence was generally directed to displaying the strength of its confidentiality regime. CA submits that the CA Information has the necessary quality of confidence because: It was created by research, the considerable expenditure of time and money and the application of skill and ingenuity. It is inherently confidential by its nature. It is intrinsically valuable to CA and its customers (and would be to CA's competitors). As Datacom is a commercially significant product for CA operating in a competitive market, CA treats matters of security in respect of Datacom (including the CA URT Macros) and the Key CA Manuals as of utmost importance. The confidentiality regime in which CA operates is regarded by CA as of utmost importance and is essential to CA's business. CA has gone to great lengths to keep the CA Information confidential by undertaking various internal security measures. It has also undertaken various external security measures implemented in respect of Datacom licensees, including licence notices on Datacom tapes, discs and the Key CA Manuals and the entering into of SLAs (or other forms of licence agreement) before a licensee is supplied Datacom and the Key CA Manuals. 403 ISI directs its submissions as to lack of confidentiality to specific categories within the CA Information, which I will expand upon further below. In general, ISI's contentions are either that the information in these categories was never confidential or that any confidentiality that was attributable to the information ceased as a result of a public disclosure. 404 In general, CA submits that the disclosures relied upon by ISI do not alter the confidentiality of the CA Information. CA submits in the alternative that, to the extent that any of the CA Information became publicly available, the springboard doctrine is applicable on the basis that ISI did not use any of the alleged public disclosures of the CA Information in developing 2BDB2 but rather used information obtained in confidence.

[55]

The Key CA Manuals 405 ISI submits that the Key CA Manuals are not confidential on the bases that: CA has not adduced evidence about the confidentiality status of the Key CA Manuals prior to CA's acquisition of ADR. In order to prove that CA's system kept information confidential, ISI contends, CA must prove that the information within that system was confidential in the first place. The Key CA Manuals for release 9.0 of Datacom were made freely available to the public since at least 1999 by virtue of having likely been published on CA's public FTP site and since at least 1997 by virtue of CDs containing the Key CA Manuals having been freely handed out by CA at events including CA World Conferences. A significant amount of information has been and still is available on the internet disclosing information which ultimately derives from one or more of the Key CA Manuals. In practice, CA's attitude to the information contained in the Key CA Manuals, in particular by failing to impose confidentiality requirements on ISI contractors who were on-site at the premises of Datacom licensees since at least February 2003, is inconsistent with a claim of confidentiality. 406 ISI says that despite the covering assertion of confidentiality in the Key CA Manuals, in reality it was necessary and to CA's benefit that as many independent contractors as possible were familiar with the workings of Datacom. 407 In response and in addition to its general submissions at [402], CA says that ISI has not established that anyone other than Datacom licensees obtained the Key CA Manuals at CA World. 408 I reject ISI's submissions. 409 In view of Mr Shuma's evidence about the confidentiality regime at CA and in the absence of any evidence suggesting that there had been no such regime prior to CA's acquisition of ADR, I am prepared to infer that a similar regime existed at ADR. That regime provided the necessary quality of confidence to the information in the Key CA Manuals. 410 It cannot be inferred, as ISI seeks to do, that the Key CA Manuals were available on CA's FTP site simply because CA's IDEAL manuals were available on that site. They are not the same manuals. 411 The evidence does not establish ISI's contention that the Key CA Manuals were handed out on CD or handed out without restriction at CA World Conferences. 412 The evidence concerning CA World Conferences and the information on the internet is not inconsistent with CA's claim for confidentiality in the Key CA Manuals. The presence of information on the internet or in CA World Conference materials that derives from the Key CA Manuals cannot be said to be equivalent to a disclosure of the Key CA Manuals. It is not inconsistent with CA's claim for confidentiality in the Key CA Manuals for CA to have provided or disclosed some information in the CA World Conference materials to participants that may, in part, derive from the Key CA Manuals. Likewise, it is not inconsistent with CA's claim for confidentiality in the Key CA Manuals for CA not to have taken action to remove material on the internet that may, in part, derive from the Key CA Manuals. Those forms of information have not been shown by ISI to be in the format of the Key CA Manuals, to copy parts of the content of the Key CA Manuals, nor to make relevant reference to the content of the Key CA Manuals. 413 Further, the evidence does not establish that, in general, CA made the Key CA Manuals publicly available other than to its licensees and others operating under an obligation of confidentiality, whether that be express or implied. In most cases, those persons were contractually bound to keep the information in the Key CA Manuals confidential. Otherwise, as in the case of the ISI contractors (which I will deal with further below), they should have realised that obligation in the circumstances of disclosure by reason of the fact that they were working for Datacom licensees, bearing in mind the fact that each of the Key CA Manuals contains what is akin to a confidentiality notice. 414 I accept the evidence of Messrs Shuma, Milliken and Clayton in respect of the Key CA Manuals. I also accept CA's submissions at [402], as applied to the Key CA Manuals. The evidence of Messrs Shuma, Milliken and Clayton establishes the requisite confidential nature of the Key CA Manuals.

[56]

CADRE-L disclosure 415 Mr Shuma explains that the CADRE group (CADRE) is a group of users with an agenda to promote the use of Datacom and to help Datacom clients. CADRE-L is a Listserv available through CADRE. It is an online user group through which one can post/email a question which is received by anyone who is registered on the Listserv. Mr Shuma says that CADRE-L is part of Datacom's "user group community" and says that it is one of the means by which Datacom provides support to its users. 416 Mr Shuma has been registered on CADRE-L for many years and has occasionally posted information on it. He says that he typically reads the CADRE-L emails and checks to see what they contain and whether there has been a response. If a client asks a question and nobody within the client base responds, Mr Shuma says that he will try to provide the client with a response. 417 Mr Clayton accepts that anyone can subscribe to CADRE-L. Both Messrs Bickerdike and Granger subscribed to CADRE-L. Mr Melito is also familiar with the CADRE website. 418 On 1 December 2005, a CADRE-L user, Souvik Sinha, posted a question on CADRE-L (the Sinha question). The relevant parts of the post are as follows: I am completely new to CA-Datacom. My clients have a CA-Datacom 10 database… The clients won't supply us any Programming Guide / manual of Datacom - forget about CA site ID! Can anyone help me by sending the Datacom Programming Guide? 419 Another CADRE-L user, James Lareau, responded just over an hour later with an attachment, stating 'here you go' (the Lareau response). 420 In response to the Sinha question and the Lareau response, which he was shown in cross-examination, Mr Shuma: agrees that he was paying attention to CADRE-L in December 2005; says that he does not remember the Lareau response and has no record of ever having received it or any attachment to it; says that he does not believe that the Lareau response was received by CA or by any recipient; says that he received the Sinha question but that there is no record of it on his computer; agrees that he could have voiced his concern on CADRE-L for readers to see but says that he tried to stay off CADRE-L unless he needed to be there. Instead, he says that he took action by calling the executive board of CADRE and asking them for assistance in correcting the problem, that is, by reminding subscribers that the materials are the property of CA and contain confidential information. He says that he was satisfied with the action taken by CADRE in this respect; and says that, in any event, he does not believe that version 10.0 of the Programmer Guide was posted, as CADRE-L does not handle the sending of large manuals and has a history of not handling non-text documents. 421 Mr Clayton obtained a list of the subscribers to CADRE-L, both as at 2 December 2005 and since that date. Mr Clayton gives evidence that Mr Shuma has verified that, as at 2 December 2005, of the 232 CADRE-L subscribers, 29 were CA employees, 182 were from businesses under licence to CA and 21 were of addresses that Mr Shuma was not able to identify. Mr Clayton says that 14 of the 97 additional subscribers since 2 December 2005 have addresses that Mr Shuma is unable to identify. Mr Clayton accepts that it is conceivable that the 35 CADRE-L subscribers who allegedly received the Lareau response purportedly attaching version 10.0 of the Programmer Guide were not under any kind of restriction by contract to CA. However, he points out that the Lareau response does not mean that the recipients actually received the manual. Rather, he says, they would have received a Base64 document that could not be read. 422 Mr Milliken maintains that he does not know how a member of CADRE-L could obtain a copy of version 10.0 of the Programmer Guide unless that person was a licensee and had it in their storage area. 423 ISI submits that the evidence establishes that, since at least 1 December 2005, version 10.0 of the Programmer Guide has been publicly available by reason of being posted on CADRE-L and that the concept of "relative secrecy" does not avail CA in the circumstances. ISI points out that: CA took no action to contact Souvik Sinha to assert any rights of confidentiality in the Programmer Guide; CA took no action to remove version 10.0 of the Programmer Guide from the CADRE-L archives; and the evidence indicates that CADRE-L is open to any member of the public who wishes to access it. Any person who joins will be able to browse archives of emails previously sent to the list. 424 ISI contends that Mr Shuma's evidence that he did not see the Programmer Guide on CADRE-L should not be accepted. ISI says that the evidence suggests that Mr Shuma was not concerned that the manual had been posted on CADRE-L. 425 CA contends that the Lareau response does not amount to a disclosure that removes or lessens the confidentiality of the confidential information within the Programmer Guide, as it was not "published on the internet". CA points out that: the participants of CADRE-L are mainly CA staff or staff of Datacom licensees; the circumstances of the alleged disclosure indicate that the reason for making the request was that the Programmer Guide was impossible to obtain otherwise; the Programmer Guide was only available in the form of a Base64 encryption; and shortly after the Sinha question and Lareau response, all potential recipients on CADRE-L were informed of the confidentiality of the Programmer Guide. 426 I accept the evidence of Messrs Shuma and Clayton on this issue. In particular, I accept that the Programmer Guide was only available in the form of a Base 64 encryption. In the face of this evidence, ISI has not adduced any evidence to suggest otherwise, nor has it adduced any evidence that establishes that any of the CADRE-L subscribers who were sent the Lareau response actually received an attachment containing version 10.0 of the Programmer Guide in an accessible format. The Lareau response was not a disclosure of version 10.0 of the Programmer Guide.

[57]

ReadRXX 427 ReadRXX is a tool external to Datacom that since release 7.5 has been provided with Datacom to licensees. According to Mr Shuma, ReadRXX allows the Datacom licensee to retrieve data changes stored in the log data (on the RXX) as readable row images. In addition, ReadRXX provides key information about the transaction that caused the change, such as time, date, program and user ID. There is a chapter on the ReadRXX routine in the Database and System Administrator Guide (the ReadRXX Chapter). 428 ISI contends that CA has not identified what parts of the information concerning the ReadRXX routine are confidential (contrary to Smith Kline and French Laboratories (Aust) Limited v Secretary, Dept of Community Services and Health (1990) 22 FCR 73 at 87). ISI says that CA fails to distinguish between the ReadRXX routine and the information about the routine. ISI points out that, as Mr Lynn confirms, the Key CA Manuals do not contain the ReadRXX routine, which itself is part of Datacom. ISI emphasises that all that is in the Key CA Manuals is information about calling the routine and a short header file that needs to be included in any customer application that does so. ISI contends that the information about what a user must do to operate Datacom to call the ReadRXX routine is not confidential or susceptible of protection in equity on the basis that it is factual information about the operation of the program, not about what the program does. 429 I accept ISI's submissions. 430 CA has made a general assertion of confidentiality for the CA Information, including for the ReadRXX routine. ISI brought a specific attack against CA's claim with respect to the ReadRXX routine. CA did not provide sufficient evidence or submissions to identify exactly what information concerning the ReadRXX routine was claimed to be confidential, nor the basis upon which that claim for confidentiality could be supported. If somewhere in the morass of evidence and submissions such support existed, CA did not provide assistance in drawing attention to it. I am unable to conclude that CA's claim with respect to the confidentiality of information concerning the ReadRXX routine has been made out. 431 I will, nevertheless, also consider the issue of whether the ReadRXX routine was publicly disclosed.

[58]

CADRE-L Disclosure 432 On 7 July 2004, a CADRE-L user, Mr Scherrer, attached the ReadRXX Chapter in a posting on CADRE-L. Mr Shuma accepts that since that date the contents of the ReadRXX routine have been accessible to any participant in CADRE-L. This is in contrast to the attachment to the Lareau response. 433 ISI contends that, even it were confidential before 7 July 2004, the ReadRXX routine has not been confidential since that date as a result of the posting of the ReadRXX Chapter. ISI's submissions can be summarised as follows: CADRE-L was not an obscure website but was the reference point for people wanting to program or work with Datacom. CADRE-L had been around for many years and had hundreds of subscribers. Every email sent to the list was sent to all of its subscribers and then stored on an easy to locate, publicly accessible website. Publication to the list was publication to at least the world of people who were interested in Datacom. The ReadRXX Chapter was posted on CADRE-L in plain English in its entirety. 434 ISI also relies upon the fact that CA did not take any action when Mr Scherrer, employed by a CA client, published the ReadRXX Chapter. Again, this contrasts with Mr Shuma's actions in response to the Sinha question and Lareau response. ISI submits that this was because it was to CA's advantage that as many IT professionals as possible knew about Datacom in order to be able to work with it. 435 In essence, CA acknowledges that the ReadRXX Chapter was posted on CADRE-L on 7 July 2004. However, CA submits that because of: the obscure listing of the posting; evidence suggesting that there was difficulty in obtaining a readable version of the posted chapter; the lack of evidence that anyone who was not a CA customer had obtained the posting; the fact that the posting was not ascertained until after these proceedings commenced; and the fact that CADRE-L was only accessed by customers of CA who were bound to confidentiality by contractual obligations and would, or should, have been aware of the confidential nature of the ReadRXX Chapter, the confidentiality was not lost. 436 CA contends that CADRE-L was designed to be accessed only by customers of CA who were bound by confidentiality agreements. An accidental disclosure, an unauthorised disclosure or a disclosure made in breach of confidential obligations does not, CA says, negate its right to claim confidentiality. CA adds that it is not clear if the unauthorised disclosure was able to be or was in fact read. 437 In any event, CA says that a reasonable person in all the circumstances would have recognised the information to be confidential. That is, CA maintains that the circumstances were such as to impose an obligation of confidence on any person who actually managed to access the ReadRXX Chapter on CADRE-L, if such existed (Coco at 591; Smith Kline at 96). 438 Further, CA points out that there is no evidence or suggestion that ISI used that disclosure on CADRE-L to obtain the information in the ReadRXX Chapter. 439 CA accepts that the ReadRXX Chapter was made available on CADRE-L. CA has not established that the format in which the ReadRXX Chapter was made available was inaccessible. Bearing in mind Mr Clayton's evidence that any member of the public can subscribe to CADRE-L and his evidence that Mr Shuma was unable to identify some of the CADRE-L subscribers both as at and after 2 December 2005, the evidence does not establish that the information was only accessible to customers of CA who were bound by confidentiality agreements. The ReadRXX Chapter was made available to the public by Mr Scherrer's posting. 440 Further, there is no basis for finding that a reasonable person who was outside the scope of any confidentiality agreements and who managed to access the ReadRXX Chapter would have recognised its contents to be confidential. There is no reference to confidentiality in the ReadRXX Chapter. CA has adduced no evidence that establishes that those likely to have accessed the ReadRXX Chapter in such circumstances would have been aware of its confidentiality. 441 Even if the information relating to ReadRXX was confidential prior to 7 July 2004 (which it was not), such information was publicly disclosed on that date and lost any confidentiality that may have been attributable to it.

[59]

The source code of the CA URT Macros 442 ISI says that the source code of the CA URT Macros only amounts to lines of text in a computer and contends that, as lines of text in a computer have only functional use, they are not subject matter capable of protection as confidential information. ISI points out that the CA URT Macros: are not held back by CA from Datacom licensees, as is "true" source code; are given to Datacom licensees for use by DBAs; and are supplied as text files and placed into the "macro library" of the user's mainframe upon installation, which is the same location that all other macros installed or created by the user are placed. ISI says that based on these facts there is no 'necessary quality of confidence' to be protected (Australian Medic-Care at [632]). 443 Further, ISI maintains that CA has not satisfied the necessary onus of demonstrating with precision the information within the CA URT Macros said to be confidential, rather than asserting confidentiality at 'high levels of abstraction' (Retractable Technologies v Occupational & Medical Innovations Ltd (2007) 72 IPR 58 at [90] per Greenwood J). 444 CA submits that the CA URT Macros were by their nature inherently confidential. The CA URT Macros are, CA emphasises, an important part of Datacom because they produce the URT and DBNTRY. CA contends that a reasonable person would, in all the circumstances, have recognised the information to be confidential. 445 The source code of the CA URT Macros is subject matter inherently capable of being protected as confidential information. The source code of the CA URT Macros provides the mechanism by which Datacom licensees and their DBAs are able to produce the URT and DBNTRY. This is a mechanism which the licensee would otherwise not have (and would, it seems, be required to create). Such a mechanism is a form of information and is inherently capable of being protected as confidential information. The fact that the information is in the form of a text file is not to the point. Further, the fact that, unlike the source code of Datacom, the source code of CA URT Macros needs to be provided to the licensee is not to the point. That is no different from the Key CA Manuals. As CA points out, the CA URT Macros were supplied as part of Datacom and subject to the same contractual arrangements concerning confidentiality as other components of the CA Information. 446 ISI also submits that the CA URT Macros and their parameters are not confidential on the basis of how they have been treated by CA. ISI submits that: CA has not proven that the Database and System Administrator Guide was not made public before CA acquired ADR in 1988. This would have made the CA URT Macros and their parameters publicly available. The CA URT Macros were disseminated by ADR as part of Datacom version 7.4 in 1985. CA has not proven that their contents were then confidential. Any confidentiality was lost when the CA URT Macros were supplied to every licensee of Datacom for use by licensees and their DBAs, including independent contractors, with CA's knowledge and to CA's benefit. 447 As I stated earlier at [409], in view of Mr Shuma's evidence about the confidentiality regime at ADR and in the absence of any evidence suggesting that there had been no such regime prior to that acquisition, I am prepared to infer that a similar regime existed at ADR. This would extend to information concerning the CA URT Macros in the Database and System Administrators Guide, as well as to the source code of CA URT Macros. 448 I reject ISI's submission that confidentiality in the CA URT Macros was lost when they were supplied to Datacom licensees. Again, as CA points out, the CA URT Macros were supplied as part of Datacom and were subject to the same contractual arrangements concerning confidentiality as other components of the CA Information. When the CA URT Macros were provided to the user, they were provided on the understanding, accepted by licensees and generally by employees and contractors in the industry, that they were subject to the relevant CA licence and CA's copyright and confidentiality. 449 Finally, in its closing written submissions, ISI cites evidence which suggests that the names of the CA URT Macros and 39 of 44 of their parameters have been publicly available since at least 1993-1994. However, ISI has not explained the significance of the evidence or the reasons why any confidentiality in the information was lost, let alone the significance of those 39 parameters to the whole of the CA URT Macros. CA provided no response to this submission. I am not in a position to consider it further. 450 The source code of the CA URT Macros is confidential information. ISI has not established that the CA URT Macros were made publicly available.

[61]

Disclosure of RQA 453 ISI submits that even if the information about the structure of the RQA and the information that may be put within it were previously confidential, as a result of the disclosures in the ADA Documents, which have been available on the internet since at least 31 January 2002, the information is no longer confidential. The ADA Documents comprise a series of documents that are found as the fourth search result for the term "Request Qualification Area" on Google. The search was apparently conducted during the course of these proceedings. These documents have labels such as "dc_int.spc", "dc_int.bdy" and "dc.doc". The first page of the latter states: 'The Datacom Interface package developed for Datacom/DB provides an ADA interface from which ADA application programs can perform database queries and database manipulation on Datacom/DB'. 454 ISI says the ADA Documents reveal: all of the Datacom commands, including SAAT commands; the characters that go into particular locations in the RQA to build up the query; and the locations where those characters have to go. 455 Despite not having personally debugged at this level of detail in 20 years, Mr Lynn agrees that: the ADA Documents contain Datacom commands and parts of the RQA. He says that the ADA Documents accurately describe the section header block used in the RQA; the ADA Documents provide a description of where pieces of information reside in each of the section blocks in an RQA; and there is information in the ADA Documents from which one can decode the contents of an RQA. 456 However, CA says that there is no evidence to show that the ADA Documents were available on the internet before the trial in these proceedings. ISI disputes this and points to: a footer of one of the ADA Documents, which contains the date of 30 January 2002; and the fact that that same document has a listing of files on a website, bearing the date 11 August 1998. 457 CA also contends that even if the ADA Documents were publicly available, there is no evidence to show how much the ADA Documents revealed to a capable reader as at the date that ISI developed 2BDB2. 458 In this regard, ISI relies on Mr Lynn's evidence and acceptance that the ADA Documents accurately describe the structure of the components of the RQA, including its overall structure, the section headers and section blocks. Mr Lynn is, ISI submits, representative of a competent programmer who would have been able to work out the contents of the ADA Documents, including the comparison operators and commands in B2BRQA and AMODDY, concepts which I will discuss in more detail later. 459 There is no suggestion that anyone accessed the ADA Documents. I accept CA's submissions as to the absence of evidence from ISI of what would have been disclosed by the ADA Documents to a member of the public. There was no evidence advanced by ISI that is of assistance. ISI has not adduced evidence that any member of the public could have used the ADA Documents to ascertain the RQA. Mr Lynn, as a creator of Datacom and as a person with knowledge of Datacom beyond the RQA, is not representative of a competent programmer or member of the public who may have accessed such a disclosure, if it was in fact made as ISI contends. Although Mr Lynn agrees that there is information in the ADA Documents from which one could decode the RQA, this evidence amounts to speculation and is affected by Mr Lynn's deep understanding of Datacom. This evidence does not establish the content of the disclosure to the relevant addressee. 460 The evidence and submissions are insufficient to establish what, in fact, would have been disclosed by the ADA Documents to the ordinary, competent programmer or member of the public or whether or not the material, if publicly available, would have disclosed the actual content of the RQA, (that is, the confidential information), or would have enabled the recipient to have discovered that information.

[64]

Evidence 467 Part of the evidence on this issue relates to the contractual terms (or absence of them) governing the relationships between CA, ISI and Macquarie or Beta. The other evidence on this issue relates to the understanding held by those working at ISI of confidentiality in the industry and, more specifically, their own confidentiality obligations. 468 The relevant parts of the SLA between Macquarie and CA have already been outlined at [388] above. 469 The licence agreement between Beta and CA signed in 1999 also included a provision for confidentiality of the licence agreement and its terms. The agreement, which lists Datacom as a "Licensed Program" in a schedule, also stated: Authorized Use. The Licensed Programs may be used only be and for the benefit, and to process exclusively the data, of Licensee at the Licensee Sites. (original emphasis) 470 Mr Richards says that he was 'not at any time instructed by [Macquarie] in relation to any confidentiality obligations surrounding the use of manuals or any other materials in connection with… Datacom'. However, in an agreement between Macquarie, ISI and Mr Richards of 7 November 1996, Mr Richards agreed to keep confidential Macquarie's confidential information. 471 Mr Holliday worked on releases 7.0 and 8.0 of Datacom at Macquarie and, later, at other client sites, he encountered versions 10.0 and 11.0. He says that he was not aware of confidentiality regimes or told that the content of the Datacom Manuals was secret. However, Mr Holliday says that he is acquainted with the general system in the software world of the use of software in the mainframe environment being pursuant to licences. He says that he has come across many such licences in his time. 472 Mr Granger says that in his experience at Beta and other Datacom licensees, no specific instructions were given about the confidentiality of manuals. However, Mr Granger agrees that he is aware that, as a general practice, computer programs in the mainframe or PC environment are released by their suppliers under the terms of licences. He agrees that in the mainframe environment somebody other than the contractor has already accepted the terms of the licence and that usually the licence is to the company for which the contractor is working. Mr Granger says that when using computer manuals in the past, he has noticed claims about copyright and confidentiality and he agrees that it is his common experience to encounter claims of that kind in computer manuals. 473 Like Messrs Holliday and Granger, Mr Richards understands that, as a general practice in the computer software mainframe industry, there is an extensive set of licences and agreements covering the use of software. However, Mr Richards questions whether placing notices on manuals and software relating to copyright was a widespread practice in the period from 1998 to 2002. He says that in a practical sense the front section of manuals was not referred to by application programmers - they would jump straight to the index. 474 In Mr Richards' experience, programmers who supported licensees such as Macquarie were often independent contractors rather than employees. However, Mr Richards says that he never instructed the team of about eight people working on 2BDB2 that they should not copy from any other source or refer to any other particular materials. He says that it was not his position to do so because the other team members were employees or contractors to ISI. 475 The 2BDB2/Datacom Installation Guide for R5.2 dated January 2006 (the Installation Guide) and the 2BDB2/Datacom Release Guide for R5.1 dated July 2000 (the Release Guide) each bears a copyright notice, as well as a detailed notice (the Notice) that states, inter alia: This documentation and related computer software program (hereinafter referred to as the "Documentation") is for the end user's informational purposes only and is subject to change or withdrawal by Independent Systems Integrators Pty Ltd. ("ISI") at any time. This Documentation may not be copied, transferred, reproduced, disclosed, or duplicated, in whole or in part, without the prior written consent of ISI. This Documentation is proprietary information of ISI and protected by the copyright laws of Australia, the United States and international treaties. To the extent permitted by applicable law, ISI provides this Documentation "as is" without warranty of any kind, including without limitation, any implied warranties of merchantability, fitness for a particular purpose, or non-infringement. In no event will ISI be liable to the end user or any third party for any loss or damage, direct or indirect, from the use of this Documentation, including without limitation, lost profits, business interruption, goodwill, or lost data, even if ISI is expressly advised of such loss or damage. The use of any product referenced in this Documentation and this Documentation is governed by the end user's applicable license agreement. 476 The 2BDB2/Datacom Installation and Administration Guide for R5.1 dated July 2000 includes a form of the notice that does not make reference to the copyright law of Australia. The 2BDB2/Datacom User Guide (the User Guide) for R5.2 dated October 2008 contains the Notice and also notifies the existence of copyright in ISI from 2000 to 2008. 477 Mr Richards accepts that he had seen a version of each of the Installation Guide, the Release Guide and the User Guide and that he had been involved in their creation. Further, the draft of the 2BDB2/Datacom Developers Reference for R5.1 dated August 2001, which is identified to be for internal use, states that copyright is held by Long Grass Systems Pty Ltd, Mr Richards' company, and also contains the Notice, with an amendment to the first paragraph to indicate the limitation to internal use only.

[66]

CA URT Macros 480 ISI says that CA has not proved that ISI received the source code of the R9 CA URT Macros in circumstances importing an obligation of confidence to CA or otherwise fixing ISI's conscience for the purposes of a breach of confidence action. 481 ISI accepts that Mr Worboys is likely to have been the "creator" of the 1999 Macros. However, ISI asserts that the evidence does not establish that ISI created the 1999 Macros at Beta through Mr Worboys, notwithstanding that, at the time of the creation of the 2004 Macros, Mr Worboys was a contractor to ISI and spending much time at Beta. ISI also contends that CA has failed to establish that Mr Worboys received any material in circumstances importing a duty of confidence and hence that his conscience was in any way affected. ISI points out that this would extend to Mr Worboys' creation of the 2004 Macros. In support of its submission, ISI draws attention to the following: There is no evidence as to when or from where Mr Worboys obtained the 1999 Macros. Release 9.0 of Datacom was released in October 1996. Although the 1999 DBUREND Macro is similar to the R9 DBUREND Macro, the other four of the 1999 Macros are not exact copies of the other four of the R9 CA URT Macros. If the source of those macros is, as Mr Turgeon suggests, from CA URT Macros earlier than release 9.0 of Datacom, this suggests that these macros would have been in existence earlier than October 1996. As ISI did not start at Beta until 1998, which was the genesis of 2BDB2, and as there is no evidence that Beta, or any other licensee with which ISI was involved, had other than the full release 9.0 of Datacom, the available inference is that Mr Worboys obtained what became the 1999 Macros before he went to Beta. The evidence suggests that Mr Worboys inserted line numbers into the files for the 1999 Macros before he inserted the ISI header, which suggests that the files had been obtained and numbered before ISI was involved. However, ISI did not specify this evidence. The fact that Mr Worboys left the line numbers, which were easily removed, in the files for the 2004 Macros suggests that he was not acting with a guilty conscience. 482 ISI adds that CA's delay in commencing proceedings has deprived it of being able to establish the provenance of the 1999 or 2004 Macros because of Mr Worboys' death in January 2008. 483 ISI contends, on the basis of the above matters, that the inference that can be drawn is that Mr Worboys obtained the 1999 Macros from a source and in a manner that suggests that he was properly able to use them in the manner in which he did. 484 ISI also contends that CA has not established that the creation of the ISI Replacement Macros has affected ISI's conscience in any way. ISI says: The presence of the 1999 Macros on ISI's system is 'immaterial'. The 1999 Macros were not distributed in that form, or said to have been used, other than for the purposes of the 2004 Macros. The existence of the 1999 Macros is relevant only when considering the 2004 Macros. There is no evidence to establish the existence of facts to affect ISI's conscience or a fact that would have put an ISI programmer on notice that the 2004 Macros contained unsuitable material, having been provided by Mr Worboys, a competent programmer. There is an absence of evidence proving that, upon receiving the 2004 Macros, ISI should have realised that they contained information confidential to CA or that ISI's conscience otherwise should have been affected. The fact that parts of the 1999 Macros are found in the 2004 Macros, an even smaller part in the 2009 Macros (together with new material) and none of relevance in the 2011 Macros, falls short of establishing the necessary state of mind for a breach of confidence case. 485 Each of the 1999 Macros includes a copyright notice indicating that copyright in the particular macro belongs to ISI. CA says that the only inference that can and should be drawn from this is that ISI was aware that it had misappropriated CA's property and rights in that property. CA asserts that any suggestion by ISI that Mr Worboys, alone, can be blamed for the copying of the ISI Macros and that it had no knowledge of this conduct should be rejected. CA asks the Court to draw the inference that not only was ISI aware of Mr Worboys' copying of the R9 CA URT Macros, but also that it directed it to occur.

[67]

Conclusion 486 It is relevant, in considering the understanding of those working on behalf of licensees, that the licences contained provisions for confidentiality. In particular, the SLA between CA and Macquarie contained a stipulation that Datacom and all related documentation were the trade secrets and proprietary property of, and confidential to, CA (see [388] above). Macquarie undertook to keep the program and all related documentation in safe custody and to restrict physical access to them. Macquarie also undertook that it and its employees would not 'change, disassemble, decompile or otherwise reverse engineer' the program or permit others to make copies of or reproduce any part of the program or related documentation. On the other hand, the licence agreement between CA and Beta provided that the terms of the agreement were confidential and also that Datacom could only be used for the benefit of licensee. Although CA has not established that ISI was bound by these provisions contractually, they are nonetheless relevant because the notices on the Key CA Manuals reference the end user's applicable licence agreement. 487 The evidence of Messrs Holliday and Granger is that they were not given instructions by the Datacom licensee about the confidentiality of the Key CA Manuals, while Mr Richards questions whether the confidentiality notices on the Key CA Manuals would have been noticed by application programmers. However, the evidence also indicates that Messrs Richards, Holliday and Granger were all familiar with licensing practices for the use of software in the mainframe environment. At its highest, this evidence may support the view that when receiving the CA Information, Messrs Holliday, McLennan, Worboys and Granger may not have been aware that they owed CA a duty of confidence. However, in my view and in the context of their involvement with software in mainframe environment, this is doubtful, even without attributing any weight to the presence of the Notice on various ISI materials. 488 Mr Richards' assertion of copyright and confidentiality in his own work relevant to 2BDB2 is inconsistent with his assertion that he was unaware that information such as the Key CA Manuals and Datacom's source code was in no way confidential information. I do not accept that he was unaware of the confidential nature of the CA Information or that it was in breach of the obligation of confidence to use his position as a contractor to Macquarie and Beta to use the CA Information otherwise than for the purposes of working with Datacom. 489 In any event, whether Messrs Richards, Holliday, McLennan, Worboys and Granger were aware or not, the test posed by Medic-Care is whether a reasonable person standing in the shoes of those working on ISI's behalf would have realised that they were receiving information in confidence. The evidence of Messrs Richards, Holliday and Granger suggests that those working in the industry well understood the existence of licences and their effect on the information they related to, including that that information was proprietary. In view of the nature of CA's customers, the commercially valuable and sensitive nature of the CA Information, the coverage by the licences (which had the effect of making licensees contractually bound to observe the confidentiality of the CA Information) and, importantly, the notices on the Key CA Manuals and other Datacom material, the evidence suggests that it would be well known among Datacom licensees and those working in the industry on behalf of Datacom licensees that such information was and was to be treated as confidential to CA. In effect, this is what was freely acknowledged by Mr Granger. A reasonable person standing in the shoes of those working on ISI's behalf at Macquarie and Beta should have appreciated that the CA Information was inherently confidential to CA. I am satisfied that the CA Information was imparted to ISI in circumstances importing an equitable obligation of confidence. 490 As to ISI's submissions on the CA URT Macros, ISI seems to be drawing a distinction between Mr Worboys' receipt of the confidential information contained therein while working at ISI and ISI's receipt of the ISI Replacement Macros from Mr Worboys. ISI seems to say that CA has not established that Mr Worboys appreciated that the macros themselves constituted or contained confidential information and, even if he did appreciate this, ISI did not appreciate it when it created and supplied subsequent versions of the ISI Replacement Macros. This submission was only advanced by way of the additional responses to the questions I posed after the hearing. ISI adduced no evidence in support of its submissions as to Mr Worboys' or its own lack of appreciation of the confidentiality of the information. 491 I am prepared to infer that Mr Worboys was working for and on behalf of ISI at the time that he accessed the source code of the R9 CA URT Macros and used it to develop the 1999 and 2004 Macros. Mr Richards also worked on the 2004 Macros. Messrs Worboys and Richards were persons who would have known of, or ought to have appreciated, the confidentiality of the source code of the CA URT Macros, generally for the reasons outlined above at [489]. This establishes that the source code of the CA URT Macros was imparted to ISI in circumstances importing an equitable obligation of confidence. 492 ISI submits that, in any event, the creation and supply of the ISI Replacement Macros has not affected ISI's conscience. In my view, this submission seems to misstate the issue at hand; the question to be answered is whether the information was imparted in circumstances importing an obligation of information. Once it has been established that the information was imparted in this manner, the fact that the information may have subsequently been used by ISI without awareness that it was being used or that it was confidential would not be to the point. In any event, bearing in mind that ISI was operating in the environment of Datacom and DB2, both proprietary and commercially valuable products, I am not prepared to find that ISI actually took possession of the 1999 Macros, the 2004 Macros and the subsequent ISI Replacement Macros in ignorance of the relevance of the information contained therein or that it was confidential information.

[68]

The third element: was there an unauthorised use of the information? 493 A Court will intervene where the circumstances are such that it is unconscionable for a party to use confidential information (Deta Nominees Pty Ltd v Viscount Plastic Products Pty Ltd [1979] VR 167 at 190-191). Where the Court discerns similarities between the confidential information and the article or product of the confidential information, the Court may draw the inference that there has been a copying or misuse of confidential information, notwithstanding that there are dissimilarities in the information and the article/product of the information (Dart Industries Inc v David Bryar & Associates Pty Ltd (1997) 38 IPR 389 at 409 per Goldberg J). 494 CA's case largely depends on what it labels 'evidentiary footprints'. CA submits that the Court should, from certain identified misuses of confidential information, draw the inference that ISI had access to and used the CA Information in developing 2BDB2. CA submits that the Court should find that, in developing 2BDB2, ISI had access to and used: the Key CA Manuals; memory dumps and traces in order to access Datacom's object code; and the source code of the R9 CA URT Macros. 495 Before outlining the structure of this section of the reasons, I wish to make two preliminary observations: First, in the ordinary course, a DBA, consultant or independent programmer working for a Datacom licensee would not be required to, or need to, understand or examine what the parties referred to as the "cloud" of Datacom itself. Secondly, I accept that different programmers seeking to write for the same outcome will write differently, I do not accept that an independent programmer setting out to write parts of 2BDB2 or the ISI Replacement Macros would just happen to write precisely the same way as to mirror the applicable elements of the CA Information, even if they are a programmer experienced with Datacom. For example, Mr Shuma says that, although the main parameters of the URTs could become well-known, with over 25 years experience in writing COBOL programs using the Datacom URT, he still does not know all of the parameters and their values. I also accept that the CA programmers, and Mr Lynn in particular, made their own decisions as to methodology and text, even within the confines of an object that exists, for example, in Datacom. 496 It is convenient first to examine the evidence of Mr Richards and, where applicable, the evidence of other witnesses about the creation of 2BDB2. I will then turn to a consideration of each of the ways in which CA contends that the CA Information was used without its authorisation. That involves setting out both the respective submissions, some of which were not responded to directly, and other evidence relevant to the submissions at hand, including that of the expert witnesses. In doing so, I will make some observations in passing and, where possible, I will give specific conclusions concerning the part of the CA Information said to have been used. Where the evidence and submissions on the unauthorised use of the particular CA Information are interrelated with the evidence and submissions on the unauthorised use of other CA Information, I reach conclusions on these aspects of unauthorised use in a subsequent section.

[70]

trouble shooting application programs 504 During the time that he worked at Macquarie, Mr Richards worked as a "trouble shooter", which involved studying "storage dumps" from the MVS operating system, a generic term that refers to a range of IBM mainframe operating systems. Mr Richards defines "storage dumps" as direct copies of the contents of some portion of the computer memory, plus additional information written by the operating system, generated when a fault occurs. He says that a storage dump is intended to reflect the contents of memory at the time that the error is detected. Mr Richards says that such work was done in conjunction with the source code of the relevant application programs and that 'it was not realistically possible to work from the object code contained in the dump alone'. 505 Mr Richards says that the storage dumps with which he worked typically contained information about the "history" of the object code that had been executed by the computer. He says that on the MVS system, "executable object code" means a sequence of instructions that can be executed by the processor and which are contained in IBM defined formats. He provides the example of a program calling another program. 506 Mr Richards says that if control had passed from the client's application program into another commercial program such as Datacom, this would involve identifying which application program had made the call to the commercial program. He says that the only source code to which he had access at Macquarie was the source code of Macquarie's application programs and that he never had access to the source code of the Datacom releases with which he worked, those being releases 8.0 and 9.0. Mr Richards says that if there was a problem in Datacom or the operating system, it was dealt with by CA as the program's vendor. 507 Mr Richards explains the process of identifying what the application program had done wrong in the event of an error. He says that this usually involved studying the application program's logic (found in its source code), the way the logic was implemented (found in the object code that was produced when it was compiled and link edited) and the data with which the application program was working. This included information retrieved from disk or input by the operator and information passed to other programs or routines or returned by those programs or routines after they had been called. Where the crash involved programs that accessed Datacom, this usually involved checking the data that had been passed to Datacom and the information passed back from Datacom, such as the return code, as well as the way the application programmer had set up the request area. Mr Richards describes the request area as an area of storage provided by the application program. He says that it is set up by the application programmer in a particular format defined by CA which must be followed precisely. 508 Mr Richards says that in the course of his work at Macquarie, he worked on many problems with application programs that accessed Datacom.

[73]

Work at Macquarie (from 1996 to 1998) and Beta 519 Mr Richards' view is that when he returned to work at Macquarie in 1996, very few people worldwide had a similar level of experience in diagnosing problems at the operating system level as he did. He says that he was thoroughly familiar with the process by which application programs passed control to and from Datacom and the structure of the relevant interface (described above as the "bridge") but says that he did not know how Datacom operated once control was passed to it (that is, after the bridge was crossed). He says that he did not need to do so. He says that he had acquired this knowledge from his previous work supporting the MVS operating system and programs that ran it, not from the Key CA Manuals or Datacom. He says that he had learned the way in which Datacom used modules containing stub programs from the contents of storage dumps. 520 From 1996 to 1998, Mr Richards worked at Macquarie to convert their applications programs to access DB2 instead of Datacom. 521 In batch, the initial approach undertaken involved the method of intercepting calls made by the application to the DBNTRY stub and passing the calls to a replacement DBNTRY stub rather than the DBNTRY stub in the original URT, with the functionality to access DB2 being implemented in the replacement DBNTRY stub. In CICS, the initial approach involved having a CICS stub that intercepted the calls to CICS and instead performed the tasks in the batch environment. 522 Mr Richards describes a new methodology that was developed jointly with Messrs Holliday and McLennan at Macquarie (the Macquarie version). He says that he undertook all of the assembler programming in developing it. The Macquarie version first involved creating a separate replacement module for each database table that an application program would access. Then a PL/1 program that read through a data table and generated the relevant access module using the standard Datacom dictionary service facility was created. This module contained a replacement DBNTRY stub written by Messrs Richards, Holliday and McLennan. At the time when the application program was run, the replacement DBNTRY stub would intercept the call from the application program and pass it to a "router" that would send it to the appropriate access module, be that Datacom or DB2. 523 Mr Richards says that they were not focused on writing or changing Macquarie's existing application programs that used Datacom. Rather, he says that the focus was on: converting Macquarie's data contained in its Datacom databases, using programs at Macquarie to extract data in its Datacom databases and saving into a DB2 format; writing code to construct DB2 commands to send calls made using Datacom and the application source code to DB2; and rearranging the results from DB2 into the form expected by the application source code. 524 Mr Richards says that where the command was sent to DB2, it was necessary to implement functionality, but it was not necessary to do so where the tables had not been converted to DB2 format, in which case the call was sent to Datacom. Mr Richards says that 'all we needed to do (and did) was translate the calls to Datacom that were already contained in the source code of [Macquarie's] application programs'. 525 The Macquarie version required the replacement stubs to be "statically linked" to the application program. Mr Richards explains how "static linking" led to problems for batch programs and says that he determined while at Macquarie that it was not satisfactory, in his view, to intercept the call from the application program to DBNTRY. He says that he determined that the better technique was to intercept the call from the DBNTRY stub to DBINFPR. He says that although he conceived of this idea while doing the conversion at Macquarie, he did not implement it while working there. Among other things, 2BDB2 encapsulates this technique. 526 Mr Richards is familiar with the four Key CA Manuals. He confirms that they were available at Macquarie and admits that he definitely would have consulted the Programmer Guide and the Database and System Administrator Guide while at Macquarie. However, he says that he has not had a copy of these manuals in his possession since his time at Macquarie. 527 Mr Richards says that, in developing the Macquarie version, he 'cannot say' whether he looked at any of the Key CA Manuals but that he does not recall doing so and does not recall seeing someone else looking at any of them. Mr Richards says that the information needed to do the tasks at Macquarie from 1996 to 1998 was not something he would have obtained from the Key CA Manuals because he could have otherwise recalled such information, presumably from his earlier period working there. He adds that his recollection of the Key CA Manuals is that they concerned how to make application programs work with Datacom, which were not matters that were relevant when migrating existing application programs to DB2. 528 Mr Richards says that if he had encountered any unfamiliar calls, he 'expects' that he would have checked the Macquarie source code. He accepts that another way would have been to check one of the Key CA Manuals. However, Mr Richards says that the primary place for finding information about Datacom parameters was in the customer's application programs, not in a manual or from an indirect source such as a dump. 529 In this regard, Mr Richards says that application programmers who access Datacom have to construct the request area for their calls in the source code of their programs. According to Mr Richards, the information passed to Datacom is contained in the source code, including the command that is to be issued. The structure of the request area and everything that is put in it is, Mr Richards says, in the application source code. He says that the variables being used are defined in the source code and the use to which returned data is put is in the source code. This is one basis given by Mr Richards for his ability to map Datacom commands to SQL calls for DB2 without access to Datacom documentation. 530 Mr Richards says that he did not have access to or use any source code of Datacom, nor did he see Messrs Holliday or McLennan do so. He accepts that the CA URT Macros, which contain statements in assembly language, could be referred to as source code, although he himself does not accept that description as in his view it is not possible to assemble the CA URT Macros into object code. 531 Mr Richards accepts that one can look at storage dumps and understand or deduce the request that has been made of the application. However, he says that in developing the Macquarie version (and for all development activities since then) he did not reverse engineer Datacom object code or look at storage dumps for this purpose. 532 Mr Richards also says that he never had to deduce the geometry of the request area because every single Macquarie application program that called DBNTRY had the mapping of the request area within it. 533 Mr Richards says that by about the end of 1998 ISI had completed the conversion of Macquarie's databases to DB2 format and created the "transparency layer" that intercepted the calls from Macquarie's application program in using the Macquarie version. The transparency layer did not require a rewriting of every application program. 534 Mr Richards says that he left Macquarie in 1998 with an 'expanded tool kit', which was in the form of source code, which itself contains notes. 535 After working at Macquarie, Mr Richards worked for ISI at Beta in the US for the first time. Mr Richards says that while at Beta, similar tools were created to the ones created at Macquarie. It was while working at Beta that Mr Richards was involved with the rewriting of the code and the implementation of the concept of intercepting calls between DBNTRY and DBINFPR for batch programs and at the CICS resource level. 536 In Mr Richards' words: ********** REMOVED BY REASON OF CONFIDENTIALITY ********** ********** REMOVED BY REASON OF CONFIDENTIALITY ********** ********** REMOVED BY REASON OF CONFIDENTIALITY ********** ********** REMOVED BY REASON OF CONFIDENTIALITY ********** 537 ***** REMOVED BY REASON OF CONFIDENTIALITY ***** 538 Mr Richards insists that during this process, he did not have access to Datacom source code and did not refer to any of the Key CA Manuals. He says that all that was required was to examine the output of the BTG file in concert with Beta's DBAs to identify which fields in the BTG report corresponded to the names Beta had for the names of records or keys that needed to be put into DB2 format. 539 Overall, Mr Richards' evidence is that the information he obtained at Macquarie and Beta was at least in part a result of looking into the source code of the customer's application programs. Mr Richards also agrees that one of the ways that he undertook investigations in his work on 2BDB2 was to run specific simple requests in order to find out more about the way in which, for example, Datacom queries were structured.

[74]

Creation of 2BDB2 540 It was at Beta that a version of 2BDB2 code was first installed, R5.1. Mr Richards says that he was involved in the creation of R5.2, which involved copying into a new source library those parts of R5.1 that were actually being used in the tool at Beta. He says that some programs were rewritten and new functionality was added. From that point, he says, in general, new functionality was developed in R5.2. Only some new functionality, plus "bug fixes", was usually worked back into R5.1. 541 Mr Richards says that at some point after he worked at Beta, in about 1999 or 2000, he went to US Customs to present a demonstration of the conversion software, and also demonstrated a successful proof of concept for State Street Bank. Mr Richards confirms that 'at about that time, ISI formally marketed the software as a product called 2BDB2, rather than as a conversion service offered by contracting ISI'. He says that 2BDB2 became a product which could be sold during the work at State Street Bank. 542 Mr Richards gives conflicting evidence about the origins of 2BDB2. He says that 'at some point during the work at Beta, we conceived of offering 2BDB2 as a product that could be installed onto mainframes, rather than as software that ISI contractors would install while acting on-site as consultants'. However, Mr Richards also says that he had no intention of producing a "product" while at Macquarie and Beta but was there performing a service on behalf of Datacom licensees. 543 In correspondence at the time, Mr Richards refers to 2BDB2 as a "tool", a term which he differentiates from "product". A document in evidence indicates that in April 1999, Mr Richards was offering 2BDB2 on behalf of ISI as a "transparency tool". At the same time, Mr Richards was taking steps to ensure that the product was consistent across the different sites in which it was being implemented. The evidence indicates that by June 1999, discussions were in train about pricing and the format of quotes for 2BDB2 being divided into data conversion and 2BDB2 implementation. Concern was expressed as to whether any of the work was or continued to be done by him while being employed at Macquarie. 544 CA says that it is clear that from as early as 30 April 1999 and soon after leaving Macquarie, Mr Richards decided to create a rival product rather than to use the 2BDB2 code to trouble shoot for Datacom. The evidence supports that submission.

[77]

RQA 550 Mr Richards says that there was an option in the 2BDB2 module simply to dump out the contents of the request sent by the customer's application program in cases where 2BDB2 could not handle the command. This included the RQA. It was then possible, according to Mr Richards, to examine the RQA that the customer's application had built, armed with the knowledge about what the customer's program was actually trying to do, which was obtained by viewing the customer's application source code. 551 Mr Richards says that in order to support the commands actually used by an application program and the RQAs actually generated with those commands by the application program, he used the source code of the customer's application and the RQAs it produced. He says that he implemented support for the SAAT commands, including the RQA, by the equivalent of "reverse engineering" the customer's application programs in this manner. He insists it was not a case of "reverse engineering" Datacom, as the commands did not actually go to Datacom; the call from the user's application program was intercepted and the information it had built and passed along with that call, intended for Datacom, was dumped within 2BDB2 without Datacom being invoked. 552 Mr Richards says that he was working out how the customer's application program worked, with the customer's consent, and then working out a way to have DB2 produce that result. Mr Richards maintains that all that he had to work out was what the customer's application program was trying to obtain from the database. He insists that it did not matter to him, and he did not try to find out, how Datacom implemented that request (that is, what Datacom did internally). Mr Richards denies having attempted to work out all aspects of the RQA and says that there may be aspects of it he does not know about. All that he has established, he says, is what parts of the RQA are needed to support the customers who have used 2BDB2 to support SAAT applications to date. In this respect, Mr Richards: accepts that ISI is seeking to produce a marketable tool that is intended to work as widely as possible and that, where a client is running SAAT calls, the more 2BDB2 knows about the RQA the better; agrees that 2BDB2 only has the ability to deal with such problems as have previously been identified in relation to SAAT applications on installations that have already taken place and if new problems come up the customer has to accept that the product is going to fail in those circumstances and will need to contact ISI; and agrees it would be more useful if 2BDB2 could deal with all parts of the RQA but says this is not a significant limitation as most products of 2BDB2's nature cater for the majority of cases and expect to encounter errors.

[78]

AMODDY and B2BRQA 553 Mr Richards says that, as at 2008, AMODDY and the macro B2BRQA were part of R5.2. Messrs Turgeon and Richards agree that AMODDY is a 5200 line assembly code template used to construct a DB2 access module. The access module uses dynamic SQL to access its target DB2 table, which is a converted table. AMODDY also contains a function called "_PARSERQA". AMODDY calls on B2BRQA and is part of the conversion and part of Transparency. Mr Richards agrees that if a customer who has used IDEAL extensively wanted a product that would serve all of its requirements, including handling SAAT requests and translating the SAAT requests by Transparency in the transitional period, AMODDY and B2BRQA would be an important part of Transparency. Mr Richards agrees that customers who receive the complete 2BDB2 product would receive all three components: 2BDB2 Datacom Data Converter, Transparency and 2BDB2 Ideal. Although he says that most customers of 2BDB2 do not need AMODDY, Mr Richards agrees that if the customer ordered all three components of 2BDB2, they would also be supplied with AMODDY (and hence B2BRQA). 554 Mr Richards says that he was initially responsible for the creation of AMODDY. He adds, in re-examination, that he thinks that AMODDY was created during the State Street Bank proof of concept, a fact that apparently eluded his memory in cross-examination. He says that he was not the sole author of the version of AMODDY as it was delivered in 2009. Mr Richards says his most recent involvement with AMODDY would have been after 2005, but he could not say when. 555 At first, Mr Richards said that he was the author of B2BRQA. However, he was taken in cross-examination to the detail of its content and, in particular, those parts of B2BRQA that he had to concede could only have been taken from the Programmer Guide and would not have been produced by means of the storage dumps that he says that he used in creating B2BRQA. Mr Richards then said that he does not recognise those parts and therefore assumes that B2BRQA has been changed by another author, which he says he had not realised until that point. That is, he no longer asserts sole authorship because of the presence of this material. 556 Messrs Holliday, Granger and Bickerdike all say they were not involved in the writing of AMODDY or B2BRQA. Their evidence is to the effect that Mr Richards had control of writing the code. 557 Mr Richards says that the writing of AMODDY did not involve recourse to any of the Key CA Manuals. Contrary to Mr Turgeon's evidence detailed below, he does not accept that the code of AMODDY could only be written with the assistance of the Programmer Guide. 558 Mr Richards does not recall inserting the particular section in AMODDY for processing RQA parameter sections and says that it is unlikely to have been done by him because he does not recognise most of those parameters. Mr Richards accepts that of the 17 parameters in the RQA parameters section of AMODDY, seven were the same as those contained in the Programmer Guide. Mr Richards also accepts that each of the same 17 parameters in AMODDY (which was also present in B2BRQA) was contained in chapter 50 of the Database and System Administrator Guide. He says that he does not know who put those parameters in there. However, Mr Richards still disputes the contention that whoever wrote that part of the code for AMODDY would have consulted those guides in listing the parameters. He admits that that is one possible source of the list but says there may be other sources, although he cannot say what such source would have been. 559 Mr Richards has no recollection of being responsible for putting the ROW, RRD and SHR parameter types into AMODDY. He says that if they are Datacom SQL, there is no point having them in AMODDY because 2BDB2 does not do anything with Datacom SQL requests. He does not accept that somebody copied them from the Database and System Administrator Guide, on the basis that such a person would have read that they were for Datacom SQL and not copied them. He therefore "suspects" that this list comes from a source other than the Database and System Administrator Guide. However, Mr Richards also says that, as he says that he was not the author of this part of AMODDY, he is unable to say one way or another whether this part has been copied from the Database and System Administrator Guide. 560 Mr Richards says that B2BRQA is a very simplistic macro, the complexity of which is low in terms of the rest of 2BDB2. He says that the fact that it extends to approximately 480 or so lines is because many of the lines are comments and descriptions of individual fields, which would have to appear on separate lines. 561 Mr Richards is unable to say with certainty the parts of B2BRQA for which he was responsible, although he is certain that he was not responsible for some parts. As to the parts for which he was responsible, he disputes that they were copied from the Programmer Guide. 562 Mr Richards accepts that other than the RQA parameter section and the E section, the information in B2BRQA precisely matches the information in the Programmer Guide. However, Mr Richards says that B2BRQA needs to map with complete precision the specifications of the Programmer Guide, otherwise it would not work, or may work with some errors, which means that customers would have errors in their programs that were running through to 2BDB2. 563 According to Mr Richards, the "mapping" process for B2BRQA occurred by examining dumped out pieces of copies of the RQA from the activities of customers running their own applications; that is, Dataqueries written and run under Dataquery, or IDEAL programs written and run under IDEAL. He says that he would never have looked at a complex dump because there was no point in looking at a complex request in order to work out the simple structure of the RQA. 564 Mr Richards agrees that the only parameters that would appear in B2BRQA based on his method of preparation are the ones that he would have encountered in a dump. He says that parameters would not appear in a dump unless they were used. He concedes that it would have been more straightforward, direct and simple to specify the balance of the parameters and make them precisely match the Datacom requirements by taking them all from the Key CA Manuals, but he disputes that that is what was done in relation to the B2BRQA macro parameters. 565 Mr Richards accepts that it is 'highly likely' that a comment block in part of B2BRQA was copied directly from release 9.0 of the Programmer Guide and that at some point somebody working on B2BRQA must have cut and pasted or copy typed that material from that source. Mr Richards later speculates that he or she may have obtained the text from 'some other document'. However, he agrees that the guide was the original source for the contents of the comment block. Mr Richards also accepts that the information concerning the RQA header and section entries in B2BRQA were available in release 9.0 of the Programmer Guide, which he says was very likely to have been present on a licensed Datacom site. However, Mr Richards says that to the extent that he worked out any part of that section of B2BRQA (and he is unable to say which parts he was involved with), it was done from the process of examining customers' applications and dumps - which he says was 'laborious, tedious'. Mr Richards maintains that it was not done by consulting the Programmer Guide, even though the relevant information was available in the Programmer Guide 'by turning a page or two away' from the source of the B2BRQA comment block. 566 Mr Richards also agrees that the list in the B2BRQA comment block of logical operators appears to be taken from the Programmer Guide. He accepts that assuming someone, at some stage in the creation of B2BRQA, had that manual available, it would be straightforward, direct and simple to specify all of the balance of the parameters and make them precisely match the Datacom requirements by taking them from the Programmer Guide, rather than going through another process. However, he denies that this is what occurred.

[81]

Creation of 2011 Macros 571 Mr Richards' evidence is that in April 2011 he wrote the 2011 Macros, a process which took approximately one and a half days. Mr Slaber's evidence is that Mr Richards did the rewriting for the 2011 Macros and that Mr Slaber tested them. Mr Slaber says that it was carried out in a 'Datacom free environment'. 572 Mr Richards says that his starting point was to write, in assembler language, the DBNTRY stub that is needed to be present in a URT that is to be used in batch. He points out that the DBNTRY stub has to perform certain simple functions when it is run, that is, when the application program calls DBNTRY in batch. He says that the DBNTRY stub he wrote is a 'short and extremely simple program' and is created in a form that would be present in a URT that also has a data table entry. Mr Richards says that he wrote the DBNTRY stub in a way that is consistent with the programming style used in 2BDB2 modules and that he also determined a structure for the data table section of the URT. 573 Mr Richards says that because stubs produced using the CA URT Macros may contain a BEGIN program that client application programs call, there is a BEGIN program in the URT produced by the B2BURT Macro. He says that the BEGIN program 'is even more trivial than the DBNTRY stub'. 574 Mr Slaber concedes that it is possible that, prior to and in preparation for the creation of the 2011 Macros, he went back to the Key CA Manuals to find out about the CA URT Macros but also maintains that he does not recall doing so and that he does not remember his actions. Mr Richards told Mr Slaber in an email dated 11 April 2011 that 2BDB2 is only interested in a few things in the URT once Datacom has been removed, including the need for the program to have a DBNTRY stub with the same name as the customer presently used. Mr Slaber replied by email on 13 April 2011. He thanked Mr Richards for the detail and said that 'there was only so much I could discern from the Datacom manuals'. In a subsequent email to Mr Slaber dated 4 May 2011, Mr Richards described an alternative method for 2BDB2 to create a Datacom format URT after Datacom had been removed. He added, 'it is a bit round-about but at least no-one could say our macros were copies of the Datacom ones' (emphasis added).

[83]

Other evidence 577 According to Mr Shuma, in a typical situation, a memory dump will be created in the following circumstances: The application program will make a request to the Datacom database region by issuing the CALL DBNTRY statement. The URT module, which has been linked with the user program (in batch) or the DBCSVPR module (in CICS) will take the application DBNTRY request and pass it on to the Datacom database region. If the Datacom database region cannot process the request, a "return code" is returned to the application program. If the application program is not prepared to handle the return code, the application program may cause the application region to fail ("abend"). Mr Shuma says an abend is when a program fails and ends abnormally; it does not freeze but the program crashes. He adds that the mainframe itself does not freeze in these circumstances. Mr Shuma says that in the instance of an abend, Datacom, which would previously have been running, would have crashed and would prematurely have failed to complete its task. If there is an abend, it is usually possible to generate a memory dump of what Datacom was doing at the time it failed. This is performed by the customer's operating system. 578 Mr Shuma confirms that if a memory dump has been produced then it is Datacom that has crashed. 579 Mr Shuma emphasises that not all errors, including some of the most severe errors which do not cause an abend, will cause a memory dump to be created. When such an error is detected, it may be necessary to attempt to recreate the circumstances in which that error occurs, and/or implement "traces" on certain processes thought to be generating such errors, in order to understand what is occurring in the computer at the time of such errors. 580 In Mr Shuma's opinion, where the return code indicates an internal database error or a problem with Datacom, the licensee is instructed to contact CA support. In the event of a memory dump, Mr Shuma would expect those working on behalf of the Datacom licensee to contact Datacom support immediately because this involves a crashing of Datacom and the customer would not be expected to 'fiddle around with it' - given the complexity of the code and the fact that CA wants to have the problem fixed as soon as possible. Mr Shuma says that if a customer has a problem involving some sort of program failure and it is not something of the nature that needs to have significant diagnosis, then CA would ask for a dump from the customer to examine. 581 Mr Shuma accepts, on the basis that it was created at the customer's site, that there is no prohibition on a customer having a looking at dump to see what the customer thinks has happened. Mr Shuma agrees that a dump contains the customer's own application information as well as Datacom information; he adds that the dump would contain everything that was in the Datacom specific part of the mainframe. Mr Shuma says that if the failure occurred on the application programmer's side - that is, the application program failed but not the database itself - it would only be that information which is dumped. In this instance, there are, Mr Shuma says, different parameters for the customer to say what it wants printed, which can be all of it or some of it. Mr Shuma says that if the failure occurred in the "cloud" of Datacom, the dump would be of that entire cloud. In this instance, Mr Shuma confirms that one would not see the application programmer's code, which stays on the other side of the cloud. Mr Shuma says that CA is very careful to prevent user code running in the Datacom region. Mr Shuma says that if there is a failure in Datacom, the customer cannot tell it to dump something else that is still running. That is, the customer cannot tell it to dump the user's application. 582 Mr Shuma is of the view that a licensee has no need to use storage dumps to gain information about the internal workings of Datacom, including the structure of the URTs and their interaction with the Datacom MUF. Mr Shuma relies on the terms of the Datacom licence which, he says, prohibit use of memory dumps obtained for any purpose other than use and support of Datacom. 583 Mr Shuma says that while some 'small pieces of ... information may be available', the complete information necessary and sufficient to enable the ISI Replacement Macros to be created, to convert Datacom command strings to SQL, to use the Datacom request area and RQA and to provide information regarding the passing of calls in batch to DBINFPR and in CICS mode by means of DBCSVPR, is only found in the Key CA Manuals. 584 Mr Shuma distinguishes between this kind of information and information that is or may be useful to users of Datacom, which may be in the public arena. He describes various public documents relied on by ISI as being in this category and identifies information that is incomplete in those documents. 585 Mr Turgeon comments on Mr Richards' evidence. He explains that Datacom uses RAAT and the alternative access type, SAAT. He agrees that SAAT is clumsy and difficult to use but observes that 2BDB2 does support the SAAT API. Mr Turgeon notes that a SAAT call is accompanied by the RQA. Mr Turgeon says that the RQA in Datacom 'is of a format so non-user friendly as to almost defy description'. Mr Turgeon suggests that the reason why Datacom uses so complex a system is given in the Programmer Guide, to the effect that it was the intent of CA that the RQA would be generated by another computer program. The Programmer Guide states that CA products offer an integrated data manipulation language that acts as a front end to build these specifications. Mr Turgeon's view, with which Mr Richards disagrees, is that AMODDY could only have been written with appeal to the Programmer Guide's chapter on SAAT. Mr Turgeon says: The RQA… is the description… ISI produced a macro [B2BRQA] that maps these data areas so they're described in the programmer's reference. But it matches them so identically, even for data that they don't refer to, that I can't help believing that the Programmer Guide came first. And then a great deal of debugging and testing and tracing and all the kinds of stuff it would take to, you know, flush out the omissions in the Datacom documentation and the special cases, and clearly that logic - that effort is reflected in that 5000-line AMODDY program, very complex and thorough piece of code. But not only does it know about the formula of the RQA and the RA [request area]; it knows it to exactly the level - needlessly knows it to the level presented in the Programmer Guide. 586 Mr Turgeon says that because the Datacom application programs remain unchanged after Datacom is removed, 2BDB2 must continue to map application requests as expressed in the request area (and possibly the RQA for SAAT requests) and generate return codes. 587 Mr Turgeon expresses the opinion that, despite accepting Mr Richards' extensive experience with Datacom and his deep understanding of technical issues, the degree to which 2BDB2 follows the breadth of the Datacom API could not have been the result of experience and an excellent memory alone. For example, his opinion is that no one could possibly: recall the format of an RQA from memory without the vendor's documentation; produce the message lines in 2BDB2 word for word without access to a Datacom Messages publication; map DB2 return codes to the Datacom return codes without reference to Datacom documentation; and provide the breadth of coverage in mapping Datacom command codes to DB2 procedures without the benefit of the Programmer Guide. 588 Mr Turgeon admits that much could be learnt about the contents of the Datacom RQA from examining dumps but says that it would not amount to everything necessary to manipulate it. He says that whoever was responsible for the mapping of the RQA may have read dumps; this is on the basis that he was unable to find documentation for some parts of the ISI code. 589 Mr Turgeon does not suggest that ISI penetrated the Datacom cloud. 590 Mr Melito's opinion is that a storage dump inevitably discloses the functional aspects of how a program on an IBM platform works, particularly, in the case of Datacom, the way that control passes from an application program to Datacom and back. He also speaks of the knowledge gained by an IT professional who has experience with Datacom and has analysed numerous storage dumps. For example, a person who has created or maintained Datacom URTs would know of the variations of how a batch program can locate a URT at execution time. This evidence is not accepted by CA and I refer to it only as Mr Melito's hypothetical opinion on creating a storage dump on a Datacom platform. 591 Mr Melito says that any changes that needed to be made to program logic not involving Datacom would be dealt with by the customer's programmers, while any changes that needed to be made to Datacom calls would be made by programmers familiar with Datacom, those being either employees or contractors. All that is necessary, in Mr Melito's view, is to know how to write DBNTRY calls. In Mr Melito's opinion, any experienced Datacom programmer or analyst would know how to do this from memory. He also expresses the opinion that any Datacom licensee's DBA would be familiar with aspects of Datacom and how it works, including the use of the External Macros, how to code a request area, how to write calls to retrieve, store or change information in a Datacom database and how to create URTs using the CA URT Macros. Again, CA does not accept this evidence. 592 Mr Lynn accepts that programmers who use Datacom to write applications for Datacom become familiar with the commands that they have put into Datacom as well as the structure of the request area that must be set up to contain all of the information including the commands, together with other information put into the request area to have the command executed. He accepts that they would also be familiar with the results that Datacom parses back after it executes the command (which is to parse at least a two digit return code). The return code is put into a particular location in one of the pieces of information set up by the application program and Datacom has access to its location and puts it into a particular spot in that piece of storage. Mr Lynn says that a programmer writing a program that accesses Datacom will 'as a matter of good practice' check that return code once the Datacom call has been processed by Datacom. The programmer must take action if it is an abnormal code. There is no claim by CA for confidentiality in the return codes. 593 Mr Lynn agrees that a programmer or contractor trying to debug a program that causes crashes during the program's operation would resort to a storage dump, which would include at least all of the object code of the application currently in memory. Mr Lynn agrees that the contents of the DBNTRY stub will also be in a storage dump if there has been a call to DBNTRY or if the DBNTRY stub has been link edited to the program. Mr Lynn accepts that, on occasions, 'you have to look at the entire contents of the dump, potentially'. Further, he says that DBINFPR and any entry point that has been loaded by name in a piece of executable code contained in the URT will have that name somewhere in the dump and batch load modules by name. Mr Turgeon agrees that any competent person well familiar with Datacom can discern from a dump that DBNTRY is the first call made in the sequence, and that DBINFPR is next in that sequence.

[85]

Programmer Guide 595 CA contends that the Programmer Guide was used to create the 2BDB2 interface required for SAAT commands and was used in the creation of AMODDY and B2BRQA. CA says that the Court should find that the author of B2BRQA copied the field names and characteristics of the Programmer Guide. CA points out that: Although Mr Richards says that he was the sole author of AMODDY, Mr Turgeon's evidence is that the level of copying in AMODDY was unnecessary and that Mr Richards must have used the Programmer Guide. As Mr Richards concedes, of the 17 parameters in the RQA parameters section of AMODDY, seven were the same as contained in the Programmer Guide. Mr Richards accepts that the Programmer Guide must have been the original source for the development of B2BRQA based on the presence of a comment block in B2BRQA that is almost identical to part of the Programmer Guide. He accepts that ISI programmers used the Programmer Guide in developing B2BRQA. Mr Richards concedes that B2BRQA maps with complete precision the specifications in the Programmer Guide apart from the complete list of parameters and the E section. Parts of B2BRQA could only have been reproduced from the Programmer Guide and not from a dump. CA submits that as text was 'plainly copied' by ISI from the Programmer Guide, whoever at ISI created B2BRQA would not have copied text from a guide but then spent days or months reverse engineering all the fields with precision and giving them field names that are mnemonics for the names from the Programmer Guide. 596 As a threshold issue, ISI contends that CA explicitly abandoned all such claims in its opening submissions on the basis that AMODDY is used in the 2BDB2 Datacom Data Converter SAAT option and CA stated in its original submissions that 'CA makes no complaint in this proceeding about the use of its copyright works and confidential information in respect of the 2BDB2 Datacom Data Converter'. CA cannot, ISI says, be permitted to raise new substantive claims on these issues in its closing submissions. However, cross-examination of Mr Richards focused on this matter extensively without objection and other evidence on this subject was read. ISI re-examined Mr Richards on AMODDY. In addition, neither party made clear where a line could be drawn as to the evidence with respect to AMODDY and its role in the 2BDB2 Datacom Data Converter and Transparency. ISI accepts that evidence in respect of Transparency is relevant and that claims in respect of Transparency have not been abandoned. The evidence indicates that AMODDY is part of Transparency. The way in which ISI created AMODDY was and is in issue in the proceedings. 597 ISI submits that the mapping of the RQA contained in B2BRQA is consistent with Mr Richards' evidence and inconsistent with copying from a manual. ISI says the Court should accept Mr Richards' evidence as to the way he discerned the contents of the RQA; Mr Richards captured the RQAs sent by client application programs generated by known queries and, armed with knowledge of what the original query was, varied the queries and watched what changed in the RQA. That is, Mr Richards closely observed the contents of the RQA until the functions of all relevant pieces of information that occurred in it were known sufficiently to allow the query contained within it to be determined and hence to be rewritten in SQL to send to DB2. ISI adds that the format of the RQA is not overly complex when viewed 'in the form that is created by application programs and dumped out on disk'. This process, ISI contends, would capture information actually used in an application whether or not it was present in a Key CA Manual. 598 ISI relies on the following evidence and inferences to be drawn from the evidence: Mr Turgeon's observation that B2BRQA contained information about the RQA that is not documented in the Key CA Manuals that ISI is accused of copying. ISI says that this supports Mr Richards' account. The fact that 2BDB2's mapping of the RQA contains parameters that the Key CA Manuals state would not have been needed for interpreting SAAT requests. ISI says that if a manual indicated that a parameter would not be encountered in the types of programs 2BDB2 was intercepting, logic dictates that, if the manual had been consulted, only those parts of the manual said to be relevant to the task at hand would have been copied. Mr Richards' evidence that AMODDY has been subject to extensive changes over a long period. In evidence is a document reflecting change log entries to AMODDY. ISI says this suggests a process of trial and error rather than copying. The text of the Programmer Guide and the comment block in B2BRQA is not identical; numerous words and some paragraphs found in the Programmer Guide are not in the comment block. I have compared these two texts and found that there are some minor differences between the two documents. ISI says this means that the suggestion of "copying and pasting" from the Programmer Guide has no basis and the inference to be drawn is that the information was obtained from somewhere other than the Programmer Guide. The change log for AMODDY shows that Mr Worboys made most of the changes to AMODDY between 23 May 2002 and 7 April 2004, while Mr Slaber was responsible for the majority of the changes after 15 April 2004. ISI says that this supports Mr Richards' evidence that he did not include the relevant comment block as it is clear that AMODDY was not complete when Mr Richards finished working on it. 599 ISI points out that it is critical for 2BDB2 to map accurately the RQA in order to decode SAAT requests, even the portions it does not "use". This, ISI adds, is because, as Mr Turgeon says, particular pieces of information must be put in particular places in the RQA and other places must be left empty; if particular information is not in the correct places, the request will be invalid. 2BDB2, ISI says, must "know" what goes into every place, even to 'skip around or avoid some' because if "reserved" places are filled in by 2BDB2, a crash may occur. Mr Richards says that he hoped that 2BDB2's map was accurate and that, if it was not, 2BDB2 would not work or would have some errors, a proposition with which Mr Turgeon agrees. 600 I reach conclusions on this aspect of the case commencing at [665] below. Additional matters 601 CA also contends that ISI programmers used the Programmer Guide to resolve problems with unusual Datacom combinations and command combinations, particularly with respect to the operation of those commands on the request area. CA relies on the evidence of Mr Turgeon, who says that the Programmer Guide is the 'how-to, the cookbook' for the combination of the lists of commands and return codes and for the determination of which command produces which of the subset of the return codes. CA also relies on evidence from Mr Shuma in his analysis of the WebCiss Report, which is ISI's record of support issues concerning its customers who have converted from Datacom to 2BDB2. For example, in one of the reported problems, Mr Shuma identifies the ISI person describing an error involving return code (RC) 94-056 and displays the specific error message generated (the Return Code Problem). He says that there are over 200 different RC94 return codes. As RC94 is a general error indicator with no specific documentation, Mr Shuma says that the user must see the IRC (internal return code) to determine the meaning of 94-056. The documentation of RC94 covers 30 pages. Mr Shuma expresses the opinion that it is impossible to believe that a person has all of the IRC codes memorised and concludes that the support person has the Datacom Messages Guide in his possession, as the Datacom Messages Guide is the only available source of this information. 602 ISI points out that CA resiled during the course of the hearing from a claim for confidence in Datacom commands. 603 CA did state that it did not claim confidentiality in Datacom commands. ISI was entitled to rely on that statement and the fact that evidence was not obviously directed to a claim for this form of confidentiality. This claim raised in closing submissions should not, and will not, be considered.

[86]

Database and System Administrator Guide 604 CA points out that Mr Richards concedes that of the 17 parameters in the RQA parameters section of AMODDY, the same 17 were contained in the Database and System Administrator Guide. In this respect, CA echoes its submission outlined above at [595]. 605 ISI's submissions outlined at [597]-[599] above also extend to this contention. 606 I reach conclusions on this aspect of the case commencing at [665] below. 607 Mr Turgeon's evidence is that the purpose of the CA URT Macros is described in the Database and System Administrator Guide. CA contends that the Database and System Administrator Guide was used in order to understand the purpose and operation of the CA URT Macros. Although this is not pointed to by CA, there is also evidence that Mr Slaber may have looked at the Key CA Manuals as part of his role in creating the 2011 Macros. That, however, does not amount to an admission of use of the information contained therein. CA has not identified information in the Database System and Administrator Guide that was actually used in the ISI Replacement Macros. CA has not established the use of the Database System and Administrator Guide in the creation of the ISI Replacement Macros. 608 CA also relies on Mr Turgeon's evidence that the Database and System Administrator Guide was used to create the equivalent of CA's ReadRXX utility in R5.1 of 2BDB2, that being the B2B0066 RXX read utility (B2B0066), which was written by 2BDB2 developers, albeit in a different computer language. 609 Mr Turgeon's evidence is that the labels used in the header of B2B0066 are the same as those suggested in chapter 57 of the Database and System Administrator Guide and that B2B0066 contains an 'unnecessarily exact mapping' of a data area included in that chapter. Mr Turgeon says that B2B0066 reads the RXX file using the ReadRXX API described only in the Database and Administrator Guide. Mr Turgeon concludes that B2B0066 could not be written without the Database and System Administrator Guide. 610 ISI submits that the information in the Database and System Administrator Guide concerning the ReadRXX routine was not improperly used. ISI: relies on the evidence of Mr Granger, who worked on B2B0066, to the effect that code already including the information needed to access the ReadRXX routine was provided to Mr Granger by an employee of Beta. However, Mr Granger says that as he could not get B2B0066 to produce output that could be used to create a corresponding DB2 table, work on the program was abandoned; ReadRXX was not used to convert Beta's data; says that CA did not put to Mr Granger that he had used the Database and System Administrator Guide when working on the B2B0066; relies on Mr Lynn's evidence that the information in the Database and System Administrator Guide was not the ReadRXX routine itself; that is, its source or object code. ISI contends that it has never written any routine to do what the ReadRXX routine does (that is, access the RXX log). ISI says that all B2B0066 did was call the ReadRXX routine; that is, it sent a call that was answered by Datacom. The information in the Database and System Administrator Guide was the information about calling the routine; emphasises, relying on the evidence of Messrs Granger and Richards, that B2B0066 was not part of R5.2 and that, although it remained in the program library for R5.1, it was never called by any other program or used as part of R5.1, as it did not work; and submits that, in any event, the ReadRXX routine is documented in the Database and System Administrator Guide specifically so that Datacom licensees are able to use that routine in those data. That is, ISI contends that it was entitled to use ReadRXX on Beta's behalf in an attempt to access Beta's data. The inclusion of the information in the Database and System Administrator Guide was, ISI submits, an implied licence for Beta to use that information to access data in the RXX log. 611 Even if the information concerning ReadRXX was confidential, CA has not established unauthorised use by ISI of that information through the Database and System Administrator Guide. I accept Mr Granger's evidence, which was not challenged in cross-examination, that he did not consult that guide in creating B2B0066.

[88]

Datadictionary Batch Guide 618 CA contends that the Datadictionary Batch Guide, in particular chapter 8, was used in order to create the 2BDB2 R5.2 program B2B0082, which is a table definition extraction utility. Mr Turgeon's opinion is that B2B0082 could not have been written without the detailed documentation contained in the Datadictionary Batch Guide. This is demonstrated, CA says, by Mr Turgeon's evidence of the unnecessary copying of 13 of the 16 "type 3150" records as detailed in the Datadictionary Batch Guide when 2BDB2 only needed four such transaction types. 619 CA also submits that the Court should find that the base of the 1200-6010 codes found in the Datadictionary Batch Guide was copied by ISI. The "type 3150" records are a subset of the 1200-6010 codes. 620 Mr Richards says that he does not recall the creation of B2B0082. He says that he knows that it was created but does not recall who did it, although he later speculates that it may have been Mr McLennan. Mr Richards accepts that, of the type 3150 records, four out of the 13 available are referenced by 2BDB2 and all 13 are mapped in the way shown in the Datadictionary Batch Guide. He has no comment on why 2BDB2 references maps or fields from the Datadictionary Batch Guide in their totality even though it references only a subset of them. 621 ISI repeats its submission that CA abandoned this claim in opening, as B2B0082 is part of 2BDB2 Datacom Data Converter. ISI contends that CA cannot, in closing, be permitted to raise new substantive claims on these issues. ISI objected to Mr Turgeon's evidence on this topic. The evidence was admitted on the basis that it was necessary as background to understand how 2BDB2 Datacom Data Converter leads to part of Transparency. However, CA has not explained whether and how this evidence is relevant to any unauthorised use by ISI in the creation of Transparency. Mr Turgeon's evidence on this topic appears in one of his expert reports under a header stating "2BDB2/Datacom Data Converter". Notwithstanding that there was short cross-examination of Mr Richards on B2B0082, CA has abandoned this topic.

[90]

Examining traces/dumps 623 CA submits that ISI examined "traces" and "dumps" impermissibly in creating 2BDB2. CA emphasises that: The evidence shows that during the development of 2BDB2 at Macquarie and Beta, ISI impermissibly used memory dumps to obtain information about Datacom and used traces to view the operation of Datacom's object code when used with 2BDB2. CA points to Mr Richards' admission that he used memory dumps at the premises of Datacom licensees in order to obtain information about Datacom to develop 2BDB2. ISI programmers continuously used Datacom licensee's sites as a "test lab" for 2BDB2 by repeatedly using traces to view the operation of the object code of Datacom when used with 2BDB2 in order to understand how it operated or failed when using 2BDB2. CA relies on ISI's activities at organisations such as the University of Western Illinois and ADP, as documented in the WebCiss Report and as analysed by Mr Shuma. For example, in the description of the Return Code Problem, the reference to "turning on all traces" means that the traces are recording the operations occurring within the Datacom system in order to understand why 2BDB2 is causing an error. That is, Mr Shuma says that ISI is being provided with data on the inner workings of Datacom for analysis in order to solve the particular problem. 624 ISI submits that CA's submissions rest upon the misapprehension that ISI was not entitled to trouble shoot 2BDB2 as it interacted with a customer's program for the purpose of making the two work together. ISI contends that no relevant licensee, nor ISI derivatively, was restrained from doing so as this activity was not prohibited by any relevant licence. The licences prevent the undertaking of activities for the purpose of creating "a corresponding source code", but this, ISI says, is not what it did. ISI also points to Mr Turgeon's view that ISI did not look "inside" the Datacom "cloud" while engaging in its activities. 625 To the extent that information was obtained by ISI from a trace or a dump, CA accepts that each client (and consequently, any consultants/independent contractors) had the right under the relevant licence to look at dumps for the purposes of problem solving. However, CA says such access was under the cloak of confidentiality. CA submits that dumps and traces could only be used by a client within the terms of the licence and could not be used as a "test lab" to create a product for the general market. 626 CA provides for the authorised use of Datacom and the associated documentation in its licence agreements and also provides notification of the confidentiality of its information in and on Datacom associated material. The SLA between Macquarie and CA relevantly states that the licensee is licensed to carry out (without infringement of CA's copyright) certain acts only in relation to Datacom, which include: To print file listings and memory dumps and generally to use each Working Copy as is reasonably necessary for the purposes of prudent system and data management and security. 627 As noted previously, the SLA also stated: Each party acknowledges that in connection with its duties hereunder it may be provided with or have access to written information data and/or other confidential material which is proprietary and/or confidential to the other and which is so marked as proprietary and or/confidential or which it would be reasonable to assume was proprietary or confidential due to its nature. Both parties agree to keep confidential all such information and shall not disclose the same either in whole or in part to any third party without the party's prior written consent… The Licensee further undertakes that it and its employees will not change, disassemble, decompile or otherwise reverse engineer the Licensed Program in order to create or attempt to create a corresponding source code… The Licensed Program and all related documentation are the trade secrets and proprietary property of CA and embody or contain useful and valuable information which is confidential to CA. 628 The licence agreement between CA and Beta relevantly stated: Authorized Use. The Licensed Programs may be used only be and for the benefit, and to process exclusively the data, of Licensee at the Licensee Sites. (original emphasis) 629 I accept that DBAs and trouble shooters for licensees of Datacom necessarily have access to information, both immediately and as necessary by way of dumps, in order to write programs and understand why a process has not worked in a particular case. The obtaining of information by a dump, including a dump that has been engineered for the purposes of dealing with the licensee's application of and utilisation of Datacom, does not involve an unauthorised use. However, engineering an unnecessary dump in order to obtain elements of the CA Information and, consequently, knowledge of Datacom does involve an unauthorised accessing of elements of the CA Information, which, as I have concluded, was information which those persons knew or ought reasonably to have known was confidential. One amounts to access for the purpose of enabling the licensee to work with Datacom, while the other involves accessing that information in order to obtain information beyond that normally available to, necessary for or to the benefit of the licensee's contractors or DBAs. The latter was use that had not been authorised by CA under its licence agreements or otherwise. 630 Accordingly, I accept that the evidence indicates that ISI examined "traces" and "dumps" impermissibly while working for licensees of Datacom. 631 Nevertheless, for there to be a finding of unauthorised use in relation to ISI's accessing of dumps and traces, the onus is on CA to identify with some degree of specificity: the part of the Confidential Information said to have been accessed by these dumps and traces; and the use of that information in the creation of 2BDB2. 632 CA has not established either of these requirements. In this respect, a finding that ISI's activities involved the accessing and obtaining of CA Information is not enough of itself to make a finding of unauthorised use in accordance with the requirements for that element identified in Coco and Fairfax, as set out at [364] above. 633 In any event, I will deal with ISI's submission that obtaining information by way of dumps and traces would not, under equitable principles, be an unauthorised use of confidential information on the basis that equity will not create a duty of confidence that would undermine ss 47B(3) and 47D of the Act, provisions which I outlined earlier in the section of these reasons on copyright. In this respect, ISI also points to s 47H of the Act, which states: An agreement, or a provision of an agreement, that excludes or limits, or has the effect of excluding or limiting, the operation of subsection 47B(3), or section 47C, 47D, 47E or 47F, has no effect. The activity of examining running programs for the purposes of making interoperable products is, ISI says, precisely the kind of conduct with which ss 47B(3) and 47D are concerned. ISI says that the application of s 47H has the consequence that one cannot use an agreement to restrict the statutory freedom that exists in ss 47B(3) and 47D. ISI says that if an equitable duty of confidence were found, this would mean that despite these sections nobody would be able to create an interoperable program on a mainframe computer. 634 CA points to s 9(3) of the Act, which provides that 'this Act does not affect the operation of the law relating to breaches of trust or confidence'. This section, CA submits, means that the consequences for which ISI contends could not apply. CA further submits that there is not necessarily congruence between computer programs and confidential information. When something is confidential information and not a computer program, this would, CA says, be outside the argument posited by ISI. CA also adds that the provisions of the Act can only possibly apply in Australia and the Court, in applying equitable principles, will act irrespective of geographical limitation. ISI did not address this latter point in its submissions. 635 I have set out the extent of the submissions on these sections and their operation in the context of the claim of unauthorised use of confidential information. ISI has not explained why ss 47B(3) and 47D apply. These sections provide for an exemption from copyright exemption, not an exemption from the misuse of confidential information. Section 9(3) makes it clear that the Act does not affect the law relating to breaches of confidence. Further, ISI is not a party to an agreement with CA for the purposes of s 47H. ISI has not explained how s 47H applies in the context of CA's claim for breach of confidence. 636 ISI has not established that the defences in ss 47B(3) and 47D are relevant to this aspect of CA's claim for breach of confidence.

[91]

Capturing RQA 637 CA contends that even if ISI programmers did not use the Programmer Guide in creating AMODDY and B2BRQA, ISI still used memory dumps impermissibly. This is on the bases that: Mr Richards accepts that AMODDY could not be constructed from the "furniture of the mind". Mr Richards' actual comment was that that he does not 'keep the information about the RQA in my head… if I'm working with it every day I will remember parts of it, but two days later, if I have no need for it, I don't remember it'. Mr Richards concedes that he initiated a request at Beta in order to dump out the entire Datacom RQA. However, it is not clear that Mr Richards' concession extends to such an admission. Mr Richards agrees that AMODDY could be created from a dumped out Datacom RQA. Mr Richards actually says that the source for creating parts of AMODDY would be a 'dumped out RQA from a valid request'. 638 ISI says that that CA's submissions on this aspect proceed on the erroneous basis that Mr Richards viewed RQAs in the form of "storage dumps". ISI says that this is incorrect and repeats its submissions outlined at [597]-[599] above to the effect that the evidence indicates that Mr Richards obtained RQAs by capturing and copying out the contents of the RQA sent out by a customer's application program, which was intercepted by 2BDB2 and saved onto disk. 639 To the extent that CA submits that Mr Richards determined the structure of the RQA by examining full storage dumps, ISI says that this is erroneous because all that Mr Richards did was the 'simple task' of viewing a file containing the contents of the "reserved places" in the RQA and comparing this against the query in the application program's source code. 640 ISI points to Mr Lynn's evidence that the RQA contains information which is a representation of the particular call that the application program wants to send to Datacom. He agrees that it is a 'packet of data' that is created by the user's application program. ISI says that the RQA does not contain any contents of the Datacom "cloud", let alone any reflection of its source or object code because, as indicated by Mr Richards' evidence, it was intercepted before it ever got to that cloud. CA has, ISI contends, confused the concept of "dumping out" just the RQA "packet of information" itself with the much larger storage dump created on an abend. ISI places great emphasis on its assertion that Mr Richards was interrogating the user's application program. ISI concludes: That Mr Richards captured the information generated by the user's application program, starting at Beta, to try to work out what the customer's application program was sending out in the RQA in response to the request that was contained in the user's source code is utterly unexceptional. 641 I reach conclusions on this below commencing at [665]. 642 ISI submits that Mr Richards' capturing of information generated by the user's application program to try to work out what the customer's application program was sending out in the RQA in response to the request contained in the user's source code is 'quintessentially the activity at the heart of' ss 47B(3) and 47D of the Act. ISI points out that s 47D(1) of the Act contains the words 'to interoperate with… any other program', which, it says, includes DB2 and also the new application program created when the user's application program object code is link edited with a URT generated by the ISI Replacement Macros. 643 CA repeats its submission as to the effect of s 9(3) of the Act. ISI reiterates the above submission about equity not creating a duty of confidence that would undermine the Act but has not explained how this is so. For the same reasons as outlined at [635] above, ISI has not established that the defences in ss 47B(3) and 47D are relevant to this aspect of CA's claim for breach of confidence.

[92]

Determining the TRUEs in CICS 644 CA contends that ISI's 2BDB2 programs B2B0013, B2B0014 and B2B0129 are evidence of ISI programmers using storage dumps to obtain part of the object code of Datacom. ***** REMOVED BY REASON OF CONFIDENTIALITY ***** 645 In this respect, CA relies on Mr Turgeon's evidence that: 2BDB2 is aware of other Datacom services called OPENCLOS and DBINITAL, which it must address when it disables the Datacom DBNTRY TRUE. ***** REMOVED BY REASON OF CONFIDENTIALITY ***** ***** REMOVED BY REASON OF CONFIDENTIALITY ***** ***** REMOVED BY REASON OF CONFIDENTIALITY ***** ***** REMOVED BY REASON OF CONFIDENTIALITY ***** 646 CA also emphasises that the capturing of the DBINITAL TRUE was 'unnecessary', based on Mr Turgeon's statement that Mr Shuma had informed him that the DBINITAL TRUE is not currently used in Datacom. 647 ISI says that CA's submission has no evidentiary foundation. ISI points out that Mr Richards' evidence explains how he learned of the CICS resources involved in a CICS call in a user's application program. In summary: Mr Richards was aware from trouble shooting Macquarie programs that the DBNTRY call in a user's application program was satisfied in the CICS environment by the module DBCSVPR, which invokes Datacom by a standard IBM CICS command asking for a TRUE called DBNTRY. There is a standard IBM CICS command that lists the available TRUEs of which CICS is aware. This includes the two "undocumented" TRUEs referred to by Mr Turgeon. It was a standard Datacom trouble shooting technique to run this command to determine if the Datacom TRUEs were enabled. This knowledge was all that was needed by Mr Richards to intercept calls in CICS. 648 ISI adds that Mr Turgeon did not offer any opinion to the effect that ISI should not have been aware of the CICS TRUEs, that it would have been difficult to obtain that awareness or that such awareness could only have been obtained by using illicit means. ISI points out that CA adduced no evidence to controvert Mr Richards' evidence. 649 ***** REMOVED BY REASON OF CONFIDENTIALITY ***** 650 CA has not established that Mr Richards' source for these matters was part of the CA Information obtained by improper use of storage dumps rather than the general knowledge that he gained in trouble shooting at Macquarie and his knowledge of CICS.

[94]

The source code of the R9 CA URT Macros 654 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]'. 655 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. 656 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. 657 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. 658 It is necessary to deal with several other submissions made by ISI. 659 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]). 660 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. 661 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. 662 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. 663 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. 664 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.

[95]

Conclusion on AMODDY and B2BRQA 665 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. 666 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. 667 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. 668 ISI used the Database and System Administrator Guide in creating AMODDY. ISI used the Programmer Guide in creating B2BRQA.

[97]

Evidence 670 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. 671 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). 672 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. 673 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. 674 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. 675 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. 676 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. 677 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. 678 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. 679 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. 680 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. 681 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. 682 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. 683 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. 684 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. 685 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.

[102]

The Third Representation 695 The Third Representation is said by CA to be that Datacom will operate correctly when 2BDB2 is used. 696 Mr Shuma refers to statements made by ISI on it's website www.2bdb2.com 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). 697 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. 698 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. 699 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. 700 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.

[103]

The Fourth Representation 701 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. 702 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. 703 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. 704 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.

Parties

Applicant/Plaintiff:

CA, Inc.

Respondent/Defendant:

ISI Pty Limited

Legislation Cited (6)

Trade Practices Act 1974(Cth)ss 52

Cases Cited (20)

ed 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 Dais Studio 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 IceTV Pty 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

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 Dais Studio 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]

(2009) 261 ALR 501

(2000) 202 CLR 45

(1986) 161 CLR 171

(1980) 147 CLR 39

(2007) 165 FCR 92

(1997) 38 IPR 389

(1999) 202 CLR 1

(2007) 73 IPR 326

(1985) 5 IPR 213

(2009) 239 CLR 458

(1984) 196 CLR 414

(1982) 150 CLR 310

(1994) 181 CLR 404

(1980) 54 ALJR 145

(2007) 72 IPR 58

(1990) 22 FCR 73

(1985) 159 CLR 466

(1949) 79 CLR 428

Cited By (4)

IPC Global Pty Ltd v Pavetest Pty Ltd

Motorola Solutions, Inc. v Hytera Communications Corporation Ltd

Qudos Mutual Limited v Infosys Limited

University of Sydney v ObjectiVision Pty Limited

CA, Inc. v ISI Pty Limited

At a glance

Court

Decision date

Before

Source

Judgment (104 paragraphs)

Parties

Legislation Cited (6)

Cases Cited (20)

Cited By (4)