FEDERAL COURT OF AUSTRALIA

Hytera Communications Corporation Ltd v Motorola Solutions Inc (No 2) [2026] FCAFC 122

ORDERS

THE COURT ORDERS THAT:

1.    Pursuant to rules 39.05(e) and (h) of the Federal Court Rules 2011 (Cth):

(a)    order 1 of the Orders of the Court made on 18 December 2024 be varied as follows:

(i)    The First and Second Appellants’ Amended Notice of Appeal dated 8 November 2023 be dismissed in respect of grounds 1 and 6 to 13 inclusive.

(b)    order 2 of the Orders of the Court made on 18 December 2024 be varied as follows:

(i)    The Cross-Appellant’s Amended Notice of Cross-Appeal dated 27 November 2023 be dismissed in respect of ground 1 and allowed in part in respect of grounds 2 and 3.

2.    The First and Second Appellants’ Amended Notice of Appeal dated 8 November 2023 be dismissed in respect of grounds 2 to 5 inclusive.

3.    The Cross-Appellant’s Amended Notice of Cross-Appeal dated 27 November 2023 be allowed in respect of grounds 2, 3 and 4.

4.    The Cross-Appellant’s Amended Notice of Contention dated 27 November 2023 be upheld in respect of grounds 2 and 3.

5.    The parties confer with respect to the form of orders to be made by way of variation to orders 1, 10 and 11 of the orders made by the primary judge on 7 June 2023 as is necessary to give effect to the reasons for judgment delivered today on the appeal and cross-appeal and, no later than 14 days after the date of these orders, provide to the Court either:

(a)    if agreement can be reached, an agreed form of orders to be made; or

(b)    if agreement cannot be reached, a form of orders proposed by the First and Second Appellants on the one hand and the Respondent on the other hand.

6.    Each party bear its own costs of the appeal and cross-appeal in relation to all issues of patent infringement.

7.    The Appellants/Cross-Respondents pay the costs of the Respondent/Cross-Appellant of the appeal and cross-appeal in relation to all issues of copyright infringement.

8.    Pursuant to ss 37AF(1)(b) and 37AG(1)(a) of the Federal Court of Australia Act 1976 (Cth), until further order of the Court, access to and disclosure (by publication or otherwise) of the unredacted text of the reasons for judgment delivered today be restricted to the legal representatives of the parties and those persons to whom access is allowed under the terms of the confidentiality regimes agreed between the parties on 10 April 2018 and/or the confidentiality regime agreed between the parties on 24 May 2019.

9.    Nothing in Order 8 or any other earlier order of the Court prevents any party from publishing the covering pages of these reasons for judgment up to and including these orders and paragraphs 1-98 and 379-389 of the reasons.

10.    Within 28 days of the date of these orders, the legal representatives for the parties exchange highlighted versions of the reasons for judgment identifying any parts of the reasons that are claimed to contain information confidential to their respective clients for redaction.

11.    Within 42 days of the date of these orders, the legal representatives for the parties confer on the proposed redactions and, if the parties are able to agree on the proposed redactions, provide to the Court an agreed form of the reasons for judgment with the proposed redactions highlighted, together with an agreed redacted form of the reasons for judgment that is suitable for publication.

12.    In the event the parties are unable to agree on the proposed redactions, within 49 days of the date of these orders, the legal representatives for the parties provide the Court with:

(a)    a version of the reasons for judgment which identifies the redactions which have been agreed and those which are in dispute; and

(b)    a short written submission addressing the areas of disagreement.

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

REASONS FOR JUDGMENT

THE COURT:

PART A: INTRODUCTORY MATTERS

A.1    Issues to be determined

Continuation of the appeal

1 These reasons concern claims made by the cross-appellant, Motorola Solutions Inc (Motorola), against the appellants, Hytera Communications Corporation Ltd and Hytera Communications (Australia) Pty Ltd (collectively referred to as Hytera), for infringement of Motorola’s copyright in software used in Motorola’s digital mobile radios (DMRs). Relevantly, Motorola alleged that Hytera infringed Motorola’s Australian copyright in the ‘Release 1’ version of its computer source code for the firmware in its DMR devices by, first, importing into Australia Hytera DMRs containing firmware which was an adaptation of the whole or a substantial part of Motorola’s source code and, second, making that firmware available for download in Australia from its website portal. Those claims were made under the Copyright Act 1968 (Cth) (Copyright Act).

2 The claims made by Motorola against Hytera are described in detail in the reasons of the primary judge: Motorola Solutions, Inc. v Hytera Communications Corporation Ltd (Liability) [2022] FCA 1585; 172 IPR 221 (primary judgment or PJ). The primary judge concluded that Hytera had infringed Motorola’s copyright in certain of the software programs in respect of which Motorola made claims for copyright infringement. His Honour also found that Motorola was entitled to an award of additional damages in respect of Hytera’s copyright infringement. His Honour granted declaratory and injunctive relief in respect of those conclusions, but deferred the question of compensatory relief pending any appeal.

3 Hytera appealed the findings of copyright infringement, and Motorola cross-appealed contending that the primary judge ought to have found that Hytera had infringed Motorola’s copyright to a greater extent. On 18 December 2024, we dismissed Hytera’s grounds of appeal and upheld certain of Motorola’s grounds of cross-appeal: Hytera Communications Corporation Ltd v Motorola Solutions Inc (2024) 308 FCR 68 (appeal judgment or AJ). In respect of Motorola’s cross-appeal, we concluded that the primary judge had erred in the approach taken to the assessment of copyright infringement in the following ways (AJ [914]):

(a)    The primary judge was in error to approach the question of infringement by considering whether small segments of Hytera source code which had been copied from a Motorola copyright work formed a substantial part of the relevant work. The question to be determined was whether, in respect of each of the Motorola works, the totality of the Motorola source code copied by Hytera (into the impugned Hytera source code) was a substantial part of the Motorola work.

(b)    The primary judge erred in two respects in his approach to the assessment of the substantiality of the copied code. First, his Honour incorrectly applied two tests or conditions for the assessment, being materiality and originality, when there is only one question to be answered. Second, his Honour applied a test of whether the copied code was functionally material to the relevant Motorola work in the sense of being significant or important to the operation of the DMR. The question of substantial part is to be determined by reference to the originality of the code that has been copied, which requires consideration of the creative and intellectual contribution to the form of expression of the code, including such matters as the structure of the code and the choice and sequencing of commands.

4 However, when delivering judgment on the appeal, we also explained that, to that point, we were not able to determine whether Motorola’s claim of copyright infringement should succeed in whole or in part (AJ [919]). By reason of the approach taken by the primary judge to the assessment of copyright infringement, relevant factual findings had not been made that would enable us to determine finally the copyright infringement case applying the methodology that we considered to be correct. Further, within the time allowed for the appeal to that point, the Court had not been taken to the entirety of the evidence bearing on the assessment. We concluded that the appropriate course was to conduct a further hearing at which the parties would be given an opportunity to advance further submissions in respect of the copyright infringement claims that arise on the appeal and the cross-appeal in accordance with our reasons. The further hearing was to be a continuation of the appeal and cross-appeal.

5 The remaining issues on the appeal and cross-appeal (which, for convenience, will be referred to collectively as the appeal) were summarised at AJ [920] as:

It is necessary to determine, in respect of each of the Motorola Works, whether the totality of the Motorola source code copied by Hytera (into the impugned Hytera source code) was a substantial part of one or more of the Motorola Works. The question of substantial part is to be determined by reference to the originality of the code that has been copied, which requires consideration of the creative and intellectual contribution to the form of expression of the code, including such matters as the structure of the code and the choice and sequencing of commands.

6 The Court subsequently made orders for the filing of further submissions by the parties on copyright infringement. Motorola filed submissions in chief on 23 May 2025. Hytera filed a responsive submission on 1 September 2025. Motorola filed a reply on 27 October 2025. The submissions were lengthy and comprehensive.

7 Motorola’s submissions in chief included, as Annexures 2 to 7, tables that identified, for each of the Motorola copyright works in issue, a list of the computer files within the work from which code had been found to have been copied by Hytera and the specific lines of the code that had been copied. Hytera’s responsive submissions included, as Annexure E, a compilation of Motorola’s Annexures 2 to 7 expanded into a table which also identified the paragraphs of the primary judgment where the specific lines of code had been considered, the evidence relating to the computer file and copied code and Hytera’s submissions with respect to the ‘substantiality’ of the copied code.  At the request of the Court, on 14 November 2025, Motorola filed a further version of Annexure E which incorporated Motorola’s position on the evidence relating to each computer file and copied code and its submissions with respect to the ‘substantiality’ of the copied code.

8 The further hearing of the appeal occurred between 17 and 20 November 2025. During the hearing, each of the parties provided the Court with numerous further submissions in the nature of “aides memoire” (10 in the case of Motorola and 12 in the case of Hytera).

9 The Court invited the parties, and also gave the parties leave, to file further submissions on specific issues after the conclusion of the hearing, which were as follows:

(a)    The Court invited the parties to file a submission addressing the relevance (if any) of the concept of animus furandi in determining whether a substantial part of a copyright work has been taken. Motorola filed a submission addressing that issue on 25 November 2025 and Hytera filed a responsive submission on 28 November 2025.

(b)    The Court gave Hytera leave to file a further response to Motorola’s version of Annexure E, which Hytera filed on 1 December 2025.

(c)    The Court gave Hytera leave to file a response to Motorola’s aide memoire regarding the discovery given by Hytera of its source code for its DMR products prior to the copyright trial, which Hytera filed on 1 December 2025.

(d)    The Court gave Hytera leave to amend Annexure D of its submissions (which purported to provide, for each of the Motorola copyright works in issue, a count of the total number of computer files within the work, the number of computer files from which code had been found to have been copied by Hytera, the total number of lines of code within all of the computer files within the work, and the number of lines of code that had been copied), which Hytera filed on 1 December 2025.

10 These reasons concern our determination of the question concerning “substantial part”: that is, whether Hytera infringed Motorola’s Australian copyright in the ‘Release 1’ version of its computer source code for the firmware in its DMR devices by, first, importing into Australia Hytera DMRs containing firmware which was an adaptation of a substantial part of Motorola’s source code and, second, making that firmware available for download in Australia from its website portal. These reasons should be read in conjunction with the appeal judgment.

11 For convenience, we will refer to the appeal hearing that culminated in the appeal judgment as the first phase of the appeal, and the subsequent appeal hearing which has culminated in this judgment as the second phase of the appeal.

Application to vary the Full Court’s orders

12 Upon delivering judgment on the first phase of the appeal on 18 December 2024, we made orders dismissing Hytera’s appeal and allowing Motorola’s cross-appeal in part and dismissing it in part. As noted above, we also listed the proceeding for further case management for the making of timetabling orders for the further hearing and determination of the copyright infringement claims that arise on the appeal in accordance with our reasons.

13 On 19 February 2025, Hytera filed an interlocutory application seeking a variation to the order dismissing Hytera’s appeal pursuant to rule 39.05(e) and/or (h) of the Federal Court Rules 2011 (Cth). Hytera contended that, to reflect the Full Court’s reasons, the order should be varied to dismiss only grounds 1 and 6 to 13 of Hytera’s appeal. The effect of the variation is to leave for final determination Hytera’s challenge to the primary judge’s conclusion that Hytera’s firmware was an adaptation of a substantial part of the following Motorola copyright works:

(a)    the Xlate component of the Darwin Ergonomics Platform (ground 2);

(b)    the HAL Serial Buffer (ground 3);

(c)    the Darwin Ergonomics Platform, the Mobile Firmware and the Portable Firmware (ground 4); and

(d)    the DSP Firmware (ground 5).

14 Rule 39.05(e) and (h) of the Federal Court Rules relevantly enable the Court to vary or set aside a judgment or order after it has been entered if it does not reflect the intention of the Court or if there is an error arising in a judgment or order from an accidental slip or omission. The Court’s power to alter or set aside a judgment or order pursuant to r 39.05 is sourced in ss 22 and 23 of the Federal Court of Australia Act 1976 (Cth): Remington Products Australia Pty Ltd v Energizer Australia Pty Ltd [2008] FCAFC 47; 246 ALR 113 at [18]. An order made pursuant to these rules operates nunc pro tunc to correct an earlier order, and thus speaks from the date of the earlier order: Elyard Corporation Ltd v DDB Needham Sydney Pty Ltd (1995) 61 FCR 385 at 391-2 (Lockhart J, with Black CJ agreeing), 400-1 (Lindgren J); Australian Rail, Tram and Bus Industry Union v Metro Trains Melbourne (2019) 276 FCR 172 at [9] (Flick J with Anastassiou J agreeing), [54]-[55] (Bromberg J).

15 We accept Hytera’s submission that, while our reasons rejected certain grounds of appeal advanced by Hytera, we did not reach a final conclusion on the question whether Hytera’s firmware was an adaptation of a substantial part of any of the Motorola copyright works (see AJ [920]), and therefore did not reach a final conclusion with respect to grounds 2 to 5 in Hytera’s appeal. That was because those grounds of appeal were rendered nugatory by the Full Court’s acceptance of Motorola’s grounds of cross-appeal (see, for example, AJ [827], [828]).

16 The issue raised by Hytera also affects the order we made allowing Motorola’s cross-appeal in part, in respect of grounds 2 and 3, and otherwise dismissing the cross-appeal. Correctly, the order should have dismissed only ground 1 of the cross-appeal (concerning the validity of the 960 Patent), allowed in part grounds 2 and 3, and left unresolved ground 4 (concerning the alleged infringement of copyright in the Motorola Works EMT, UIT, L1 Timer, Framer and the framerLib Library).

17 It is therefore appropriate to correct the orders made on 18 December 2024 in both of the respects referred to above. The second phase of the appeal was argued on that basis.

Motorola’s copyright works

18 Motorola’s copyright works that were the subject of the infringement claims were described in both the primary and appeal judgments. Although we will generally avoid repeating matters set out in the appeal judgment (and we will assume familiarity with it), it is convenient to identify Motorola’s copyright works at the outset of these reasons.

19 Motorola began work on its DMR project in earnest in 2003. The software development for this project was called the ‘Matrix’ project. The development of the Matrix software continued until February 2007.

20 Motorola’s DMR devices comprised subscriber units (also called terminal equipment), which included portable DMRs (i.e. handheld) and mobile DMRs (i.e. those fitted inside vehicles), and base stations (also called repeater equipment). Each type of device came installed with its own firmware (that is, object code installed within the device). The firmware for each kind of device differed. The host firmware for the portable devices was known as the ‘Portable Firmware’, and that for the mobile devices as the ‘Mobile Firmware’. Each mobile and portable device and each base station was also installed with what was known as the ‘DSP Firmware’. The DSP is that part of a device which implements and operates the requirements of the 2005 DMR Standard including synchronising and transmitting on a timeslot.

21 Motorola’s claims for copyright infringement concern the source code for the firmware installed on its DMR devices. The source code was written in the C++ computer programming language. In its pleaded case, Motorola specified the copyright works that were allegedly infringed by Hytera at three levels of aggregation.

22 At the first (and highest) level of aggregation, Motorola alleged that Hytera infringed its copyright in each of the following suites of software:

(a)    the suite of software known as ‘MOTOTRBO Mobile Subscriber FW Package R01.00.01’ (Mobile Firmware);

(b)    the suite of software known as ‘MOTOTRBO Portable Subscriber FW Package R01.00.01’ (Portable Firmware); and

(c)    the suite of software known as ‘DSP (C55x) R01.00.01’ (DSP Firmware).

23 At the second (and middle) level of aggregation, Motorola alleged that Hytera infringed its copyright in computer programs that formed part of each of the Mobile Firmware, Portable Firmware and DSP Firmware:

(a)    in respect of the Mobile and Portable Firmware, Motorola alleged that Hytera infringed its copyright in the computer program called the Darwin Ergonomics Platform; and

(b)    in respect of the DSP Firmware, Motorola alleged that Hytera infringed its copyright in the computer programs called the framerLib Library and the HAL Serial Buffer.

24 At the third (and lowest) level of aggregation, Motorola alleged that Hytera infringed its copyright in the following computer programs:

(a)    each of the EMT, Xlate and UIT components of the Darwin Ergonomics Platform; and

(b)    each of the Framer and L1 Timer components of the framerLib Library program.

25 The hierarchy of the copyright works is depicted in the following diagram:

26 In its pleaded case, Motorola identified each of the above works (Motorola Works) by the location of the work within a computer directory, giving the computer directory name. For example, the Framer program was located within two directories called:

(a)    \samurai\code\source\rfhal\framerLib\framer\; and

(b)    \samurai\code\source\rfhal\framerLib\framer\release\.

27 The relevant question to be determined is whether the Hytera source code, which the Court has found to have been copied from each of the Motorola Works, is a substantial part of the relevant Motorola Work. These reasons consider that question, first, at the lowest level of aggregation, second, at the middle level of aggregation and, third, at the highest level of aggregation.

Identification of the copied code

28 The first step in answering the ‘substantial part’ question is to identify the Hytera source code that the Court has found to have been copied from each of the Motorola Works. The identification of the copied code is summarised in the Annexure to these reasons. This section of the reasons explains the materials used, and steps taken, to prepare the Annexure.

29 The starting point is Motorola’s pleading which particularised the alleged infringement of the Motorola Works by reference to two tables, the first listing instances of copying from the Mobile Firmware and the Portable Firmware programs and the second listing instances of copying from the DSP Firmware program. Each table contained five columns which identified:

(a)    the name of the Motorola source code file that Motorola alleged had been copied by Hytera;

(b)    the directory address for where the Motorola file was located;

(c)    the name of the Hytera source code file or files that Motorola alleged contained copies of part or all of the Motorola file;

(d)    the specific lines of source code within the Motorola file that Motorola alleged had been copied by Hytera; and

(e)    the specific lines of source code within the Hytera file that Motorola alleged contained copies of the lines of source code within the Motorola file.

30 As noted in the appeal judgment (AJ [665]), the primary judge expressed frustration that Motorola had failed to identify the computer files that it relied on in support of its infringement case concerning the different Motorola Works. That criticism stemmed from the structure of the particulars of infringement, which listed Motorola’s files by reference to whether they formed part of the Mobile and Portable Firmware or the DSP Firmware, but did not list the files by reference to the underlying Motorola Work of which they formed part. The criticism was justified. Considerable effort was required at trial (and on appeal) to identify the Motorola Works of which copied computer files form part.

31 Overcoming many of the difficulties in the manner in which Motorola presented its case, the primary judge made findings with respect to the Motorola code that had been copied into Hytera code on the basis of the objective similarity of the code. For the purposes of the first stage of the appeal, the parties prepared a document titled “Summary of the primary judge’s findings on objective similarity”, which also came to be known as the “Objective Similarity Matrix” (or “OSM”). The Objective Similarity Matrix was a table listing, for each of the Motorola Works, the computer files within the works, and the lines of code within those files, that the primary judge found had been copied by Hytera (because corresponding lines in Hytera computer files were objectively similar). The identification of the copied code, based on the findings of the primary judge, was largely agreed between the parties in that document.

32 On appeal, this Court made different findings to the primary judge on the question of copying in respect of certain computer files.

33 First, this Court upheld Hytera’s contention that certain lines of code, which the primary judge had found were objectively similar to Hytera code, had not been compiled into object code in the Hytera devices imported into Australia and, accordingly, there was no breach of copyright in Australia in respect of those lines of code: AJ [819] and [822]. This meant that there could be no copyright infringement in respect of lines 170-198 and 199-229 of the Motorola file cor_emt_user_defines.h within the EMT program and lines 54-127 of the file rs_emt_load_init_mode_info.c within the EMT program. Those lines of code are accordingly excluded from the Annexure.

34 Second, this Court upheld Motorola’s contention that the primary judge erred in concluding that Motorola’s case did not involve the copying of the computer files listed at PJ [1739] and [1940]: AJ [839]. As a result, in so far as the primary judge found that lines of code in those files had been copied, they form part of Motorola’s case. The primary judge found that lines of code had been copied by Hytera from the following files: vris.h (PJ [1774]); app_powerup.c (PJ [1753], [1754], [1757]); app_powerup.h (PJ [1763], [1765], [1766]); powerup_app_launch_handler.c (PJ [1770]); rs_cpvalue_list.h (PJ [1777]); ListenerBase.h (PJ [1793] and [1941]); EventBase.h (PJ [1797] and [1941]); NotifierBase.h (PJ [1797] and [1941]); and PowerupToIdleFrame.cpp (PJ [1956]). Those lines of code are included in the Annexure.

35 Third, this Court upheld Motorola’s contention that the primary judge erred in not finding, on the balance of probabilities, that the Hytera source code from which the object code in Hytera library files raf_arm9.lib, rfhal_c55.lib and DmrDspLib.lib was compiled reproduced a substantial part of the relevant Motorola source code: AJ [867]. As discussed in the appeal judgment (at [652]), Hytera generally gave discovery of source code from which the object code (firmware) installed in its DMR devices had been compiled. However, in the course of giving discovery in tranches, Hytera discovered three ‘library’ files named raf_arm9.lib, rfhal_c55.lib and DmrDspLib.lib.  Library files are in the form of object code rather than source code. As found by the primary judge (PJ [1273]), when source code is compiled into object code, the object code is combined into an “archive” or “library”.

36 Hytera was unable to produce the source code from which the object code in the library files raf_arm9.lib, rfhal_c55.lib and DmrDspLib.lib had been compiled (PJ [1274]). In the absence of the Hytera source code, Motorola faced an evidentiary hurdle in showing that the library files were created by Hytera copying a substantial part of Motorola’s source code. Motorola sought to overcome that hurdle by undertaking a process of disassembling the Hytera object code and inviting the Court to draw an inference of copying from all the circumstances. The disassembly process generated the names of files and functions which had existed in the missing source code (PJ [1278]). Some of those file and function names matched or partially matched file and function names in Motorola’s source code. The primary judge found that:

(a)    in respect of the library file raf_arm9.lib, the disassembly identified 18 files from within the Darwin Ergonomics Platform, comprising 12 files from within the EMT work (PJ [1510]), 5 files from within the Xlate work (PJ [1681]) and 1 file from within the UIT work (PJ [1715]);

(b)    in respect of the library file rfhal_c55.lib, the disassembly identified 8 files from within the DSP Firmware work, comprising 1 file from within the L1 Timer work (PJ [1846]), 5 files from within the Framer work (PJ [1857]-[1858]) and 2 files from within the DSP Firmware work more generally (PJ [1977]); and

(c)    in respect of the library file DmrDspLib.lib, the disassembly identified 64 files from within the DSP Firmware work (PJ [1962]).

37 Contrary to the conclusion of the primary judge, this Court decided that an inference should be drawn that the source code from which the Hytera library files raf_arm9.lib, rfhal_c55.lib and DmrDspLib.lib were compiled reproduced a substantial part of the Motorola source code having matching file names (AJ [867]). Accordingly, each of those Motorola files are included in the Annexure, identified as being files copied into the applicable Hytera library file raf_arm9.lib, rfhal_c55.lib or DmrDspLib.lib.

38 For the purposes of this second phase of the appeal, and as noted above, the parties prepared a number of documents that tabularised the combined findings of the primary judge and this Court with respect to the copied code. One of those tables was Annexure E to Hytera’s submissions (which was subsequently annotated by Motorola on 14 November 2025 and by Hytera on 1 December 2025). Annexure E refers to all Motorola computer files in respect of which Hytera has been found to have copied code. The Annexure to these reasons has been structured in materially the same manner as Annexure E prepared by the parties. It is organised in a hierarchical manner, such that computer files are identified by the Motorola Work of which they form part, beginning with the lowest level of aggregation, then the middle level and then the highest level.

39 One difference between the findings of the primary judge and Annexure E should be noted. The Motorola files svc_string_utils.h and svc_string_utils.c were each categorised by the primary judge as being files within the Darwin Ergonomics Platform but outside of the EMT, Xlate and UIT works (PJ [1723]). However, the evidence of Prof Wicker establishes that the files are part of the UIT work, and the files were categorised as such in Annexure E. The Annexure to these reasons has adopted the same approach as Annexure E.

40 One further computer file requires mention. The disassembly of the library file rfhal_c55.lib identified a file from within the framerLib Library called qspi.cpp. The primary judge discussed Motorola’s case in respect of the framerLib Library work at PJ [1892]-[1896], concluding that, if Motorola’s case went beyond the computer files within the Framer and the L1 Timer works, it was not apparent what the case was. As a consequence, the primary judge did not specifically consider the file qspi.cpp which the evidence shows formed part of the framerLib Library work (but which was outside of the Framer and the L1 Timer works). In our view, Motorola’s case at trial did include the file qspi.cpp, as the file was listed in Motorola’s particulars of infringement. Consistently with this Court’s conclusion (at AJ [867]) that the source code from which the Hytera library file rfhal_c55.lib was compiled reproduced a substantial part of the Motorola source code having matching file names, we conclude that a substantial part of qspi.cpp was copied by Hytera. Accordingly, the file qspi.cpp is also included in the Annexure to these reasons as a copied file. The parties addressed this file in the second phase of the appeal.

A.2    Evidence relied on by the parties

41 At the further hearing, each of the parties prepared detailed submissions referencing the evidence adduced at trial with respect to the claims of copyright infringement.

Lay evidence

42 The relevant lay evidence was adduced by Motorola and was in the form of affidavits. No software engineers from Hytera who worked on the Hytera software were called to give evidence (PJ [1576]). The relevant lay evidence adduced by Motorola was as follows.

Lo Kang Kwai Sin (all works)

43 Lo Kang Kwai Sin (referred to in Motorola’s submissions as Lo Kang) was the Software Engineering Lead for Subscriber (Core and Portable), and had responsibility for leading the Matrix development teams based in Penang in Malaysia and Chengdu in China, where much of the software development for the Matrix project occurred. He gave evidence as to the overall development of the Matrix software, including the initial architecture and design phase, and the teams who were responsible for that development. Lo Kang affirmed an affidavit on 28 February 2019.

44 Lo Kang was not cross-examined. Accordingly, his evidence with respect to the copyright claims was unchallenged, and we have no hesitation in relying upon his evidence on this appeal.

Daniel Paul Zetzl (all works)

45 Mr Zetzl was one of two Chief Radio Software Architects on the Matrix project. Mr Zetzl’s primary role was to provide technical oversight of the development of the Matrix platform, and he oversaw the work of software development teams based in all of the development sites involved in the Matrix project, namely Schaumburg and Plantation in the United States, Penang in Malaysia and Chengdu in China. In addition, Mr Zetzl was directly involved in certain aspects of the code development, for example where specific aspects were presenting difficulties or falling behind schedule. He gave evidence as to the overall architecture and structure of the Motorola Works, and in relation to certain specific elements of those works. Mr Zetzl swore two affidavits dated 28 February 2019 and 21 June 2019 respectively.

46 Mr Zetzl was cross-examined, but there was no challenge to any of his evidence concerning the development of the Motorola Works, or his description of those works. Accordingly, we have no hesitation in relying upon his evidence on this appeal.

David James Ley (Darwin Ergonomics Platform)

47 Mr Ley was the original architect and developer of the Darwin Ergonomics Platform. Mr Ley also acted as a consultant and technical advisor to the team who subsequently enhanced the Darwin Ergonomics Platform as part of the Matrix project. Mr Ley gave evidence as to the design and process of creation of the Darwin Ergonomics Platform and its components (including, relevantly, the EMT, Xlate and UIT components of the Darwin Ergonomics Platform). Mr Ley affirmed three affidavits dated 27 February 2019, 20 June 2019 and 12 March 2020 respectively.

48 Mr Ley was not cross-examined. Accordingly, his evidence with respect to the copyright claims was unchallenged, and we have no hesitation in relying upon his evidence on this appeal.

Mark Alan Antilla (Darwin Ergonomics Platform)

49 Mr Antilla was a software developer who worked on enhancements to the Darwin Ergonomics Platform during the Matrix project. He gave evidence about the nature of those enhancements and the process of their creation. Mr Antilla affirmed an affidavit dated 27 February 2019.

50 Mr Antilla was not cross-examined. Accordingly, his evidence with respect to the copyright claims was unchallenged, and we have no hesitation in relying upon his evidence on this appeal.

Matthew Emmett Simms (framerLib Library)

51 Mr Simms was a developer of software for the DSP Firmware, specifically the ‘L1 Timer subsystem’ (including relevantly the framerLib Library). He gave evidence as to the design of the L1 Timer subsystem and the process of its creation, including both its initial creation for an earlier project and its modification for the Matrix project. Mr Simms swore three affidavits dated 6 March 2019, 27 June 2019 and 12 March 2020 respectively.

52 Mr Simms was not cross-examined. Accordingly, his evidence with respect to the copyright claims was unchallenged, and we have no hesitation in relying upon his evidence on this appeal.

Jesus Francisco Corretjer (certain components of the DSP Firmware)

53 Mr Corretjer was the chief architect of the DSP framework and had responsibility for DSP software components that go into all of Motorola’s subscriber radio products. Mr Corretjer was responsible for the architecture and design of the DSP ‘framework entities’ and ‘lineup entities’, which are processing blocks that carry out specific functions that are used for the processing of digital signals. Mr Corretjer swore an affidavit dated 20 June 2019.

54 Mr Corretjer was not cross-examined. Accordingly, his evidence with respect to the copyright claims was unchallenged, and we have no hesitation in relying upon his evidence on this appeal.

Benjamin James Andrew Hayes (all works)

55 Mr Hayes is a patent attorney at FPA Patent Attorneys. He holds a Bachelor of Engineering (1st class honours), majoring in software engineering, and a Bachelor of Laws, from the University of New South Wales. Mr Hayes has worked as a patent attorney since 2014 and specialises in the IT and computer software areas. He has previously worked as a software engineer for Optus in their Satellite Communications group as well as in smaller software companies across a number of different industries such as telecommunications, energy and industrial automation. Mr Hayes has professional programming experience in the software languages C, C++ and C#. Amongst other things, Mr Hayes undertook the process of disassembly of the library files discovered by Hytera in the proceeding, which identified numerous files having the same name as files within the Motorola Works. Mr Hayes also verified, on behalf of Motorola, the number of files within the Motorola Works. Mr Hayes affirmed two affidavits dated 21 June 2019 and 16 March 2020 respectively.

56 Mr Hayes was not cross-examined. Accordingly, his evidence with respect to the copyright claims was unchallenged, and we have no hesitation in relying upon his evidence on this appeal.

Expert evidence

57 Motorola adduced expert evidence relevant to the copyright infringement claims primarily from Professor Stephen Bryant Wicker. Expert evidence was also adduced from Professor Sundeep Rangan on certain issues. Hytera adduced expert evidence relevant to the copyright infringement claims from Craig Matthew Brown and also Andrew Neil Grimmett.

58 In addition to filing reports, the experts participated in the preparation of a Joint Expert Report (JER). The experts also gave evidence in concurrent session and were cross-examined.

59 Each of the experts gave evidence with respect to their relevant qualifications and experience, which can be summarised as follows.

Prof Wicker

60 At the time of affirming his first affidavit in the proceeding in 2018, Prof Wicker was Professor of Electrical and Computer Engineering at Cornell University in New York.

61 Prof Wicker was awarded a Bachelor of Science degree in Electrical Engineering from the University of Virginia in 1982, a Master of Science degree in Electrical Engineering from Purdue University in 1983, and a PhD in Electrical Engineering from the University of Southern California in 1987 (his thesis being on the theory of sequences and error control codes for digital communication systems).

62 Prof Wicker has held the following positions during his career:

(a)    In 1982, he was a member of the Network Architecture Research Group at Bell Laboratories in Columbus, Ohio, where he worked on digital switching systems for the messages that control the telephone network.

(b)    Between 1983 and 1987, he was a Staff Engineer in the Space and Communications group of the Information Sciences Department at Hughes Aircraft in El Segundo, California, where he designed and developed wireless communication payloads for commercial, military and NASA spacecraft. During this time, he also acted as the Principal Systems Engineer for new business in advanced satellite systems.

(c)    In 1987, he joined the Georgia Institute of Technology in Atlanta, Georgia as an Assistant Professor in the School of Electrical and Computer Engineering. In 1992, he was promoted to Associate Professor.

(d)    Since 1996, he has been a member of the faculty of the School of Electrical Engineering at Cornell University, first in the position of Associate Professor and, since 1999, in the position of Professor. In that role, he teaches and conducts research in wired and wireless information networks, digital telephony, information theory, security, and location-based services. Between 2000 and 2003, he was also Associate Director for Research in the School of Electrical Engineering at Cornell University.

63 Between 1990 and 2005, Prof Wicker consulted extensively in the telecommunications industry including for Lockheed Sanders, Integrated Device Technology, Unisys Corporation, Texas Instruments and other corporations to develop advanced technologies for their telecommunications products. Between 1997 and 1998, Prof Wicker was a consultant to the Advanced Mobile Messaging Division of Motorola in relation to the design and development of mobile radio systems. Prof Wicker also consulted to SkyTel in relation to mobile radio systems during the 1990s.

64 Prof Wicker has also published extensively in the field of digital communication systems and information networks, including having written or edited six books and approximately 250 journal and conference papers, most of which focus on digital communication systems and information networks.

65 Prof Wicker has over 35 years’ experience with writing and reviewing source code, and has used source code as a research tool for equipment testing and general computing purposes throughout his career, including in his roles at Bell Laboratories and Hughes Aircraft. Together with the PhD students that he has supervised, Prof Wicker has also written source code for software designed for wireless systems. Through these experiences, he is familiar with a number of programming languages, including Python, C, C++, Java, Pascal and COBOL. As a result of this experience, he is able to read and understand source code in those programming languages, including how such source code interacts with hardware to control the operation of devices in digital communications systems.

66 Prof Wicker affirmed five affidavits dated 28 March 2019, 25 July 2019, 26 March 2020, 25 June 2020 and 1 July 2020 respectively.

Prof Rangan

67 At the time of affirming his first affidavit in the proceeding in 2018, Prof Rangan was Professor in Electrical and Computer Engineering at New York University. Prof Rangan is also a fellow of the Institute of Electrical and Electronics Engineers and Director of NYU Wireless, an academic-industry research centre researching next-generation wireless systems.

68 Prof Rangan was awarded a Bachelor of Applied Science degree in Electrical Engineering from the University of Waterloo in Waterloo, Canada in 1992; a Master of Science degree in Electrical Engineering from the University of California in Berkeley, California in 1995; and a PhD in Electrical Engineering from the University of California in Berkeley, California in 1997.

69 Prof Rangan has held the following positions during his career:

(a)    From 1997 to 1998, he worked as a Postdoctoral Research Fellow in the Department of Electrical Engineering at the University of Michigan, his research being focused on the development of a commercial MATLAB toolbox for system identification.

(b)    From 1998 to 2000, he worked as a Postdoctoral Member of Technical Staff at Bell Labs, Lucent Technologies in New Jersey where he worked on the initial high-level system design and simulation of the Flash-orthogonal frequency division multiplexing (OFDM) wireless system, a project that was spun off to become Flarion Technologies. Flash-OFDM was one of the first cellular OFDM data systems and a precursor to later 4G standards including WiMAX and Long-Term Evolution (LTE).

(c)    From 2000 to 2006, he worked as the Director and Co-Founder of Flarion Technologies, where he supervised the design, simulation and testing of virtually every aspect of the PHY (physical) and MAC (medium access control) layers of the Flash-OFDM system, through three generations of mobile and base station products.

(d)    From 2006 to 2010, he worked as the Director of Engineering at Qualcomm Technologies in Bridgewater, New Jersey, where he supervised advanced research and development of cellular communication products.

(e)    In 2010, he was appointed to the position of Associate Professor in the Electrical and Computer Engineering Department at New York University. In September 2018, he was promoted to Professor. In this role, he teaches courses and directs research in digital and wireless communications, signal processing, information theory and control theory.

70 During his time at New York University, Prof Rangan has also consulted to industry clients, including for Microsoft Research in 2010 and Kandou Technologies (Switzerland) between 2011 and 2013. Prof Rangan has also been on the technical advisory board of PHAZR since 2016.

71 Prof Rangan has authored over 50 journal articles, four books, expository articles and book chapters, and over 100 conference papers, the vast majority of which are in the field of wireless communications and signal processing.

72 Prof Rangan has at least 18 years’ experience with writing and reviewing source code, including in his roles at Flarion Technologies and Qualcomm Technologies. The majority of his source code experience relates to source code for wireless communications systems including source code that interacts with hardware to control the operation of devices in wireless communications systems. Prof Rangan wrote most of the firmware developed for the Flash-OFDM system at Flarion Technologies, and worked as software lead in developing high performance base station ASICs for 3GPP LTE systems at Qualcomm Technologies. Prof Rangan has regularly used source code as part of his teaching and research throughout his academic career. Through these experiences, he is familiar with a number of programming languages, including C, C++ and general assembly programming languages. As a result of this experience, he is able to read and understand source code written in those programming languages, including how such source code interacts with hardware to control the operation of devices in wireless communications systems.

73 Prof Rangan affirmed five affidavits, although only the fifth affidavit affirmed on 26 March 2020 was before this Court on the appeal.

Mr Brown

74 At the time of affirming his first affidavit in the proceeding in 2019, Mr Brown was Chief Technology Officer at Deckard Technologies, Inc.

75 Mr Brown was awarded a Bachelor of Commerce from the University of Melbourne in 1990 and a Bachelor of Computer Science from the University of Melbourne in 1991. As part of his studies leading to the award of a Bachelor of Computer Science, Mr Brown learned to program in various programming languages, including C and C++.

76 Mr Brown has held the following positions during his career:

(a)    From 1991 (after leaving Melbourne University) until 2004, he was employed at Canon Information Systems Research Australia (CISRA) in Sydney, Canon's Australian research and development centre. He started as an Associate Software Engineer, before being promoted to Software Engineer in about 1992, Senior Software Engineer in about 1995 and Principal Engineer in about 1999.

(b)    From 2004 to 2005, he was a contractor to Adobe in Sydney developing a precursor to the HTML5 layout system for rendering and editing rich text and graphics.

(c)    From January to June 2006, he developed embedded software for the Boeing 737 airborne early warning and control system.

(d)    Mr Brown joined Qualcomm in Sydney in July 2006 as a member of the global product security team, primarily performing static analysis of Qualcomm source code to detect potential security vulnerabilities. In about May 2007, he was promoted to Principal Engineer at Qualcomm and in about May 2009, he was promoted to Principal Engineer/Manager leading Qualcomm's Australian development team, which was part of a larger global group within Qualcomm's Office of the Chief Scientist. In that role, Mr Brown analysed the behaviour of competitor devices and software systems, reverse-engineered binary (machine-readable) software and utilised various techniques to compare software in end-user cellular devices, and supported the Qualcomm brand protection team in identifying and prosecuting counterfeit phone manufacturers. In about November 2010, he was promoted to Senior Director of Technology.

(e)    He joined Telstra in July 2018 to be responsible for big data delivery for its network investment and operations. In September 2018, his position was expanded to take on the role of Chief Data Scientist.

(f)    From June 2018 through to January 2019, he worked for Deckard Technologies, Inc. on a part-time basis as a software engineering and data science consultant, in addition to his full-time job at Telstra. Mr Brown left Telstra in January 2019 so that he could work full-time for Deckard from February 2019 onwards.

77 Mr Brown affirmed three affidavits dated 6 December 2019, a fourth affidavit dated 12 June 2020 and a fifth affidavit dated 24 July 2020. In these reasons, the three affidavits affirmed on 6 December 2019 will be identified as the first, second and third affidavit in the same manner as they were identified in the appeal book.

Mr Grimmett

78 At the time of affirming his first affidavit in the proceeding in 2018, Mr Grimmett was the Technical Director at Pyronix, which designed and manufactured wired and wireless security systems. Mr Grimmett oversaw the development of products such as intruder alarms. At the time of affirming his second affidavit in the proceeding in 2019, Mr Grimmett had left Pyronix and commenced his own consulting business called Rockabillies Limited. In his affidavit dated 6 December 2019, Mr Grimmett stated that, through his consulting business, he provides “consulting services relating to digital mobile radios”. However, the curriculum vitae attached to his affidavit stated that the consulting business provides “expert opinion for patent and trade secret litigations in the USA and Australia”. It appears that Rockabillies Limited is the corporate entity through which Mr Grimmett has provided his services as an expert to Hytera in the proceeding below and related proceedings in America and that, as at December 2019, that was Mr Grimmett’s sole employment.

79 Mr Grimmett was awarded a Bachelor of Science in Computer Science at Coventry University in the United Kingdom in 1992. During his university degree, Mr Grimmett learned to read and write several computer programming languages including C and C++. Mr Grimmett deposed that his professional experience has required him to write software in C and C++, although he only referred to writing software in C and C++ while at Mobicom/Simoco.

80 Mr Grimmett has held the following positions during his career:

(a)    From 1993 to 1998, he worked as a Software Engineer in the United Kingdom at Mobicom, which became Simoco in 1996 following a buyout. The company manufactured and supplied advanced radio communications infrastructure products and systems to customers including the United Kingdom Ministry of Defence and British Gas. When Mr Grimmett started at Mobicom, voice communications used analogue technology and the company’s focus was on analogue radio voice and data communications. But as a software engineer, he was developing innovative protocols for radio voice and data communications and digital signalling for telephony networks. In that role, Mr Grimmett was coding software in the programming language C, and to a lesser extent C++.

(b)    In 1999, he worked for a short time as a Software Engineer at Alstom Automation, using real time software to control the baggage handling system at London Heathrow Airport.

(c)    From 1999 to 2015, he was employed by several entities in the Simoco Group. Between 1999 and 2002, he worked on a project for the Western Australian Police Force to deliver a voice and data gateway interfaced to TETRA radio infrastructure. From May 2002 to September 2005, he was Simoco’s Research & Development Manager, with overall responsibility for R&D and project delivery of telecommunications projects worldwide. From October 2005 to May 2011, he was the Chief Technical Officer at Simoco and was effectively Simoco’s technical expert for development of mobile radio technology. In around 2008, Simoco started developing DMR systems. In around 2011, Simoco obtained a licence from Motorola for essential patents relating to the DMR Standards and Simoco released its first DMR product in 2012. From 2011 to 2015, he was Simoco’s Head of Product Strategy.

(d)    From 2015 to 2017, he was the Head of Global Application Support at Experian, working on software related to consumer credit reporting.

(e)    From mid-2017 to 2019, he was the Technical Director at Pyronix, a designer and manufacturer of wired and wireless security systems.

81 Mr Grimmett affirmed two affidavits in the proceeding, but only the second affidavit affirmed on 5 December 2019 was before this Court on the appeal.

A.3    Applicable principles

Principles applicable to the assessment of substantial part

82 The principles that are applicable to the assessment of substantiality for copyright infringement are well-established. What amounts to the reproduction of a substantial part of the copyright work cannot be defined in precise terms and is a matter of fact and degree; it will depend not merely on the quantity of the reproduction, but on the significance of the part that is taken: Ladbroke (Football) Ltd v William Hill (Football) Ltd [1964] 1 WLR 273 (Ladbroke) at 283 (Lord Evershed); IceTV Pty Limited v Nine Network Australia Pty Limited (2009) 239 CLR 458 (IceTV) at [30]-[32] (French CJ, Crennan and Kiefel JJ).

83 In the appeal judgment (at [790]-[798]), we observed that the plurality judgment in Data Access Corporation v Powerflex Services Pty Ltd (1999) 202 CLR 1 (Data Access) provides the most extensive guidance to the assessment of substantiality in the context of computer code. It is convenient to reproduce that part of the appeal judgment:

791    In Data Access, the plurality stated their agreement with the following observations of Mason CJ in Autodesk (No 2) (at 305, citations omitted):

It is clear that the phrase ‘substantial part’ refers to the quality of what is taken rather than the quantity. In Ladbroke (Football) Ltd v William Hill (Football) Ltd, Lord Pearce stated:

“Whether a part is substantial must be decided by its quality rather than its quantity. The reproduction of a part which by itself has no originality will not normally be a substantial part of the copyright and therefore will not be protected. For that which would not attract copyright except by reason of its collocation will, when robbed of that collocation, not be a substantial part of the copyright and therefore the courts will not hold its reproduction to be an infringement. It is this, I think, which is meant by one or two judicial observations that "there is no copyright" in some unoriginal part of a whole that is copyright.”

As this statement makes clear, in determining whether the quality of what is taken makes it a “substantial part” of the copyright work, it is important to inquire into the importance which the taken portion bears in relation to the work as a whole: is it an ‘essential’ or ‘material’ part of the work?

In this case, it is argued by the appellants that such an inquiry compels an affirmative answer as the look-up table is essential to the operation of the AutoCAD locking mechanism. Such an argument, however, misconceives the true nature of the inquiry and seeks to re-introduce by another avenue an emphasis upon the copyright work's function. True it is that the look-up table is essential to the functioning of the AutoCAD lock. However, in the context of copyright law, where emphasis is to be placed upon the 'originality' of the work's expression, the essential or material features of a work should be ascertained by considering the originality of the part allegedly taken. This is particularly important in the case of functional works, such as a computer program, or any works which do not attract protection as ends in themselves (eg, novels, films, dramatic works) but as means to an end (eg, compilations, tables, logos and devices).

792    The above passage makes three points in the context of computer code. First, the phrase “substantial part” refers to the quality of what is copied rather than the quantity. Second, in determining whether the quality of what is copied makes it a substantial part of the copyright work, it is important to inquire into the importance which the copied portion bears in relation to the work as a whole: is it an “essential” or “material” part of the work? Third, in this context “essential” does not mean essential to the operation of the computer code. Rather, in the context of copyright law, where emphasis is to be placed upon the originality of the work’s expression, the essential or material features of a work should be ascertained by considering the originality of the part allegedly taken.

793    After referring to the above observations of Mason CJ, the plurality in Data Access said (at [85]):

In order for an item in a particular language to be a computer program, it must intend to express, either directly or indirectly, an algorithmic or logical relationship between the function desired to be performed and the physical capabilities of the “device having digital information processing capabilities”. It follows that the originality of what was allegedly taken from a computer program must be assessed with respect to the originality with which it expresses that algorithmic or logical relationship or part thereof. The structure of what was allegedly taken, its choice of commands, and its combination and sequencing of commands, when compared, at the same level of abstraction, with the original, would all be relevant to this inquiry.

794    It follows that the assessment of whether copied computer code constitutes a substantial part of a relevant computer program (work) is concerned with the quality of what is taken rather than the quantity. The quality of the copied code is to be assessed by reference to the importance which the code bears in relation to the work as a whole, which can also be described as the materiality of the code. But importance and materiality do not refer to the function of the code in the sense of whether the code is important or material to the operation of the computer or device in which the code is installed. Rather, importance and materiality refer to the originality with which the code expresses the functions sought to be performed by the computer or device, which includes such matters as the structure of the code and the choice and sequencing of commands.

795    The foregoing principles were also affirmed by the High Court in IceTV, albeit that IceTV did not concern computer software and was a “compilation” case. As noted earlier in these reasons, French CJ, Crennan and Kiefel JJ confirmed that, in order to assess whether material copied is a “substantial part” of an original literary work, it is necessary to consider not only the extent of what is copied, but also the quality of what is copied (at [30]). After observing that the question of whether a substantial part has been copied is a question of fact and degree, their Honours stated that a factor critical to the assessment of the quality of what is copied is the “originality” of the part which is copied (citing Mason CJ in Autodesk (No 2) at 305 and Data Access at [83]-[84]). Their Honours referred (at [40]) with approval to the following statement made by the authors of Copinger and Skone James on Copyright:

[T]he more simple or lacking in substantial originality the copyright work, the greater the degree of taking will be needed before the substantial part test is satisfied.

796    An issue that was considered by the High Court in IceTV is the relevance to the assessment of whether material copied is a substantial part of an original work of the “appropriation” of the author’s skill and labour. French CJ, Crennan and Kiefel JJ observed (at [49]) that it is always necessary to focus on the nature of the skill and labour, and in particular to ask whether it is directed to the originality of the particular form of expression. Their Honours explained (at [52]):

… The Act mandates an inquiry into the substantiality of the part of the work which is reproduced. A critical question is the degree of originality of the particular form of expression of the part. Consideration of the skill and labour expended by the author of a work may assist in addressing that question: that the creation of a work required skill and labour may indicate that the particular form of expression adopted was highly original. However, focusing on the “appropriation” of the author’s skill and labour must not be allowed to distract from the inquiry mandated by the Act. …

797    Gummow, Hayne and Heydon JJ disapproved, in stronger terms, of reasoning based on the “misappropriation” of the author’s skill and labour. Their Honours stated (at [131], references omitted):

The first is to emphasise the dangers when applying the Act of adopting the rhetoric of “appropriation” of “skill and labour”. A finding that one party has “appropriated” skill and labour, of itself, is not determinative of the issue of infringement of a copyright work. The Act does not provide for any general doctrine of “misappropriation” and does not afford protection to skill and labour alone.

798    In assessing the originality of a computer program and specific code within the program for the purposes of infringement, the functionality of the code cannot be ignored because it is intrinsic to the nature of the copyright work. As observed by Mason CJ in Autodesk (No 2) at 305, a computer program is a “functional” work. That fact is reflected in the definition of “computer program” in s 10 of the Copyright Act, being “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result”. The relevant question is, though, in what manner is the functionality of computer code relevant to the assessment of infringement, and specifically the assessment of whether copied computer code constitutes a substantial part of a relevant computer program. The authorities discussed above show that the assessment of substantiality is focussed on the originality with which the code expresses the functions sought to be performed by the computer or device in which the code is installed, which includes such matters as the structure of the code and the choice and sequencing of commands. The assessment is not concerned with the function of the code in the sense of whether the code is important or material to the operation of the computer or device.

84 We have applied the foregoing principles in the assessment of whether the Hytera source code, which the Court has found to have been copied from a Motorola Work, is a substantial part of the Motorola Work.

The relevance of an animus furandi (intention to steal)

85 At the further hearing of the appeal, the Court invited the parties to address the relevance (if any) of an animus furandi (intention to steal) in determining whether a substantial part of a copyright work has been taken.

86 As noted in the appeal judgment (AJ [7] and [866]), the primary judge found that the ex-Motorola engineers, who were recruited by Hytera to develop Hytera’s software, brought with them to Hytera all of the computer source code for Motorola’s DMR device to provide themselves with a resource for the purposes of writing Hytera’s source code for its DMR device. The primary judge characterised Hytera’s actions as a “substantial industrial theft” and found (PJ [1576]):

There is no doubt that Hytera’s software engineers engaged in industrial scale harvesting of Motorola’s source code and that they set out to make this as difficult to detect as possible.

87 In its written submission dated 25 November 2025, Motorola submitted that, on the facts of this case, copying of a substantial part is established without considering Hytera’s intention to steal. Nevertheless, Motorola submitted that there was animus furandi on the part of Hytera and that fact may be taken into account and may reinforce a conclusion that the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works. Motorola argued:

The concept may be regarded as an example of an evidentiary principle which is echoed in other areas of the law, in which a court takes into account in determining a factual question as to whether a particular state of affairs existed or was achieved, the fact that a party intended by its conduct that that state of affairs exist or be achieved and in effect gives credit to the party in succeeding in that intention. It is in the nature of an informal admission. Examples include identification of the plaintiff for the purposes of defamation (Lee v Wilson (1934) 51 CLR 276 at 288), likelihood of use of a trade mark being deceptive (Australian Woollen Mills Ltd v FS Walton & Co Ltd (1937) 58 CLR 641 at 657-8; Telmak Teleproducts (Aust) Pty Ltd v Coles Myer Ltd (1988) 84 ALR 437 at 445) and likelihood of a misleading or fraudulent representation intended to being acted on in fact being acted on (Gould v Vaggelas (1984) 157 CLR 215 at 238; Poseidon Ltd v Adelaide Petroleum NL (1991) 105 ALR 25 at 33). In the present case, Hytera’s intention was to take the benefit of Motorola’s copyright works and it may be inferred that effect was given to that intention by the parts which were copied.

88 In its written submissions dated 28 November 2025, Hytera submitted that an animus furandi is not a relevant consideration under Australian law in assessing the question of substantial part. Hytera advanced three arguments in support of that submission. First, the text, context and purpose of the Copyright Act make it clear that the question of substantial part involves an objective inquiry, which does not involve any element of intention or purpose on the part of the alleged infringer. Second, the Australian authorities suggest that the relevance of animus furandi is at best unclear. Third, English authorities have concluded that an animus furandi is irrelevant to copyright infringement. In relation to the English authorities, Hytera relied upon the following statements of Lloyd LJ in Baigent v Random House Group Ltd (2007) 72 IPR 195 (Baigent):

[96]     Breach of copyright does not depend on intention or knowledge (though these may be relevant in some cases to remedy), under s 97 of the Copyright, Designs and Patents Act. The idea of animus furandi is referred to by Sir James Page-Wood VC in Jarrold v Houlston (1857) 3 K & J 708, but the law was very different then, and the principal issue, apart from whether there had been any copying (which was found, in face of a denial), was whether the use made had been fair or not. In Ravenscroft v Herbert & New English Library [1980] RPC 193, Brightman J referred to animus furandi as being relevant to the question whether a part taken is a substantial part, meaning thereby an intention on the copier’s part to take material from the copyright work in order to save himself labour: see RPC 203 at lines 42–5 (recording the submissions of Mr Laddie for the defendants), and at RPC 207 at lines 27–9.

[97]     Whatever may have been the state of the law at the time of Jarrold v Houlston, the question now is whether there has been copying, not what the intention of the copier was in doing it. If the alleged infringer denies copying, and is disbelieved, then what matters is the finding of fact as to copying which follows, though no doubt his being disbelieved may also have other forensic effects as to the findings made by the judge in the case. I cannot see how the intention with which any copying was done is or can be legally relevant to the issue whether the copying is an infringement, either generally or by reference to the question whether what was copied is a substantial part of the copyright work. Mr Rayner James submitted that a wrongful denial of copying can and should assist the court in concluding that what has been copied is of value and is therefore likely to represent a substantial part of the effort of the author in producing the copyright work. I disagree. That seems to me to be as a misleading a rhetorical device as the proposition that if something is worth copying, it is worth protecting, and should therefore be found to be a substantial part of the work from which it is taken. It seems to me that animus furandi is a red herring in modern English copyright law, and that it should not be invoked in future.

[98]     We were referred to recent decisions in Australia and Canada in which the point has been mentioned. Neither of those seem to me to lead to any different conclusion as to its possible relevance.

89 For the reasons that follow, we accept Motorola’s submission that animus furandi remains a relevant consideration in assessing whether a substantial part of a work has been copied, as the principle has been explained in the authorities. The translation of the phrase as an “intention to steal” does not capture the proper meaning of the principle. Rather, the principle is that evidence concerning the extent to which the impugned copying has saved the respondent labour in creating its own work is relevant to an evaluation of whether the impugned copying is a substantial part of the copied work.

90 The relevance of evidence of an animus furandi was explained by Sir James Page-Wood VC in Jarrold v Houlston (1857) 3 K & J 708 at 716-7:

The question I really have to try is whether the use that in this case has been made of the Plaintiffs' book has gone beyond a fair use. Now, for trying that question, several tests have been laid down. One which was originally expressed, I think by a Common Law Judge, and was adopted by Lord Langdale in Lewis v. Fullarton, is, whether you find on the part of the Defendant an animus furandi – an intention to take for the purpose of saving himself labour. I take the illegitimate use, as opposed to the legitimate use, of another man's work on subject-matters of this description to be this: If, knowing that a person whose work is protected by copyright has, with considerable labour, compiled from various sources a work in itself not original, but which he has digested and arranged, you, being minded to compile a work of a like description, instead of taking the pains of searching into all the common sources, and obtaining your subject-matter from them, avail yourself of the labour of your predecessor, adopt his arrangements, adopt moreover the very questions he has asked, or adopt them with but a slight degree of colorable variation, and thus save yourself pains and labour by availing yourself of the pains and labour which he has employed, that I take to be an illegitimate use.

91 In Ravenscroft v Herbert & New English Library Ltd [1980] RPC 193, Brightman J considered that there are four principal matters to be taken into account in deciding whether copying is substantial (at 203):

First, the volume of the material taken, bearing in mind that quality is more important than quantity; secondly, how much of such material is the subject matter of copyright and how much is not; thirdly, whether there has been an animus furandi on the part of the defendant; this was treated by Page-Wood VC in Jarrold v Houlston (1857) 3 K & J 708; 69 ER 1294 as equivalent to an intention on the part of the defendant to take for the purpose of saving himself labour; fourthly, the extent to which the plaintiffs and the defendant's books are competing works.

92 The foregoing passage was referred to with approval by von Doussa J in Milpurrurru v Indofurn Pty Ltd (1994) 54 FCR 240 (Milpurrurru) at 260. His Honour concluded (at 261) that the most important consideration in that case was:

… the existence of an ‘animus furandi’ on the part of the designers of the carpets, that is to say an intention on the part of these people to take from the Wititj artwork for the purpose of saving themselves labour … The complex parts of the design and artwork in the tail and body colouring was copied exactly to form the predominant feature of the carpet.

93 In IceTV, Gummow, Hayne and Heydon JJ concluded that it was important to ask whether the infringer acted with animus furandi, to take from the copyright work in order to save itself from effort on its part (at [171], citing Milpurrurru). In contrast, French CJ, Crennan and Kiefel JJ, having concluded that the information that was copied was not sufficiently original (including because the skill and labour required to express the information was minimal), found that it was unnecessary to consider the relevance of any animus furandi on the part of the alleged infringer (at [55]). In the course of their judgment, their Honours referenced the statement of Lloyd LJ in Baigent at [97], reproduced above, on two occasions. On the first occasion (at [31]), their Honours acknowledged the caution expressed by Lloyd LJ about the aphorism: “if something is worth copying, it is worth protecting”. On the second occasion (at [55]), their Honours contrasted the statement of Lloyd LJ concerning animus furandi with the conclusion  expressed by Gummow, Hayne and Heydon JJ.

94 In Seafolly Pty Ltd v Fewstone Pty Ltd [2014] FCA 321; 313 ALR 41, Dodds-Streeton J observed (at [254]) that the judgments of the High Court in IceTV might be viewed as being consistent with the High Court’s maintenance of the traditional position concerning the relevance of an animus furandi, but on another view might be thought to indicate a division of opinion. Her Honour concluded (at [354]):

In the present case, animus furandi was also established. I am satisfied that City Beach intended to make use of the Seafolly artwork in order to produce its own design and when confronted with the clear risk that the magnitude of taking had exceeded any lawful use, did not hesitate to cross that line rather than accept alterations which would diminish or negate the similarity. While I do not accept that animus furandi is irrelevant to substantiality, its relevance is no longer uniformly upheld. Animus furandi is unnecessary to, but fortifies, my conclusion that City Beach took a substantial part of Seafolly’s copyright in the English Rose artwork.

95 In Career Step, LLC v Talentmed Pty Ltd [2018] FCA 132; 354 ALR 300, Robertson J found (at [148]) that the fact that the respondent copied parts of the works for the purpose of saving itself labour fortified his Honour’s conclusion that the respondent took a substantial part of the applicant’s copyright in the work.  The respondent’s evidence was that it would have taken significantly longer to develop the respondent’s work if it had not used the applicant’s work.

96 The weight of authority supports a conclusion that, in assessing whether the part of a work that was copied is a substantial part, evidence of the extent to which the impugned copying has saved the respondent labour in creating its own work is relevant and admissible. Such evidence is logically probative of the degree of originality in the part of the work that was copied; the greater the need for the respondent to copy to create its own work, and the greater the labour saved by the respondent in copying to create its own work, are both suggestive of a higher degree of originality in the part of the work that was copied.

97 In the present case, the primary judge made extensive findings concerning Hytera’s need to copy Motorola’s source code and the labour saved by Hytera in doing so. Those findings include the following:

(a)    Motorola began work on a DMR project in earnest in 2003 (PJ [767]). The software development for this project was called the ‘Matrix’ project (PJ [767]). The development of the Matrix software continued until February 2007 (PJ [768]). Motorola began selling its DMR devices in the United States and Canada in the first quarter of 2007 (PJ [768]).

(b)    Hytera was also seeking to develop a DMR device from about 2005 (PJ [770]). By September 2007, Hytera’s development of a DMR device had proceeded as far as the creation of a prototype (PJ [770]). However, by the end of 2007,  the DMR project was confronted with two significant problems: the first was that it was going to result in a product which would not be competitive with Motorola’s device; and the second was that that product would take at least until the end of 2009 before the process of commercialisation could begin, which meant that a product launch would not occur before the middle of 2011 (PJ [931]). By the end of 2007, Hytera’s development of its DMR device was in disarray (PJ [931]). Hytera had wasted three years getting to that position and its competitor, Motorola, was already in the market (PJ [939]).

(c)    The President and Chief Executive Officer of Hytera, Mr Chen, recruited Mr GS Kok from Motorola, commencing mid-February 2008 (PJ [942], [945], [950]). Mr GS Kok was a senior employee within Motorola on the Matrix project (PJ [944]). At Hytera, Mr GS Kok was put in charge of the DMR team (PJ [948], [1990(a)]). Very soon after his arrival at Hytera, Mr GS Kok provided Mr Chen with a negative assessment of the state of Hytera’s DMR project and proposed the recruitment of additional engineers from Motorola who had worked on the Matrix project (PJ [950], [951], [952]). Over the ensuing months, Mr GS Kok recruited 12 engineers from Motorola (PJ [955]-[963]). Mr GS Kok and certain of the other ex-Motorola engineers brought with them to Hytera, without authorisation from Motorola, Motorola documents and computer code relating to Motorola’s DMR device (PJ [964]).

(d)    The ex-Motorola engineers brought with them to Hytera all of Motorola’s source code for the Mobile and Portable Firmware and the DSP Firmware for the purpose of copying -  to provide themselves with a resource for the purposes of writing Hytera’s source code for its DMR device (PJ [1538]). This was a substantial industrial theft (PJ [5]). The engineers engaged in industrial scale harvesting of Motorola’s source code and set out to make this as difficult to detect as possible (PJ [1576]).

(e)    The Hytera DMR devices were brought to market in March 2010 (PJ [953]). Hytera benefitted from the actions of the ex-Motorola engineers in at least two ways: first, it got to market with devices which were commercially competitive with Motorola’s products where otherwise it would not have done so; and second, it got to market by at least 15 months earlier than it otherwise would have (PJ [1992]).

98 Later in these reasons we conclude that the evidence establishes that Hytera copied a substantial part of the Motorola Works, without taking into account the above evidence concerning the labour saved by Hytera in its copying.  However, the above evidence concerning Hytera’s need to copy Motorola’s source code and the labour saved in doing so reinforces that conclusion.

PART B: OVERARCHING SUBMISSIONS

B.1    Overview

99 On this second phase of the appeal, Hytera advanced five principal submissions in defence of Motorola’s claim that the Motorola source code copied by Hytera (into the impugned Hytera source code) was a substantial part of one or more of the Motorola Works. These overarching submissions apply to all of the copied code and all of the Motorola Works. The submissions lie at the heart of the dispute between the parties. To a large extent, the submissions also explain the differences in opinion of the Hytera expert witnesses on the one hand and the Motorola expert witnesses on the other. It is therefore appropriate to address the overarching submissions at the outset, before turning to each of the specific Motorola Works. By way of overview, the five submissions were as follows.

100 First, Hytera submitted that it is necessary for the Court to identify the relevant creative and intellectual effort that gives rise to the originality in the Motorola Works on the findings made by the primary judge and this Court, being the creative and intellectual effort directed to adapting the antecedent source code for use in Motorola’s DMR devices. By this submission, Hytera sought to re-enliven, and re-purpose, a submission advanced during the first phase of the appeal: that insofar as Motorola’s source code had been copied by Motorola from its own antecedent computer programs, the code would lack originality for the purposes of infringement. The submission advanced during the first phase of the appeal was rejected in the appeal judgment.

101 Second, Hytera submitted that, in assessing whether the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works, it is necessary to have regard to the factual findings made by the primary judge as to how the code expresses the functions sought to be performed by the devices in which it is installed. Hytera argued that, although this Court found that the primary judge erred in his approach to the assessment of substantial part, his Honour’s underlying factual findings were not challenged by Motorola and have not been overturned by this Court and therefore cannot be ignored.

102 Third, Hytera submitted that, where the parts taken of a computer program are header files (or parts thereof), to assess the originality of what was taken, the relevant source files (into which the header files were included) need to be considered. Without an understanding of the relevant source files, the Court cannot assess the extent to which the code found to have been taken is relevant to the “structure, choice of commands and combination and sequencing of the commands in source code”.

103 Fourth, Hytera submitted that Motorola’s reliance on the “architecture” and “framework” of the Motorola Works, which it contends was copied by Hytera, does not reflect the approach to the assessment of infringement discussed in the appeal judgment which requires an identification of the particular form of expression in the code, including such matters as the structure of the code and the choice and sequencing of commands.

104 Fifth, while acknowledging that the question whether the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works involves a qualitative assessment, Hytera submitted that quantity is nevertheless relevant and that the quantity of the code copied from the Motorola Works “is a relatively small part of Motorola’s overall DMR technology” (citing the finding of the primary judge at PJ [2067]).

105 Each of those submissions will be considered in turn.

B.2    Antecedent works submission

Hytera’s submissions

106 Hytera argued that Motorola’s “pleaded case” relied solely upon software alleged to have been developed in the period from approximately 2003 to 2007 in Motorola’s Matrix project. Matrix was the internal codename for Motorola’s DMR project. Work on the Matrix project began in 2003, with development of the first release of the Matrix software continuing until approximately February 2007: PJ [767]-[768]. Hytera argued that Motorola did not rely on work conducted prior to 2003 on other projects or products as forming part of the development of the Motorola Works, and it was not open to Motorola to do so. Hytera submitted that, as a result, “care is required when engaging with Motorola’s affidavit evidence concerning the development of its source code”. As an illustration, Hytera referred to Mr Ley’s evidence concerning the development of the Darwin Ergonomics Platform during the approximate period 1994/1995 to 2000/2001 for use in Motorola’s ‘Astro’ products. Hytera observed that the platform to which Mr Ley referred in that context is not the Darwin Ergonomics Platform, which is one of the Motorola Works, but an antecedent software program from which the Motorola Work was later developed.

107 Hytera submitted that, in advancing the above argument, it is not seeking to reopen or cavil with this Court’s rejection of its previous “antecedent source code” argument: that the Motorola Works copied by Hytera lacked originality by reason of the fact that they were derived from antecedent source code. Hytera submitted that it was now advancing a different argument: that in assessing whether the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works, it is necessary to consider the originality with which the copied parts of the source code express the functions sought to be performed by the computer or device. Hytera argued that this must be based on evidence relating to the process which the primary judge and this Court held gave rise to originality in the Motorola Works – the careful revision, review and adaptation of the antecedent source code for use in Motorola’s DMR devices.  Hytera argued that, as a consequence, the relevant intellectual and creative effort for consideration is the adaptation of the code for use in the DMR devices by the software engineers involved in the Matrix project, in the period from approximately 2003 to 2007.

108 Hytera submitted that, for the most part, Motorola’s evidence does not identify how the creative and intellectual effort directed to adapting Motorola’s antecedent code for use in the DMR devices is reflected in the particular form of expression of the functions of the code. Hytera submitted that Motorola’s lay and expert evidence largely concerned the creative and intellectual effort involved in the design and development of the antecedent works. The evidence of creative and intellectual effort directed to adapting the code for use in the DMR devices is largely expressed at a level of generality and does not engage with the expression of the code, let alone identify creative and intellectual effort expended in adapting the copied parts of the code. Hytera argued that there is limited evidence of specific modifications made to the copied code in the course of the Matrix project during the period in which the Motorola Works (as pleaded) are said to have been developed (i.e. 2003 to 2007).

109 On the basis of the foregoing submissions, Hytera placed considerable emphasis on the absence of evidence of modifications having been made by Motorola, during the period 2003 to 2007, to the computer files from which code was copied. Hytera noted that Motorola utilised a software revision control system called Rational ClearCase up to and including the period of the Matrix project. The system provided information concerning revisions to a computer file made over time, back to the file’s original date of creation. However, ClearCase records were in evidence for only one of the copied Motorola files, being com_cp_button_def.h (Hytera’s application for discovery of corresponding records for the remainder of the files in issue in the proceeding was dismissed: Motorola Solutions, Inc. v Hytera Communications Corporation Ltd (Discovery) [2019] FCA 1887; 150 IPR 1). Hytera submitted that the ClearCase records for the file com_cp_button_def.h demonstrate that: (i) the file was first added to ClearCase on 16 July 1997, which is more than 5 years before the Matrix project began; and (ii) the particular version of the file included in the Motorola Works (the “main/8” version) was created on 18 October 2000, which is more than two years before the Matrix project began. Hytera submitted that this affords evidence that an existing version of the file was simply adopted for use in the Matrix project without modification. In the absence of ClearCase records for the other computer files from which code was copied, Hytera relied upon data drawn from print outs of the copied files (where available) such as “date of origin” or “creation”. Hytera submitted that there are a total of 130 computer files from which code was found to have been copied and that, for 94 of those 130 files, there is no specific evidence of modifications made to the copied code during the period in which the Motorola Works are said to have been developed (i.e. 2003 to 2007). For some of those 94 files there is some evidence of modifications expressed at a level of generality. As Hytera acknowledged, Motorola witnesses gave evidence of their belief that computer files were modified during the Matrix project, even if the fact of modification was not notated in the revision history within the computer file.

Consideration

110 We reject Hytera’s antecedent works submission, particularly in so far as the submission seeks to diminish the relevance of Motorola’s evidence concerning the creation of the antecedent works and the incorporation of the antecedent works in the Matrix project to create the Motorola Works.

111 Motorola’s reliance on evidence, adduced at trial, concerning the creation of the antecedent works is not constrained by its pleading. There is no indication in the primary judgment that Hytera advanced this pleading argument at trial and it should not be permitted to advance such an argument on appeal. In its pleading, Motorola referred to the creation of the Motorola Works, in the period between 2003 and 2007, in the context of subsistence of copyright (at para 2(a) of its second further amended particulars of copyright claim). Hytera ultimately admitted subsistence. Motorola’s infringement allegations, and specifically its allegation that Hytera’s DMR devices contained an adaptation of a substantial part of one or more of the Motorola Works (para 31D of the third further amended statement of claim), particularised the computer files that were allegedly copied but not the allegation of substantial part. Accordingly, Motorola’s pleading did not constrain Motorola’s evidence relevant to the question of the substantiality of the copied code. Motorola adduced considerable evidence at trial concerning the intellectual and creative effort involved in creating the antecedent works that were adapted for use in Motorola’s DMR devices being developed during the Matrix project, and that evidence was considered by the primary judge. We consider that all of that evidence is properly before this Court on the appeal.

112 As to the issues of principle that underlie Hytera’s antecedent works submission, the applicable principles were stated in the appeal judgment. Contrary to Hytera’s protestations, much of its antecedent works submission in the second phase of the appeal seeks to revisit arguments that were rejected by this Court in the appeal judgment. Hytera continues to place reliance upon, and to seek to analogise from, cases that involve facts that are not analogous to the facts of this case. Given Hytera’s submission, it is necessary to repeat certain matters that were considered in the appeal judgment.

113 Before the primary judge, and in the first phase of the appeal, Hytera contended that Motorola had to demonstrate that each part of the source code which it alleged had been copied by Hytera was original in the sense of not having been copied from elsewhere and, in particular, not copied from earlier iterations of the same source code (PJ [1173(b)] and AJ [717], [747]). That argument was rejected by both the primary judge and this Court (AJ [725]-[753]). As stated by this Court, the flaw in Hytera’s contention is to assert that the copied parts of the Motorola Works that had been drawn from earlier Motorola software necessarily lacked originality for the purposes of assessing whether those parts were a substantial part of the Motorola Works (AJ [747]).

114 In this second phase of the appeal, Hytera has modified its antecedent works submission: it now contends that the copied parts of the Motorola Works that had been drawn from earlier Motorola software have some lesser originality for the purposes of assessing whether those parts were a substantial part of the Motorola Works. Much of Hytera’s antecedent works submission in this second phase of the appeal is based upon a distorted reading of the appeal judgment at [748] and [749] and the factual findings of the primary judge at PJ [1253]-[1255] which were reproduced in the appeal judgment at [751]. It is convenient to reproduce those passages from the appeal judgment:

748     The principles elucidated in Ladbroke, Data Access and IceTV recognise that, within a work in which copyright subsists, different parts of the work may have different degrees of originality. The assessment of whether a part of the work that is copied is a substantial part for the purposes of the Copyright Act will be affected by the degree of originality in that part. At one end of the spectrum are copyright works that consist of a compilation of information, in respect of which (typically) there is no originality (and indeed no copyright) in the information that is compiled, and where the originality only resides in the form of compilation. In such a case, the copying of the information, but not the form of compilation, will not infringe copyright. At the other end of the spectrum are works that might be described as wholly original (whilst recognising that the vast majority of works have elements that are derivative of other work). When assessing, in such cases, whether a part of the work that is copied is a substantial part, it remains relevant to consider the degree of originality in that part; however, as explained in Data Access, originality of the part copied is assessed by reference to the essential or material features of the copyright work.

749     In that context, we respectfully agree with the primary judge that, where a work has been created, in part, from a pre-existing work, two situations may be usefully distinguished from each other: the first is a work which reproduces extracts from another work (such as an anthology); and the second is a work which builds on earlier versions of itself (PJ [1234]). In respect of the former, if the part copied did not originate with the author of the anthology, it will not be a substantial part (PJ [1235], citing IceTV at [37]). In the case of the latter, provided the relevant version of the work involved sufficient intellectual and/or creative effort in reviewing and revising the work, the whole of the work will be an original work (PJ [1236]-[1243], citing JR Consulting). That is not to suggest, in the case of a work which builds on earlier versions of itself, that the question of originality of the part copied has no relevance to the assessment of whether the part copied is a substantial part of the work. As explained by French CJ, Crennan and Kiefel JJ in IceTV, originality in the context of infringement has a broader aspect (at [38]); it is necessary to consider the degree of originality in the expression of the part of the work reproduced (at [40]). It does mean, though, that Hytera’s contention must be rejected. Contrary to Hytera’s contention, in the case of a work that builds on earlier versions of itself, it is not necessary for the copyright owner to show that the parts of the work which were copied were original in the sense of not having been copied from earlier iterations of the work developed by the author over time. The primary judge was correct to conclude (at [1250]) that, where successive updates of software are released and originality is conceded for the purposes of subsistence, an argument for infringement purposes that a substantial part of a particular version of the software has been taken is not defeated by showing that the part in question derives from antecedent code.

…

751     Although the questions of subsistence and infringement are separate questions, the authorities discussed above explain that they are related through the concept of originality. The nature of the copyright work and the features and characteristics of the work that support a conclusion that the work is original for the purposes of subsistence of copyright are relevant to the assessment of infringement, particularly in the context of assessing whether a substantial part of a work has been copied. For that reason, evidence concerning the making of the work has relevance to the overall assessment of originality both on the question of subsistence and the question of infringement. In the present case, the primary judge observed that Motorola led a great deal of evidence about the manner in which the Motorola Works were made, which evidence was directed at meeting Hytera’s initial non-admission that copyright subsisted in the Motorola Works (PJ [1251]). At trial, Hytera abandoned that defence and admitted subsistence. Given the admission, his Honour expressed his findings with respect to the making of the Motorola Works in relatively brief terms, but which are nonetheless significant (at [1253]-[1255]):

In fact, the 11 works are not merely the result of review and revision of earlier code. The 11 works in suit were part of the Matrix DMR project which began in 2003. Motorola had not manufactured DMRs before then and the Matrix program was designed to provide an advance over its existing analogue models. The 2005 DMR Standard was published two years before Motorola’s devices came to market in early 2007. As such, the three sets of firmware (the Mobile Firmware, the Portable Firmware and the DSP Firmware) were an attempt to create an entirely new product range. As the reasoning above in relation to the patents in suit demonstrates, the creation of a system which gave effect to the kind of two timeslot TDMA system that the 2005 DMR Standard required was no simple undertaking. The difficulties it presented are significantly underscored, in my opinion, by the failure of the Hytera DMR program to surmount them.

On the other hand, it may readily be accepted that much of what was contained in the software developed under the Matrix program was not brand new. Motorola had made radios before and it is evident that it did not begin its development of the firmware from scratch. For example, it had had to deal with the interface between the user and the device before so this was not a new problem. The Darwin Ergonomics Platform was not new when it was introduced into the DMR devices since it had been used in analogue devices. But neither was it the same. It had to be adapted to work in a new operating environment. It was not simply a case of copying the platform over without any changes. Indeed, the process of development took nearly four years. Hundreds of computer engineers worked on it.

In that circumstance, I do not hesitate to conclude that the 11 works are themselves substantial original works. Whilst it is true that earlier code was reused, a better description would be to say that it was adapted to the new devices. As such, it clearly meets the requirement for careful revision and review flowing from JR Consulting. No doubt, this is why Hytera did not ultimately contest the originality of the 11 works from the standpoint of subsistence.

115 After referring to the above passages, Hytera submitted that “the originality of the 11 Motorola Works lies in the careful revision and review of the code, in particular the adaptation of the code for use in new devices and to work in a new operating environment – as distinct from simply copying the code across without making any changes”. That submission seeks to analogise the facts of this case to a work that comprises a compilation of information  (such as Ladbroke and IceTV) or a work that comprises an anthology. That is the antithesis of the factual findings made by the primary judge and the antithesis of this Court’s reasons as set out in the passages reproduced above.

116 In the present case, the Motorola Works are computer programs each comprising a suite of computer files, which programs were derived from earlier versions of original computer programs created by Motorola. As found by the primary judge, much of what was contained in the software developed under the Matrix project was not brand new. The Darwin Ergonomics Platform was not new when it was introduced into the DMR devices since it had been used in Motorola’s earlier analogue radio devices. But neither was it the same: it had to be adapted to work in a new operating environment. Motorola had not previously manufactured DMRs and the Matrix program was designed to provide an advance over its existing analogue models. The three sets of firmware (the Mobile Firmware, the Portable Firmware and the DSP Firmware) involved the creation of an entirely new product range. The process of development took nearly four years. Hundreds of computer engineers worked on it.

117 In that factual context, the whole of each Motorola Work is an original work for the purposes of both copyright subsistence and infringement. It is not necessary for Motorola to show that the parts of the works which were copied (being parts of computer files within the computer programs that constitute the works) were original in the sense of not having been copied from earlier iterations of computer programs developed by it over time. To reiterate, this Court has rejected Hytera’s contention that the copied parts of the Motorola Works that had been drawn from earlier Motorola software necessarily lacked originality for the purposes of assessing whether those parts were a substantial part of the Motorola Works.

118 Nor is it the case that, because a computer file within a Motorola Work was created prior to the Matrix project and was then reused within the DMR devices, it necessarily has some undefined lesser originality than software modifications that were made during the Matrix project. For the purposes of both subsistence and infringement, the assessment of the originality, or the degree of originality, of any part of the code is not confined to the effort in reviewing the code and deciding to use it with or without modification. As stated by the plurality in Data Access (at 85), the originality of a computer program must be assessed by reference to the originality with which the computer code expresses the functions to be performed by the computer or device, which includes the structure of the code, the choice of commands and the combination and sequencing of commands. The originality of the form of expression of the computer code does not reduce merely because the code has been reused in a different product.

119 Having conceded that the Motorola Works are original works for the purposes of subsistence of copyright, the assessment of whether the copied code is a substantial part of any of the works simply requires consideration of the originality of the copied code in the manner explained by the plurality in Data Access. Contrary to Hytera’s submission, the evidence that is relevant to that assessment is not limited to evidence of the creative and intellectual effort in reviewing and revising the antecedent work. Relevant evidence includes the creative and intellectual effort in making the antecedent work. It is the combination of the creative and intellectual effort in making the antecedent work, and deciding whether and how it will be used in the Motorola Works, which bears upon the assessment of its originality for the purposes of infringement.

B.3    The findings made by the primary judge with respect to ‘functional materiality’

Hytera’s submissions

120 Hytera submitted that, while this Court concluded that the primary judge erred in his approach to substantial part (AJ [806]), it does not follow that all of the findings of fact made by the primary judge with respect to the functionality of the copied code should be disregarded. Hytera submitted that, in assessing whether the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works, it is necessary to have regard to the factual findings made by the primary judge as to how the code expresses the functions sought to be performed by the devices in which it is installed.

121 Using the Motorola file cor_emt_user_defines.h from the EMT as an illustration, Hytera submitted that the primary judge made a number of findings as to how the copied code expresses functions sought to be performed by the DMR devices (at PJ [1341]-[1363]), but concluded that there was insufficient evidence to understand the importance or significance of that code. Hytera submitted that, although the primary judge erred by failing to consider whether all of the code found to have been copied from EMT collectively constituted a substantial part of the relevant work, the findings made in respect of each file from within the EMT are relevant to the significance of the copied code when considered collectively. Hytera argued that all of the findings made by the primary judge ought to be considered along with the evidence the primary judge failed properly to have regard to as to the significance of the code (as found by this Court at AJ [805]).

Consideration

122 In the second phase of the appeal, both parties were guilty of attempting to ‘cherry-pick’ findings made by the primary judge that they considered were favourable to their respective cases on infringement, but without proper regard to the conclusions reached by this Court in the appeal judgment.

123 This Court concluded that the primary judge’s approach to the assessment of whether the impugned Hytera source code was a copy of a substantial part of the Motorola Works was affected by error, which was summarised as follows (at AJ [914]):

(a)    The primary judge was in error to approach the question of infringement by considering whether small segments of Hytera source code which had been copied from a Motorola Work formed a substantial part of the relevant Motorola Work. The question to be determined was whether, in respect of each of the Motorola Works, the totality of the Motorola source code copied by Hytera (into the impugned Hytera source code) was a substantial part of the Motorola Work.

(b)    The primary judge erred in two respects in his approach to the assessment of the substantiality of the copied code. First, his Honour incorrectly applied two tests or conditions for the assessment, being materiality and originality, when there is only one question to be answered. Second, his Honour applied a test of whether the copied code was functionally material to the relevant Motorola Work in the sense of being significant or important to the operation of the DMR.  The question of substantial part is to be determined by reference to the originality of the code that has been copied, which requires consideration of the creative and intellectual contribution to the form of expression of the code, including such matters as the structure of the code and the choice and sequencing of commands.

(c)    By reason of adopting an erroneous approach to the assessment of substantial part, the primary judge necessarily failed properly to have regard to the evidence of Motorola’s witnesses as to the significance of the copied code as a whole to each of the Motorola Works.

124 The errors in the approach adopted by the primary judge necessarily mean that this Court must be circumspect in relying upon the findings of the primary judge with respect to each segment of copied code within each computer file. Not only is the approach of atomising each segment of copied code incorrect, but his Honour examined the question of substantial part through an incorrect lens (the functional materiality of the code in the sense of the significance of the code to the operation of the DMR). As we stated in the appeal judgment at AJ [788]:

… for most of the segments of impugned Hytera source code, his Honour concluded that the evidence was insufficient to enable him to understand the significance of the particular segment of code to the operation of the relevant Motorola Work, and therefore insufficient to persuade him that the segment of code was material. For some of the segments, his Honour also expressly concluded that, because he was not satisfied that the segment was material, it was unnecessary to reach a view on whether the segment was original. More often than not, having concluded that the segment was not material, his Honour made no express reference to originality.

125 Taking the Motorola file cor_emt_user_defines.h from the EMT as the illustration, as proposed by Hytera, it is apparent that the findings of the primary judge are affected by the errors referred to above. Contrary to Hytera’s submissions, the primary judge did not make findings as to the originality with which the copied code expresses the functions to be performed by the DMR devices; rather, his Honour merely made findings as to the function performed by the code in the operation of the devices. The findings are not entirely irrelevant, but they are not the principal focus of the assessment.

B.4    Header files

Hytera’s submissions

126 To introduce Hytera’s submission concerning header files, it is necessary to refer briefly to the three types of computer files referred to in the Annexure to these reasons: header files, source files and library files. The following descriptions are taken from both the primary judgment and the appeal judgment:

(a)    Most of Motorola’s and Hytera’s source code was written in the C++ programming language (PJ [1149], [1331]). The phrase ‘source code’ refers to software written in a computer language that is comprehensible to humans (PJ [1148]).

(b)    The phrase ‘object code’ refers to software that has been converted from source code into binary code (a code that only uses the digits 0 and 1) in the form of commands and operations that can be executed by a processor within a computer or device (PJ [1147]). For that reason, ‘object code’ is often referred to as ‘machine readable code’. The process of converting source code into object code is referred to as “compilation” (PJ [1148]). When source code is compiled into object code, the object code is combined into files known as ‘library files’ (PJ [1273]).

(c)    When software is written in the C++ language, it is common to split the code between ‘header’ files (files with the suffix ‘.h’) and ‘source’ files (files with the suffix ‘.c’) (PJ [1331]). Although not expressly stated by the primary judge, the evidence established that ‘source’ files can also have the suffix ‘.cpp’.  The word ‘file’ refers to a segment of source code. A file can take many forms, in that it may comprise data or definitions or it may comprise particular commands or instructions used within the computer program (AJ [606]). As found by the primary judge at PJ [1331]-[1336], header files are used to declare variables (a data item that can take different values) and function prototypes (a definition of certain parameters of a function, identifying the name of the function, the data type the function returns and the parameters or variables the function takes) that can be used in multiple source files (which contain functions) without having to repeat the process of declaration in each file. During the process of compilation, the source file picks up the declarations contained in the relevant header file by means of a command which causes the compiler to do so (by way of an #include statement).

(d)    There are two advantages of splitting the source code into header files and source files: first, it makes the declarations more universally available; and second, it achieves efficiencies when the source code is compiled. When the source code is compiled, the header files are not themselves compiled. Rather they are ‘included’ in source files to make the process of compiling the source files more efficient. The #include statement has the same effect as compiling the code in the header file but without needing to copy the whole of the header file code into the source file.

127 As can be seen from the Annexure to these reasons, many of the computer files from which code was copied by Hytera were header files. Hytera submitted that, where the parts taken of a computer program are header files or parts thereof, to assess the originality of what was taken, the relevant source files (into which the header files were included) need to be considered. Hytera submitted that it is the code in the relevant source files that expresses the algorithmic or logical relationship between the function desired to be performed and the physical capabilities of the DMR devices, rather than the header files. Hytera submitted that, without an understanding of the relevant source files, the Court cannot assess the extent to which the code found to have been taken is relevant to the “structure, choice of commands and combination and sequencing of the commands in source code”.  Hytera submitted that, for the most part, Motorola’s evidence does not link the header files, from which code was copied by Hytera, with the source files in which the header files were used.

128 In support of that submission, Hytera referred to the following evidence given by Prof Wicker:

The header files for a software component such as the Darwin ergonomics platform, or the framerLib library and its Framer and L1 Timer components, contain the fundamental elements of the code that are important and necessary for the software to function. The decisions made by developers in writing the code in the header files permeate the rest of the code for that software component.

129 It is not at all clear how that evidence supports Hytera’s submission. The evidence is to the effect that header files contain the fundamental elements of the code that are important and necessary for the software to function.

130 Hytera also placed reliance on the following statement of the primary judge (at PJ [1343]):

… Motorola made very general submissions about whether header files, in principle, could be a substantial part of a computer code. This analysis is of no use. The question cannot be answered in the abstract. Some header files may be a substantial part of a computer program; others may not. It depends on the header file and the program. Because Motorola did not engage in an analysis of the particular header and source files, it did not equip its submissions usefully to address this question.

131 However, the foregoing statement does not assist Hytera. The statement occurs in a section of the reasons in which the primary judge considered the functional operation of the copied code for the purpose of assessing its ‘materiality’. His Honour’s finding related to the absence of analysis of the importance of the copied code to the functional operation of the DMR devices, which is not the relevant enquiry.

Consideration

132 Hytera’s submissions with respect to header files are based upon, and reflects, the opinions expressed by its experts, Mr Brown and Mr Grimmett.

133 In the Joint Expert Report tendered at trial, the experts summarised their joint opinion with respect to the importance of the copied header files as follows (answers to question 4(c)):

The experts disagree on the importance of header files specifically. The experts agree that, in general, header files are developed in conjunction with other source code and the architecture of the code more generally. But there is disagreement on the relative importance of header files in general, and the importance of the copied header files specifically.

134 Mr Brown then explained the basis of his opinion as follows:

… it is my opinion that header files contain memory structures and interfaces but do not contain any functional code (i.e. do not contain any operations performed by the radio). They define how components use memory and how components interact but do not include any of the operations of the device and as such it is my opinion that they have substantially less significance than the C source code.

135 It is apparent that Mr Brown considered that header files were “substantially less significant” than source files because the header files did not contain “functional code” – code that performed operations on the radio device. Mr Brown expressed the same views in his oral evidence, explaining that he did not consider that header files contained any “verbs” of the radio (transcript p 717, 12 August 2020):

The definition of functional code, the – I’ve been using, I think Mr Grimmett had used the same, is in effect, the verbs [of] the radio. The operations. And when a radio, when any computer program runs, it starts with the first instruction and it operates it. And then it jumps to the next instruction and depending on whether it’s asked to jump off to somewhere else in the code or continue going, it repeats this process. And so those instructions, the things that it actually executes, the verbs [as] Mr Grimmett said[,] in all of the Hytera code, Motorola code we’ve looked at, we haven’t found any verbs in the headers.

Now, we certainly have found code in the headers that may well have an impact on those functional lines, for example, the numbers change. We saw, when you see an email [sic] about a number. Or when you see a memory structure, you’ll see an offset. And that offset into the memory may well change or the size of the memory will be different. But the actual verbs in the operation, the operations of the radio or the functional code, we don’t see that in the header.

136 In the Joint Expert Report, Mr Grimmett explained the basis of his opinion as follows:

Header files in general do not contain functional code, rather they contain function signatures that are duplicative of those written in the functional code. In addition, header files typically define values and variable types used by the functional code.

The specific Motorola header files within the scope of this question would not have required any specialised knowledge of the DMR standard or of any two way radio technology. I believe the header files would have likely been developed in conjunction with the functional code and could have been created by any competent programmer and do not demonstrate any particular creativity or complexity.

137 Mr Grimmett’s focus on whether header files contained “functional code” – code that performed operations on the radio device – is also apparent from his written evidence (in his second affidavit):

163.     A header file may be used to provide definitions and declarations for use by other code. For example, a header file may include “#define” statements that are used by a pre-processor to define constant values or macros that will be expanded prior to compilation of that code. A header file may also include the definition of variable types and structures on which the definition of variables may be based within other, functional source code. Header files may provide signatures for certain functions. On the other hand, a header file does not itself supply those functions, nor does a header file indicate the role performed by the functions to which it refers, or how those functions execute to perform their intended tasks. The functions to which a header file refers are supplied by other parts of the code base.

…

165.     The use of header files may make source code simpler for a software engineer to read. In at least some instances, the use of header files may also make source code simpler for engineers to work with. On the other hand, in my experience, header files are generally of much less importance for the operation of software than the files which supply the functions to which those header files refer.

…

168.     The Accused Motorola Header Files do not themselves supply any of the functionality necessary to the operation of a DMR radio device. Rather, such header files provide definitions and declarations to be utilised by other, operative parts of the software for the radio device. In my opinion, it would be possible to recreate software having the same functionality as each of the Motorola Works without use of any header files.

138 Mr Grimmett expressed the same views in his oral evidence (transcript p 716-7, 12 August 2020):

So what I was explaining by the – the lack of functional code is that code where – where instructions actually execute and perform a task, and – and in general, we don’t find any of that in header files. It’s, again, it’s technically quite possible to write functional code in header files but it’s generally not done. … So all the header file is doing is providing an administrative task to enable [the] compiler to know where certain functions are located. It replaces symbols with actual values, in the case of – actually finds macros. And it provides data structures to be used by the functional code. But those data structures, again in themselves, don’t serve any function. They don’t perform anything without the functional code to go with them. So I still maintain that the header files, whilst they have some use and purpose, they don’t contain functional code.

139 As Motorola submitted, it is apparent that Mr Brown and Mr Grimmett conducted an assessment of the importance of each of the copied header files (i) in isolation and (ii) by reference to the functional significance of the code in that file to the operation of the device. That is not the correct approach to an assessment of whether the totality of the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works. It is an incorrect approach because it involves an analysis of each header file in isolation (indeed, Messrs Brown and Grimmett commented on lines of copied code in isolation). It is also an incorrect approach because it assesses the question of substantial part by reference to the degree to which the code is directly involved in controlling an operation performed by the device – whether the header file, in isolation, causes a significant function to occur on the device.

140 The approach taken by Hytera’s experts, and by Hytera, to the question of copyright infringement of computer software proceeds from an apparent misunderstanding of the High Court’s reasons in Data Access. When the High Court stated that a computer program expresses, either directly or indirectly, an algorithmic or logical relationship between the function desired to be performed and the physical capabilities of the “device having digital information processing capabilities”, the court was not referring to the physical tasks able to be performed by a device which includes digital information processing capabilities (such as a DMR). The High Court was using the language of the Copyright Act (the then definition of ‘computer program’) and was referring to the functions and operations performed by the electrical circuits of the computer (the digital information processing capabilities). The focus of the relevant enquiry is the computer program, and the manner in which it expresses the intended computing functions, not the physical functions of any particular device that may include a digital processor such as a radio.

141 In that context, it is important to return to the High Court’s reasons in Data Access, and particularly the plurality’s explanation of copyright infringement in the context of a computer program. Two initial points should be made.

142 First, at the time of Data Access, the Copyright Act protected computer programs as literary works and defined a computer program as:

… an expression, in any language, code or notation, of a set of instructions (whether with or without related information) intended, either directly or after either or both of the following:

(a)     conversion to another language, code or notation;

(b)     reproduction in a different material form;

to cause a device having digital information processing capabilities to perform a particular function.

143 Understandably, the language of the definition permeates the High Court’s reasons.

144 Second, the principal issues that required determination in Data Access were whether 169 word commands that were used in the Dataflex computer programming language, in and of themselves, were a computer program within the above definition, or whether they were a substantial part of the Dataflex program. The Dataflex program was a computer system which allowed a programmer or developer to develop customised database applications or databases. As is common in computer programming languages, many of the 169 word commands were common English words, and the Dataflex programming language had syntactical rules governing the use of the words. Each of the 169 word commands was an instruction to the computer to process a set of instructions (in source code) associated with the word. The respondent decided to create and market a competing application development system which would be compatible with the Dataflex language and the Dataflex database file structure so that persons who were familiar with the Dataflex system would be able to use the respondent’s new product. The competing system was called PFXplus. For that purpose, the respondent copied 169 word commands that were used in the Dataflex language, and independently wrote source code for those words that would effect the same operations as were effected in the Dataflex system. The result was that persons who were familiar with the Dataflex system could readily use the PFXplus system because it used many of the same word commands. Significantly, however, the respondent did not copy any of the source code instructions used in the Dataflex system; the respondent only copied the words that were used to instruct the computer to process the source code associated with the word.

145 The High Court concluded that the word commands copied by the respondent were not a computer program because each was a single word and none was a set of instructions in the Dataflex language; as such, none of the words expressed, directly or indirectly, an algorithmic or logical relationship between the function desired to be performed and the physical capabilities of the computer (at [28]). The High Court also concluded that the collocation of the word commands did not constitute a substantial part of the computer program that was the Dataflex system (at [92]).

146 In explaining its conclusion, the plurality observed that, at the physical level, a computer operates by receiving instructions into its electronic circuits. The plurality adopted the following description of a computer system given by the Full Court in that case (at [35]):

A computer system consists of hardware and software. The hardware includes a central processing unit which contains the electronic circuits which control the computer and perform the relatively simple arithmetical calculations and logical operations (ie comparing values to determine which is larger) of which the computer is capable. It is because the computer is able to perform millions of such operations each second that computers may be used to perform extremely complex calculations and functions.

147 The plurality continued (at [36]):

… In order for the simple logical functions of a computer to translate into a useful result, it is necessary to express complex problems in terms of a sequence of a large number of these simple operations. 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. No doubt it is very rare to express a complex computer program in terms of the simple logical operations which are hard wired into a computer. That is because the process of writing programs becomes practically unmanageable unless the “set of instructions” is 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.

148 A computer functions because the instructions contained within a computer program are able to be translated and expressed as a sequence of operations within the electrical circuits of the computer. The skill associated with writing a computer program, the creative and intellectual effort, was described by the plurality in the following terms (at [54] and [58]):

It is the particular selection, ordering, combination and arrangement of instructions within a computer program which provide its expression. A computer program in a particular language may be relatively inefficient because it uses many instructions to achieve the function that a single instruction could achieve. A computer program in a particular language may also operate relatively inefficiently because of the way it is structured, in terms of the ordering of the instructions and the sequence in which they are executed. Considerations of efficiency are largely a function of the particular language which is used. It is the skill of the programmer in a particular language which determines the expression of the program in that language.

…

It is the ability to express in a computer language an algorithmic or logical relationship between an identifiable function which is desired to be performed and the physical capabilities of the computer, which is the true skill of the programmer. This remains true even if the programmer is working via the medium of a high level language and is unaware of the physical capabilities of the computer. It is the expression of this skill which is intended to be protected by the Act.

149 Having determined that the 169 word commands copied by the respondent were not a computer program, the High Court considered whether the 169 word commands were a substantial part of the Dataflex computer program. It was in that context that the plurality explained (at [84] and [85]) that:

(a)    in determining whether the quality of what is copied makes it a substantial part of the copyright work, it is important to inquire into the importance which the copied portion bears in relation to the work as a whole;

(b)    in the context of copyright law, where emphasis is to be placed upon the originality of the work’s expression, this should be ascertained by considering the originality of the part allegedly taken;

(c)    because a computer program expresses, either directly or indirectly, an algorithmic or logical relationship between the function desired to be performed and the physical capabilities of the computer, the originality of what was allegedly taken must be assessed with respect to the originality with which it expresses that algorithmic or logical relationship; and

(d)    the structure of what was allegedly taken, its choice of commands, and its combination and sequencing of commands, when compared, at the same level of abstraction, with the original, would all be relevant to this inquiry.

150 For the purposes of assessing copyright infringement, we reject the emphasis given by the Hytera experts to the distinction between “definitional” code (header files) and “functional” code (source files), and the opinion expressed by those experts that header files are of lesser significance than source files when assessing copyright infringement. As the evidence demonstrates, the computer programs constituting the Motorola Works required both header files and source files to function – to perform operations within the circuits comprising the computer processing units. In the C++ computer language, the separation of computer code into header files and source files was a common method of writing the relevant software. All of the experts agreed that source files and header files are designed in conjunction with each other (Mr Brown at transcript pp 703 and 705, 12 August 2020; Mr Grimmett at transcript p 709, 12 August 2020; Prof Wicker’s second affidavit at [111]). As found by the primary judge, during the process of compilation, the source file picks up the declarations contained in the relevant header file by means of a command which causes the compiler to do so.  As also found by the primary judge, there are advantages of splitting the source code into header files and source files: first, it makes the declarations more universally available; and second, it achieves efficiencies when the source code is compiled.

151 It is significant that, when questioned by the primary judge, Mr Brown accepted that both source files and header files would need to be designed carefully, that the structure of them has to be carefully thought about, and that their design requires creativity. The following exchange occurred (transcript p 722, 12 August 2020):

HIS HONOUR: I was wondering whether, in terms of the – and I think what you were saying was that there’s more originality in the executable instructions than there is in the data which might be stored in a ....[header] file.

MR BROWN: I think there’s – there’s – in the way of both, you – you need to design both carefully, and so certainly it’s – I made the distinction that the verbs are not in the header, but – but no, the – the data structure design in general has to be carefully thought about, especially in .....

HIS HONOUR: Yes, all right. So just because – you’re not saying that just because it has just data in the header files or the definition of variables, you’re not saying that necessarily means that there’s a lack of creativity or originality involved in that process.

MR BROWN: Certainly.

HIS HONOUR: Okay.

MR BROWN: Yes ... there is a level of creativity when designing data structure. Now, to the level of creativity in relation to radios and the specific data structures, Mr Grimmett has talked about, certainly there is creativity in designing data structures and interfaces.

152 Mr Ley is a software engineer who was an original architect and developer of the Darwin Ergonomic Platform. In his first affidavit, Mr Ley explained why the decision was made to use header files in developing the Darwin Ergonomic Platform software, and how the header files were to be used:

51    Because the Darwin platform was intended to be as portable as possible (that is, it was designed to be able to operate on different radio products), the Darwin project team also made decisions as to the approach to coding in order to implement best practice. For example, a structured file naming convention was adopted so that the file names indicated the component to which those files belonged. As an example, cor_uit_task.c belongs to the core (‘cor_’), as opposed to the radio-specific plugin layer (‘rs_’), and specifically belongs to the UIT component (‘uit_’). Also, the header files, which contained code such as definitions of data types and declarations of functions, were split from the other source code files. This meant the applications could just reference the header files to be aware of what functions exist and what data types are used within a component, without being aware of the content of those functions or how those data types were used.

153 Mr Ley expanded on this topic in his third affidavit:

7.     In section F.2 of Confidential Annexure DLJ-1 to my first affidavit, I explained that the Darwin platform was originally written in C programming language, and included both header (.h) and source (.c) files.

8.     The header files are important to providing the overall structure and framework for the Darwin platform, as the header files are used to define the ways in which the components of the Darwin platform interact with each other and with different applications.

9.     In section C.1 of Confidential Annexure DLJ-1 to my first affidavit, I explained that the Darwin platform had been developed by Motorola as an application environment in which radio functionalities could be developed in a way that did not couple the code together, in order to address issues with the existing ergonomics code used in previous Motorola products. The Darwin platform achieved this by creating a level of abstraction in order to support different user interfaces, including by separating the application environment or “platform” from the functionalities or “applications”. The use of header files was important in achieving this purpose, as the definitions of data types and declarations of functions in the header files meant the applications could just reference the header files to be aware of what functions exist and what data types are used within a component, without being aware of the content of those functions or how those data types were used (as I explained in paragraph 51 of Confidential Annexure DLJ-1 to my first affidavit). In this way, the header files enabled the decoupling (that is, the level of abstraction) that is a key feature of the Darwin platform. The header files therefore provide a customized, flexible platform architecture and allow for significant time-saving in the development of applications to be used on that platform.

10.     The header files also enabled the sharing of uniform definitions for customized data types and declarations of functions across the entire code for the Darwin platform, such that these customized definitions and declarations could be used throughout the Darwin platform for different applications. This was important to the Darwin platform’s ability to support different user interfaces and to be readily used on different radio products, being another feature of the Darwin platform (as I explained in section C.1 of Confidential Annexure DLJ-1 to my first affidavit).

154 Both Prof Wicker and Prof Rangan gave persuasive evidence concerning the relative importance of header files in the overall architecture of the source code. In his first affidavit, Prof Wicker explained the use of header files within the C and C++ programming languages as follows:

22.     When developing code in either C or C++ it is common to split code between ‘header’ files and ‘source’ files (although I note that the term ‘source code’ includes both header files and source files).

23.     Header files are used to provide structure to and definitions for the rest of the code. They contain declarations and definitions, which are shared across files, and which different parts of the program need to execute. For example, header files may include declarations of variables that are used in the code (I discuss variables further in paragraph 31 below), as well as function prototypes, which declare certain information about a function, but do not contain the code that the function executes (I discuss function prototypes further in paragraph 30 below).

24.     The use of header files in this way provides a number of advantages including making the code contained within the header files more universally available (because the code in the header files can be used in multiple places throughout the code without needing to write it into the code over and over again), and making the process of compiling the source code more efficient.

155 In his third affidavit, Prof Wicker responded to the evidence of Messrs Brown and Grimmett that the copied code had lesser significance because much of the copied code consisted of header files which are ‘declarative’ and not ‘functional’. Prof Wicker expressed the following opinions:

108.     In any event, however, I disagree with the suggestion that header files are “less important” than other files contained in the Motorola Programs.

109.     As I have described in my previous copyright affidavits, and this affidavit, the code copied from the Motorola header files contains fundamental data structures, function prototypes, class definitions and other elements that are both unique and essential to the operation of the Motorola Programs and the particular Motorola Works within them that I have discussed. These are the structures that other parts of the code use to achieve the functionality they are designed to achieve.

110.     At a simplistic level, if these elements of the code were omitted, the code simply would not compile or function. They are, accordingly, essential to the function of those components.

111.     However, it is also important to recognize that header files do not simply contain a random or arbitrary collection of convenient definitions. The header files for a software component such as the Darwin ergonomics platform, or the framerLib library and its Framer and L1 Timer components, contain the fundamental elements of the code that are important and necessary for the software to function. The decisions made by developers in writing the code in the header files permeate the rest of the code for that software component. As a result, the content of the header files reflects the work and decisions that have gone into the design and architecture of the software component. As the Zetzl #1 and Ley #1 Affidavits and the affidavits of Lo Kang Kwai Sin and Matthew Simms (by way of example) indicate, this design and architecture process itself took considerable effort and time. It is in this sense that I described the header files, and the code copied from them, in my previous copyright affidavits as providing the “framework” for the Motorola Works. …

156 During cross-examination, Prof Wicker explained the importance of header files using Mr Brown’s metaphor of source files being “verbs” (transcript pp 745 and 748, 12 August 2020):

And just so I’m clear, if I may, the fact that, you know, we’ve got verbs, we still have to have the structures, the scene in which this action takes place, to continue that metaphor. So the data structures are important to what can be done in the source code.

…

To continue your analogy, it would be more like the noun “phrases”, large-scale structures would be in the headers. But when we say, “Do this with that particular structure”, we would be looking at the source code.

157 In his fifth affidavit, Prof Rangan responded to the evidence of Mr Grimmett which was to the effect that header files are generally of much less importance for the operation of software than the files which supply the functions to which those header files refer. Prof Rangan expressed the following opinions:

161.     In my opinion, contrary to Mr Grimmett’s views, the Accused Motorola Header Files do provide the structure for the code in the Motorola Works, and are fundamental to the overall framework of the various Motorola Works, and the overall architecture of the software for Motorola’s DMR radio devices. In particular, they form the basis for, and give effect to, the overall framework and architecture of Motorola’s Darwin ergonomics platform and the rest of the Mobile and Portable Firmware, as well as Motorola’s L1 timer subsystem and the rest of the DSP Firmware … . In my opinion, the Accused Motorola Header Files therefore represent significant and essential elements of the various Motorola Works, especially when viewed in combination with the numerous Motorola source files identified in Wicker #1 and Wicker #2 as having also been copied in the Hytera code.

162.     Contrary to Mr Grimmett’s views that ‘the Accused Motorola Header Files are amongst the most generic and least creative parts of the Motorola Works’ … , in my opinion the Accused Motorola Header Files, as well as the Accused Motorola Source Files in respect of which Mr Grimmett expresses similar views … , reflect the output of significant creativity from the Motorola engineers who designed and developed them. These files form part of, and give effect to, a unique, sophisticated and complex framework architecture, as also reflected by the significant amount of time and effort spent by Motorola engineers in developing this architecture and code …

158 Prof Wicker and Prof Rangan expressed the same views in the Joint Expert Report.

159 Prof Wicker stated:

I consider header files to be an important element of the Motorola Works in general, and in the copied code in particular.

Header files are used to provide structure to and definitions for the rest of the code. They contain declarations and definitions, which are shared across files, and which different parts of the program need to execute. They thus provide increased efficiency and more efficient compiling.

The content of the header files reflects the work and decisions that have gone into the design and architecture of the software components in which they are used.

160 Prof Rangan stated:

On the specific issue of header files, these files provide the structure for the code in the Motorola Works and are fundamental to the overall framework of the various Motorola Works and Motorola DMR devices.

The development of the header files would be performed in conjunction with the C files and the overall architecture development. The Mot [Motorola] Works have a unique, sophisticated and complex architecture. This effort to develop this architecture is considerable and reflects a high level of creativity.

161 In our view, the opinions of Prof Wicker and Prof Rangan adopt a correct approach to the question of copyright infringement, and for that reason their opinions should be preferred to those of Messrs Brown and Grimmett.

B.5    Architecture and framework of the Motorola Works

Hytera’s submissions

162 Hytera submitted that a central theme of Motorola’s case is its assertion that the copied code takes the overall “architecture” and “framework” of the Motorola Works, but that Motorola’s reliance on “architecture” and “framework” does not reflect the approach to copyright infringement explained in the appeal judgment (being concerned with the form of expression in the code, including such matters as the structure of the code and the choice and sequencing of commands).

163 Hytera submitted that there were three interrelated issues with Motorola’s evidence supporting its claim that the copied code takes the architecture and framework of the Motorola Works. First, Hytera submitted that Motorola’s experts appeared to proceed on the basis that, because the Hytera firmware was developed with an understanding of the architecture and framework of the Motorola Works and the fundamental data structures within the architecture and framework, the copied code must take that architecture and framework. Second, Hytera submitted there is a lack of evidence as to how the architecture and framework of the Motorola Works are expressed in the code. The features of each Motorola Work are described in general terms and at a conceptual level rather than at the level of any particular expression in terms of structure and choice and sequencing of commands. Third, Hytera submitted that, as a consequence of the second issue, Motorola does not address the extent to which the architecture and framework of each Motorola Work as expressed in the code have been taken. Hytera further submitted that it is difficult to see how the overall architecture or framework could be taken where only portions of the code have been copied.

164 The overarching submission made by Hytera on this topic is the contention that Motorola is attempting to claim copyright in the concepts or ideas informing the expression of the code and/or design of each Motorola Work, rather than the particular form of expression of those concepts or ideas. Hytera submitted that the architecture and framework referred to by Motorola do not contribute to or dictate the relevant expression of the source code, including its structure and the choice and sequencing of commands in the code.

Consideration

165 We reject Hytera’s submissions for three reasons: the submissions proceed from an incorrect understanding of the relevant legal principles as explained in the appeal judgment; relatedly, the submissions conflate the ideas or concepts within computer software with the architecture and framework of the software; and the submissions are not based on a fair reflection of Motorola’s expert evidence.

166 As emphasised by the High Court plurality in Data Access, it is a fundamental principle that copyright protects expression and not ideas and, in the context of computer software, copyright protects against the copying of code rather than the copying of the idea or function underlying the code (at [110]). In the present case, the primary judge found that the ex-Motorola engineers, who transferred to Hytera, took with them all of the computer source code for Motorola’s DMR device to provide themselves with a resource for the purposes of writing Hytera’s source code for its DMR device, and the primary judge described their actions as industrial scale harvesting of Motorola’s source code. However, Hytera did not merely ‘harvest’ the concepts and ideas within Motorola’s source code. Hytera has been found to have copied many lines of code from the Motorola Works, as identified in the Annexure to these reasons.

167 The question that must be determined is whether the lines of code copied from each of the Motorola Works constitutes a substantial part of the work. As explained by Mason CJ in Autodesk Inc v Dyason (No 2) (1993) 176 CLR 300 at 305, in a passage referred to with approval by the plurality in Data Access at [83], that question requires consideration of the quality of what is taken, rather than the quantity; and in determining whether the quality of what is taken makes it a ‘substantial part’ of the copyright work, it is necessary to consider the importance of the part taken to the work as a whole.  The importance of the part taken must be ascertained by considering the originality of the expression of the part taken. In the context of computer software, which is a functional work (in that computer code expresses an algorithmic or logical series of functions or steps for the computer to perform), the originality of the expression of the part taken relates to the method chosen to express the algorithmic or logical series of steps or functions. This directs attention to the structure of the copied code, which includes the choice, combination and sequencing of commands contained within the code. That is aptly referred to by Motorola’s experts as the architecture and framework of the code. It is clear from the evidence given by Motorola’s experts that their reference to the architecture and framework of the code is not a reference to concepts and ideas but a reference to the choice, combination and sequencing of commands, which constitutes the form of expression of the code.

168 There is a significant difference in the analysis undertaken by Hytera’s experts and Motorola’s experts. Hytera’s experts, Messrs Brown and Grimmett, explained the function performed by each line or section of copied code considered in isolation, typically concluding that the function is a relatively simple or common function. In contrast, Motorola’s experts sought to explain the function performed by each element of the copied code from a Motorola Work, considered collectively, by explaining the choice, combination and sequencing of commands within the Motorola Work.

169 By way of illustration, in his first affidavit, Prof Wicker summarised the significance of the code copied from the EMT program as follows:

72.    In summary, much of the code that I consider has been copied from the EMT component of the Motorola source code into the Hytera source code relates to fundamental data structures (such as type definitions), macros and function prototypes that are used by EMT. For example, this code includes:

(a)     [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(b)     [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(c)     [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(d)     [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

73.     The copied code also contains a number of functions.

74.     In my view, these are important parts of EMT. These fundamental structures set out the ‘framework’ upon which the rest of the code comprising EMT is built, and the ‘language’ with which the code communicates with other code both within EMT and outside it. Indeed, in my opinion, these parts of the code reflect much of the skill, effort and creativity that went into developing EMT. For example, in my opinion these aspects of the code reflect the planning and understanding of what the architecture would be, including (by way of example) aspects such as [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], and [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Once this ‘framework’ is in place, it greatly assists in writing the ‘source’ files that are built on it. For example, once the structures related to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] are in place, writing the code that handles [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] is considerably simpler than writing such code without that framework already existing.

170 Contrary to Hytera’s submissions, Prof Wicker is not expressing an opinion that Hytera has copied the concepts and ideas of the Motorola source code. Rather, Prof Wicker is explaining why the code that has been copied by Hytera is an important part of EMT, being one of the Motorola Works. The copied code is an important part of EMT because it relates to fundamental data structures, macros and function prototypes that are used by EMT, and these fundamental structures set out the framework upon which the rest of the code comprising EMT is built, and the language with which the code communicates with other code both within EMT and outside it. In his oral testimony (transcript p 715, 12 August 2020), when discussing lines 136-146 of the file cor_emt_app_defines.h, Prof Wicker explained the difference in approach between the experts as follows:

… there is a danger in looking at portions of the header [in] abstraction. I – I would take us back to cor_emt_app_defines.h. There is, as both Mr Brown and Mr Grimmett noted, a rather simple – something called a typedef enum that talks about [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], and that – that sounds quite simple. [REDACTED] [REDACTED] [REDACTED]. But if you look at the entire header, you start to see more and more structure. For example, in this same file we’ve got [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. We’ve got [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] and so forth, and as you go through this header, you start to realise that you’re actually building up the architecture that’s in that rather complicated diagram to which counsel took Mr Brown, the Hytera version is application manager architecture. It’s the same as the – the Motorola version. So what these headers are doing [is] providing the structure to which the – the code is written to which the – the source code will be written. It provides the variables. It provides [REDACTED] [REDACTED] [REDACTED] [REDACTED]. It provides [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED],  so these header files, if – if you zero down on a small piece, you could say, “Yes, that looks relatively simple.” But its place within an overall scheme can be quite complicated, and in this case, it is. It’s a very powerful application management architecture.

171 In the Joint Expert Report, Prof Rangan expressed his agreement with Prof Wicker’s analysis referred to above, stating:

I agree with the analysis in SBW-32 Section 10 on the importance of the copied code to Motorola Works. For example, the copied EMT and Darwin code includes fundamental structures on which the framework is built (SBW-32 Section 10.2, 10.3, 10.4). Similarly, the copied code includes fundamental components on which the Framer and L1 timer are built which are in turn fundamental to the DSP firmware (SBW-32 Sections 10.5 to 10.7). Once this framework is in place, it greatly assists building further software. This framework takes considerable time and expertise to build.

172 In our view, Prof Wicker’s evidence illustrates the correct approach to the question of substantiality and accurately explains the difference in approach of the respective experts.

173 An illustration of the difference in approach of the experts is given in respect of the EMT file rs_emt_imt_com.c. The primary judge found that the file created [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] (PJ [1443]). The primary judge also found that Hytera copied, into its file ps_imt.cpp, Motorola’s code which effected the structure of [REDACTED] [REDACTED], but Hytera did not copy the contents of [REDACTED] [REDACTED] (Hytera’s table invoked different [REDACTED] [REDACTED] designed for its own devices) (PJ [1464]). In oral testimony (transcript p 593, 10 August 2020), Mr Brown agreed that the structure of using [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] represented a significant design choice of [REDACTED] [REDACTED] in the Motorola code, but said that the structure was “commonly done”. However, Mr Brown agreed that he could not say that it was commonly done in two-way radio software in 2003 to 2007. In response, Prof Rangan observed (transcript p 594, 10 August 2020):

I think the words Mr Brown used, and maybe even the question used, was “a design choice”, but this is going well beyond a design choice. Yes, one can copy the concept of [REDACTED] [REDACTED] [REDACTED] [REDACTED] in a certain manner, but this is not just copying that decision. It’s not like they had that decision and then reimplemented everything from scratch. You have the whole framework on which this is built, which we’re going to talk about, the EMT framework in the first place, the idea of [REDACTED], the exact syntax of [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], which means that the person, even if they’re implementing it from that design choice, they don’t have to debug anything. All of this is done, and they simply have to rearrange and reselect the applications that are being done. I mean, the idea that we’re talking about a design choice is completely misleading about the level of copying.

174 Again, in our view, Prof Rangan’s evidence illustrates the correct approach to the question of substantiality and accurately explains the difference in approach of the respective experts. The approach of Mr Brown was to consider lines of code in the abstract, and comment on the relative novelty of the code. In contrast, Prof Wicker and Prof Rangan properly gave attention to the choices made by Motorola in implementing its programming functions – the selection and sequencing of commands – and the extent to which the Motorola code copied by Hytera reflected that selection and sequencing.

B.6    Quantity of copied code

Hytera’s submissions

175 On this second phase of the appeal, Hytera maintained its submission that, while the assessment of whether the copied code is a substantial part of each of the Motorola Works involves a qualitative evaluation, the quantity of the copied code is nevertheless a relevant consideration, citing Tamawood Ltd v Henley Arch Pty Ltd [2004] FCAFC 78; 61 IPR 378 at [50] and University of Sydney v ObjectiVision Pty Ltd [2019] FCA 1625;  148 IPR 1 at [730].

176 For that purpose, Hytera’s submissions on each of the Motorola Works was accompanied by a table (Annexure D) that purported to show the number of lines of code copied from, and the total number of lines of code within, each file in the Motorola Works. Hytera submitted that the primary judge had found, and Annexure D showed, that the portions of code allegedly taken were “a relatively small part of Motorola’s overall DMR technology” (PJ [2067]).

Consideration

177 The authorities are clear that the expression “substantial part” in copyright legislation places an emphasis on the quality of the part taken, rather than the quantity: Ladbroke at 276 (Lord Reid), 288 (Lord Hodson), and 293 (Lord Pearce); Data Access at [83]–[87] (Gleeson CJ, McHugh, Gummow and Hayne JJ); IceTV at [30] (French CJ, Crennan and Kiefel JJ) and [155] (Gummow, Hayne and Heydon JJ). Nevertheless, the quantity taken is also a relevant consideration: Network Ten Pty Limited v TCN Channel Nine Pty Limited (2004) 218 CLR 273 at [47] (McHugh A-CJ, Gummow and Hayne JJ).

178 The quantity of the copied code as a proportion of the entirety of the source code in the Motorola Works was a major focus of Mr Brown’s evidence at trial. Motorola submitted, and we accept, that this formed the primary argument raised by Mr Brown as to why the copied code was not a substantial part of the Motorola Works. Mr Brown addressed the importance of the copied code to the Motorola Works in section L of his first affidavit. Broadly stated, Mr Brown’s quantitative methodology was to calculate the quantity of lines of Hytera code that Mr Brown considered had been copied from Motorola code (as the numerator), and divide that number with the total quantity of lines of code within the Motorola Work from which the code was copied (as the denominator). However, and as discussed below, Mr Brown’s methodology involved considerable subjectivity and was the subject of relevant criticisms by Prof Wicker.

179 In the Joint Expert Report, all of the experts agreed that, in the context of computer code, line counting has significant limitations and, in this case, is further undermined by the absence of parts of Hytera’s source code. The experts agreed to the following joint statement:

The experts agree that line counting is only one aspect in the assessment of software.

(1)     We do not have all of the Hytera code; any line counting can only be used to form conclusions as to the extent of the accusations of copying, or the extent of source code comparisons performed. In this case, line counting is not suitable to form conclusions on overall similarity between Motorola and Hytera systems given not all Hytera source code is available for analysis.

(2)     Not all lines of code are created equal especially with higher level languages. Counting lines is only one aspect of software and the complexity, novelty and quality of the code under analysis must also be taken into consideration when evaluating the importance of code.

180 The second part of the joint statement mirrors Prof Wicker’s evidence in his third affidavit:

66.    … a quantitative assessment of the number of lines copied is not, in my opinion, a reasonable indication of the extent or significance of copying. This is so for a number of reasons, including because the number of lines of code (even if it can be determined correctly) does not necessarily reflect the degree of skill, judgment or effort required to create it (including, in particular, in relation to activities such as design and architecture), nor its importance to the rest of the program.

181 Despite the joint statement, Mr Brown expressed the following opinion in the Joint Expert Report:

In terms of size, the Particularised Hytera Code [the Hytera code alleged to be a copy of Motorola code] only amounts to a tiny percentage of the Motorola works. Of the overall files, the alleged copying is limited to 2% of the Motorola Works. By line count the number is also less than 2%.

182 In the Joint Expert Report, Prof Wicker expressed the opinion that Mr Brown’s methodology for line counting contained errors and systematically undercounted the extent of copying.

183 In assessing Mr Brown’s evidence with respect to the quantity of copied code, it is necessary to have careful regard to the basis of his calculations. The following aspects of his approach undermine the reliability of his methodology.

184 First, as noted above, Mr Brown’s methodology was to calculate the quantity of lines of Hytera code that Mr Brown considered had been copied from Motorola code (as the numerator), and divide that number with the total quantity of lines of code within the Motorola Work from which the code was copied (as the denominator). That methodology presents an incomplete picture. A quantitative assessment of the copying should consider both how and to what extent the copied code is used in the Motorola Works. Many files in the Darwin Ergonomics Platform were present in numerous directory locations. Where such code was copied by Hytera, Mr Brown counted that code only once among the copied code (that is, in the numerator), but counted each replicated version of the code in the Motorola Works in the total code (that is, in the denominator) (this was explained by Mr Brown in his fourth affidavit at [38]-[40], and confirmed during cross-examination at transcript pp 582-3, 10 August 2020). Prof Wicker explained why Mr Brown’s methodology produced a distorted figure by undervaluing the quantity of the copied code within the Motorola Works (third affidavit at [39(b)]). Mr Brown did not attempt to calculate the number of times copied code appeared within the Motorola Works and aggregate the total number of lines in the numerator before dividing by the total number of lines of code in the Motorola Works. In Annexure D, provided to the Court by Hytera in the second phase of the appeal, Hytera purported to account for that deficiency in Mr Brown’s calculations. However, in the absence of expert evidence, the Court cannot be confident that Hytera has undertaken the exercise accurately.

185 Second, as explained in his first affidavit, Mr Brown only counted (in the numerator) Hytera code that was copied from Motorola where the code “may impact the Hytera firmware” (first affidavit at [158], [159]). Mr Brown’s definition of code that “may impact the Hytera firmware” was as follows (first affidavit at [142], emphasis added):

By “impact” I mean the lines of Hytera source code which are not wholly discarded in the compilation process and may materially influence the composition of the final executable that is used or written as firmware onto the physical hardware in a device. This would include “functional” code in the sense described in the preceding paragraph, as well as the other examples of code described in that paragraph (declarations and definitions, function prototypes, and structures that define memory layout) that influence the compilation process.

186 In the preceding paragraph (first affidavit at [141]), Mr Brown had defined “functional” code as follows:

By “functional”, by which I mean whether or not they contain code relating to the function of the device, that is, what the device actually does, and which is actually compiled into object code, written as firmware onto the device and executed by the device, as compared to other code which may impact what is written to the device but is not executed by the device, such as declarations and definitions used while compiling, function prototypes used to join the source files together during the linking step or structures that define memory layout. I consider that this is a relevant consideration as to the quality of the source code that is alleged to have been copied.

187 As explained by Prof Wicker, Mr Brown’s methodology introduces another distortion to his calculation: whilst Mr Brown only counted in the numerator Hytera code that he considered may impact the Hytera firmware, Mr Brown counted in the denominator all code in the Motorola Works regardless of whether it would “impact” the Motorola firmware (Prof Wicker’s third affidavit at [39(c)]). As also explained by Prof Wicker, Mr Brown’s assessment of whether copied code may impact the Hytera firmware lacked transparency and involved subjectivity: Mr Brown did not identify which of those lines he considered met that description or provide an explanation as to why he considered that the lines met the description. Prof Wicker explained why it was impossible to verify Mr Brown’s approach (in his third affidavit at [56]-[63]).

188 An illustration of the subjectivity of Mr Brown’s methodology was given by the Motorola header file rs_cpvalue_list.h (which was a file within the Mobile and Portable Firmware, but outside the Darwin Ergonomics Platform), which was found to have been copied by Hytera into its file ps_cpvalue_list.h. The Motorola file has 203 lines of code, while the Hytera file has 257 lines of code. Mr Ley’s evidence was that the Motorola file is used to define the values (referred to as ‘CP values’) that are programmed to user inputs (including buttons, menus and switches). By way of illustration, CP_SCAN is what the customer would program to a button to toggle the scan state. Prof Wicker identified that, in Hytera’s file ps_cpvalue_list.h, some minor changes were made including that the constant CP_VOL had been replaced with CP_VOLKNOB, and a new first entry CP_NULL was added, resulting in the value of each subsequent constant being increased (Prof Wicker’s second affidavit at [56]). Prof Wicker further explained that, as a result of that minor change, when the source code is compiled, the object code gives different defined values: the Motorola value for CP_VOL is 0x02 whereas the Hytera value for the equivalent CP_VOLKNOB is 0x03 and the value of each subsequent entry being increased by one unit (Prof Wicker’s third affidavit at [51(c)]). By reason of that minor change, which affected the compiled object code, Mr Brown included only 2 lines of the Hytera file in his line counting. In cross-examination, the following exchange occurred (transcript p 561, 10 August 2020):

MR MOORE: … you would agree, wouldn’t you, that that has the potential to create a slightly incorrect impression as to the extent to which the Hytera code copies the Motorola code.

MR BROWN: Well, in my analysis of this, there was – I totally agree with, you know, Dr Wicker that some copying has occurred. The question in the end is how much of it remains the same, and in this case, certainly, the values no longer remain the same, and so the radio no longer remains the same. And, certainly, in this case, where most of this file – of the – I’m just checking the other lines – most of this file of the 275 lines, there’s no resemblance.

MR MOORE: Looking at the ones, for example, that we’ve looked at, such as where the Motorola code says define push-to-talk button as [0x01], and the Hytera file says define the push-to-talk button as [0x02], your approach here is to say well, that’s different, so I disregard that, correct?

MR BROWN: So – in this counting, yes.

189 As the primary judge found, Mr Brown’s reliance on the difference that appeared in the object code after compilation was a “red herring” – the correct question is whether the source code is objectively similar (PJ [1777]). We note for completeness that the transcript records Mr Brown stating that the file contains 275 lines of code, whereas the evidence indicates that the Hytera file contained 257 lines of code. Nothing turns on that discrepancy.

190 Third, Mr Brown’s line counting methodology failed to account for the importance of “definitional code” (header files) copied by Hytera. Prof Wicker noted that simply counting the number of lines in which a particular identifier (such as a function name or data type) is defined does not reveal the extent to which that identifier is used by the rest of the code. By way of illustration, Prof Wicker referred to the [REDACTED] [REDACTED] [REDACTED], which was a data type defined within lines 142-146 of the file cor_emt_app_defines.h and was copied into Hytera file raf_app.h (see PJ [1366]). Prof Wicker observed that the data type takes 7 lines to define, but reference is made to it more than 1,000 times in each of the Motorola source code and the Hytera source code (Prof Wicker’s third affidavit at [69]). Prof Wicker expressed the opinion, which we accept, that the fact that a number of copied identifiers are used hundreds or thousands of times is an indication of the fundamental nature and importance of these definitions to the rest of both the Motorola and Hytera source code (at [71]).

191 Fourth, Mr Brown’s line counting methodology failed to account for the importance of the structure of the code copied by Hytera, which includes the choice, combination and sequencing of commands contained within the code copied by Hytera. For example, the Hytera file ps_imt.cpp, containing [REDACTED] [REDACTED] [REDACTED] [REDACTED], was found to have been copied from the Motorola file rs_emt_imt_com.c (located within the EMT) on the basis that the structure of the Hytera and Motorola [REDACTED] was the same (PJ [1464]). However, the specific [REDACTED] which were defined in the Motorola code and the Hytera code differed by reason of the different functions of the Motorola and Hytera DMRs. Although the Hytera file consisted of 401 lines and the Motorola file consisted of 1,220 lines, on Mr Brown’s methodology only 10 lines were counted as having been copied. As explained by Prof Wicker in his third affidavit, the code comprising the [REDACTED] [REDACTED] was structured to enable [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] to be modified:

72.    … this is exactly how this file is supposed to be used in the Darwin ergonomics platform. As indicated by the “rs_” prefix in the filename, it resides in the “radio-specific” layer, which is designed to be customized for each specific product … In my opinion, the fact that Hytera has modified [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], which was designed by Mr Ley and his colleagues at Motorola precisely to be modified by product teams, does not lessen the significance of what they have copied. What has been copied is [REDACTED] [REDACTED] [REDACTED] [REDACTED], which is an essential part of the particular program (i.e. EMT) designed by Motorola to provide [REDACTED] [REDACTED] [REDACTED] as part of the Darwin ergonomics platform. As I described in my second copyright affidavit, I consider this table to be “a unique implementation based on the specific concepts set out in the Darwin Ergonomic Platform Architecture document.” Mr Brown does not state in his affidavit that he disagrees with this assessment, and instead focuses only on counting the number of lines he considers to be superficially similar.

192 Fifth, Mr Brown’s line counting exercise could not, and therefore did not, take into account the “missing” Hytera source code – the code in Motorola’s source files that had been copied by Hytera but which Hytera had subsequently destroyed to avoid detection of copying, as found by the primary judge (at PJ [1553]). This was the subject of the joint statement in the Joint Expert Report set out earlier but which warrants repetition:

We do not have all of the Hytera code; any line counting can only be used to form conclusions as to the extent of the accusations of copying, or the extent of source code comparisons performed. In this case, line counting is not suitable to form conclusions on overall similarity between Motorola and Hytera systems given not all Hytera source code is available for analysis.

193 In this context, it is necessary to revisit some matters that were canvassed in the appeal judgment concerning the missing Hytera source code and the discovery given by Hytera of its source code, which were the subject of further submissions in the second phase of the appeal under this topic.

194 As discussed in the appeal judgment at [652], the primary judge found that Hytera gave discovery in four tranches. Relevantly, in the course of giving discovery, Hytera discovered certain ‘library’ files of object code with the file names raf_arm9.lib, rfhal_c55.lib and DmrDspLib.lib. As noted earlier in these reasons, when source code is compiled into object code, the object code is combined into an ‘archive’ or ‘library’. However, the source code from which the object code in the library files had been compiled was not discovered by Hytera. In the absence of Hytera’s source code, Motorola submitted at trial that the Court should infer that Hytera had copied a substantial part of Motorola’s source code in producing the Hytera source code from which the library files were compiled. The primary judge concluded that he was unable to draw that inference. On the appeal, this Court concluded that such an inference could and should be drawn (AJ [867]). In reaching that conclusion, this Court observed (at AJ [862]-[863]):

862    The findings made against Hytera by the primary judge in this proceeding are damning of its conduct. As noted earlier, the primary judge found that the ex-Motorola engineers took with them to Hytera all of the computer source code for Motorola’s DMR device to provide themselves with a resource for the purposes of writing Hytera’s source code for its DMR device (PJ [1538]). His Honour characterised Hytera’s actions as a “substantial industrial theft” (PJ [5]) and found that Hytera’s software engineers engaged in industrial scale harvesting of Motorola’s source code and that they set out to make this as difficult to detect as possible (PJ [1576]). Most egregiously, and most relevantly for present purposes, the primary judge found that the source code from which the library file was compiled was deliberately deleted by or at the instigation of the ex-Motorola software engineers, that much of the deleted evidence would have thrown light on the infringement suit, and the deletion was a deliberate attempt to suppress evidence which might assist in an infringement suit (PJ [1553]). The evidence given by Professor Rangan explains why it is an extraordinary step for a software company to delete the source code used to compile object code (the library files) used in devices that it continues to sell. Without the source code, the software developers would be unable to make modifications to the underlying code, whether in response to changes in processors or other parts, to fix technical bugs, or to add a feature.

863     The finding that the source code was deliberately deleted so as to suppress evidence which might assist in an infringement suit, when coupled with the other factual findings made by the primary judge concerning the library files, strongly supports an inference that the deleted source code would have revealed that it was a copy of a substantial part of the relevant Motorola source code.

195 In the absence of the source code used by Hytera to compile the object code in the library files, it is not possible to determine precisely how much of Motorola’s source code was copied by Hytera into its source code. Nevertheless, through a process of disassembly, it was shown that the library files contained many file and function names which were the same or similar to the file and function names in Motorola’s source code.

196 For the reasons given in the appeal judgment, we have inferred that Hytera’s source code, from which the library files were compiled, contained a substantial part of each of those Motorola files. Each of the relevant Motorola files is listed in the Annexure to this judgment (which contains a list of the copied code), albeit that there is no evidence as to the number of lines of code in each of the files.

197 The significance of these findings goes beyond the mere quantification of the number of lines of code copied by Hytera. The findings also provide an answer to one of Hytera’s criticisms of Motorola’s case on substantial part: that the Hytera code shown to have been copied from Motorola code consists primarily of header files which are of lesser significance than source files. For the reasons explained earlier, we do not accept Hytera’s submission that header files are of lesser significance than source files. But it is necessary to go further. At least part of the reason that the Hytera code, shown to have been copied from Motorola code, consists primarily of header files is because Hytera has destroyed the source code for the accompanying source files. All that is left is object code from the discovered ‘library’ files. This can be illustrated by reference to the list of copied code in the Annexure to these reasons. Whilst most of the Hytera files containing copied code were header files, the accompanying source files (that is, source files having the same name as the header files) appear in the library files, for which the source code has been deliberately destroyed by Hytera.

198 Having regard to the above five issues concerning Mr Brown’s line counting methodology, we consider that Mr Brown’s line counting evidence lacks reliability and only limited weight should be given to his evidence in assessing whether the copied code is a substantial part of each of the Motorola Works.

199 As stated earlier, Hytera’s submissions on each of the Motorola Works was accompanied by a table (Annexure D) that purported to show the number of lines of code copied from, and the total number of lines within, each file in the Motorola Works. With the leave of the Court, after the hearing of the second phase of the appeal, Hytera filed a further version of Annexure D containing corrections. Annexure D is heavily footnoted, containing references to the expert evidence (including Mr Brown), findings made by the primary judge and by this Court, and other submissions filed on the appeal. However, many of the figures require calculations from the underlying evidence (for example, the calculation of the total number of lines in the Darwin Ergonomics Platform is apparently derived from annexure BJAH-24 to the second affidavit of Mr Hayes, and the calculation of the total number of lines in the Mobile and Portable Firmware respectively is apparently derived from annexure CMB-26 to the fourth affidavit of Mr Brown, which in turn purports to be derived from the evidence of Prof Wicker). Many of the footnotes contain further calculations within the footnote based on evidence or findings by the Court. In our view, it is not reasonable for Hytera to file a submission in the form of Annexure D and expect that the Court is in a position to work through numerous evidentiary references and perform calculations in order to assess the reliability of the figures stated in the Annexure. Hytera must be held to the “line counting” evidence it adduced at trial through Mr Brown, and bear the consequences of the many deficiencies in Mr Brown’s evidence.

200 Despite the flaws in Hytera’s evidence and submissions concerning the quantity of copied code, we accept that, in assessing whether the copied code is a substantial part of each of the Motorola Works, it is appropriate to have regard to the quantity of the copied code in comparison to the size of the Motorola Work, provided any such comparison can be performed on a reliable basis. In this case, it is not possible to determine the full quantity of copied code because Hytera destroyed the source code from which the library files raf_arm9.lib, rfhal_c55.lib and DmrDspLib.lib were compiled. It is possible, though, to have regard to the overall size of the Motorola Works. In the following parts of these reasons which consider each of the Motorola Works in turn, we have had regard to Motorola’s submissions with respect to the size of each of the Motorola Works recorded in the Objective Similarity Matrix. As stated earlier, the parties prepared the Objective Similarity Matrix for the purposes of the first stage of the appeal. In addition to identifying the lines of code within the computer files that the primary judge found had been copied by Hytera, the table contained each party’s submission with respect to the total number of the lines of code within each of the Motorola Works. In this second phase of the appeal, Motorola submitted that the figures given by them in the Objective Similarity Matrix are accurate. We consider that Motorola’s submission in that regard can be treated as being in the nature of an admission, as the submissions recognise that the Motorola Works are large computer programs containing many files and lines of code. For the same reasons, we have also had regard to the evidence of Mr Hayes, given on behalf of Motorola, with respect to the total number of files in the Mobile and Portable Firmware and the DSP Firmware.

201 We nevertheless conclude this section of the reasons by recording our general agreement with the opinion expressed by Prof Wicker that a quantitative assessment of the number of lines of copied code is not a good indication of the importance of the copied code to the Motorola Works. The number of lines of copied code, even if it can be determined correctly, does not necessarily reflect the degree of skill, judgment or effort required to create it, nor the importance of the copied code to the rest of the program in which it is used.

B.7    Conclusion with respect to the overarching submissions

202 For the reasons stated in this section B, we largely reject the five principal submissions advanced by Hytera in defence of Motorola’s claim that the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works. As stated earlier, the submissions generally explain the differences in opinion of the Hytera expert witnesses on the one hand and the Motorola expert witnesses on the other. It follows from our rejection of the submissions that we consider that Hytera’s expert witnesses adopted an incorrect approach to the assessment of the question whether the Motorola source code copied by Hytera was a substantial part of one or more of the Motorola Works. Conversely, we consider that Motorola’s experts adopted the correct approach. As a consequence, we generally prefer the evidence of Motorola’s expert witnesses on the question of substantial part.

203 It remains to consider each of the Motorola Works in light of the lay and expert evidence adduced by Motorola and applying the principles discussed above.

PART C: MOBILE AND PORTABLE FIRMWARE

C.1    Introduction

204 As found by the primary judge (at [1144] – [1145]), Motorola launched its DMR products in the first quarter of 2007. Those products consisted of subscriber units, including portable DMRs (i.e. handheld) and mobile DMRs (i.e. those fitted inside vehicles) and base stations. Each type of device came installed with its own firmware. The host firmware for the portable devices was known as the ‘Portable Firmware’ and for the mobile devices was known as the ‘Mobile Firmware’. Each mobile and portable device and each base station was also installed with what was known as the ‘DSP Firmware’, which was the firmware that operated the DSP (digital signal processor) within those devices or the base stations.

205 In his first affidavit (at [10]), Mr Zetzl explained that the mobile and portable DMR devices contain two processors: a ‘host’ (or ARM) processor, which runs most of the radio firmware and applications, and a digital signal processor (DSP), which is responsible for low-level audio processing (for example, demodulating the incoming signal and processing the audio signal from the microphone). The Matrix project involved developing both host firmware (which is referred to in these reasons as the Mobile and Portable Firmware) and DSP firmware.

206 Mr Zetzl explained (at [22]) that, within Motorola, the Matrix platform was described as having high level, common level and low level code. The high level relates to ergonomics, which refers to the layer of software that the user of the radio interacts with. The high level can vary between different radio devices, which have different keypads, displays and other attributes of the radio that the user interacts with. The common level contains the connectivity code and signalling code that is protocol specific, but the same across different types of radio devices (that is, portables and mobiles) regardless of the specific attributes of the radio (for example, whether or not the radio has a display). For example, if the user, via the high level, inputs a command to send a particular message via the radio, the common level code determines what steps are necessary to action that command given the particular signalling protocol that is currently being used by the radio. The low level contains code that directly interacts with, and operates, the radio hardware. The low level includes the operating system used by the radio device.

207 Mr Zetzl stated (at [23]) that the purpose of developing software in a layered approach was to decouple the architecture into layers of functionality that are independent, to the extent possible, from the other layers in the architecture, such as what signalling protocols the radio supports, or the particular hardware used in the radio. Taking this approach allowed Motorola to adapt the requirements, design, code and test frameworks for use across different types of radio devices. An aspect of this layered approach to software development is defining a set of interfaces between layers, which the code in both layers had to understand and adhere to in order to pass commands and data between them. For example, the high level and common level code, when calling particular low level functions, does not need to know that there is more than one processor or precisely which processors will execute the command. Instead, it only needs to pass appropriate commands to the low level using the appropriate interface.

208 The components of the Matrix programs are depicted in the diagram below which was extracted by Mr Zetzl from an internal Motorola presentation titled ‘Matrix Subscriber Firmware Architecture Overview’ dated August 2010:

[REDACTED]

209 In his first affidavit (at [27]), Mr Zetzl explained that the DSP Firmware is indicated by the labelled box depicted in the bottom right of the diagram, whilst the remainder is the host firmware, being the Mobile and Portable Firmware.

210 Mr Zetzl stated (at [25]) that, while Matrix was Motorola’s first DMR project, the project sought to selectively utilise and further develop previous Motorola product lines and platforms that had components suited to the design and architecture requirements of the Matrix devices, including the technical requirements of DMRs. In the above diagram, individual components of the software were coloured to indicate whether they were developed specifically for the Matrix project or whether they originated from a different project within Motorola. Mr Zetzl gave evidence that, in most cases, the components were still modified prior to their use in the Matrix platform.

211 The different components of the overall Matrix platform, which are depicted in the above diagram, were described in Lo Kang’s affidavit (at [21]). Lo Kang described the five ‘domains’ of the software, being the DSP (digital signalling processor), low level, signalling, connectivity and ergonomics, as follows:

(a)    The DSP handles low-level audio processing such as the demodulation of received signal and processing the audio signal for transmission. The low level of the DSP was called the low level hardware abstraction layer (HAL).

(b)    The low level includes drivers that operate hardware, the operating system, and low-level calls and services such as turning the radio speaker on or off, adjusting the microphone volume, or operating accessories.

(c)    The signalling layer handles the over-the-air protocols. For example, this code determines what the radio should do when it receives an over-the-air call: that is, whether it should accept the call and turn on the speaker, or reject it, depending on various parameters.

(d)    The connectivity layer enables the radio to connect to other devices via various protocols, such as via USB or via network connection.

(e)    The ergonomics layer handles the user interaction with the radio devices, including the user interface and inputs from and outputs to the user. The ergonomics layer consists of the ergonomics framework (the Darwin core) and the applications.

212 In his affidavit (at [22]-[25]), Lo Kang described the development of the software code for the Matrix project. He explained that, whilst each of the above software ‘domains’ had a separate team of software developers, each of the domain teams worked together on various aspects of the software. This is because a given feature or capability of the radio often required code across multiple domains. For example, the capability of the radio to make or receive a group call requires signalling code, ergonomics code (for example, to handle the display and to also manage the interactions between the group call and other applications that might be running), low-level code (drivers for the relevant chipsets to provide instructions to the DSP), and DSP code (to correctly handle the relevant digital signals).

213 The Matrix firmware depicted in the above diagram contains a large number of computer files. In his second affidavit (at [32]), Mr Hayes calculated the total number of header (.h) and source (.c, .cpp and .asm) files in each of the Motorola programs, as depicted in the following table:

214 This Part C of the reasons concerns the Mobile and Portable Firmware. Part D of the reasons concerns the DSP Firmware.

215 Motorola alleged that Hytera’s firmware was an adaptation of a substantial part of Motorola’s source code in:

(a)    each of the EMT, Xlate and UIT components of the Darwin Ergonomics Platform;

(b)    the Darwin Ergonomics Platform; and

(c)    the Mobile and Portable Firmware.

216 The Darwin Ergonomics Platform is shown in the above diagram as the ‘Darwin Core’. Mr Ley exhibited to his first affidavit a document titled ‘Darwin Ergonomic Platform Architecture’ which contains a detailed description of the architecture of the Darwin Ergonomics Platform. In his first affidavit (at [7]), Mr Ley stated that every feature of the radio that the user interacts with has some ‘ergonomics’ component, which is implemented as one or more ‘applications’.

217 Mr Ley stated (at [48]) that the Darwin Ergonomics Platform contains five ‘core’ components: EMT, Xlate, UIT, UIQ and CLIM. The development of the Darwin Ergonomics Platform, both in its initial release and the enhanced version created for the Matrix program specifically, is described in the affidavits of Mr Zetzl, Mr Ley and Mr Antilla.

218 Mr Zetzl stated (first affidavit at [79]) that the Darwin Ergonomics Platform was based on a component originally developed for Motorola’s earlier Astro platform, but was used in the Matrix project with further developments. Mr Ley explained (first affidavit at [10] and [11] and third affidavit at [9]) that a primary objective in developing the Darwin Ergonomics Platform (originally for the Astro platform) was to address issues with prior iterations of ergonomics code at Motorola. Those prior iterations were developed in a way in which the code was ‘coupled’, with a lack of clear delineation between code achieving one function and code achieving a different function. This had various drawbacks including making the code difficult to modify. The aim of the Darwin project was to develop an application environment in which different radio functionalities could be developed in a way that did not couple the code together, and in a way that could be readily used on different radio products. This was done by separating the application environment (also referred to as the Darwin ‘core’ or ‘platform’) from the functionalities themselves (also referred to as ‘applications’ or ‘features’); this is also referred to as creating a layer of ‘abstraction’ between the platform and applications. Each component of the Darwin platform provides a set of services, which allows the applications to run on a stand-alone basis. However, parts of the code that depended on the specific radio hardware being used were separated into a different radio-specific layer, so that the majority of the Darwin platform was hardware-independent.

219 As part of the work he and his colleagues undertook on the architecture of Darwin Ergonomics Platform, Mr Ley noted (first affidavit at [51]) that a deliberate decision was made to split the header files from the other source code files. Mr Ley explained (third affidavit at [9]) that the use of header files was important in achieving the goal of a level of abstraction and providing the overall architecture, structure and framework of the Darwin Ergonomics Platform. This is because, since the components of the Darwin Ergonomics Platform were abstracted from the applications (and from each other), those header files provide a set of definitions and declarations that can be referenced by each of those parts of the code and used by them to interact with one another.

220 In his affidavit at [28]-[38], Mr Antilla described the intellectual effort involved in making enhancements to the Darwin Ergonomics Platform that had previously been used in the Astro products. The first step in creating the enhancements was for the team members responsible for the enhancement to map out the design of each of the enhancements. This involved a considerable amount of time and work, and collaboration with other team members. All of the code was handwritten by team members. Some enhancements required modifications to existing files in the Darwin platform code and some enhancements required the creation of new files. There was often a great deal of trial and error in creating the enhancements, given that there were generally multiple ways of writing the code to create each enhancement, and several attempts at writing the code were sometimes needed before deciding on how to create the relevant enhancement. In making modifications to the existing code, the Motorola team would examine the existing code in detail to work out why the code had been written in the way it had, in order to inform how the code would be written for the modifications. After the code was written, the whole team met together and reviewed the code line by line, to make sure there were no errors in the code.

221 EMT (Ergonomic Manager Task) is a component of the Darwin Ergonomics Platform. As explained by Mr Ley in his first affidavit (at [30]), the EMT is the main ‘application environment’ on the radio. That is, EMT [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. EMT performs a number of functions, including [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Mr Ley stated (at [31]) that EMT was a major improvement on the previous (Astro) system, as it decoupled and centralised the way in which features (or ‘applications’) were managed. This meant that new applications could be written, or existing ones modified, without needing to modify the EMT code.

222 Xlate (also referred to as XLT or the user input translate task) is also a component of the Darwin Ergonomics Platform. As explained by Mr Ley in his first affidavit (at [22]-[24]), Xlate converts the physical user inputs received from a separate component (UIQ) into logical inputs that can be understood by the software running on the radio (such as assigning the “scan” meaning to an input produced by pressing a button on the side of the device). Xlate does this by [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. It then sends this logical input to EMT. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In addition, some inputs on the radio can be user programmable, through the customer programming software, to be associated with particular features. On the other hand, some buttons are not programmable by the user, such as the PTT or ‘push-to-talk’ button. Xlate accordingly [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] and ensures that the correct logical input is passed to EMT. The development of UIQ and Xlate meant that applications, and the rest of the ergonomics platform, do not need to know what physical buttons or other inputs the radio has, or what combinations have been programmed to have special meanings. Instead, UIQ and Xlate handle translating these physical inputs into logical ones, and the applications and the rest of the ergonomics platform only have to understand what to do with the logical inputs.

223 UIQ (User Input Queue) works together with Xlate to form the user input subsystem with the Darwin Ergonomics Platform. As explained by Mr Ley in his first affidavit (at [22]), UIQ is [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

224 Mr Ley stated (at [27]) that Xlate and UIQ were significant improvements over Motorola’s previous ergonomics code. With respect to Xlate, in the Darwin platform different parts of the platform were divided more clearly, so that the core Xlate task is common to all features [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. With respect to UIQ, with the previous platform [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. With the development of UIQ, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

225 UIT (the User Indication Task) is another component of the Darwin Ergonomics Platform. As explained by Mr Ley in his first affidavit (at [11], [33]-[35]), UIT manages outputs to the user, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Mr Ley stated that, before UIT was developed, the way in which displays were managed was relatively rudimentary. The development of the UIT component was a major improvement from the existing ergonomics code used at Motorola, because [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] it is not coupled to any applications. UIT is a more flexible and powerful component than the code handling displays in Motorola’s previous code.

226 CLIM (Common Level Interface Manager) is the final component of the Darwin Ergonomics Platform. As explained by Mr Ley in his first affidavit (at [37]-[39]), [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Mr Ley stated that, in the previous (Astro) ergonomics platform, there was no equivalent to CLIM, with the applications instead being more tightly coupled to [REDACTED] [REDACTED] [REDACTED]. The fact that CLIM added a level of abstraction between the applications and [REDACTED] [REDACTED] [REDACTED] was a significant improvement.

227 In understanding the evidence, it is also helpful to note the convention generally adopted by the Darwin development team for naming computer files within the platform. Mr Ley explained (first affidavit at [41] and [44]) that the prefixes ‘com_’ (common) and ‘cor_’ (core) were generally applied to files that are used by more than one component of the Darwin Ergonomics Platform; the prefix ‘rs_’ was generally applied to radio-specific files; and the prefix ‘svc_’ was applied to files comprising service functions that the Darwin platform provided to applications.

C.2     EMT component of the Darwin Ergonomics Platform

The copied code

228 The code that was copied by Hytera from the EMT component of the Darwin Ergonomics Platform is identified in Part 1 of the Annexure to these reasons. The copied code comprises:

(a)    parts of 6 header files and one source file copied into Hytera source code; and

(b)    unspecified but substantial parts of 12 further source files which were copied into Hytera source code that was compiled into the library file raf_arm9.lib.

Evidence relevant to the copied code

229 In his first affidavit, Mr Ley described the Motorola files from which code was copied into Hytera source code:

(a)    cor_emt_app_defines.h and com_ergo_platform_app_defines.h provide [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(b)    cor_emt_user_defines.h [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(c)    com_cp_button_def.h defines [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(d)    svc_applications.h and svc_interact_mgmt_services.h [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Specifically, svc_applications.h [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. svc_interact_mgmt_services.h [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

230 In his second affidavit, Mr Ley gave the following description of each of the 12 further source files from within the EMT component that were found to be within the library file raf_arm9.lib:

(a)    com_ergo_platform_utils.c contains [REDACTED] [REDACTED] that are used by different Darwin core components - for example, this contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(b)    cor_emtds_acbl_services.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(c)    cor_emt_acrt.c relates to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In summary, these [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This file contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(d)    cor_emt_adt.c relates to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In summary, this [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] is used to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This file contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(e)    cor_emt_application_manager.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(f)    cor_emt_app_interact_mgr.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(g)    cor_emt_init.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(h)    cor_emt_pending_queue_services.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(i)    cor_emt_process_xlate_inputs.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(j)    cor_emt_task.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(k)    svc_applications.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(l)    svc_interact_mgmt_services.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

231 As can be seen from the foregoing, much of the copied code relates to [REDACTED] [REDACTED] [REDACTED] within EMT. Both Mr Zetzl and Mr Ley gave evidence about the design of the code implementing [REDACTED] [REDACTED] [REDACTED] within EMT as part of the Darwin Ergonomic Platform. Mr Zetzl stated (first affidavit at [31]) that a key role of the Darwin Ergonomics Platform is [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. For example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Mr Ley explained (first affidavit at [71]) that [REDACTED] [REDACTED] [REDACTED] was a particular problem during the design phase of the Darwin Ergonomic Platform. The initial design aim was that [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] would be sufficient [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. However, as the features were developed, it became apparent that [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] would not be sufficient and the design was changed [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

232 Mr Ley exhibited to his first affidavit a document that described the architecture of the Darwin Ergonomics Platform. In submissions, Motorola drew attention to the aspects of the design of EMT’s management of application interactions:

(a)    EMT implements [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This means that [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This is defined when the code is compiled, but EMT also contains a function that can be called [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] dynamically while the radio is running.

(b)    The [REDACTED] [REDACTED] [REDACTED] [REDACTED] are assigned in a [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The [REDACTED] contains [REDACTED] [REDACTED] [REDACTED] all applications present on the radio [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] and the information needed by EMT for each application [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], including [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. A further [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], is created dynamically when the radio is running and contains effectively a subset of [REDACTED] [REDACTED], being [REDACTED] [REDACTED] corresponding to the currently running applications only.

(c)    The [REDACTED] [REDACTED] [REDACTED] [REDACTED] are used to construct [REDACTED] [REDACTED] [REDACTED], called [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. An illustrative example is shown in the following diagram, showing a portion of [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] (the [REDACTED] [REDACTED] shown in the diagram are arbitrary for example purposes, and are abbreviated for clarity):

[REDACTED]

(d)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(e)    Mr Ley and his team determined that there may be specific [REDACTED] that require deviation from the “default” outcome dictated by the [REDACTED] [REDACTED]. As a consequence, they also developed [REDACTED] [REDACTED] [REDACTED] [REDACTED], which contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. If [REDACTED] [REDACTED] [REDACTED] is specified for a given application, it will be added to [REDACTED] [REDACTED] [REDACTED] [REDACTED], and the corresponding [REDACTED] [REDACTED] [REDACTED] [REDACTED] will be recorded in that application’s [REDACTED] [REDACTED] [REDACTED] [REDACTED]; EMT will check [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] and, if so, use [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. EMT also contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

233 Prof Wicker gave evidence with respect to the 6 header files and the source file which were copied into Hytera’s source code.  In his first affidavit (at [72]), Professor Wicker described the copied code as relating to fundamental data structures (such as type definitions), macros and function prototypes that are used by the EMT and as including the following:

(a)    [REDACTED] [REDACTED] providing [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] and the ability of EMT to change these properties, which are essential to enable EMT to [REDACTED] [REDACTED] [REDACTED] [REDACTED] (for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] from within the file cor_emt_user_defines.h);

(b)    [REDACTED] [REDACTED] that are used to build [REDACTED] [REDACTED] [REDACTED] used by EMT, which constitute [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] which form the basis for EMT’s [REDACTED] [REDACTED] (for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] from within the file cor_emt_user_defines.h);

(c)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] that are used to provide the ability for applications [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] (for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] from within the file cor_emt_user_defines.h); and

(d)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] used to enable [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] (for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] from within the file cor_emt_user_defines.h [REDACTED] [REDACTED] from within the file com_ergo_platform_app_defines.h).

234 In respect of this code, Prof Wicker expressed the following opinions in his first affidavit, which we accept:

74.     In my view, these are important parts of EMT. These fundamental structures set out the ‘framework’ upon which the rest of the code comprising EMT is built, and the ‘language’ with which the code communicates with other code both within EMT and outside it. Indeed, in my opinion, these parts of the code reflect much of the skill, effort and creativity that went into developing EMT. For example, in my opinion these aspects of the code reflect the planning and understanding of what the architecture would be, including (by way of example) aspects such as [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], and [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Once this ‘framework’ is in place, it greatly assists in writing the ‘source’ files that are built on it. For example, once the structures related to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] are in place, writing the code that handles [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] is considerably simpler than writing such code without that framework already existing.

75.     Moreover, because this ‘framework’ is fundamental to the rest of the code, amending it requires considerable effort. This is because, if a developer were to amend elements of this framework, those amendments would in turn affect the rest of the code that was developed to work with that framework.

76.    Each of the features of EMT that these components relate to – [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]  – represent the core functionalities that EMT provides to the radio.

235 In the Joint Expert Report, Prof Rangan expressed his agreement with Prof Wicker’s opinion, and added that the copied EMT code includes fundamental data structures on which the framework is built.

236 In his first affidavit (at [77]), Prof Wicker observed that the code that he examined (principally header files) contained a number of function prototypes, which indicated that the related functions were likely to be found elsewhere in the software. However, he was unable to find the functions within the Hytera source code. That absence was subsequently explained when Hytera discovered the library file raf_arm9.lib, which, when disassembled, revealed that it contained the ‘missing’ source files, as described above.

237 This Court has previously concluded that the Hytera source code, from which the raf_arm9.lib library file was compiled, copied a substantial part of the Motorola source files identified within the library. Motorola submitted, and we accept, that the source files described above reflects the particular, creative, approach that Mr Ley and his colleagues at Motorola adopted when writing EMT. Many of these files relate to the same aspects of EMT’s designs as the EMT header files from which Hytera copied code, and which was the subject of Prof Wicker’s evidence. The source files involve the use of [REDACTED] [REDACTED] which are an essential aspect of providing the modular, abstracted design of EMT (and the Darwin Ergonomics Platform generally). As Mr Ley described in his first affidavit, Darwin was designed such that each component provides [REDACTED] [REDACTED] [REDACTED] [REDACTED], which can be called by other components or the applications in order to access the functions provided by that component without needing to know anything about [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

Evaluation

238 Motorola submitted, and we accept, that the code copied by Hytera from EMT, considered collectively, is a substantial part of EMT, determined by reference to the originality of the code that has been copied, the creative and intellectual contribution to the form of expression of the code, and such matters as the structure of the code and the choice and sequencing of commands. As Prof Wicker stated, the copied code from the EMT was fundamental to EMT and reflected much of the skill, effort and creativity that went into developing EMT. The copied EMT code included not only important data structures on which the framework of the EMT was built but also code (that was used to compile raf_arm9.lib) providing the functions relating to the same aspects of EMT’s design. The evidence demonstrates that considerable skill, judgment and effort were involved in creating the copied EMT code and also that the copied EMT code was significant or important in the context of the Motorola Work as a whole.

239 It can be accepted that the code copied by Hytera represents only a part of the EMT. Mr Hayes’ evidence indicates that the EMT comprises 100 computer files. However, the list of 100 files contains many duplicated files (each of the files com_cp_button_def.h, com_ergo_platform_app_defines.h, com_ergo_platform_user_defines.h, com_ergo_platform_utils.h, cor_single_linked_list.h, cor_emt_app_defines.h, cor_emt_user_defines.h, svc_applications.h, svc_heb_services.h, svc_interact_mgmt_services.h and svc_tone_services.h is listed 3 times, and each of the files com_ergo_platform_opcodes.h, com_ergo_platform_typedefs.h, print_adb.h, cor_emtds_acbl_services.h, cor_emt_acbl.h, cor_emt_adt.h, cor_emt_pending_queue_services.h, cor_emt_task.h, svc_fs_services.h, rs_common_utilities.c, rs_emt_default_sb_msg_handle.c, rs_emt_get_input_origin.c, rs_emt_handle_unused_input.c, rs_emt_load_init_mode_info.c, rs_emt_mode_arbitrator.c, rs_emt_process_cfeb_data_update.c, rs_emt_sb_translator.c and  rs_emt_virtual_source_subscriber.c is listed 2 times). Removing the duplicates reduces the number of files to 60. Hytera copied code from 19 of those files. In respect of the header files that were copied, only a proportion of the lines of code within the files were copied. In respect of the source files that were copied and compiled into the Hytera raf_arm9.lib library file, we have concluded that a substantial part of each of those files was copied. While the assessment of whether a substantial part of the work has been copied is concerned more with quality rather than quantity, it can be readily concluded that Hytera copied a substantial quantity of the EMT work.

240 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the EMT component of the Darwin Ergonomics Platform is a substantial part of that Motorola Work.

C.3    Xlate component of the Darwin Ergonomics Platform

The copied code

241 The code that was copied by Hytera from the Xlate component of the Darwin Ergonomics Platform is identified in Part 2 of the Annexure to these reasons. The copied code comprises:

(a)    parts of 5 header files and 3 source files copied into Hytera source code; and

(b)    unspecified but substantial parts of 5 further source files which were copied into Hytera source code that was compiled into the library file raf_arm9.lib.

Evidence relevant to the copied code

242 In his first and second affidavits, Mr Ley described the Motorola files from which code was copied into Hytera source code as follows:

(a)    com_ergo_platform_app_defines.h provides [REDACTED] that are used by components of the Darwin Ergonomics Platform to [REDACTED] [REDACTED] [REDACTED].

(b)    com_cp_button_def.h defines [REDACTED] [REDACTED] that are used by Xlate to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Essentially, these are [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], which form part of Xlate.

(c)    svc_xlt_services.h declares functions provided by Xlate relating to the translation of inputs. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(d)    rs_bco.h and rs_xlt_config_com.c are radio-specific implementation files. rs_bco.h [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], which is used by Xlate. rs_xlt_config_com.c has radio-specific Xlate functions.

(e)    rs_xlt_cpval_uiop_table.c provides [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This provides a level of abstraction of the codeplug within the Darwin platform and its applications, since the platform and applications can utilise the radio-specific [REDACTED] [REDACTED] [REDACTED] rather than needing to be aware of the specific values programmed in the codeplug.  

243 In his second affidavit, Mr Ley gave the following description of each of the 5 further source files from within the Xlate component that were found to be within the Hytera library file raf_arm9.lib:

(a)    com_ergo_platform_utils.c contains [REDACTED] [REDACTED] that are used by different Darwin core components (giving the example of [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]).

(b)    svc_xlt_services.c contains [REDACTED] [REDACTED] that are used by radio-specific [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The file contains [REDACTED] [REDACTED] [REDACTED] that enable Xlate to be used by other parts of the code (specifically [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]) [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(c)    cor_xlt_task.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(d)    cor_xlt_utilities.c contains [REDACTED] used by Xlate to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In other words, the file contains [REDACTED] [REDACTED] used by Xlate to perform its primary function of translating physical inputs into logical inputs.

(e)    cor_xlt_xe_functions.c contains [REDACTED] [REDACTED] that provide the [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

244 In his first affidavit (at [22]), Mr Ley explained that the role of Xlate is to translate physical button presses into logical button presses which it passes to EMT. In this way, EMT and applications do not need to know what physical buttons are present on the radio, but can be written to act on the logical input (which is device-agnostic). The Darwin Ergonomic Platform Architecture document describes the physical button presses as [REDACTED] [REDACTED] [REDACTED] [REDACTED] and the logical button presses as [REDACTED] [REDACTED]. Motorola submitted, and we accept, that the data structures within Xlate reflect the particular, creative, approach that Mr Ley and his colleagues at Motorola adopted when writing Xlate. For example, Mr Ley explained in his first affidavit (at [25]-[27]), that the following decisions were made during the creation of Xlate:

(a)    Although Xlate’s role is to translate physical inputs into logical inputs, he and his colleagues realised that [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. As such, Xlate was designed such that, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(b)    On some radios, inputs like buttons might have multiple different meanings, for example [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This functionality could have been implemented in the applications themselves. However, consistently with the aim of improving on Motorola’s previous translation code, Motorola designed Xlate to translate these presses as well, through the Xlate Extension (XE) functions.

(c)    Inputs might also have different meanings depending on [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Again, Motorola decided to design Xlate to handle these matters, rather than [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

245 Prof Wicker gave evidence with respect to the 5 header files and 3 source files which were copied by Hytera.  In his first affidavit (at [79] and [81]), Professor Wicker described the copied code from the 5 header files as containing fundamental aspects of the framework for the Xlate component of the Darwin ergonomics platform, including:

(a)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(b)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(c)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

246 Prof Wicker stated (at [81]) that Xlate is responsible for translating physical inputs into more generic logical inputs that it passes to EMT, as well as [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], and that the aspects of Xlate code that were copied into the Hytera source code were essential to Xlate providing these functions.

247 In his second affidavit, Prof Wicker discussed the additional source files that had been discovered by Hytera as part of its source code, which revealed copying of very substantial sections of the radio-specific files rs_xlt_config_com.c, rs_xlt_utilities.c and rs_xlt_cpval_uiop_table.c. Prof Wicker stated (at [99]-[100]) that his review of the code copied from those source files only reinforced the opinion expressed in his first affidavit that the code copied by Hytera represents significant and essential elements of the Motorola Work.

248 This Court has previously concluded that the Hytera source code, from which the raf_arm9.lib library file was compiled, copied a substantial part of the Motorola source files com_ergo_platform_utils.c, svc_xlt_services.c, cor_xlt_task.c, cor_xlt_utilities.c and cor_xlt_xe_functions.c. Motorola submitted, and we accept, that those source files are linked to the code copied from the Xlate header files, and also reflect the particular, creative, approach that Mr Ley and his colleagues at Motorola adopted when writing Xlate.

Evaluation

249 Motorola submitted, and we accept, that the code copied by Hytera from Xlate, considered collectively, is a substantial part of Xlate, determined by reference to the originality of the code that has been copied, the creative and intellectual contribution to the form of expression of the code, and such matters as the structure of the code and the choice and sequencing of commands. We accept the opinion of Prof Wicker that the copied code from Xlate represents fundamental aspects of the framework for Xlate, and that the copied code is essential to the means by which Xlate translates physical inputs into more generic logical inputs that it passes to EMT. The copied Xlate code included not only important data structures on which the framework of Xlate was built but also code (that was used to compile raf_arm9.lib) providing the functions relating to the same aspects of Xlate’s design. The evidence demonstrates that considerable skill, judgment and effort were involved in creating the copied Xlate code and also that the copied Xlate code was significant or important in the context of the Motorola Work as a whole.

250 It can be accepted that the code copied by Hytera represents only a part of the Xlate. Mr Hayes’ evidence indicates that the Xlate comprises 49 computer files. However, the list of 49 files contains many duplicated files (each of the files com_cp_button_def.h, com_ergo_platform_app_defines.h, com_ergo_platform_user_defines.h, com_ergo_platform_utils.h, cor_single_linked_list.h, cor_xlt_user_defs.h and svc_xlt_services.h is listed 3 times, and each of the files com_ergo_platform_opcodes.h, com_ergo_platform_typedefs.h, cor_xlt_task.h, cor_xlt_utilities.h, rs_common_utilities.c, rs_umxe_protos.h, rs_xlt_config.c and rs_xlt_utilities.c is listed 2 times). Removing the duplicates reduces the number of files to 27. Hytera copied code from 13 of those files. In respect of the header files that were copied, only a proportion of the lines of code within the files were copied, although a larger proportion of the source files was copied. In respect of the source files that were copied and compiled into the Hytera raf_arm9.lib library file, this Court has concluded that a substantial part of each of those files was copied. While the assessment of whether a substantial part of the work has been copied is concerned more with quality rather than quantity, it can be readily concluded that Hytera copied a substantial quantity of the Xlate work.

251 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the Xlate component of the Darwin Ergonomics Platform is a substantial part of that Motorola Work.

C.4    UIT component of the Darwin Ergonomics Platform

Copied code

252 The code that was copied by Hytera from the UIT component of the Darwin Ergonomics Platform is identified in Part 3 of the Annexure to these reasons. The copied code comprises:

(a)    parts of 5 header files copied into Hytera source code; and

(b)    unspecified but substantial parts of 2 further source files which were copied into Hytera source code that was compiled into the library file raf_arm9.lib.

Evidence relevant to the copied code

253 In his first and second affidavits, Mr Ley described the Motorola files from which code was copied into Hytera source code as follows:

(a)    com_ergo_platform_app_defines.h provides [REDACTED] that are used by components of the Darwin Ergonomics Platform to [REDACTED] [REDACTED] [REDACTED].

(b)    com_cp_button_def.h defines [REDACTED] [REDACTED] that are used by Xlate to translate physical button inputs received from UIT into logical inputs.

(c)    svc_display_protocols.h and svc_string_utils.h contain [REDACTED] [REDACTED] [REDACTED] [REDACTED] that the Darwin platform provided to applications.  svc_display_protocols.h declares [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].  svc_string_utils.h [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(d)    cor_uit_user_defs.h includes [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

254 Mr Antilla provided a further explanation of the files svc_display_protocols.h and svc_string_utils.h. Mr Antilla stated (at [43] and [45]) that these files are part of the UIT component, which is responsible for the presentation of the display to the user. The file svc_display_protocols.h provides [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. For example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The file svc_string_utils.h provides [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. For example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

255 In his second affidavit, Mr Ley gave the following description of each of the 2 further source files from within the Xlate component that were found to be within the Hytera library file raf_arm9.lib:

(a)    com_ergo_platform_utils.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] - for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(b)    svc_string_utils.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] (for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]).

256 In his first affidavit (at [63]), Mr Ley stated that, in developing the code for UIT, there were a number of decisions that needed to be made along the way both in the initial design phase and also in the writing of the code. This was because there were any number of ways in which the code could be designed and written to achieve the desired functionality. Before starting work on writing the code, Motorola spent a lot of time and effort in designing how the desired functionality would be achieved, including in terms of identifying the tasks that would need to be executed to achieve this functionality and the individual functions that needed to be created in the code to execute those tasks. Even after this design work, the exact form of the code to be written for the relevant functions remained unclear, because there still remained flexibility in how the code for the relevant functions was to be written.

257 Prof Wicker gave evidence with respect to the 5 header files which were copied by Hytera.  In his first affidavit (at [79] and [81]), Professor Wicker described the copied code from the 5 header files as containing fundamental aspects of the framework for the UIT component of the Darwin Ergonomics Platform, including:

(a)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(b)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(c)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

258 This Court has previously concluded that the Hytera source code, from which the raf_arm9.lib library file was compiled, copied a substantial part of the Motorola source files com_ergo_platform_utils.c and svc_string_utils.c. Motorola submitted, and we accept, that those source files are linked to the code copied from the UIT header files, and also reflect the particular, creative, approach that Motorola adopted when writing UIT. In that regard, it can be noted that [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] is part of the code that was copied from the header file svc_string_utils.h, which is [REDACTED] [REDACTED] used in the source file svc_string_utils.c.

Evaluation

259 Motorola submitted, and we accept, that the code copied by Hytera from UIT, considered collectively, is a substantial part of UIT, determined by reference to the originality of the code that has been copied, the creative and intellectual contribution to the form of expression of the code, and such matters as the structure of the code and the choice and sequencing of commands. We accept the opinion of Prof Wicker that the copied code from UIT represents fundamental aspects of the framework for UIT, and that the copied code is essential to the means by which UIT generates user outputs to the particular radio hardware in response to requests from applications. The copied UIT code included not only important data structures on which the framework of UIT was built but also code (that was used to compile raf_arm9.lib) providing the functions relating to the same aspects of UIT’s design. The evidence demonstrates that considerable skill, judgment and effort were involved in creating the copied UIT code and also that the copied UIT code was significant or important in the context of the Motorola Work as a whole.

260 It can be accepted that the code copied by Hytera represents only a part of the UIT. Mr Hayes’ evidence indicates that the UIT comprises 111 computer files. However, the list of 111 files contains many duplicated files (each of the files com_cp_button_def.h, com_ergo_platform_app_defines.h, com_ergo_platform_user_defines.h, com_ergo_platform_utils.h, cor_single_linked_list.h, cor_uit_format_defs.h, cor_uit_svc_interface.h, cor_uit_user_defs.h and svc_display_protocols.h is listed 3 times and each of the files com_ergo_platform_opcodes.h, com_ergo_platform_typedefs.h, print_uit.h, cor_uit_class_handlers.h, cor_uit_class_handler_utils.h, cor_uit_control_block.h, cor_uit_dbs_protocols.h, cor_uit_display_req_handler.h, cor_uit_display_req_info.h, cor_uit_evaluator.h, cor_uit_format_display_handlers.h, cor_uit_indicator_req_handler.h, cor_uit_indicator_stacking.h, cor_uit_realizer.h, cor_uit_table_access_utils.h, cor_uit_task.h, cor_uit_timed_display_log.h, rs_common_utilities.c, rs_uit_formatter.h, rs_uit_formatter_table.c, rs_uit_indicator_mask_id.h and rs_uit_utils.c is listed 2 times). Removing the duplicates reduces the number of files to 71. Hytera copied code from 7 of those files. In respect of the header files that were copied, only a proportion of the lines of code within the files were copied. In respect of the source files that were copied and compiled into the Hytera raf_arm9.lib library file, we have concluded that a substantial part of those files were copied. Whilst the relatively small portion of the UIT that was copied must be taken into account, in our view the quality of what was taken is more significant than the quantity.

261 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the UIT component of the Darwin Ergonomics Platform is a substantial part of that Motorola Work.

C.5    Darwin Ergonomics Platform

Copied code

262 In addition to its allegations concerning each of the EMT, Xlate and UIT components of the Darwin Ergonomics Platform, Motorola also alleged that Hytera’s firmware was an adaptation of a substantial part of Motorola’s source code in the Darwin Ergonomics Platform. For the purposes of that allegation, Motorola relies upon:

(a)    all of the code that was copied by Hytera from the EMT, Xlate and UIT components of the Darwin Ergonomics Platform (as discussed in the preceding sections of Part C of these reasons); and

(b)    the code identified in Part 4 of the Annexure to these reasons, which comprises an unspecified but substantial part of two further source files copied into Hytera source code that was compiled into the library file raf_arm9.lib.

Evidence relevant to the additional copied code

263 The two additional source files from which Hytera copied a substantial part of the code are part of another component of the Darwin Ergonomics Platform called UIQ. As explained by Mr Ley in his first affidavit (at [22]), the role of UIQ is to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Mr Ley stated (at [27]) that Xlate and UIQ were significant improvements over Motorola’s previous ergonomics code. The previous code that handled button translations often went further and also implemented some of the feature itself (but did so inconsistently). For example, in some cases this meant that the implementation of a particular feature was split between different places in the platform. With the Darwin platform, different parts of the platform were divided more clearly, so that the core Xlate task is common to all features and [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. With respect to UIQ, with the previous platform [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. With the development of UIQ, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

264 In his second affidavit, Mr Ley gave the following description of each of the two UIQ source files copied by Hytera:

(a)    cor_uiq_task.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]; and

(b)    cor_uiq_utils.c contains [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

265 It is apparent from Mr Hayes’ evidence that UIQ is the smallest component of the Darwin Ergonomics Platform. Mr Hayes’ list of all of the files within the Darwin Ergonomics Platform shows only 7 files which have the letters ‘UIQ’ in the file name being: cor_uiq_task.h, cor_uiq_task.c, cor_uiq_user_defs.h, cor_uiq_utils.c, rs_uiq.h and rs_uiq.c. The two files that appear in the Hytera library file are significantly larger, by line count, than the other UIQ files.

Evidence of Prof Wicker

266 In his first affidavit, Prof Wicker expressed the following opinion with respect to the significance of the code copied from the Darwin Ergonomics Platform:

78    My comments above as to the importance of this code to EMT also apply as to its significance to the Darwin platform as a whole. As I noted in paragraph 55 above, EMT provides the key functions relating to running and managing applications, which I consider to be the primary purpose of the Darwin ergonomics platform.

…

82    … within the Darwin ergonomics platform, Xlate is responsible for translating physical inputs into more generic logical inputs that it passes to EMT, as well as handling more complex inputs such as multiple button presses, while UIT handles generating user outputs to the particular radio hardware in response to requests from applications. The aspects that, in my opinion, are copied into the Hytera Source Code are essential to these components providing these functions. As such, in totality, I consider that the code copied from the Darwin ergonomics platform is essential to the operation of the Darwin ergonomics platform as a whole.

Evaluation

267 We have concluded that the code copied by Hytera from the EMT, Xlate and UIT components of the Darwin Ergonomics Platform is a substantial part of each of those Motorola Works. The evidence relating to the functions of those programs within the Darwin Ergonomics Platform necessitates a conclusion that the copied code, considered in aggregate, is a substantial part of the Darwin Ergonomics Platform.

268 The EMT, Xlate and UIT components of the Darwin Ergonomics Platform comprises the vast majority of the software code within the Platform. Mr Hayes’ list of all of the files within the Darwin Ergonomics Platform shows 289 files, although as noted above the list contains many repeated file names. Ignoring the repeated file names for present purposes, 260 of the 289 files are designated in the list as being files within the EMT, Xlate and UIT components of the Darwin Ergonomics Platform. It can be concluded from the evidence explaining the role of those components within the Darwin Ergonomics Platform, and the relative size of those components, that they are highly significant to the Darwin platform. The evidence relating to the two UIQ files that were copied by Hytera does not add greatly to the assessment, but nor does it detract. UIQ is a small component which operates in conjunction with Xlate. It is significant that Hytera copied code from that component also.

269 Mr Ley’s evidence demonstrates that the writing of the EMT, Xlate and UIT components involved considerable skill, judgment and effort, which was reflected in the architecture of the code and the structure of the code and the choice and sequencing of commands. With respect to the code that was copied from those components, both Prof Wicker and Prof Rangan expressed the opinion that the code includes fundamental structures on which the framework for the Darwin Ergonomics Platform is built, and which reflect much of the skill, effort and creativity that went into developing the programs.

270 Again, it can be accepted that the code copied by Hytera represents only a part of the Darwin Ergonomics Platform. We reiterate, though, that the assessment of whether a substantial part of the work has been copied is concerned more with quality rather than quantity. Further, we have concluded earlier that Hytera copied a substantial quantity of both the EMT and the Xlate works.

271 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the Darwin Ergonomics Platform is a substantial part of that Motorola Work.

C.6    Mobile and Portable Firmware

Copied code

272 In addition to its allegations concerning each of the EMT, Xlate and UIT components of the Darwin Ergonomics Platform, and its allegations concerning the Darwin Ergonomics Platform, Motorola also alleged that Hytera’s firmware was an adaptation of a substantial part of Motorola’s source code in the Mobile and Portable Firmware. For the purposes of that allegation, Motorola relies upon:

(a)    all of the code that was copied by Hytera from the EMT, Xlate, UIT and UIQ components of the Darwin Ergonomics Platform (as discussed in the preceding sections of Part C of these reasons); and

(b)    the code identified in Part 5 of the Annexure to these reasons, which comprises parts of 6 header files and 2 source files copied into Hytera source code.

Evidence relevant to the additional copied code

273 The additional code that was copied from the Mobile and Portable Firmware was discussed in the evidence in four categories:

(a)    the header file vris.h;

(b)    the header file rs_cpvalue_list.h;

(c)    the following header and source files from Motorola’s ‘power up’ application: app_powerup.h; app_powerup.c; and powerup_app_launch_handler.c; and

(d)    the header files ListenerBase.h, EventBase.h and NotifierBase.h.

274 Each is considered in turn.

Virtual Radio Interface Standard (VRIS)

275 In respect of the file vris.h, Prof Wicker explained in his first affidavit that the file relates to the Virtual Radio Interface Standard (VRIS). The VRIS application appears to be within the component marked “VRIS” in the diagram of the Matrix Subscriber Firmware Architecture reproduced in section C.1 of these reasons, and it is described in the Matrix Subscriber Firmware Architecture Overview annexed to Mr Zetzl’s first affidavit.

276 In his first affidavit (at [20]), Mr Ley explained that VRIS was a Motorola proprietary hardware abstraction layer between the low level code and the higher levels of code. It enabled the higher levels of code to be designed for VRIS, rather than for the specific hardware being used on the device. Mr Antilla further explained (at [23]) that VRIS is the internal name for the application programming interfaces that are used by the Darwin Ergonomics Platform to access low level drivers.

Xlate and rs_cpvalue_list.h

277 Mr Ley explained that the file rs_cpvalue_list.h is associated with the Xlate program. As discussed earlier, Xlate takes the physical user inputs from UIQ and applies a logical meaning to them. Xlate does this by [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. It then sends this logical input to EMT. In his second affidavit (at [42]), Mr Ley stated that rs_cpvalue_list.h is used to define the feature values that are programmed to user inputs (including buttons, menus and switches). It is generally accessed by Xlate as part of its user input translation services.

The Power Up application

278 By reference to the diagram of the Matrix Subscriber Firmware Architecture reproduced in section C.1 of these reasons, Mr Zetzl stated (first affidavit at [29(c)]) that the Power Up application is within the component marked ‘Initialisation’.

279 Mr Ley gave evidence about the specific files app_powerup.h, app_powerup.c and powerup_app_launch_handler.c in his second affidavit. He explained (at [43]-[44]) that these files relate to the Power Up application which is launched when the radio is powered up. Among other things, the Power Up application [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. After describing the copied code, Mr Ley expressed an opinion about the uniqueness of the coding of the Power Up application (at [49]):

[REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

The ListenerBase.h, EventBase.h and NotifierBase.h files

280 The location of the ListenerBase, EventBase and NotifierBase components of the Matrix platform is not clearly indicated on the diagram of the Matrix Subscriber Firmware Architecture reproduced in section C.1 of the reasons. Nevertheless, the evidence indicates that the ListenerBase.h, EventBase.h and NotifierBase.h files are present in both the Mobile and Portable Firmware and the DSP Firmware, and their role (and significance) is the same in each of those Works.

281 A description of the functionality of these files was provided by Mr Zetzl and Mr Simms. Mr Zetzl explained in his second affidavit (at [15]) that these files define connection types and methods of communication that are permitted by the Motorola’s Global Common Platform to enable the different software components that make up the Mobile and Portable Firmware (and the DSP Firmware) to communicate with one another. Specifically:

(a)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] (defined in ListenerBase.h and NofitifierBase.h, respectively) [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]; and

(b)    [REDACTED] [REDACTED] [REDACTED] (defined in EventBase.h) provides [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

282 Mr Simms, who was involved in the development of these files, similarly explained in his second affidavit that these files (and their associated source files) together formed part of the event notification system in Motorola’s DSP Firmware (and, as noted above, Mobile and Portable Firmware), and that this system enables software components to communicate with other software components. Mr Simms illustrated the function of the files as follows (second affidavit at [17]):

[REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

283 In relation to the header files specifically, Mr Simms explained (second affidavit at [18]) that these files define the fundamental or ‘base’ classes for these types of communications in the event notification system. Software components ‘inherit’ these classes in order to access their methods and data; for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In addition to these base classes, there are also a number of further classes that ‘inherit’ the functionality provided by the base classes and extend them to provide further functionalities.

Evidence of Prof Wicker and Prof Rangan

284 In his first affidavit, Prof Wicker expressed the following opinion with respect to the significance of the Darwin Ergonomics Platform to the Mobile and Portable Firmware (at [82]):

Based on my review of the documents and affidavits set out in paragraphs 45 and 47 above, in my opinion the Darwin ergonomics platform is a core functional element of the software for Motorola’s radio devices. It provides for fundamental elements that are needed in the radio devices, in particular the user interface and applications, via which the user controls the radio to cause it to perform its functions. In particular, I understand from the documents and affidavits that most of the features of the radio are implemented via one or more applications, which the user uses to access those features. I understand from my review of the Zetzl Affidavit in particular that the Mobile Firmware and Portable Firmware contain a number of different modules that perform different functions. However, the ability of the user to use and control these functions depends on the Darwin ergonomics platform, and specifically on the code that I have discussed above. It follows that, in my opinion, the copied code, as well as forming an essential part of the Darwin ergonomics platform, also forms a core element of the Mobile Firmware and the Portable Firmware in their totality.

285 In his second affidavit (at [100]), Prof Wicker stated that the further code he had considered in the affidavit only reinforced his view that the totality of the code copied by Hytera represents significant and essential elements of each of the Motorola Works, including the Mobile and Portable Firmware.

286 In the Joint Expert Report, Prof Wicker expressed the following opinions:

Much of the code listed above has been copied from the Darwin ergonomics platform and the framerLib library (which contains the code for the Framer, L1 Timer and QSPI components of Motorola’s DSP Firmware). In my opinion, these components are core, foundational, components of the entire Motorola Programs, in that they provide functionality that is utilised by other parts of the Motorola Programs to achieve their functions. In short, the radios would not work without this code.

As an example, it would be possible to remove one or more radio applications while ensuring that the remainder of the firmware continued to compile and operate correctly (albeit lacking one or more features, which may be significant). However, if the Darwin ergonomics platform – or the code from it that I consider has been copied into the Hytera source code – were removed, none of those applications would function. Without the copied code from the Darwin ergonomics platform, Hytera would not have had a platform on which to build its applications. If that code were replaced with a different application framework, each of those applications would have to be rewritten, possibly from scratch, to work with that application framework. Similar comments apply to the framerLib library.

These parts of the code reflect much of the skill, effort and creativity that went into developing EMT and the framer/L1 timer/HAL code. For example, in my opinion these aspects of the code reflect the planning and understanding of what the architecture would be, including (by way of example) aspects such as [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], and [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Once this ‘framework’ is in place, it greatly assists in writing the ‘source’ files that are built on it. For example, once the structures related to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], writing the code that handles [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] is considerably simpler than writing such code without that framework already existing.

Moreover, because this ‘framework’ is fundamental to the rest of the code, amending it requires considerable effort. This is because, if a developer were to amend elements of this framework, those amendments would in turn affect the rest of the code that was developed to work with that framework.

287 Prof Rangan expressed the following opinion concerning the significance of the Darwin Ergonomics Platform in the Joint Expert Report:

Regarding software architecture, the Motorola’s Darwin ergonomics platform was a unique, sophisticated and complex platform for providing the ergonomics and application framework in Motorola’s DMR radios, as also reflected by the significant amount of time and effort spent by Motorola engineers in developing the software requirements, architecture, design, evaluation and code implementing this platform.

…

Due to the fundamental nature of the copied code, and the architectural nature of the copying, large parts of the Motorola code would in some ways be influenced by the copied code.

288 As set out earlier in these reasons, in his fifth affidavit (at [161]-[162]), Prof Rangan also expressed the opinion that the Motorola header files copied by Hytera provide the structure for the code in the Motorola Works, and are fundamental to the overall framework of the various Motorola Works, and the overall architecture of the software for Motorola’s DMR radio devices. In particular, they form the basis for, and give effect to, the overall framework and architecture of the Darwin Ergonomics Platform and the rest of the Mobile and Portable Firmware (as well as Motorola’s L1 Timer subsystem and the rest of the DSP Firmware). Prof Rangan stated that he considered that the Motorola header files copied by Hytera reflect the output of significant creativity from the Motorola engineers who designed and developed them. These files form part of, and give effect to, a unique, sophisticated and complex framework architecture, as also reflected by the significant amount of time and effort spent by Motorola engineers in developing this architecture and code.

Evaluation

289 It is necessary to assess whether the code copied by Hytera from the Darwin Ergonomics Platform, and from the eight further files within the Mobile and Portable Firmware, together constitute a substantial part of the Mobile and Portable Firmware.

290 Although we have earlier rejected Mr Brown’s line counting evidence, it must be accepted that, assessed quantitatively, the copied code is a small proportion of the Mobile and Portable Firmware. The total number of files within the Mobile and Portable Firmware is in the order of 5,000 (although this count is likely to be significantly overstated by the replication of files within the firmware), and code has been copied from 45 files. Even allowing for the overstatement of the total number of files, it is apparent that the copied code is a small proportion of the Mobile and Portable Firmware.

291 Motorola submitted that the code copied from the Darwin Ergonomics Platform is a substantial part of both the Mobile and Portable Firmware because the copied code “directly influenced the form of expression (in particular, the structure) of each of the applications present in the Mobile and Portable Firmware, which is the code by which essentially every feature of the Mobile and Portable Firmware is implemented”. The submission is overstated and is not supported by the evidence. The ‘ergonomics layer’ of the software handles the user interaction with the radio devices, including the user interface and inputs from and outputs to the user. The ‘ergonomics layer’ consists of the Darwin Ergonomics Platform and ‘applications’. Mr Ley explained that every feature of the radio that a user interacts with has an ‘ergonomics’ component and is implemented as an application. However, it is those applications that interact with the Darwin Ergonomics Platform, not “every feature of the Mobile and Portable Firmware” as submitted by Motorola.

292 We accept, though, that the Darwin Ergonomics Platform is the component of the Matrix platform that handles the user interaction with the radio devices, and can be considered a qualitatively important, albeit quantitatively small, part of the overall firmware. Mr Ley explained that a primary objective in developing the Darwin Ergonomics Platform was to address issues with prior iterations of ergonomics code at Motorola. The aim of the Darwin project was to develop an application environment in which different radio functionalities could be developed in a way that did not couple the code together, and in a way that could be readily used on different radio products. This was done by separating the application environment (also referred to as the Darwin ‘core’ or ‘platform’) from the functionalities themselves (also referred to as ‘applications’ or ‘features’); this is also referred to as creating a layer of ‘abstraction’ between the platform and applications. Both Prof Wicker and Prof Rangan expressed the opinion that writing the Darwin Ergonomics Platform involved skill, effort and creativity. Prof Rangan gave evidence that the Darwin Ergonomics Platform was a unique, sophisticated and complex platform for providing the ergonomics and application framework in Motorola’s DMR radios. We accept that evidence.

293 Prof Wicker expressed the opinion that “the radios would not work” without the Darwin Ergonomics Platform, explaining that if the Darwin Ergonomics Platform were removed, none of the radio applications (that is, a radio feature that the user interacts with) would function. We accept the accuracy of that opinion, but it is not determinative of, and arguably is not relevant to, the question of copyright infringement. As explained by the plurality in Data Access at [83]-[84], a “but for” essentiality test is not a useful test for determining whether computer code copied from a computer program is a substantial part of the program – removal of any part of the computer program will usually prevent the program from functioning, either at all or at least as intended.

294 Of more significance, though, is Prof Wicker’s opinion concerning the relationship between the Darwin Ergonomics Platform and the writing of the code for the applications that interface with the Darwin Ergonomics Platform. Prof Wicker expressed the opinion that the copied code reflects the planning and understanding of the architecture of applications, such as the way in which [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. To the same effect is Prof Rangan’s opinion that, due to the fundamental nature of the copied code, and the architectural nature of the copying, large parts of the Motorola code would in some ways be influenced by the copied code.

295 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the Mobile and Portable Firmware is a substantial part of that Motorola Work. In arriving at that conclusion, we are most influenced by the lay and expert evidence that establishes the originality and creativity associated with the Darwin Ergonomics Platform and the importance of the Darwin Ergonomics Platform within the Mobile and Portable Firmware. As Mr Ley explained, the code was written so as to create a layer of ‘abstraction’ between the platform and applications. Prof Rangan described it as a unique, sophisticated and complex platform for providing the ergonomics and application framework in Motorola’s DMR radios. The platform is an important part of the Mobile and Portable Firmware, because it controls the user interface with the radios. The evidence relating to the eight additional files that were copied by Hytera does not add greatly to our assessment, but nor does it detract. It is significant that Hytera copied code from those additional components of the Mobile and Portable Firmware.  Whilst the relatively small portion of code that was copied must be taken into account, in our view the quality of what was taken, particularly in respect of the Darwin Ergonomics Platform, is more significant rather than the quantity.

PART D: DSP FIRMWARE

D.1    Introduction

296 As introduced in section C of these reasons, each of Motorola’s mobile and portable DMR devices, and each base station, was also installed with what was known as the ‘DSP Firmware’, which was the firmware that operated the DSP (digital signal processor) within those devices and base stations. As explained by Mr Zetzl (first affidavit at [10]), the DSP is responsible for low-level audio processing (for example, demodulating the incoming signal and processing the audio signal from the microphone).

297 Motorola alleged that Hytera’s firmware was an adaptation of a substantial part of Motorola’s source code in:

(a)    each of the Framer and L1 Timer components of the framerLib Library program;

(b)    the framerLib Library program;

(c)    the HAL Serial Buffer; and

(d)    the DSP Firmware.

298 Each of the Framer, L1 Timer and HAL Serial Buffer are part of the DSP Firmware and are represented on the diagram of the Matrix Subscriber Firmware Architecture reproduced in section C.1 of these reasons. By reference to that diagram, Mr Zetzl stated in his first affidavit (at [34]) that the low level of the DSP Firmware consists of the components identified as HAL, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] Framer and L1 Timer.

299 Mr Zetzl stated (first affidavit at [32]) that the HAL (hardware abstraction layer) is a component of both the DSP Firmware and the Mobile and Portable Firmware (in which it is called HALi - hardware abstraction layer instantiation). The role of HAL is to provide an interacting layer between the firmware and the radio hardware so that the firmware can be, as much as possible, written in a manner that is isolated (that is, independent) from the hardware on which it will be run (although some software will inevitably be hardware-specific). The Matrix project was the first to use this component.

300 Mr Zetzl explained (first affidavit at [35]) that HAL, L1 Timer, Framer [REDACTED] [REDACTED] [REDACTED] are all part of the ‘Layer 1 (L1) Timer subsystem’. This subsystem composes timing-critical and complex hardware programming sequences in a flexible manner that allows re-use across many different radio protocols. The purpose of the L1 Timer subsystem within the Matrix platform is to regulate the timing of various actions (which Motorola describes as [REDACTED] in the Motorola programs) that have to occur on the DSP so as to ensure compliance with timing required by slotted communication protocols (such as the time-division multiple access (TDMA) protocol). [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Within the L1 Timer subsystem, the role of each component is  as follows:

(a)    The L1 Timer provides the timing functionality of the L1 Timer subsystem. It provides an extremely accurate and precise timer that enables the L1 Timer subsystem to do programming at very specific times.

(b)    The Framer is responsible for [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(c)    The [REDACTED] [REDACTED] [REDACTED] [REDACTED] is used primarily for [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

301 Mr Zetzl stated (first affidavit at [36]) that three other components that comprise the low level of the DSP Firmware are the [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. It is only necessary to refer to the [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

302 Mr Zetzl stated (first affidavit at [80]) that the L1 Timer subsystem and HAL components had originally been developed for a Motorola product line known as the HPD product. The Matrix project used those components with further developments. Mr Zetzl explained that the decision was made to further develop those components because they provide very rigid timing. Rigid timing was critical for the success of the DMR products because such products were required to implement a TDMA protocol, which has very strict timing requirements.

303 Mr Simms also gave extensive evidence about the L1 Timer subsystem. In his first affidavit (at [16]), Mr Simms explained that, when he refers to the L1 Timer subsystem, he is referring to a range of software components including the [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED], Framer, L1 Timer, QSPI and HAL.

304 In his first affidavit (at [9]), Mr Simms reproduced a diagram representing some of the key concepts associated with the L1 Timer subsystem (being a diagram extracted from an internal Motorola presentation created by Mr Simms for internal training purposes):

[REDACTED]

305 Mr Simms explained (at [10]-[12]) that the smallest element shown in the diagram is the [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

306 Mr Simms stated (at [21]) that the [REDACTED] [REDACTED] [REDACTED] [REDACTED] receives [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

307 Mr Simms stated (at [13]-[14]) that a key feature of the L1 Timer subsystem (and specifically the Framer component) is that it is able to quickly and flexibly adapt to changes and compose the required sequences of events without having to rebuild each sequence from scratch. The flexibility arises from the L1 Timer subsystem’s (and specifically the Framer’s) design as a class-based object-oriented system. The Framer code defines [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. As a result, [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

308 Mr Simms explained (at [29]-[31]) that the L1 Timer subsystem that was used in, and further developed for, the Matrix platform was first developed for the HPD product, which is a data modem that was developed by Motorola from around 2002 to 2004. Mr Simms was part of the team within Motorola that worked on the design and architecture of the HPD product, and specifically the L1 Timer subsystem. The subsystem was developed from ‘scratch’, being designed to overcome deficiencies encountered in previous Motorola products. Mr Simms stated (at [32]) that the L1 Timer subsystem was designed as a new software solution to provide a creative and organized framework for sequence management to address deficiencies in previous products, and in particular to be able to handle more complex functionality and timing requests in a flexible, precise and responsive manner that could be adapted across different requirements.

309 Mr Simms explained (at [34]) that one of the decisions he made with the development team was to develop the majority of the L1 Timer subsystem code in C++ language (with some parts written in C language). Mr Simms said that C++ is what is known as an ‘object-oriented’ programming language. Object-oriented coding is a programming tool to help manage data and operations. The approach centres on the use of ‘classes’ (with an ‘object’ being an instance of a class). A class [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] can be defined to hold certain data, methods or functions.  [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

310 Mr Simms stated (at [37]) that he commenced work on the Matrix project in around 2004 and he continued working on that project until 2008 or 2009. His role in the Matrix project was to design and oversee the implementation of the L1 Timer subsystem within the Matrix platform. Specifically, he was responsible for leading a team in the further development of the L1 Timer subsystem, including so that it could perform new functions required for the Matrix products that it was not able to do in the previous Motorola products as well as the integration of the modified L1 Timer subsystem code into the Matrix platform. He also provided support during the Matrix project as an ad hoc consultant for the architecture and design for the whole low level for the Matrix platform, including to provide support to ensure that other components within the Matrix platform operated effectively with the L1 Timer subsystem. Mr Simms stated (at [48]) that the process of code development and integration resulted in approximately 20 to 25 per cent of the L1 Timer subsystem code being specifically developed for the Matrix platform. Modification and integration of the L1 Timer subsystem into the Matrix platform was a challenging and complicated task, and often required Mr Simms and his team to design and implement innovative coding solutions to support new functionality that was added to the L1 Timer subsystem. Because of the unique design of the L1 Timer subsystem code, and the precise and dynamic nature of the tasks that it was required to execute, modifying and integrating the L1 Timer subsystem code required a detailed understanding of the code and the inter-related nature of the different components.

311 In his third affidavit (at [10]), Mr Simms concluded his evidence by stating that, in his view, the L1 Timer subsystem, and specifically each of the Framer and L1 Timer components, are of fundamental and critical importance to the overall functionality of Motorola’s DMR radio devices. This is because they provide the sequence management capabilities which are required to operate all of the functionality executed in the DMR radio device. These sequence management capabilities are used widely in the DMR radio device to perform critical functions such as initiating transmissions, handling receptions, radio frequency channel control and timeslot synchronization. Mr Simms stated that the code for the L1 Timer subsystem in the Matrix DSP Firmware was one of the most challenging and difficult to develop, including because of the need to address the sequence management issues encountered in previous projects, and also in order to handle the complex functionality and timing requests required by the Matrix project and to integrate the L1 Timer subsystem into the Matrix platform as a whole.

D.2    Framer component of the framerLib Library program

Copied code

312 The code that was copied by Hytera from the Framer component of the framerLib Library program is identified in Part 6 of the Annexure to these reasons. The copied code comprises:

(a)    parts of 2 header files copied into Hytera source code; and

(b)    unspecified but substantial parts of 5 further source files which were copied into Hytera source code that was compiled into the library file rfhal_c55.lib.

Evidence relevant to the copied code

313 In his first affidavit (at [22]), Mr Simms described the Framer component of the framerLib Library program as a [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

314 Mr Simms explained (at [80]-[82]) that the file frame_primitive.h provides the main definitions for [REDACTED] [REDACTED] [REDACTED] within the Framer component. As stated earlier, [REDACTED] [REDACTED] is a term used in Motorola code and documentation to refer to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In relation to the lines of code copied by Hytera, Mr Simms stated that:

(a)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

(b)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

315 Mr Simms explained (at [85]-[87]) that the file frame_list_primitive.h provides the main definitions [REDACTED] [REDACTED] [REDACTED] [REDACTED] within the Framer component. As stated earlier, [REDACTED] [REDACTED] [REDACTED] is a term used in the Motorola code to refer to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In relation to the lines of code copied by Hytera, Mr Simms deposed that:

(a)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(b)    As is the case with the frame_primitive.h file, this file also includes [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(c)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

316 As stated earlier, the library file rfhal_c55.lib discovered by Hytera reveals that it copied from the Framer component an unspecified, but substantial part, of 5 source files which included the files frame_primitive.cpp and frame_list_primitive.cpp being the source files associated with the two header files discussed in Mr Simms’ evidence, as well as the source files framer.cpp, default_frame_list.cpp and run_dvi.cpp.

317 In his first affidavit, Prof Wicker stated (at [83], in respect of both Framer and the L1 Timer):

The Framer and L1 Timer provide a way of [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] system in the radios, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. They form a powerful tool, as they [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. There are lots of ways in which a similar functionality could have been achieved, of which the Framer and L1 Timer is just one way to achieve this functionality, and one that I consider reflects a substantial amount of ingenuity, creativity and effort on behalf of the Motorola engineers who developed these components. This also reflects my opinion in respect of the particular code that I consider has been copied from the Framer and L1 Timer components of the Motorola Source Code into the Hytera Source Code.

318 Prof Wicker stated (at [84] and [85]) that much of the code that he considered had been copied by Hytera from the Framer and L1 Timer components relates to fundamental [REDACTED] [REDACTED] [REDACTED] [REDACTED] that are used by the Framer and L1 Timer components, and that they set out the ‘framework’ upon which the rest of the code comprising the Framer and L1 Timer is built (for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] and [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] from within the file frame_list_primitive.h).

319 Prof Wicker expressed the same opinions in the Joint Expert Report and stated that, in his opinion, the copied code reflects much of the skill, effort and creativity that went into developing, relevantly, the Framer and L1 Timer code.

Evaluation

320 Motorola submitted, and we accept, that the code copied by Hytera from Framer, considered collectively, is a substantial part of Framer, determined by reference to the originality of the code that has been copied, the creative and intellectual contribution to the form of expression of the code, and such matters as the structure of the code and the choice and sequencing of commands. We accept the unchallenged evidence of Mr Simms that the code for the L1 Timer subsystem (which includes Framer) was one of the most challenging and difficult to develop. We accept the opinion of Prof Wicker that there are lots of ways in which a similar functionality could have been achieved, of which the Framer is just one way to achieve the functionality, and one that reflects a substantial amount of ingenuity, creativity and effort on behalf of the Motorola engineers who developed these components. The copied Framer code included not only important [REDACTED] [REDACTED] on which the framework of Framer was built but also code (that was used to compile the library file rfhal_c55.lib) providing the functions relating to the same aspects of Framer’s design. The evidence demonstrates that considerable skill, judgment and effort were involved in creating the copied Framer code and also that the copied Framer code was significant or important in the context of the Motorola Work as a whole.

321 It can be accepted that the code copied by Hytera represents only a portion of the Framer component. Mr Hayes’ evidence indicates that the Framer component comprises 22 computer files contained in two directories, being the \rfhal\framerLib\framer\ directory and the \rfhal\framerLib\framer\release\ directory. However, in his first affidavit, Mr Simms explained (at [59]) that Motorola typically used ‘release’ directories to store the library (that is, a .lib file that contains the object code that is compiled from the source code) and header files that are required for the compiled object code to be converted into executable code. Thus, the files in the ‘release’ directory duplicate those in the main directory (and this can be seen from the duplicated file names). The main directory comprises only 13 files. Code was copied by Hytera from 7 of those 13 files. In respect of the header files that were copied, only a proportion of the lines of code within the files were copied. In respect of the source files that were copied and compiled into the Hytera rfhal_c55.lib library file, we have concluded that a substantial part of those files were copied. Although the assessment of whether a substantial part of the work has been copied is concerned more with quality rather than quantity, in the case of the Framer component a substantial quantity of code was also copied by Hytera.

322 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the Framer component of the framerLib Library program is a substantial part of that Motorola Work.

D.3    L1 Timer component of the framerLib Library program

Copied code

323 The code that was copied by Hytera from the L1 Timer component of the framerLib Library program is identified in Part 7 of the Annexure to these reasons. The copied code comprises:

(a)    parts of 2 header files copied into Hytera source code; and

(b)    an unspecified but substantial part of 1 further source file copied into Hytera source code that was compiled into the library file rfhal_c55.lib.

Evidence relevant to the copied code

324 In his first affidavit (at [23]), Mr Simms described the L1 Timer as a software component [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The L1 Timer receives [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

325 Mr Simms explained (first affidavit at [67]-[71]) that the file event_codes.h [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. As stated earlier, Motorola [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In relation to the lines of code copied by Hytera, Mr Simms deposed that the [REDACTED] relate to the three types of actions that the L1 Timer subsystem (and specifically the L1 Timer) can execute in the radio hardware:

(a)    The first action is launching what is referred to in Motorola’s code and documentation for the L1 Timer subsystem as [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(b)    The second action is [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(c)    The third action is launching what is referred to in Motorola’s code and documentation for the L1 Timer subsystem as [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

326 Mr Simms explained (at [75]-[77]) that the file l1timer.h is the header file for the entire class of L1 timer objects within the L1 Timer component. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. In relation to the lines of code copied by Hytera, Mr Simms deposed that lines 102 to 108 [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The [REDACTED] structure is a key structure in the operation of the L1 Timer subsystem because the [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

327 As stated earlier, the library file rfhal_c55.lib discovered by Hytera reveals that it copied from the L1 Timer component an unspecified, but substantial part, of a source file called l1timer.cpp, being the source file associated with the header file l1timer.h discussed in Mr Simms’ evidence.

328 Prof Wicker’s evidence with respect to both the Framer and L1 Timer components of the framerLib Library (in his first affidavit at [84] and [85]) have been set out earlier in the context of the Framer component. Prof Wicker also drew attention to Hytera’s copying of [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] from the file event_codes.h which [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Prof Wicker observed that these are essential to enabling the L1 Timer to execute the required tasks in the radio with their associated timing, being its core functionality. Prof Wicker also referred to Hytera’s copying of [REDACTED] [REDACTED] [REDACTED] [REDACTED] from within the file l1timer.h, which are used by the Framer and L1 Timer to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

Evaluation

329 Motorola submitted, and we accept, that the code copied by Hytera from L1 Timer, considered collectively, is a substantial part of L1 Timer, determined by reference to the originality of the code that has been copied, the creative and intellectual contribution to the form of expression of the code, and such matters as the structure of the code and the choice and sequencing of commands. We accept the unchallenged evidence of Mr Simms that the code for the L1 Timer subsystem (which includes the L1 Timer component) was one of the most challenging and difficult to develop. We accept the opinion of Prof Wicker that there are lots of ways in which a similar functionality could have been achieved, of which the L1 Timer component is just one way to achieve the functionality, and one that reflects a substantial amount of ingenuity, creativity and effort on behalf of the Motorola engineers who developed these components. The copied L1 Timer code included not only important data structures on which the framework of L1 Timer was built but also code (that was used to compile the library file rfhal_c55.lib) providing the functions relating to the same aspects of L1 Timer’s design. The evidence demonstrates that considerable skill, judgment and effort were involved in creating the copied L1 Timer code and also that the copied L1 Timer code was significant or important in the context of the Motorola Work as a whole.

330 It can be accepted that the code copied by Hytera represents only a portion of the L1 Timer component. Mr Hayes’ evidence indicates that the L1 Timer component comprises 10 computer files contained in two directories, being the \rfhal\framerLib\l1timer\ directory and the \rfhal\framerLib\framer\release\ directory. As stated in the context of the Framer component, the files in the ‘release’ directory duplicate those in the main directory (and this can be seen from the duplicated file names). The main directory comprises only 6 files. Code was copied by Hytera from 3 of those 6 files. In respect of the header files that were copied, the entirety of one file was copied and a proportion of the lines of code within the other file was copied. In respect of the source file that was copied and compiled into the Hytera rfhal_c55.lib library file, we have concluded that a substantial part of that file was copied. Although the assessment of whether a substantial part of the work has been copied is concerned more with quality rather than quantity, in the case of the L1 Timer component a substantial quantity of code was also copied by Hytera.

331 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the L1 Timer component of the framerLib Library program is a substantial part of that Motorola Work.

D.4    framerLib Library program

Copied code

332 In addition to its allegations concerning each of the Framer and L1 Timer components of the framerLib Library program, Motorola also alleged that Hytera’s firmware was an adaptation of a substantial part of Motorola’s source code in the framerLib Library program. For the purposes of that allegation, Motorola relies upon:

(a)    all of the code that was copied by Hytera from the Framer and L1 Timer components of the framerLib Library program (as discussed in the preceding sections of Part D of these reasons); and

(b)    the code which is identified in Part 8 of the Annexure to these reasons which comprises an unspecified but substantial part of the source file qspi.cpp which was copied into Hytera source code that was compiled into the library file rfhal_c55.lib.

Evidence relevant to the additional copied code

333 The additional source file from which Hytera copied a substantial part of the code is another component of the framerLib Library program called QSPI [REDACTED] [REDACTED] [REDACTED] [REDACTED]. As explained by Mr Simms in his first affidavit (at [26]), QSPI refers to a driver in the HAL that is used to transfer information between different components (and in particular to the integrated circuits). The L1 Timer passes requests for particular [REDACTED] [REDACTED] [REDACTED] to the QSPI. These [REDACTED] [REDACTED] [REDACTED] are requests for [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

Evaluation

334 We have concluded that the code copied by Hytera from the Framer and L1 Timer components of the framerLib Library program is a substantial part of each of those Motorola Works. The evidence relating to the functions of those programs within the framerLib Library program necessitates a conclusion that the copied code, considered in aggregate, is a substantial part of the framerLib Library program.

335 The Framer and L1 Timer components of the framerLib Library program comprise the vast majority of the software code within the program. Mr Hayes’ list of all of the files within the framerLib Library program shows 23 files, excluding the 16 files in the \release\ directory. Only 2 of those files are the QSPI component, being the source file qspi.cpp and the associated header file qspi.h. It can be concluded from the evidence explaining the role of Framer and L1 Timer components of the framerLib Library program, and the relative size of those components, that they are highly significant to the framerLib Library program. The evidence relating to the QSPI file that was copied by Hytera does not add greatly to the assessment, but nor does it detract. QSPI is a small component. Nevertheless, it is significant that Hytera also copied a substantial part of the source file qspi.cpp.

336 Mr Simms’s evidence demonstrates that the writing of the Framer and L1 Timer components of the framerLib Library program involved considerable skill, judgment and effort, which was reflected in the architecture of the code and the structure of the code and the choice and sequencing of commands. With respect to the code that was copied from those components, Prof Wicker expressed the opinion that the code includes fundamental structures on which the framework for the framerLib Library is built, and which reflect much of the skill, effort and creativity that went into developing the program.

337 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the framerLib Library program is a substantial part of that Motorola Work.

D.5    HAL Serial Buffer

Copied code

338 The code that was copied by Hytera from the HAL Serial Buffer is identified in Part 9 of the Annexure to these reasons. The copied code comprises the header file SerialHalBuffer.h which was copied into a Hytera source code file. The primary judge found that the whole of the file was copied (PJ [1929]).

339 Both Mr Simms (in his second affidavit at [8]-[9]) and Prof Wicker (in his first affidavit at [63]) stated that the HAL Serial Buffer consists of only two computer files: the header file, SerialHalBuffer.h, and the accompanying source file, SerialHalBuffer.cpp. Prof Wicker gave evidence (in his second affidavit at [58]) that Hytera’s source code revealed that Hytera had also copied the Motorola source file SerialHalBuffer.cpp with only a small number of changes. Although that evidence was not contradicted by Hytera’s expert witnesses, the primary judge did not make a finding that Hytera copied that file. His Honour gave the following reasons for not making that finding (see PJ [1905]-[1914]).

340 First, his Honour noted that Prof Wicker’s evidence (in his second affidavit at [58] and Annexure SBW-57) showed that the file SerialHalBuffer.cpp appeared in both the Mobile and Portable (host) Firmware and in the DSP Firmware. This is apparent from the names of the two Motorola directories in which the file is located: samurai\code\source\hal\omap1611\hal_dsp\ and samurai\code\source\hal\omap1611\hal_host\.

341 Second, his Honour found that Motorola’s case at trial was limited to an allegation of infringement of the HAL Serial Buffer within the DSP Firmware, and did not include an allegation of infringement of the same software within the host (Mobile and Portable) Firmware. Therefore, his Honour would only consider that case.

342 Third, the only side-by-side comparison of the code in Motorola’s version of SerialHalBuffer.cpp and Hytera’s version was contained in the evidence of Mr Brown, but Mr Brown’s comparison used the Motorola code from the host firmware, not the DSP Firmware. As a consequence, his Honour did not have a side-by-side comparison of the file SerialHalBuffer.cpp from Motorola’s DSP Firmware. His Honour was unwilling to find objective similarity in the absence of a side-by-side comparison.

343 For those reasons, his Honour found that Motorola had not established objective similarity in respect of the file SerialHalBuffer.cpp.

344 We record some misgivings about that conclusion for three reasons. First, it is uncontroversial on the evidence that the HAL Serial Buffer was contained in both the host firmware (where it is called HALi) and the DSP Firmware. As stated earlier, Mr Zetzl gave that evidence (first affidavit at [32]). In his first affidavit (at [62]), Mr Simms stated that the two sub-directories \hal_dsp\ and \hal_host\ contain source code for the device drivers, including the HAL Serial Buffer, for the DSP and host processor respectively. Second, in his second affidavit (at [10]), Mr Simms stated that the function served by the HAL Serial Buffer on the “host side” (in other words, within the Mobile and Portable Firmware) is identical to the HAL Serial Buffer in the DSP Firmware and the code is very similar. Third, Prof Wicker gave evidence that Hytera’s version of the file SerialHalBuffer.cpp was virtually identical to the Motorola file within the DSP Firmware, and that evidence was not contradicted in any material way by Hytera’s experts.

345 Nevertheless, there was no appeal by Motorola from the primary judge’s finding that Motorola had not proved objective similarity in respect of the file SerialHalBuffer.cpp. As a result, the discussion below is confined to the file SerialHalBuffer.h.

Evidence relevant to the copied code

346 In his first affidavit (at [27]), Mr Simms explained that the HAL (Hardware Abstraction Layer) is a software component providing hardware abstraction for software applications operating on a particular hardware platform. This means that the software components (specifically the L1 Timer and QSPI within the L1 Timer subsystem, and also other software components not in the L1 Timer subsystem) are able to send instructions to the hardware without needing to know the particulars of the hardware. Both the L1 Timer and QSPI communicate time-sensitive commands to the HAL, so that the HAL can then instruct the radio hardware to execute the relevant actions accordingly and at the appropriate time. The HAL uses a number of drivers to communicate instructions to the hardware.

347 Mr Simms stated (at [28]) that one aspect of the HAL is the HAL Serial Buffer which encapsulates [REDACTED] [REDACTED] [REDACTED] for all objects implementing the HAL Serial interfaces. In other words, when instructing the different drivers in the HAL to transmit data, the HAL Serial Buffer functions [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This allows for more efficient memory storage and transfer of data. Mr Simms explained (at [90]) that the file SerialHalBuffer.h provides the main definitions for the ‘SerialHalBuffer’ class, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. This file also includes the [REDACTED] [REDACTED] described earlier in relation to the frame_primitive.h file.

348 Similarly, in his first affidavit (at [63]), Prof Wicker described the HAL Serial Buffer as software that allows for commands, being sent to different drivers for execution in the radio hardware, to be [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Prof Wicker observed that this thereby allows for more efficient memory storage and transfer of data on the radio. Prof Wicker expressed the opinion (at [86]) that the code that he considered had been copied by Hytera from the HAL Serial Buffer comprises the key class definitions used by the HAL Serial Buffer. Prof Wicker stated that these class definitions are fundamental to how the HAL Serial Buffer operates, and the copied code is therefore essential to the operation of the HAL Serial Buffer as a whole. Prof Wicker was asked about the HAL Serial Buffer during oral testimony and the following exchange occurred (transcript p 766, 12 August 2020):

MR DIMITRIADIS: Did you agree with Mr Brown that the HAL serial buffer is small part of the hardware abstraction layer?

PROF WICKER: I would say it’s an important part as it is the common point of focus for higher layers sending data of various kinds down to lower layers. In other words, the presence of this buffer is important to there being a hardware abstraction layer. It is not a large piece of code, so I would agree with that.

MR DIMITRIADIS: You agree that it’s simplistic code, similar to software found in many other systems?

PROF WICKER: If you took it in isolation, you would see that there are similar buffers that have been created, but what I’m referring to when I disagree with Mr Brown is the position of this buffer within the overall architecture.

MR DIMITRIADIS: And when you refer to the overall architecture, are you referring to the hardware extraction layer and the broader Motorola works?

PROF WICKER: Exactly.

Evaluation

349 Motorola submitted, and we accept, that the code copied by Hytera from the HAL Serial Buffer is a substantial part of that work, determined by reference to the originality of the code that has been copied, the creative and intellectual contribution to the form of expression of the code, and such matters as the structure of the code and the choice and sequencing of commands. We accept the unchallenged evidence of Mr Simms that the code for the L1 Timer subsystem (which includes HAL) was one of the most challenging and difficult to develop. We accept the opinion of Prof Wicker that the code that was copied by Hytera from the HAL Serial Buffer comprises the key class definitions used by the HAL Serial Buffer and that these class definitions are fundamental to how the HAL Serial Buffer operates.

350 As noted earlier, the HAL Serial Buffer consists of only two files: the header file SerialHalBuffer.h (which was copied by Hytera) and an accompanying source file SerialHalBuffer.cpp. The primary judge found that Motorola had not proved that Hytera had copied the source file. In our view, the header file should be considered to be a substantial part of the HAL Serial Buffer for the reasons given by Prof Wicker.

351 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the HAL Serial Buffer is a substantial part of that Motorola Work.

D.6    DSP Firmware

Copied code

352 In addition to its allegations concerning each of the Framer and L1 Timer components of the framerLib Library program, its allegations concerning the framerLib Library program, and its allegations concerning the HAL Serial Buffer, Motorola also alleged that Hytera’s firmware was an adaptation of a substantial part of Motorola’s source code in the DSP Firmware. For the purposes of that allegation, Motorola relies upon:

(a)    all of the code that was copied by Hytera from the framerLib Library program and the HAL Serial Buffer (as discussed in the preceding sections of Part D of these reasons); and

(b)    parts of 70 further files within the DSP Firmware which are identified in Part 10 of the Annexure to these reasons, which comprise:

(i)    parts of 3 header files and 1 source file copied into Hytera source code files;

(ii)    unspecified but substantial parts of 2 source files which were copied into Hytera source code that was compiled into the library file rfhal_c55.lib; and

(iii)    unspecified but substantial parts of 46 source files and 18 assembly files which were copied into Hytera source code that was compiled into the library file DmrDspLib.lib.

Evidence relevant to the additional copied code

353 The additional copied code from the DSP Firmware was discussed in the evidence in three categories:

(a)    the [REDACTED] [REDACTED] files [REDACTED] [REDACTED] and [REDACTED];

(b)    the ListenerBase, EventBase and NotifierBase files; and

(c)    the DSP framework entities and lineup entities files.

354 Each is considered in turn.

The [REDACTED] [REDACTED] files

355 In his first affidavit (and as stated earlier), Mr Simms explained that the [REDACTED] [REDACTED] (which he also refers to as the [REDACTED] [REDACTED]) uses [REDACTED] [REDACTED] [REDACTED] to construct [REDACTED] [REDACTED] that are executed by the Framer component of the L1 Timer subsystem. In his second affidavit (at [11]-[13]), Mr Simms explained that:

(a)    The file [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

(b)    The file [REDACTED] provides one such [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. It has one primary function, which is to [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

356 None of the witnesses gave direct evidence with respect to the role and function of the file [REDACTED]. However, in describing the L1 Timer subsystem, Mr Simms referred to a presentation that he created and which describes the functions of the L1 Timer subsystem. The document is written in shorthand technical language which is not readily understood without explanation. It is apparent from the document that the file [REDACTED] is a component of the [REDACTED] [REDACTED], but it is not clear what role or function it performs.

ListenerBase, EventBase and NotifierBase files

357 The evidence concerning the header files ListenerBase.h, EventBase.h and NotifierBase.h is discussed in section C.6 of these reasons as those files are also part of the Mobile and Portable Firmware. As there stated, the role and significance is the same in each of the Mobile and Portable Firmware and the DSP Firmware. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Specifically:

(a)    [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] (defined in ListenerBase.h and NofitifierBase.h, respectively) [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]; and

(b)    [REDACTED] [REDACTED] [REDACTED] (defined in EventBase.h) [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

DSP framework entities and lineup entities

358 The DSP framework entities and lineup entities code relates to unspecified but substantial parts of 46 source files and 18 assembly files which were copied into Hytera source code that was compiled into the library file DmrDspLib.lib.

359 Mr Corretjer gave evidence about the DSP framework entities and lineup entities. Mr Corretjer explained (at [9]-[10]) that the DSP framework entities and lineup entities are processing blocks that carry out specific functions or algorithms used for the processing of digital signals. The difference between them is that [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The DSP framework also comprises [REDACTED] [REDACTED] [REDACTED], which includes fundamental data types and class definitions used to carry out DSP operations efficiently (for example, [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]). These are ‘inherited’ and used by the framework and lineup entities.

360 In relation to the development of the code for the framework and lineup entities, Mr Corretjer stated (at [12]-[14]) that, before code development began, he and others in his team undertook considerable design and architecture work: for example, the work included designing the interfaces that would be used to access the DSP framework and ensure that the code that was developed would meet the architecture requirements that had been defined for the Global Common Platform as a whole. The framework and lineup entities were primarily developed in C++ using the Rational Rose RealTime development environment. Rational Rose RealTime enabled the developers to visually design certain aspects of the code (such as classes and other objects), referred to as RealTime ‘models’, though other aspects had to be coded ‘by hand’ into the models. However, some target-specific coding was done directly in assembly language, rather than C++ or another high-level language. This was generally done in relation to specific functions or routines in the code that had been identified as ‘bottlenecks’. Where such a bottleneck was identified, code for that particular aspect was developed in assembly language to improve its efficiency, and the assembly code was ‘linked’ into the code in the RealTime models during compilation. In general, most of the code for the framework and lineup entities was designed ‘from scratch’ by Mr Corretjer and his team at Motorola.

361 Mr Corretjer identified the Motorola directories containing the DSP framework entities and lineup entities and the files within them. In his second affidavit (at [91]-[93]) and his third affidavit (at [102]), Prof Wicker expressed the opinion that the file names within Hytera’s library file DmrDspLib.lib replicate the file names in Motorola’s directories for the framework and lineup entities. Prof Wicker expressed his understanding that these entities are fundamental algorithms that are used in, and form part of, Motorola’s digital radio protocol stack.

362 Two components of the framework and lineup entities were discussed by the experts during their oral evidence at trial, being the functions known as the ‘Carrier Detector’ and the ‘Mod Limiter’. As at 2008, Hytera had failed to develop a Carrier Detector for its DMR (see PJ [808]-[812]) and its design for the Mod Limiter was expected to perform poorly (see PJ [824], [881]).

363 In relation to the Carrier Detector, the disassembly of the Hytera library file DmrDspLib.lib revealed that it included the file name CarrierDetectorBase.cpp and certain functions within it, which was the name of a Motorola file within the DSP Firmware. During oral testimony, Mr Grimmett was asked about aspects of the code within the Motorola file and expressed the opinion (transcript p 721, 12 August 2020):

Carrier detection is something that software engineer would need some radio expertise to code this. That said, carrier detection algorithms have been around for many, many years and used on analogue radios. So this isn’t exactly ground-breaking software either. But no, it’s not simple. This is not simple code.

364 Prof Rangan expressed his opinion about the creativity of the same Motorola code as follows (transcript p 721, 12 August 2020):

I will just refer you, for example, to lines 82 in this file, is [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

You will also notice that there’s a lot of optimisations for this DSP. [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

365 In relation to the Mod Limiter, the disassembly of the Hytera library file DmrDspLib.lib revealed that it included the file name ModLimiterBase.cpp and certain functions within it, which was the name of a Motorola file within the DSP Firmware. During oral testimony, Mr Grimmett was asked about the Mod Limiter and he explained that it keeps the modulation of the transmitted signal within the correct sizing or limits (transcript p 723, 12 August 2020).  Mr Grimmett was asked about aspects of the code within the Motorola file ModLimiterBase.cpp and he agreed that the code was not simplistic (transcript p 723, 12 August 2020). Prof Rangan expressed the following opinion (transcript p 723, 12 August 2020):

… again, we will see here a fair amount of work involved in this, in the algorithms. And I just also want to emphasise that, again, this requires testing to be able to get these correct, as well as all the data structures to efficiently implement this type of algorithm on a DSP. So this is an example of the, both, creativity and the effort that’s relevant to this question.

Evidence of Prof Wicker and Prof Rangan

366 In his first affidavit, Prof Wicker expressed the following opinion with respect to the significance of the Framer, L1 Timer and HAL Serial Buffer components to the DSP Firmware (at [87]-[88]):

87.     Based on my review of the documents and affidavits set out in paragraphs 45 and 47 above, in my opinion the Framer, L1 Timer and HAL Serial Buffer, individually and collectively, represent core functional elements of the software for Motorola’s radio devices. They provide for fundamental elements that are needed in the radio devices. In particular, the Framer and L1 Timer provide the framework for [REDACTED] [REDACTED] on the radio, via which [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED].

88.     As I have explained above, I consider that the copied code within the DSP Firmware is essential to the operation of each of the Framer, L1 Timer and HAL Serial Buffer as a whole. It follows that, in my opinion, the copied code form part of core functional elements of the DSP Firmware for Motorola’s radio devices.

367 In his second affidavit (at [100]), Prof Wicker stated that the further code he had considered in the affidavit only reinforced his view that the totality of the code copied by Hytera represents significant and essential elements of each of the Motorola Works, including the DSP Firmware.

368 As noted earlier in the context of the Mobile and Portable Firmware, Prof Wicker expressed the opinion in the Joint Expert Report that the code copied from, relevantly, the framerLib library (which contains the code for the Framer, L1 Timer and QSPI components of Motorola’s DSP Firmware) are core, foundational, components of the entire Motorola Programs, in that they provide functionality that is utilised by other parts of the Motorola Programs to achieve their functions. Prof Wicker stated that these parts of the code reflect much of the skill, effort and creativity that went into developing, relevantly, the framer/L1 timer/HAL code, and reflect the planning and understanding of what the architecture would be.

369 As also noted in the context of the Mobile and Portable Firmware, Prof Rangan expressed the opinion in his fifth affidavit (at [161]-[162]) that the Motorola header files copied by Hytera provide the structure for the code in the Motorola Works, and are fundamental to the overall framework of the various Motorola Works, and the overall architecture of the software for Motorola’s DMR radio devices. In particular, they form the basis for, and give effect to, the overall framework and architecture of, relevantly, Motorola’s L1 Timer subsystem and the rest of the DSP Firmware. Prof Rangan stated that he considered that the Motorola header files copied by Hytera reflect the output of significant creativity from the Motorola engineers who designed and developed them. These files form part of, and give effect to, a unique, sophisticated and complex framework architecture, as also reflected by the significant amount of time and effort spent by Motorola engineers in developing this architecture and code.

Evaluation

370 It is necessary to assess whether the code copied by Hytera from the framerLib Library program and the HAL Serial Buffer, and from the 70 further files within the DSP Firmware which are identified in Part 10 of the Annexure to these reasons, together constitute a substantial part of the DSP Firmware.

371 Although we have earlier rejected Mr Brown’s line counting evidence, it must be accepted that, assessed quantitatively, the copied code is a small proportion of the DSP Firmware. The total number of files within the DSP Firmware is in the order of 5,866 (although this count is likely to be significantly overstated by the replication of files within the firmware), and code has been copied from 82 files. Even allowing for the overstatement of the total number of files, it is apparent that the copied code is a small proportion of the DSP Firmware.

372 Motorola submitted that, considered in totality, the code copied from the Framer, L1 Timer and HAL Serial Buffer components forms an essential part of the DSP Firmware. Specifically, the copied code forms the basis for, and gives effect to, the overall framework and architecture of Motorola’s L1 Timer subsystem, HAL Serial Buffer and the rest of the DSP Firmware, and contains fundamental data structures, function prototypes, class definitions and other elements that are both unique and essential to the operation of the DSP Firmware.

373 Both the lay and expert evidence, which is discussed in this section D of the reasons and which we accept, supports that submission.

374 As Mr Zetzl and Mr Simms explained, the L1 Timer subsystem [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Mr Simms stated that a key feature of the L1 Timer subsystem is that it is able to quickly and flexibly adapt to changes and [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. The flexibility arises from the L1 Timer subsystem’s design as a class-based object-oriented system. The software for the subsystem was developed ‘from scratch’, being designed to overcome deficiencies encountered in previous Motorola products. One of the decisions Mr Simms made with the development team was to develop the majority of the L1 Timer subsystem code in C++ language because it is an ‘object-oriented’ programming language. The L1 Timer subsystem’s (and specifically the Framer’s) design as a class-based object-oriented system is part of what allows the flexibility and responsiveness in [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Mr Simms stated that, in his view, the L1 Timer subsystem, and specifically each of the Framer and L1 Timer components, are of fundamental and critical importance to the overall functionality of Motorola’s DMR radio devices, and that the code for the L1 Timer subsystem in the Matrix DSP firmware was one of the most challenging and difficult to develop.

375 Prof Wicker expressed the opinion that Framer and L1 Timer form a powerful tool, as they [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]. Prof Wicker said that there are lots of ways in which a similar functionality could have been achieved, and he considered that the means adopted in the Framer and L1 Timer reflects a substantial amount of ingenuity, creativity and effort on behalf of the Motorola engineers who developed these components.

376 Prof Wicker expressed the opinion that “the radios would not work” without the framerLib Library (which contains the code for the Framer, L1 Timer and QSPI components of the DSP Firmware). As discussed earlier in the context of the Mobile and Portable Firmware, we accept the accuracy of that opinion, but it is not determinative of, and arguably is not relevant to, the question of copyright infringement. A “but for” essentiality test is not a useful test for determining whether computer code copied from a computer program is a substantial part of the program.

377 Of more significance, though, is Prof Wicker’s opinion in the Joint Expert Report that the code copied from, relevantly, the framerLib library are core, foundational, components of the entire Motorola Programs, in that they provide functionality that is utilised by other parts of the Motorola Programs to achieve their functions. Prof Wicker stated that these parts of the code reflect much of the skill, effort and creativity that went into developing, relevantly, the framer/L1 timer/HAL code, and reflect the planning and understanding of what the architecture would be. To the same effect is Prof Rangan’s opinion that Motorola header files copied by Hytera provide the structure for the code in the Motorola Works, and are fundamental to the overall framework of the various Motorola Works, and the overall architecture of the software for Motorola’s DMR radio devices. In particular, they form the basis for, and give effect to, the overall framework and architecture of, relevantly, Motorola’s L1 Timer subsystem and the rest of the DSP Firmware.

378 Taking all of the evidence into account, we are satisfied that the code copied by Hytera from the DSP Firmware is a substantial part of that Motorola Work. In arriving at that conclusion, we are most influenced by the lay and expert evidence that establishes the originality and creativity associated with the L1 Timer subsystem and the importance of the subsystem within the DSP Firmware. Whilst the relatively small portion of code that was copied must be taken into account, in our view the quality of what was taken, particularly in respect of the L1 Timer subsystem, is more significant than the quantity.

PART E: CONCLUSION AND ORDERS

379 In conclusion, we are satisfied that Hytera infringed Motorola’s Australian copyright in the ‘Release 1’ version of its computer source code for the firmware in its DMR devices by, first, importing into Australia Hytera DMRs containing firmware which was an adaptation of a substantial part of Motorola’s source code in each of the Motorola Works and, second, making that firmware available for download in Australia from its website portal.

380 We have reached this conclusion without regard to Hytera’s animus furandi. Nevertheless, as stated earlier, the evidence demonstrating Hytera’s need to copy Motorola’s source code in order to produce a competitive product, and the labour saved in doing so, reinforces our conclusion. By the end of 2007, Hytera’s development of its DMR device was in disarray. It faced two significant problems: its development was going to result in a product which would not be competitive with Motorola’s device; and the development of that product would take at least until the end of 2009 before the process of commercialisation could begin, which meant that a product launch would not occur before the middle of 2011. In those circumstances, it embarked on what the primary judge described as a substantial industrial theft. It recruited software engineers from Motorola who brought with them to Hytera all of Motorola’s source code for the Mobile and Portable Firmware and the DSP Firmware for the purpose of copying. The engineers engaged in industrial scale harvesting of Motorola’s source code and set out to make this as difficult to detect as possible. Hytera benefitted from the actions of the ex-Motorola software engineers in at least two ways: first, it got to market with devices which were commercially competitive with Motorola’s products where otherwise it would not have done so; and second, it got to market by at least 15 months earlier than it otherwise would have.

381 Having previously dismissed Hytera’s Amended Notice of Appeal dated 8 November 2023 in respect of grounds 1 and 6 to 13, an order should now be made dismissing the remaining grounds 2 to 5 inclusive.

382 Having previously allowed in part grounds 2 and 3 of Motorola’s Amended Notice of Cross-Appeal dated 27 November 2023, an order should now be made wholly allowing the cross-appeal in respect of grounds 2, 3 and 4, and upholding grounds 2 and 3 of Motorola’s Amended Notice of Contention dated 27 November 2023.

383 With respect to the costs of the appeal, the parties have enjoyed mixed success. We consider it appropriate to separate the costs of the appeal by reference to the claims for patent infringement and the claims for copyright infringement.

384 In respect of the appeal concerning patent infringement, Hytera was wholly unsuccessful on its appeal concerning the 355 Patent. Motorola was also unsuccessful on a contention it raised with respect to the 355 Patent, but that was a minor issue (see AJ [265]-[267]). Conversely, Motorola was wholly unsuccessful on its cross-appeal concerning the validity of the 960 Patent. Hytera was also unsuccessful on contentions it raised with respect to the 960 Patent. It can be seen that both parties were unsuccessful on every issue raised on the appeal and the cross-appeal concerning patent infringement. It might be said that Hytera raised more issues, and the issues raised by Hytera occupied more time, in comparison to the issues raised by Motorola. However, having regard to the scale of the proceeding as a whole, in our view justice would not be served by attempting to apportion costs incurred on the appeal and cross-appeal in respect of patent infringement. We consider that the appropriate order is for each party to bear its own costs of the appeal and cross-appeal in respect of patent infringement.

385 In respect of the appeal concerning copyright infringement, Hytera was unsuccessful other than in respect of a small number of discrete issues (see AJ [816]-[822]).  Conversely, Motorola was wholly successful on its cross appeal and contentions. We consider that Hytera should pay Motorola’s costs of the appeal and cross-appeal in so far as they concern copyright infringement.

386 As a consequence of the conclusions we have reached, it will be necessary to set aside order 1 made by the primary judge on 7 June 2023 with respect to declaratory relief concerning copyright infringement, and replace it with an order reflecting the conclusions reached in this judgment. Consequential variations may need to be made to order 10 (with respect to injunctive relief) and order 11 (otherwise dismissing the relief sought in the originating application). An order will be made for the parties to confer and seek to agree the necessary orders to give effect to the conclusions reached in this judgment in those respects.

387 As stated earlier, the primary judge deferred the question of compensatory relief in the proceeding until the resolution of any appeal. The proceeding will therefore return to the primary judge to determine compensatory relief, including the payment of additional damages.

388 By order 18 of the orders made on 7 June 2023, the primary judge reserved the costs of the trial. It is appropriate that the question of the costs of the trial also be determined by the primary judge, in light of the final determination of the claims on this appeal. It is therefore unnecessary for this Court to vary that order.

389 Finally, the substantive part of these reasons will be temporarily suppressed to afford the parties an opportunity to consider whether any part of the reasons reveals commercial in confidence information and to make an application for redaction of any such information from the published version of the reasons.

Associate:

Dated: 7 September 2026

ANNEXURE: COPIED CODE

131 computer files in total

Part 1 – EMT (19 computer files)

1.1     Code from Motorola files copied into Hytera source code files

1.2    Code from Motorola files copied into Hytera source code and compiled into the library file raf_arm9.lib

Part 2 – Xlate (13 computer files)

2.1    Code from Motorola files copied into Hytera source code files

2.2    Code from Motorola files copied into Hytera source code and compiled into the library file raf_arm9.lib

Part 3 – UIT (7 computer files)

3.1    Code from Motorola files copied into Hytera source code files

3.2    Code from Motorola files copied into Hytera source code and compiled into the library file raf_arm9.lib

Part 4 – Darwin Ergonomics Platform (outside EMT, Xlate and UIT) (2 computer files)

4.1    Code from Motorola files copied into Hytera source code and compiled into the library file raf_arm9.lib

Part 5 – Mobile / Portable Firmware (outside Darwin Ergonomics Platform) (8 computer files)

5.1    Code from Motorola files copied into Hytera source code files

Part 6 – Framer (7 computer files)

6.1    Code from Motorola files copied into Hytera source code files

6.2    Code from Motorola files copied into Hytera source code and compiled into the library file rfhal_c55.lib

Part 7 - L1 Timer (3 computer files)

7.1    Code from Motorola files copied into Hytera source code files

7.2    Code from Motorola files copied into Hytera source code and compiled into the library file rfhal_c55.lib

Part 8 – FramerLib Library (outside Framer and L1 Timer) (1 computer file)

8.1    Code from Motorola files copied into Hytera source code and compiled into the library file rfhal_c55.lib

Part 9 - HAL Serial Buffer (1 computer file)

9.1    Code from Motorola files copied into Hytera source code files

Part 10 - DSP Firmware (outside Framer, L1 Timer and HAL Serial Buffer) (70 computer files)

10.1    Code from Motorola files copied into Hytera source code files

10.2    Code from Motorola files copied into Hytera source code and compiled into the library file rfhal_c55.lib

10.3    Code from Motorola files copied into Hytera source code and compiled into the library file DmrDspLib.lib