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

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

Database management systems

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).

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.

DB2

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

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

2BDB2

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.

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.

WITNESSES

CA witnesses

Richard Turgeon

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

Joseph Lynn

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

Kevin Shuma

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

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

Gerald Clayton

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

Michael Milliken

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

ISI witnesses

Carl Melito

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

Peter Richards

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

Mark Granger

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

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

Ralph Slaber

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

Wayne Bickerdike

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

John Holliday

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

Observations about the witnesses

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

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

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

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

FURTHER BACKGROUND

Functioning of Datacom

URTs

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.

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.

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.

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.

Operation in batch and CICS modes

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

91    ***** REMOVED BY REASON OF CONFIDENTIALITY *****

92     ***** REMOVED BY REASON OF CONFIDENTIALITY *****

93    ***** REMOVED BY REASON OF CONFIDENTIALITY *****

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.

Copyright

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

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

104    The copyright issues for determination are, in summary:

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

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

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

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

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

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

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

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

Subsistence

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

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

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

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”.

CA URT Macros

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.

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”.

Authorship

158    It is not in dispute that both Datacom and the CA URT Macros comply with the authorship requirements of the Act. I will briefly set out the salient facts for completeness.

159    CA has a record of all of the authors who have written the code for Datacom since 1975. Mr Lynn has been a principal author of Datacom since 1975 and remains an author. His evidence identifies those others who worked on Datacom, or any part of it, and the authors of the CA URT Macros.

160    Mr Lynn wrote the original CA URT Macros in early 1984 for release 7.4 of Datacom. Since that time, the CA URT Macros have been modified by Mr Lynn or by other members of the CA Development team under Mr Lynn’s control and supervision.

161    Mr Shuma provides records in respect of all employees of CA and its predecessors in title who have written Datacom code. He identifies the individuals who wrote part of the code and the period of their respective authorship contribution and, separately, in respect of their authorship of the CA URT Macros. Mr Shuma has known all of the authors, has worked with them personally and verifies the details from his personal knowledge. They are all residents of either the United States or the Czech Republic, working for CA in CA’s facilities in those countries.

162    Each of the authors of both Datacom and the CA URT Macros, including Mr Lynn, is a “qualified person” within the meaning of ss 32(4) and 184 of the Act and reg 4 of the Copyright (International Protection) Regulations 1969 (Cth).

Originality

163    It is not in dispute that both Datacom and the CA URT Macros comply with the originality requirements of the Act. However, as originality is relevant to the assessment of the reproduction of a substantial part, it is appropriate to outline the foundation of this.

Datacom

164    Mr Lynn explains that the Datacom Development team does most of the programming in “assembler language” which is then translated into the machine code of the target computer, the IBM mainframe used at CA. Assembler language is based on mnemonics that symbolise processing steps or instructions, processor registries, memory locations and other language features.

165    Mr Lynn describes the consultation that occurs during the course of writing developments for Datacom. Mr Lynn also sets out the ways in which the necessary changes are identified and the programming work identified and allocated within the group of writers, the software engineers. Part of that work involves the creation of a document, the “Detailed Design Specification”, which takes into account the licensee-visible features of Datacom, primarily in the user documentation, and describes those aspects of a new feature or change that will affect the user documentation and of which the licensee should be aware. Mr Lynn also describes the development and testing of any change to Datacom by himself or by others under his supervision in consultation with each other.

CA URT Macros

166    Mr Lynn’s evidence is that CA chose a method of creating URTs by the use of CA URT Macros, which it supplies with the Datacom product.

167    Mr Lynn alone wrote the original CA URT Macros in 1984 to simplify the process and cause fewer support problems. Before that time, URTs for the licensee’s application programs were created using a single macro which, according to Mr Lynn, was confusing to many licensees.

168    Mr Lynn says that in response to this problem he came up with the idea of utilising multiple macros. He describes the function of the macros as, to put it in simple terms:

    one to start the process and the nature of the relationship with the main processing engine of Datacom;

    one to define the interface requirement;

    one to define the tables required; and

    one to say “I’m done now” and invoke another second level macro, which takes the answers to each of the questions and generates the URT required.

169    Mr Lynn’s choice of having five macros, four External Macros and one internal macro, was, he says, arbitrary.

170    Mr Lynn says that the writing of the CA URT Macros took one to two weeks of work, of which two or three days of focused thought was required for actual writing and the remainder for testing the CA URT Macros with a great number of combinations to ensure that every time the correct, predetermined URT was produced. In that process, Mr Lynn made further changes to better the working of the CA URT Macros.

171    Changes to the CA URT Macros have since been made by Mr Lynn or other members of the development team under his supervision and direction. Mr Lynn describes the changes as small changes, adding or removing only a few lines of “code” to make the affected macros more efficient and understandable.

Conclusion

172    Both Datacom and the CA URT Macros are “computer programs” and are therefore “literary works” under the Act.

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).

Has ISI reproduced a substantial part of Datacom in the ISI Replacement Macros?

181    In correspondence between the parties, CA conceded that the CA URT Macros are a quantitatively insignificant part of Datacom. Accordingly, CA relies on a qualitative rather than quantitative assessment of substantiality in this analysis. A qualitative assessment involves consideration of functionality, while a quantitative assessment involves consideration of textual similarity.

182    CA submits that due to the importance of the CA URT Macros to Datacom as a whole, ISI’s reproduction of the CA URT Macros constitutes the reproduction of a substantial part of Datacom. CA says that there is no need for the Court to receive the whole of the Datacom source code in order to consider this issue.

183    Although Mr Lynn explains that Datacom will not operate as intended without the CA URT Macros, this does not, of itself, establish that they are a substantial part of Datacom. Mr Lynn also agrees that the same can be said of many other aspects of Datacom.

184    Although there is sufficient evidence to allow identification of Datacom as a copyright work, there is a lack of evidence relating to Datacom’s functions as a whole. To engage in a qualitative assessment involving functionality, it is necessary for there to be evidence of all that Datacom does in order to understand the significance, in context, of what the CA URT Macros do. This evidence has not been adduced. Accordingly, I am unable to perform a qualitative assessment of substantial part. CA has not discharged its onus of proof in this respect.

185    It follows that ISI has not infringed the copyright in Datacom.

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.

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.

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.

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:

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.

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.

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.

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.

Defences

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.

Section 47B(3) of the Act

360    This section provides:

Subject to subsection (4), the copyright in a literary work that is a computer program is not infringed by the making of a reproduction of the work if:

(a)    the reproduction is incidentally and automatically made as part of the technical process of running a copy of the program for the purpose of studying the ideas behind the program and the way in which it functions; and

(b)    the running of the copy is done by, or on behalf of, the owner or licensee of the copy.

361    Section 47B(3) was not referred to in oral submissions in the context of acting as a defence to infringement. In written closing submissions by ISI, the only reference to that subsection in the context of or defence under the Act is an assertion that ‘ISI was acting on behalf of [Macquarie] and Beta and later customers for the purposes of s 47B and s 47D of the Act’. There is nothing further. It can be concluded that ISI has abandoned a defence based on s 47B(3). In any event, ISI has not established that the defence applies.

362    Whether or not ISI was acting “on behalf of” Macquarie, Beta and later customers in scrutinising the programs to assist in an understanding of the workings of the R9 CA URT Macros, I do not accept that the reproduction of the 1999 Macros, or any later version of the ISI Replacement Macros, was made incidentally and automatically for the purpose referred to in s 47B(3).

Conclusion

363    By reproducing the R9 CA URT Macros in the form of the 2004 Macros and the 2009 Macros, ISI has infringed CA’s copyright in the R9 CA URT Macros.

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.

Identification of the confidential information – has it been identified with sufficient precision?

368    The confidentiality claimed must be identified with the necessary degree of specificity (see e.g. O’Brien v Komesaroff (1982) 150 CLR 310 at 326–8).

369    CA has identified the confidential information claimed as follows:

    the source code of Datacom;

    the object code of Datacom;

    the source code of the CA URT Macros; and

    the Key CA Manuals, which includes the content of the Datadictionary DSF Programmer Guide (which relates to Datadictionary and is a product used by licensees to define, set up and manage data tables used by Datacom), the Datadictionary Batch Guide (which relates to Datadictionary), the Database and System Administrator Guide (which sets out the way Datacom works and the way in which it should be used) and the Programmer Guide (which sets out the programming language that must be used by the Datacom licensee),

(collectively, the CA Information).

370    ISI has provided an undertaking not to use the 1999, 2004 and 2009 Macros. However, CA maintains that the 2011 Macros still make use of CA’s confidential information comprising the source code in the CA URT Macros by reason of the development from the 1999 Macros to the 2011 Macros.

371    CA accepts that the Datacom commands and their short descriptions and return codes are not confidential on the basis of a prior disclosure.

372    CA submits that it has identified with the necessary degree of specificity the confidential information claimed.

373    ISI says that CA’s case relies on the assertion that the Key CA Manuals are confidential and that they were used in the making of part of 2BDB2, but does not identify what the information actually is such that the asserted confidentiality can be tested. ISI contends that CA has failed to identify a specific fact or proposition that is confidential.

Conclusion

374    In considering whether CA has sufficiently identified the confidential information, it is important to bear in mind the subject matter. CA’s claim is not about one letter, client list or technical document. It concerns complex programming information about very complex systems. The information exists not only in the source code but also in the information about Datacom, the way in which it works and in the information given to licensees to enable them and their employees and/or contractors to work with Datacom.

375    Having regard to the nature of the information and the context of complex computer systems, I am satisfied that CA has sufficiently identified the confidential information. To my observation, the witnesses had no problem in understanding how that information was described or why confidentiality was claimed. Other specific subject matter, such as the source code of the CA URT Macros, has also been identified.

The first element: does the information have the necessary quality of confidence?

376    To be confidential, information must be capable of being given the attribute or quality of confidence; that is, it must be something which is not within the public knowledge (Saltman Engineering Co Ltd v Campbell Engineering Co Ltd [1963] 3 All ER 413 at 415). However, that something has been disclosed in a limited manner does not rob it of its confidentiality, even if the dissemination was via mass media or the internet. It is a question of degree in each case. The expression “relative secrecy” has been used to describe this concept (see e.g. Franchi v Franchi [1967] RPC 149 at 153; Australian Medic-Care Co Ltd v Hamilton Pharmaceutical Pty Ltd (2009) 261 ALR 501 at [633] per Finn J).

377    This section of the reasons is structured as follows. First, I will outline the general evidence of both parties concerning whether the CA Information is capable of being given the quality of confidence. Following this, I turn to the parties’ submissions. CA makes general submissions as to why the CA Information is confidential. ISI, on the other hand, directs its submissions to specific parts of the CA Information, which it contends are incapable of being given the quality of confidence. I make findings on whether this is so. In relation to several of these specific parts of the CA Information, ISI contends that, even if the information once had the quality of confidence, this is no longer the case because of a disclosure of that information. I will examine the evidence and submissions of both parties on these disclosures, before reaching conclusions as to their effect. Finally, I will also reach a conclusion based on those elements of the CA Information that are not specified in ISI’s submissions.

The evidence on the quality of confidence

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…