Navitaire Inc v Easyjet Airline Co. & Anor

This is an action for infringement of copyright in computer software. It concerns the software implementing an airline booking system principally employed by low-cost airlines who employ ‘ticketless’ booking. The claimant’s system is called OpenRes. It (and its successor system) have been commercially successful, and are employed by a number of airlines. The claimant (‘Navitaire’) is now the owner of the copyright in the various works that go to make up the source code of OpenRes. The first defendant (‘easyJet’) is the well-known low-cost airline. The second defendant (‘BulletProof’) is a software developer located in California, who is responsible for writing the code of the allegedly infringing system, which is called eRes, in consultation with easyJet’s IT department. I will refer to the claimant and its predecessors in title (Open Skies, Inc.

The case is factually and technically complex and has taken a considerable amount of time in court. It raises starkly an issue of considerable importance in the law of copyright. While there are comparatively minor allegations of infringement by copying of certain code and an allegation in relation to the databases that I summarise below the striking feature of this action is that Navitaire does not suggest that easyJet or BulletProof ever had access to the source code of the OpenRes system. What is alleged, and not disputed, is that easyJet wanted a new system that was substantially indistinguishable from the OpenRes system, as easyJet used it, in respect of its ‘user interface’. This term is used to denote the appearance the running software presents to the user, who may be an agent in a call centre or a private individual seeking to make a booking by use of the World Wide Web. It substantially achieved this far from simple goal. It is not in dispute that none of the underlying software in any way resembles that of OpenRes, save that it acts upon identical or very similar inputs and produces very similar results, but it is said that the copyright in OpenRes is infringed by what was called ‘non-textual copying.’

In its context in this action, ‘non-textual copying’ had three aspects. The first was the adoption of the ‘look and feel’ of the running OpenRes software. The second, not always clearly distinguished from the first during the trial, was a detailed copying of many of the individual commands entered by the user to achieve particular results. The third was the copying of certain of the results, in the form of screen displays and of ‘reports’ displayed on the screen in response to prescribed instructions. In other words, as used by easyJet the systems are very similar in use. Internally, it is correct to say that they are completely different, subject to a point on the names used to identify certain data in the databases in eRes. Given that near-identity in appearance and function could not have been achieved without a close analysis of the OpenRes system in action, Navitaire say that there is here ‘non-textual’ reproduction of either the whole of the OpenRes software considered as a single copyright work or alternatively of the various copyrights subsisting in ‘modules’ going to make up the system.

The commands alleged to have been copied by easyJet amount to some 44% of the OpenRes commands, on the estimate of Dr Hunt, Navitaire’s expert witness.

“All of the OpenRes complex commands and nearly all of their sub-options are reproduced in eRes. 44% of the OpenRes simple commands are also reproduced. Most of the commands that are not reproduced, or where there are differences in suboptions, result from the fact that easyJet only used a sub-set of the OpenRes commands. For example, commands relating to standby passengers, seat assignments and connecting flights have not been reproduced, presumably because easyJet does not need these facilities.”

I should make it clear at this stage that this conclusion is slightly inaccurate. Parts only of some of the complex commands are present in OpenRes because the easyJet business model has no place for certain of the options that were accordingly not incorporated; and a certain amount depends upon the sustainability of the distinction between simple and complex commands, which is discussed below.

There is here an issue of general importance. To emulate the action of a piece of software by the writing of other software that has no internal similarity to the first but is deliberately designed to ‘look’ the same and achieve the same results is far from uncommon. If Navitaire are right in their most far-reaching submission, much of such work may amount to the infringement of copyright in the original computer program, even if the alleged infringer had no access to the source code for it and did not investigate or decompile the executable program.

The World Wide Web interface of the OpenRes system was provided by a software module called TakeFlight. For reasons that I explain below, the TakeFlight module consists only of source code (it was written in an interpreted rather than a compiled language) and it was copied and modified on a number of occasions by easyJet. The purpose of this copying was to fix bugs, provide for the display of promotions and the like and to provide foreign language interfaces because the code was not internationalised. This copying is said to be a breach of the terms of the licence to use the software granted by Navitaire or its predecessor in title to easyJet. easyJet’s own WWW interface for eRes was written in-house by easyJet’s employees and, again, it cannot be suggested that the code itself was copied. Again the allegation is of ‘nontextual copying’ of the software by producing a user interface having the same ‘look and feel’ as TakeFlight.

An airline booking system depends crucially upon the underlying method of recording data relating to availability of flights, availability of seats, details of passengers, their flights, their baggage, and so on. This data is what is called ‘persistent’ data and must be recorded in databases. The principal function of the airline booking system software is to read data from the relevant databases in response to requests from the user and to record details specified by the user, while adjusting the former in dependence upon the latter. The allegation of infringement of copyright in respect of the databases had two aspects. The first was that in transferring or ‘migrating’ the data contained in their OpenRes databases, which contained a record of every passenger and every flight on an easyJet aeroplane, to the new system, easyJet made interim copies of the existing OpenRes databases that they were not entitled to make. The second is that easyJet and BulletProof used their knowledge of the OpenRes databases to design the eRes databases in such a way that the copyright or copyrights alleged to subsist in certain ‘schemas’ which define aspects of the structure of the OpenRes database have been reproduced in the structure of the eRes database.

Factually the claim in respect of the user interfaces of the eRes system does not present serious difficulty. There is a dispute as to originality, or more accurately to the amount of originality in the works relied on, but the problems are essentially legal ones once the technical aspects have been understood. The position in respect of the databases is different. There is a serious dispute as to the material employed by BulletProof in specifying the eRes database structures, and whether and to what extent information about the OpenRes databases gleaned during the data migration process was used, and, if it was used, whether that use was illegitimate. There is again no doubt that none of the code used to manipulate the databases themselves can be said to have been copied, and for reasons that I explain below there is now no suggestion that the databases in eRes are in some way manipulated in a manner similar to that in OpenRes.

Procedurally, there has been one important problem with the case. By the order of Master Moncaster made 18 February 2003, Navitaire were required to provide complete particulars of each and every similarity between OpenRes and eRes relied upon in support of its allegations of infringement. Rather than supply such particulars, Navitaire’s advisers required Navitaire’s expert witness, Dr Gillian Hunt, to prepare an expert report that concerned itself only with the similarities between the systems. It said nothing about the differences and it did not provide alternative explanations for features alleged to be copied. It was in effect the indictment. This was not compliance with the Master’s order, and it was not fair to Dr Hunt, who prepared an entirely onesided document, to the extent even that if a help message contained some text similar and some text different from that in the Navitaire system, the similar part only was referred to. The report turned out to be an embarrassment, as it contained material that was not placed in context by any other report (Dr Hunt ended up making seven reports), and its nature ensured that it contained no nuance.

There is a great amount of technical detail in the case. Some of the issues cannot be properly approached without some understanding of the technical issues. I have tried not to overburden this judgment with technical discussion, but some reference to the source software is essential. I explain the matters relating to the user interface in my own words. The material relating to databases was more difficult, and the parties provided me with extensive extracts from two text books and the manual for TurboIMAGE XL, the database management system used in the OpenRes system. I will not attempt to repeat that information here, but my understanding of the database case has been largely informed by these publications.

The copyright works relied on form part of the source code of version 5.58 of OpenRes. The whole of the source code of the entire system is also relied on. It is a fairly large software system, a simple line count showing a total of about 786,000 lines of code, largely in the COBOL language, in the source files for the OpenRes 5.58 system supplied to me. The supply of OpenRes to easyJet

The OpenRes system is an airline booking system that is intended for use in ‘ticketless’ transactions. The passenger does not receive a ticket as a result of a booking transaction, but is instead given a single reference number. The reference number is used for the purpose of check-in at the airport. A paperless model, in which the financial functions are also handled without paper and in which the structure of reservations is comparatively simple is of particular interest to low cost airlines.

So far as the evidence in this case is concerned, ticketless reservations were first used by Morris Air, a low-cost airline in the United States. Its founder and President, Mr Neeleman, gave evidence that he sold Morris Air to Southwest Airlines having first employed David Evans as Vice President of Information Services. Between January and June 1993, Mr David Evans wrote a reservation system called MARS (Morris Air Reservation System). This system was written for a Hewlett Packard (“HP”) computer, the HP 3000, in a language called Business Basic/XL. This appears to have been a version of the BASIC language proprietary to HP. The data was stored in a database managed by the HP TurboImage system.

When Morris Air was purchased by Southwest Airlines in 1994, I infer from Mr David Evans’s evidence that he was dismissed, either at that stage or some short time later. Notwithstanding his departure from Southwest Airlines, he developed a ticketless system comprising a data repository that derived its data from the SABRE reservation system used by Southwest. SABRE stands for Semi-Automated Business Research Environment. It was created by American Airlines in 1964, and has been developed continuously since then, now being the property of a company called Sabre Inc. It is a computer reservation system intended for use with tickets and is widely used. Mr Evan’s ticketless system for Southwest Airlines was released in August 1994.

In April 1994 Mr David Evans signed a contract with Southwest Airlines to help them in writing a new reservation system to replace SABRE. In June 1994, he started a company called Evans Airline Information Systems Inc. He signed a contract to become a Hewlett Packard Value Added Reseller (VAR) at this time. The replacement for SABRE appears to have been written in the two years from January 1995 to December 1996. But before this work started, and while he was working on the ticketless system for Southwest Airlines, Mr David Evans was approached by two representatives of a small charter airline operating in Brussels that was then called Eurobelgian Airlines but became Virgin Express. Eurobelgian Airlines wanted to purchase MARS but, when they were told that it was the property of Southwest Airlines, agreed with Mr Evans that he would write them a ticketless booking system. This he did, on an HP 3000 purchased by Eurobelgian Airlines, in the evenings while he was working on the Southwest ticketless system. It became known as the Evans Airline Reservation System (EARS) and was completed, so I was told, in about three months, working in the evenings and at weekends. EARS is the basis of OpenRes.

EARS differed from MARS in that it was written in a different language (COBOL rather than BASIC) and to the specific requirements of Eurobelgian Airlines. It was only ever supplied to Eurobelgian Airlines and CityBird, another small Belgian airline.

In September 1995, a further enquiry from a small airline, this time WestJet from Calgary, Canada led to the employment of Greg McDaniel, a veteran of Morris Air who also gave evidence, who started to convert EARS to something suitable for WestJet in September 1995. The result of this development was OpenRes. At about this time, EAIS was purchased by David Neeleman who renamed it Open Skies, Inc. Hewlett Packard acquired the company in October 1998, and sold it to PRA Solutions

easyJet was one of the first companies to take a licence of the OpenRes system. Mr

The easyJet licence was signed on behalf of Open Skies inc, and easyJet Airlines on 18 November 1996. It is convenient to set out the relevant provisions in one place.

Exhibit B to the agreement is concerned with customisation for easyJet’s requirements. Phases I, II and III specify the items to be completed before installation, within sixty days of installation and ‘as part of a long-term enhancement list’ respectively, and each Phase is itself divided into three categories of development. For present purposes it is only necessary to note that Category I of Phase III specifies the development of internet access to the booking engine. This eventually appeared in the

easyJet ‘went live’ with OpenRes in June 1997. Before that date, all the data on the AVOPS system had to be transferred to the new databases. This was done by Ms Lane Antry’s specifying a so-called ‘neutral file format’. This format identified the data that was necessary to the operation of OpenRes and accordingly needed to be extracted from AVOPS. As I understand the evidence, the data was then extracted from the AVOPS system using software designed for the purpose into text files of a prescribed format, perhaps ‘comma-delimited’, in which the data fields are separated by commas. The data was then loaded into the OpenRes database using software that was designed by Ms Antry to expect the data in the prescribed order and separated by the prescribed delimiters.

Dr Chiu, easyJet’s expert, produced a diagram of the functional components of the OpenRes system and the systems associated with it as it was used at easyJet. This is a useful diagram, and was not challenged for accuracy.

The diagram needs some explanation. The OpenRes and TakeFlight systems that form the subject matter of the claim are within the dotted box. Flows of data between the OpenRes system and programs cooperating with it are shown by the black-headed arrows that cross the dotted line. The OpenRes system itself comprises a database and a family of programs that manipulate the data. I am concerned with those parts of the

Dr Chiu also produced a diagram of the software modules making up the OpenRes system (Footnote: ¹)

A great amount of time was spent on the command line interface, more than the difficulty of the subject really justified. During the trial, both the terminal (i.e. noninternet) interface, the Fares and Scheduling interface and the Internet user interface were considered separately. Any user interface of the kind under consideration in this part of the action has two aspects: the commands typed on the keyboard by the user, and the display on the screen. The code defining the user interface is accordingly distributed, in the OpenRes system, between the various software modules that require input from the terminals: BUILDPNR, MODFYPNR, CICLNT01 and

The pleaded case identifies four classes of relevant copyright works in paragraphs 7.2—7.5 of the Particulars of Claim. In summary, they are:

eRes

OpenRes

The pleaded commands are in Schedules A and B to the Particulars of Claim. When Dr Hunt came to prepare her reports, she produced a different table (Appendix 2 to her report of 22 October 20003) which sets the commands out in a different order. It is Dr Hunt’s Appendix 2 which is cross-referenced to a large collection of code fragments from OpenRes and eRes that are intended to show how the codes are themselves expressed in software. The OpenRes fragments were made available with the 22 October report: the eRes fragments followed in January with her second supplementary report.

This is not the place comprehensively to describe the manner in which digital computers work. It is still necessary to examine certain aspects in a little detail. The call centre operative, or airline booking clerk, is provided with a screen and a keyboard. We are not here concerned with a screen capable of displaying complex graphics but an 80 by 24 character standard green screen. Most such terminals respond to control codes devised by Digital Equipment Corporation for its VT100 terminal, and are generically referred to as VT100 terminals. When the terminal is switched on a program running on the computer to which the terminal is connected prompts the operator for a password. Then he or she is given an introductory screen, listing the various functions that may need to be undertaken. Once the operator has selected the type of operation, an appropriate prompt will be presented, inviting the operator to type a command. He or she wants to know the availability of seats on

The answer is that it depends upon what the author of the software wrote. There are a myriad ways of constructing a program or part of a program (a ‘parser routine’) that takes a line of input, breaks it into its component parts, interprets the command as requiring certain data relating to all flights with free seats between Luton and Amsterdam on 13 June, calls appropriate routines to produce that data from persistent stored data (the database), formats it and causes it to be displayed. What the software does is recognise the whole command: Navitaire originally proposed that it was not necessary to examine the software at all. All that was necessary was to see what the command did. In the end, there was evidence as to what the software did, but it was produced mainly in cross-examination, although Dr Hunt had, by the end of the trial, identified the parts of the code that contained the parsing routines for all the commands alleged to have been copied in both systems. Thus, when talking of parsing a city pair (LTNAMS in my example) Dr Hunt said this:

This answer was given to a question about the eRes system, but the position is no different for OpenRes. Mr David Evans was taken through the parsing of an availability command in words, without showing him the code, in re-examination. He described the process:

I am not sure that I was ever taken through the actual code that David Evans is describing by one of witnesses. It is to be found in the file labelled 26.txt in the code fragments produced by Dr Hunt to accompany Appendix 2 to her October report. (Footnote: ²) I have copied the relevant passage from the source code for OpenRes 5.58 and I have set out the section corresponding to Mr David Evans’s evidence in Annexe 1 below.

Generally, a digital computer required to parse a line of input text will analyse the line according to rules that are implicit in the software that controls the parsing operation. The computers with which this action is concerned parse their input sequentially. It is the task of the programmer to provide code which controls the machine to analyse the line correctly and act as required in response to what the line contains. We have in this case a large number of commands, generally identified by their first letter or other symbol. In OpenRes, the Reservations module contains a command for either sorting lines on the screen (‘/A’) or for inserting a line after a particular segment displayed on the screen (‘/nMm’), for displaying certain information (first character ‘.’), for providing help (‘?’), for displaying available flights (‘A’), for entering comments in respect of a particular reservation (‘C’), for displaying a calendar (‘CAL’), for doing calculations (‘CC’), for payment (‘F’), for getting/selling seats (‘G’) and so on. So, what does the programmer do? In OpenRes, the code starts by analysing the first character of the string typed at the VT100 terminal. In Annexe 2 below, I set out a code fragment that does this and provide my understanding of it.

What cannot be found in the OpenRes code is a record of the commands in anything like the form in which they appear in Dr Hunt’s Schedule 2 and the annexes to the Particulars of Claim. The name of the command will appear if it is a single letter. If the name of the command has two or more letters, it may or may not appear recognisably. A further code extract may make this clear. This is part of the ‘acommands’ section of code which is entered when the first letter is ‘A’:

The same point may be seen in the code extract in Annexe 2 in the processing of the ‘F’ commands. The ‘F--’ (amended Schedule 2 number 48) (Footnote: ⁵) is never expressly recorded as such in the code. At lines 198200-198300, two checks for a dash are performed: the first on position 2 and the second on position 3. This is done so that a negative answer to the second check can be followed by a check for an ‘H’ in the third position, indicating the ‘F-H’ command (number 49) (Footnote: ⁶).

As the purpose of the software is to analyse the commands to see what has been typed and execute the appropriate action, it is perfectly irrelevant to function whether the codes are all set out expressly somewhere or not. (In eRes they are all set out expressly, because the parsing technique is quite different, but I shall return to that.) It does, however, mean that the command code can only be identified as such from the software itself by working out what strings of letters and symbols it recognises as command codes: in other words, by seeing how it works in use. I have read through the various input routines in BUILDPNR and CICLNTT01 to see to what extent the codes are present expressly. In the majority of cases they are, but in some they are not. Whether they are or not is irrelevant to whether the code works to recognise the commands: it is a different way of analysing the input to see if it contains a particular command.

The ‘syntax’ or permitted arguments of the various commands and sub-commands is not explicit in the code. This is invariably the case. It follows that if the syntax of the command is not recorded in some manual or help screen, the only way of determining the syntax of a given command is to analyse how the code operates in use. As easyJet submits, the syntax of the various commands is not recorded in the source code; rather the source code recognises and acts on permitted arguments to a given command.

An analysis of Mr David Evans’s evidence, with that of the experts and consideration of the code itself satisfies me that OpenRes does not contain any text corresponding to the commands as pleaded. What it does contain is code which, when executed by the computer, will accept commands with the particular arguments specified and produce the specified results. As part of the code, the individual letters and other symbols (‘.’, ‘/’ and so on) will appear expressly somewhere in the code, and the whole name of the command will often do so, in the section of code in which the components of the command entered at the command prompt are analysed. With this introduction, I can turn to the story of the commands.

It has been surprisingly difficult to list all the commands in the OpenRes system. Indeed, Schedule A to the Particulars of Claim, which lists the ‘complex’ commands, has been amended four times, and the list of all commands contained in Schedule B has been amended five times. It is not clear that even now the lists are entirely accurate, but this seems to me to be a matter of slight importance. The codes were mainly designed by Mary Beesley, who gave evidence. She was not responsible for writing the software to implement these commands. David Evans coded the commands for the Reservations module, Greg McDaniel those for the Check-In module and Mike Padgen those for the IROP module.

The word ‘brainstorming’ is used some forty times in the witness statements in support of Navitaire’s case, and is always used either in respect of the design of a command or of a display. The process is described by Lane Antry, a systems designer:

There is in my judgment no doubt that the OpenRes user interface was influenced by other reservation system command line interfaces. Ms Beesley, who was intimately involved with the development of OpenRes, had a good knowledge of other systems. David Evans was himself well acquainted with SABRE, which remains a widely used system. Command line interfaces are common. OpenRes’s origins are in MARS, which had an interface that was in part derived from SABRE. Indeed, Mark Sapitsky, who worked with David Evans in its design, wanted the whole of the command set to be the same as SABRE, but Ms Beesley thought many of the latter’s commands to be excessively complex and in those cases, a simplified or altered command was included in MARS. Sometimes, she says, both the new command and the SABRE command were incorporated. There is a hangover from this in OpenRes (and, given

MARS was not, of course, a ticketless system. Most of the commands are entirely independent of the nature of the system, but some are not. Availability is not affected by whether tickets are to be printed or not, and there is a general similarity with other systems, such as Galileo and Amadeus, which is obvious. The commands do differ between systems (apart from OpenRes and eRes); but the essence of an availability command, for example, lies in the operator’s ability to specify a date, a departure point and a destination. They all have this, and the refinements, such as ranges of dates, return flights, class, maximum fare the customer is willing to pay, numbers of passengers and so on come later. Ms Beesley’s evidence was not entirely consistent, but there is no doubt that what the Open Skies programmers produced was another command line interface, with the same general capabilities as other command line interfaces had, over a system expressly orientated to ticketless travel. The evidence is quite clear that it is in this business model and in its implementation, that the real innovation of OpenRes lies.

I have no doubt that it is proper to refer to a ‘command code design process’ and that the specification of a command would, as Ms Beesley describes, start with the function to be performed, as it is normal to start with the result to be achieved. Navitaire’s evidence as to who was responsible for the design of the various commands is uncertain. I reject any suggestion that the entire command set was systematically designed. Although the commands obviously form functional groups, there is little evidence of systematic design over and above the necessity of avoiding duplication and ambiguity when a new command is added. It is very difficult to discern any overall structure to the codes, other than that they implement a particular way of doing business, or business model.

I am asked by Navitaire to make a number of findings in respect of the user commands. I set out the proposed findings with my comments.

I should observe that all these proposed findings are loaded with terms (author, skill and labour, compilation and so on) that might be thought to assume that copyright subsisted in the commands set out either in Schedule A or in the collection of all the commands set out in Dr Hunt’s Annex 2, and I have attempted to avoid using these terms because one of the principal issues in the case is whether copyright does subsist in the matters set out in these documents.

This is true, but repetitive. It is also a statement of how the commands appear to the user, rather than how they are parsed, which is not so well defined. The phrase ‘interrelated or interlinked in their expression, syntax and functional meaning’ is just another way of saying they are a family of commands, and adds nothing.

This is not generally correct. I have already explained (paragraph 33) that an availability command such as A13JUNLTNAMS is parsed in the BUILDPNR module for the purpose of identifying it as such. When the display-schedule routine is called (line 264500), control is passed to the AVAILSCR module, which contains the code that recognises the ‘syntax’, i.e. the arguments, of the command in the manner described in Annexe 2. Of course, it does depend on what ‘the same section of the source code’ means. If all it means is that once the command code is recognised, the arguments of that command are processed together then it is quite correct, but it is difficult to see why it matters.

I have no doubt that more than negligible skill and judgment went into specifying the codes in general. Some of the complex codes (‘A’ for availability, ‘G’ for grab/sell, ‘N-’ to name a passenger, ‘.’ for print, ‘CC’ for calculator (Footnote: ⁷), and so on) do not, on their own, seem to me to require much skill or labour. Ms Antry accepted that QEP (Footnote: ⁸) is common in the business, as are E, ER, I and IR. As Dr Chiu demonstrated, Galileo and Amadeus, the mainframe systems, use ‘A’ for availability. Galileo, Amadeus and Sabre all use N (‘Needs’) rather than G (grab) for the grab/sell command. Passenger names are provided by the ‘N.mm’ command in Galileo (mm is the number of passengers), the ‘NMmm’ command in Amadeus, ‘-mm’ in Sabre, ‘N-’ in OpenRes and ‘N-mm’ or ‘NTmm’ in eRes. The ‘.’ command made its appearance in EARS as an alternative for the ‘*’ command, which appears to be generally used by others, because the keyboards used by the Belgian airline for which EARS was written did not provide a convenient asterisk key. All these commands differ, to varying extents, in their detailed syntax. It goes without saying that the syntax should be consistent across sub-commands, but no doubt it requires some skill to achieve that but the fact that the development of the commands was in some cases ad hoc can be seen by considering the names of the author(s) and dates claimed for the individual commands and sub-commands claimed in Dr Hunt’s Annex 2, where the clearest example is the ‘.’ command. The evidence as to ease of use and memorability was not extensive. I suspect that ease of use comes in any such case with familiarity: even the most intractable command line interface becomes easy to use as it becomes familiar to the user. Some of the commands (DATE, HELP, ?, CAL, EXIT) are entirely standard across many platforms over many years and are not original to the claimants at all.

As I have indicated, the history of the originators of the commands is not entirely clear. I find myself, however, able to say that if such-and-such a command was not originated by the person(s) specified in Schedule A as the author(s) of that command, it was originated by some other person, at about the same time, who was one of the other persons specified.

Again this is generally correct of the commands listed in Schedule A, but the remarks that I have made above apply equally here. I do not accept it as true in respect of the standard commands I have identified, and, of course, many resemble the commands in other systems more-or-less closely. It would be idle to suggest that this command set owed nothing to the pre-existing command sets of which the authors were aware.

I have not so far discussed the IROPs code as it seems to me to raise no separate issue of principle. ‘IROPs’ stands for irregular operations, and covers a series of commands that are designed to carry out bulk alterations, such as assigning a group of passengers already booked to a different flight. IROPs is an airport system. As far as the evidence goes, OpenRes is the only system with bulk commands of this kind. They were designed to operate closely with the commands concerned with check-in in the Check-In module, but on the evidence this suggested finding is justified.

The emphasis of this proposed finding is on the collection of commands. This is meaningful only if the collection constitutes a whole that is more than the sum of its parts, and this would be the case if the assembly of the parts into the whole were inspired by some governing criterion. It is tempting to use the phrase ‘planned whole’ but that is probably putting the criterion too high. Again, concealed in this proposed finding is a submission that the collection of commands amounts to a compilation in the copyright sense. The whole of the evidence was quite contrary to any such suggestion. The members of the collection were added ad hoc on the basis of the knowledge of existing systems possessed by its various designers, and their need to construct new commands appropriate to a ticketless reservation system suitable for smaller low-cost airlines. No command set was ever designed. I do not think it was born: it just growed. It does not, as a collection, represent a single exercise of taste and judgement.

Navitaire emphasise that it was not suggested (and cannot be) that the whole instruction set was copied from any other system. This is true, and it is true also that few commands were copied in their entirely. I have given a summary of the main

I have accepted that this is true in general. Any design of a command may involve judgement whether to make it a sub-command of an existing command or a fresh command.

I shall consider the consequences of these conclusions after I have considered the eRes system commands and the screen layouts in both systems. I consider that it is necessary to consider all the aspects of the user interface together, and although it complicates the structure of the judgment I cannot at present see any alternative.

In response to any command information will be displayed on the screen. The format in which information is displayed is also in issue (I have given an example in paragraph 26.iv) above). I think, with Ms Antry, that the screens and the commands really have to be considered together, as the system is structured so that each successive command is entered in response to what is displayed in response to the previous command. This is well illustrated in the so-called walk-throughs that were prepared by Dr Hunt. (Footnote: ⁹)

The VT100 screen display formats (i.e. the Reservations, Check-in and IROPs) have two aspects: fixed data and the position of variable data. The six Schedule Planning screens are of the familiar Microsoft Windows GUI type, and raise different considerations.

The evidence in relation to the devising of the screens is divided between Ms Beesley, David Evans, Greg McDaniel, Lane Antry, and Mike Padgen, the last-named being primarily responsible for the Schedule Planning GUI. Others are said also to have contributed. Twenty-seven screens, all identified in Amended Schedule C to the Particulars of Claim are relied on. Some but not all of those screens are set out by Dr Hunt in section 5 of her ‘Similarities’ report, the remainder being found at various places in the very long Section 4 of that report. Section 4 is said to demonstrate the ‘Business Logic’ of OpenRes and eRes, and I shall deal with it below. Unfortunately the degree of similarity between the specified corresponding OpenRes and eRes screens varies widely and they cannot be considered globally. Dr Hunt ascribes percentage scores for similarities in her September report at section 9. Crossexamination revealed that the percentage scores merely reflected a qualitative assessment of similarity and that the scores were accordingly unhelpful.

There are a number of general observations that can be made. The content of each of the screens to be displayed in response to a command was, on the evidence, discussed and from time to time sketched out on paper. Ms Beesley said:

The evidence taken as a whole is not satisfactory. It is important to notice, however, that some skill and effort went into the question of what the screen should look like, but that the manner in which the result was achieved was not the responsibility of Ms Beesley (or the others providing input as to requirements) but the responsibility of the programmer, who had to write the code to display the results in the required format.

I was only shown the code that gave rise to the fixed part of the screen display for any command in Dr Chiu’s evidence in his third witness statement. This is a lengthy passage, and I cannot set it out here. There was no effective challenge to what he said. In the example that he gave which is the ‘incomplete reservation screen’ that is the first item in section 5 of Dr Hunt’s report. His conclusions (paragraphs 8.24-26) were not effectively challenged. The cross-examination concentrated on the fact that the spaces and letters of the fixed data (eg. ••Currency code:, ••Language code) are present in the code. The spaces (I have denoted them with a ‘•’) will print on the line on the screen as they appear on the page in the code. Which lines appear depends upon where the program is in execution and on the data input—see Dr Chiu’s third report, paragraph 8.24.

Dr Chiu again provided a useful diagram showing the overall structure of the eRes system.

Again, the case is only concerned with what is inside the dotted box. Outside the box are the existing systems at easyJet that were accommodated by the new system. The fact that these systems were required to be substantially unaltered with the introduction of eRes imposed certain constraints on the new system, but, as the double-headed arrows show, these constraints (so far as they exist) relate to the database, with which I deal below. They do not constrain the user interfaces in any way.

Dr Chiu also produced a diagram of the software modules in eRes (compare Figure 2 above).

All the command parsing for the VT100 terminals is carried out in the VT100 Interface server. The system makes extensive use of so-called ‘client-server’ architecture, and the application server communicates with its clients (the VT100 Interface server and the Web server) using a uniform Application Programming Interface (API). What happens is that when the VT100 interface server has interpreted a command typed by the user (such as A0113JUNLTNAMS) it creates a message in extensible mark-up language (XML) which is then transmitted to the appropriate ‘workflow’ in the application server. The application server does what is required by the message, and returns the result, also in XML. The received message is interpreted by the VT100 Interface server and the results displayed.

There is no similarity relied on by Navitaire between the actual code for the user interface parts of the software structures shown in Figure 2 and Figure 4. What is relied on is the fact that the eRes software implements an interface that is very similar, in the aspects relevant to the way that easyJet does business, to that of OpenRes.

Some 44% or thereabouts of the OpenRes command set has been reproduced, with some variations, in eRes. The principal differences lie in two areas. The first is that the ‘core’ availability command differs between the two systems in that eRes requires the number of passengers to be input after the ‘A’, while OpenRes has no such requirement. Where there is more than one passenger (not covered by Dr Hunt’s walkthroughs) that affects the way the enquiry and the ensuing transaction are effected. The second is that optional arguments to commands, and whole commands, for which easyJet has no use are omitted. Dr Chiu produced ‘syntax diagrams’ that I found much easier to understand than lists of possible options for the commands in the two systems:

Comparing the two diagrams shows, first, that there is a requirement that the number of travellers be specified in eRes but not OpenRes, and second, that the eRes command has been somewhat simplified by omitting the optional ‘.[fare class]’, because easyJet do not have different fare classes. As I understand the evidence, that is entirely typical of the eRes interface. The commands and options omitted are those for which easyJet has no commercial use.

The commands typed at the terminal by the user of eRes are parsed by the VT100 Interface server. The relevant pieces of code are contained in Appendix 14 to Dr Hunt’s report of 21 January 2004 (F3A[14]). Annexe 3 below explains, again by reference to the ‘A’ availability command how, in outline, a command is parsed.

The names of all the commands appear explicitly in the eRes code in the

There is no full discussion in the evidence of the code that gives rise to the displays in eRes. This problem is discussed further in Annexe 4 with reference to one screen (the incomplete reservation screen) only, which was considered by Dr Chiu in his third Report.

With a few exceptions where my own examination has revealed clear examples, I have not been provided with sufficient evidence to indicate that it is possible to recognise other layouts simply by reading the OpenRes and eRes code, or, if that is not the case, to indicate how much work is needed to extract the nature of the displays from the code. This is unsatisfactory, but the fact remains that all Navitaire’s efforts were expended on demonstrating that the individual screens were either identical or similar, and that the association between copied screens and copied commands contributed to the case on ‘non-textual copying’. The contention was that because the

While computer programs were protected as literary works under the Copyright Act 1956 at least by virtue of the Copyright (Computer Software) Amendment Act 1985, the Copyright, Designs and Patents Act 1988 contains express provisions to a similar effect. The 1988 Act was amended in a number of material respects by regulations made under the European Communities Act 1972 (the Copyright (Computer Programs) Regulations 1992, SI 1992/3233 and the Copyright and Rights in Databases Regulations 1997, SI 1997/3032). The 1992 Regulations do not refer expressly to Council directive (91/250/EEC) of 14 May 1991 on the Legal Protection

In summary, the issues are as follows. Navitaire contend that copyright subsists in the command set as a copyright work distinct from the source code. This claim has a number of aspects: (i) the collection of commands as a whole is entitled to copyright as a ‘compilation’; (ii) each of the commands is a copyright work in its own right; (iii) alternatively, each of the ‘complex’ commands is a work in its own right. As to the displays, Navitaire contend that (i) in respect of the VT100 screen displays, the ‘template’ (fixed data and layout of variable data) is a separate copyright work for each display and (ii) certain GUI screens on the separate Schedule Maintenance module are copyright works as they stand and have been copied. Then it is said (and this is a quite distinct allegation) that the similarity exhibited by eRes to OpenRes in the eye of the user is such that there has been ‘non-textual copying’ of the whole of the source code. This is said to be strictly analogous to taking the plot of a book (Footnote: ¹²): an author who takes the plot of another work and copies nothing else will still infringe copyright if a substantial part of the earlier author’s work is represented by that plot, and the same goes for computer programs: John Richardson Computers v Flanders [1993] FSR 497 (Ferris J).

easyJet accept that copyright subsists in the source code of OpenRes. They submit, however, that since it is common ground that (so far as the user interface is concerned) none of that source code has been directly copied, the only question is whether a substantial part of that code has been taken. The only part of the code that can even arguably be said to appear in eRes is some (but not all) of the command names, and these do not amount to a substantial part of the code. Substantiality is to measured having regard to the skill and labour expended by the programmer on the choosing of those letters: and such skill and labour was trivial, although on any view the skill and labour in writing the software was substantial. They stigmatise the suggestion that copyright subsists in the command set as a compilation, or in the individual commands or some of them as an attempt by Navitaire to invent copyright works from aspects of the system that cannot be described as works at all. This goes for the VT100 displays as well, but the case on the GUI displays (which include the icons) is really only put as a matter of authorship and of substantiality. They contend that the case on ‘non-textual copying’ is objectionable because it extends the protection conferred by the copyright subsisting in computer software to matters that cannot legitimately be the concern of copyright, that is, to the intended effects of running the code on a machine in the business sense: there is no suggestion that the machine physically acts in the same way as the HP3000 machine running OpenRes— it is a quite different computer, involving different hardware etc, and its ‘atomic’ operations are quite different—but the results from the user’s perspective are the

It is convenient to set out all the statutory provisions here.

A further provision has been added to the statute by reg 15 of the Copyright and Related Rights Regulations 2003:

The defendants submit that this is probably a belated implementation of Article 5(3) of the Software Directive, which seems to me to be correct, as does their contention that it probably doesn’t matter, since s. 29 of the 1988 Act must anyway be construed conformably with that provision so far as possible.

The manner in which the claimant’s case has been put reflects the difficulties in identifying the proper approach to a command set such as the present one. The difficulties are (i) single letter commands, and those with longer names, even if clearly recorded in the source code, are unlikely to be entitled to a copyright—Exxon Corp v Exxon Insurance Consultants International Ltd [1982] RPC 69: (ii) whether it can be contended that the syntax of the ‘complex’ commands is recorded in the source code, and skill and labour went into their devising, and they are individual copyright works; and (iii) alternatively, whether it can be contended that the collection of command names as a whole is recorded in the source code and amounts to a compilation entitled to copyright even if the individual components of the compilation are not copyright works.

In my judgment, it is not possible to suggest that a copyright subsists in the individual command names as literary works. They do not have the necessary qualities of a literary work. The Exxon case wisely skirts the problem of providing a test for a literary work. There was no definition of literary work in the 1956 Act (section 48 merely stated that it included any written table or complation) and the definition in the 1988 Act is new. When one considers the modern definition (anything written spoken or sung which is not a dramatic or musical work—paragraph 75 above) it becomes essential to eschew any attempt at further definition. A single command name, or the word Exxon, is certainly written, and is plainly neither a musical nor a dramatic work. So why is it not a literary work? Laddie & al. The Modern Law of Copyright and Designs (3rd Edn) (hereinafter ‘The Modern Law’) suggests that Exxon decides that the word is not a work, but warn that it is the composite phrase ‘original literary work’ which is what matters. There is obviously no bright line test. To attempt definitions ad hoc (such as, does it convey information or emotion?) is ultimately unhelpful. With great respect, this is particularly the case with old dicta from a different world, such as that of Davey LJ in Hollinrake v Truswell (1894) 3 Ch D 420, albeit that it was relied on by Stephenson LJ in the Exxon case:

In the 1988 Act, the phrase ‘literary work’ embraces tables or compilations, computer programs, preparatory design material for computer programs and databases. To concentrate on the word ‘literary’ may mislead, but it must not be ignored. In the end, the question is merely whether a written artefact is to be accorded the status of a copyright work having regard to the kind of skill and labour expended, the nature of copyright protection and its underlying policy. It is not sufficient to say that the purpose of the act is to protect original skill and labour: there was plenty of that in Exxon. Nor is it of much weight that other forms of protection may be available. I think however, that it is clear that single words in isolation are not to be considered as literary works. The individual command words and letters do not qualify.

The second possible class arises from concentrating on the ‘complex’ commands alone. These are the commands that have a syntax, or, put another way, have one or more arguments that must be expressed in a particular way. Mr Arnold QC observes that it is not possible in fact to draw a sensible distinction between the commands identified by Dr Hunt as simple commands and those identified as complex. Dr Hunt described the classification of the DC command as a moot point, and there are others. I think that Dr Chiu’s approach as he expanded on it under cross-examination is probably more satisfactory. It is necessary to distinguish commands that have one form from sets of commands with a common prefix. This is a workable distinction, provided it is remembered that the complexity of the effects of a command is not related to the complexity of its syntax. To describe a command as complex is just to describe its syntax, not its implementation nor its effects. It is possible to divide the commands up in this way. In such a classification, a command with two variants would be a complex command.

However, the division into simple and complex commands throws no light on the correct approach to the subsistence of copyright either in the collection of commands or in the commands considered individually. Some of the commands start little subparsers of their own: for example, the FEE command starts a series of prompts for further input, each line of which must be in an acceptable form. But the command itself is just the word ‘FEE’.

In my judgment, the ‘command word + syntax’ approach to the complex commands in this case is not a valid one. I do not consider that the individual complex commands are distinct copyright works at all. The corresponding work cannot be identified. As pleaded, they are said to be literary works: that is, they must be written—see section 3(1). This aspect of the case turns, it seems to me, on whether and to what extent they have been recorded. They are recorded, in so far as they can be said to be recorded, in the manner I have described in paragraphs 36 and 37. In other words, the source code records them in the sense that it is possible to analyse the code to ascertain that a machine operating according to that code will ‘recognise’ the command

This is a feature of all computer programs in what are often called procedural languages, which are the kind of languages with which this case is primarily concerned. It cannot be too strongly emphasised that a computer program controls a machine, and the result of that control may not appear from the program at all. Accordingly this part of the claim falls at the first hurdle.

However, I am acutely conscious that this may not be a satisfactory answer to the problem. It depends too much upon the way in which OpenRes was written. In answer to a question from me, it was made clear by Dr Hunt that it would be possible to

I consider that the better approach is to take the view that it is not possible to infringe the copyright that subsists either in the source code for a parser or in the source code for a parser generator by observing the behaviour of the final program and constructing another program to do the same thing. In expressing this view, I am verging on drawing a distinction between the ‘idea’ of the program and its

I think the problem should be approached in the following way. To define a series of commands and their syntax to be recognised by the computer is to define a computer language. It is exactly the same as defining a language such as BASIC or a simple language to control a calculator program. A program consists of a statement or series of statements in that ‘language’. Thus, to take the availability command as an example, one would say that the language includes an availability statement that starts with the letter ‘A’ and one of the permissible forms of which is A[date][City-Pair]. An example of a statement that will be parsed as an allowable statement to control the computer in accordance with this language is A13JUNLTNAMS. Recitals 13, 15 and 14 (Footnote: ¹³) of the Software Directive are as follows:

The Software Directive is a harmonizing measure. I must construe any implementing provision in accordance with it: if the implementing provision means what it should,

There is here more than an echo of a conceptual distinction between idea and expression, but it is unprofitable to pursue this approach in the light of the express reference to computer languages and interfaces in the recital and to the interfaces in Art 1(2).

The third possibility to which I refer in paragraph 78 above is to consider the collection of commands as a compilation of non-copyright items entitled as a whole to a copyright as a compilation. Mr Carr QC put considerable emphasis on two cases in particular. Anderson v Lieber Code Co [1917] 2 KB 469 is the case of the telegraphic code, and Kalamazoo (Aust) Pty v Compact Business Systems Ltd (1985) 5 IPR 213 is the case of the pre-ruled forms. Anderson’s case is concerned with the Copyright Act 1911. The code consisted of 100,000 5-letter words that had been arrived at by generating 450,000 words, from which those that were unpronounceable and those that were likely to lead to an error in telegraphic transmission were eliminated. The 100,000 remaining words were used as a cipher. The judgment of Bailhache J in substance follows that of Kay J in Ager v Collingridge (1886) 2 Times LR 291, the core of his decision being that ‘there could be no doubt of the enormous utility of the book, and of the service rendered to anybody desirous of forming a telegraphic code by an undertaking which once and for all eliminated words liable to error, and supplied such a collection of the aptest words for telegraphic use.’ It followed that the collection of codes was the proper subject of copyright.

The Kalamazoo case concerned a collection of accounting forms which when used together made up an accounting system. Some of the forms were intended to be used in a peg-board system in which writing on the top form was reproduced on the lower forms in a stack, the forms being held in the correct register by a system of punched

In my view, the answer to the compilation point is the same as that as I have given in respect of the individual commands. They are a computer language, not a program, and they should not be entitled to copyright. If I am wrong in this, however, I must consider Mr Arnold’s further submission, that there is no pre-existing material to form the subject matter of a compilation, and no compiler. His example is the NP commands, NP, NP. and NP-. Each is said to have been devised by Dave Evans and Mary Beesley, and he submits that there is no scope for selection or ordering. I do not think this is right. The commands are grouped by name into notepad commands. Such a grouping may involve a trivial exercise of skill and labour, but it is there. His better point, I think, is that there is no overall compilation, but merely an accretion of commands. The only influence that one command or set of commands has on the others is that the others must, by definition, have a different name. It is possible for a work that grows over time (say successive editions of Palgrave) to have a single compiler’s copyright, but there must be an overall design. I distinguish between the collection of commands needed for the system, upon each of which skill and labour was expended and the collection of their names, which was never part of the endeavour of the designers. The collection of command names and syntax was never designed as such. It did not have an author, and it did not have joint authors, since it is perfectly possible to distinguish the contributions of the various authors. On this ground also, I think that there is here no compilation.

I am aware that a great deal of interest has been excited by this question in the software industry. I was particularly interested in the development of the law in other countries, both within the EU and outside it, and the parties responded to this interest by providing a great deal of material from other jurisdictions. As I should have foreseen, the law is everywhere in a state of development, and the results differ from jurisdiction to jurisdiction. Within Europe, the German approach appears to be that identity of interface is not objectionable in itself, but may point to copying of the underlying code. In France, the user interface may be protectable. In the US, there are divergent authorities. In New Zealand and Australia, the point is undecided. While I have read much of this material with interest it has not, in the end, provided me with assistance. The point has evidently vexed many judges and will no doubt vex many more.

Copyright protection for computer software is a given, but I do not feel that the courts should be astute to extend that protection into a region where only the functional effects of a program are in issue. There is a respectable case for saying that copyright is not, in general, concerned with functional effects, and there is some advantage in a bright line rule protecting only the claimant’s embodiment of the function in software and not some superset of that software. The case is not truly analogous with the plot of a novel, because the plot is part of the work itself. The user interface is not part of the work itself. One could permute all the letters and other codes in the command names, and it would still work in the same way, and all that would be lost is a modest mnemonic advantage. To approach the problem in this way may at least be consistent with the distinction between idea and expression that finds its way into the Software Directive, but, of course, it draws the line between idea and expression in a particular place which some would say lies too far on the side of expression. I think, however, that such is the independence of the particular form of the actual codes used from the overall functioning of the software that it is legitimate to separate them in this way, and not to afford them separate protection when the underlying software is not even arguably copied.

The screens are obviously part of the user interface. The degree of similarity varies, and in my view the GUI screens raise different issues from those raised by the VT100 screens. There are 26 screens in all, and my analysis is set out in Annexe 5.

The VT100 is a character-based terminal, that is, it displays only printable characters. It provides 80 single-character columns and 24 rows for the display. As I endeavour to show in Annexe 5, one can see some of the layouts, at least, in the code because they are character-based, a good example being the baggage count display (item 11). The inference I draw from this is that the character-based displays are properly to be viewed as tables and so literary in character for the purposes of copyright (section 3(1)(a) of the 1988 Act above). They are, in my view, ‘ideas which underlie its interfaces’ in the sense used in Article 1(2) of the Directive: they provide the static framework for the display of the dynamic data which it is the task of the software to produce.

The GUI screens stand in a different position. The Directive is concerned only with the protection of computer programs as literary works, and I do not read it as having any impact on relevant artistic copyrights. It is certainly possible to view the GUI screens as tables, because they are ‘drawn’ by selecting from a palette of available objects things such as command buttons, toggle buttons, checkboxes, scrolling lists and so forth and moving them around on a form until a satisfactory layout is concerned. The ‘interface builder’ program provides ‘stubs’ for the routines that will be executed when the user selects or clicks on one of these objects, and it is the task of the programmer to provide the necessary code to ensure that the right thing happens when the user presses (for example) the OK button. Although composed of elements made available by the manufacturer of the interface builder program, I can see that the screen resulting from such an operation might properly be considered to be an artistic work. What the programmer ultimately produces is code that depends upon a large number of complex graphic routines that draw the background, the boxes

In my judgment, the better view is that the GUI screens are artistic works. They are recorded as such only in the complex code that displays them, but I think that this is strictly analogous to more simple digital representations of graphic works. The code constructs the screen from basic elements, and is so arranged to give a consistent appearance to the individual elements. I think, nonetheless, that to arrange a screen certainly affords the opportunity for the exercise of sufficient skill and labour for the result to amount to an artistic work. I consider that the GUI screens satisfy this requirement. There is force in the suggestion that they present a uniform appearance in layout of the elements, and so contribute to a uniformity of interface. On the whole this is sufficient skill and labour to entitle the screens sued on to artistic copyright.

In the result, therefore, the action fails so far as the VT100 screens are concerned, but succeeds so far as the GUI screens are concerned. The icons are plainly copyright works, albeit minor, and the action succeeds in respect of them as well.

Navitaire does not only complain of the copying of the screen displays during the operation of the reservation and check-in modules. They complain also of the copying of certain so-called reports. Reports are presentations of the data in the database, and are of particular importance in providing information about the functioning of the business. The reports are generated for the most part by individual programs. The evidence is not entirely clear as to how they are accessed, but it does not matter. My conclusions are in Annexe 6 below. In summary, this claim wholly fails.

OpenRes maintains an audit trail of all transactions. A record of every transaction is inserted into the History database. Part of the record written into the History database is a two-letter code identifying the nature of the transaction. Two commands, .H and .Hn are used to query the History database, and produce a general history for the currently active booking and a detailed response respectively.

To refer to a ‘History application’ is a misnomer. There is no separate application. In OpenRes it consists of code that is invoked at many points in the program, and a dataset. The history codes (that is, the two character codes that are used to identify the nature of the entry in the database are specified in the COBOL code.

In eRes, there is also a separate history database. The names of some of the fields of the history table in this database are very similar to those of the corresponding OpenRes dataset. The two letter codes are not all the same, but very similar. The structure of this table was copied from OpenRes by taking the layout of the history data during the migration process. I will discuss this in detail when I consider the database claim, and it is not necessary to consider it here.

The software has nothing in common apart from the use of the same codes (there are sixteen) for identifying different history items. I do not understand copyright to be claimed in this set of codes. The two commands (.H and .Hn) are the same. The screens are similar. The database representation is very similar. Thus (database issues

The ‘History Application’ is no longer relied on as a copyright work, unsurprisingly since there is no identifiable module. It was abandoned as a distinct claim after service of the experts’ reports in October 2003. It is thus part of the ‘Business Logic’ claim, but distinguished, as I understand it, by its standalone nature.

The History function is entirely banal. Dr Hunt described its corresponding database table as lying between the core tables and the pathetic ones (sic) because the functionality was necessary to a functioning system but not for the purpose either of effecting a reservation or of getting the passenger on to the aeroplane. She also accepted that *H or .H commands were common for history in reservation systems, that the function itself was commonplace, and that other systems produce displays similar to that in OpenRes. Two letter history codes are common, albeit that the eRes and OpenRes ones are very similar if not identical. It is accepted that the manner of operation of the two systems is different, but that they produce results that are consistent (the History dataset is one of the datasets migrated into eRes). Of course, there is no similarity in the underlying source code. This aspect of the functionality of eRes can only form an aspect of the non-textual copying claim and, for the foregoing reasons, is entitled to little weight.

As I have indicated above, the case advanced by Navitaire is based on the fact that the functions of OpenRes and eRes are identical to the user so far as the aspects of the system of interest to easyJet are concerned. The case had its origin in the suggestion that what was called the ‘business logic’ of OpenRes had been appropriated.

During the course of her cross-examination on this subject, Dr Hunt gave this important answer.

As will appear from what I have said, I agree that the commands were really quite a limited feature. The question is whether the ‘something else that has been copied’ over and above the limited features of commands and screens is something Navitaire may protect from being copied. It seems to me that the following list sets out the matters copied over and above the comparatively limited aspects of the user interface:

This formulation concentrates on similarities and ignores differences. It is basic to the discussion that all the processing carried out by the systems, including background processing, is different: and it is accepted that the error processing, an essential feature of any program, is also different.

Dr Hunt’s use of the term ‘Business Logic’ for what was taken was bound to run into problems, because it seems to assume that one can identify in the source code programming logic that in some way reflects the business logic. This assumption was explicit in Dr Hunt’s original reference to pseudocode in section 3 of her April report, which was dedicated to the question of what business logic was. It is clear from her cross-examination that it was she who was responsible for the reference to pseudocode. This gave rise to a dispute with Dr Chiu that is enlightening.

I shall return to first principles. For present purposes, a computer running a particular program is a deterministic machine. A particular input to the machine will produce a predictable result derived from all previous inputs to the machine. If therefore one studies a machine in operation, it should be possible to identify the machine’s response to all possible sequences of inputs, and so construct a new machine that operates to give the same outputs for the same sequences of inputs by writing an appropriate program. Navitaire contend that if this is done, it follows axiomatically that any copyright in the source code for the first machine must be infringed in writing the second program. Indeed, it was urged on me at an earlier hearing that it was unnecessary to consider any of the source code for the OpenRes system in determining whether there had been copying of a substantial part of the copyright(s) subsisting in the source code for it.

There is no doubt that easyJet and BulletProof had no access to the source code of OpenRes, and it is not in dispute that in languages used, actual code and architecture (subject to the claim in respect of the database) the systems are quite different. There is no suggestion that the eRes code represents a translation or adaptation of the OpenRes code. The term ‘non-textual copying’ might be replaced by the more accurate ‘copying without access to the thing copied, directly or indirectly’.

The claim depends first upon the contention that the manner in which a machine behaves under the control of a program represents part of the skill and labour that went into the program. This is not an unreasonable observation. On the contrary, it is the whole object of the programmer to get the computer to behave in the required manner.

To copy an operating machine in this manner avoids the need to conduct any systems analysis or the production of functional specifications. Thus, it may be observed that although the copyist has not avoided the need to write software to achieve the desired result, he has avoided the need to identify the result by any of the normal methods of analysis that either precede or accompany the writing of a substantial piece of business software. Dr Hunt described this process as follows:

In this connection, it may be noted in passing that no such formal analysis was ever carried out in the design of OpenRes. It is clear from the responses of David Evans, Greg McDaniel and Mike Padgen that they based OpenRes upon their previous experience and upon the comments and requests received from customers. It is not unfair to say that Navitaire object to BulletProof’s and easyJet’s acquiring the greater part of their experience from an examination of OpenRes in use alone. However, shorn of the specific user interface features that I have discussed, the operation of OpenRes cannot be distinguished from the manner in which other booking systems operate. Ms Antry, who was responsible for the design of the system was crossexamined on this point:

The overall functionality, from a business perspective, is what is accepted by Ms Antry in this passage. The steps are, in essence, check flights–check availability of seats–reserve–take passenger details–take payment details–record transaction. The seats thus sold must be made unavailable for future passengers, and that may be done at a number of stages in the transaction (including the initial grab: they can be returned to stock if the transaction is ultimately not proceeded with). This is common to reservation systems, and makes up what Dr Hunt calls the ‘core’ functions of the system.

The problem, therefore, if one is to arrive at a finding of infringement is to settle on a level of abstraction that describes something that is not merely inherent in the nature of the business function to be performed by the software, is taken by the defendants, represents the skill and labour of the designers and programmers but goes wider than the details of the command set and the screen displays, acknowledged by Dr Hunt to be a limited feature. Since copyright in computer programs is a literary copyright, the

In Designer’s Guild v Russell Williams Textiles Ltd [2000] 1 WLR 2416, Lord Hoffman says at 2422:

This passage encapsulates the state of the law. Mr Carr QC submits that Lord Hoffmann is describing a case of ‘non-textual copying’. That is no doubt so, if the meaning of those words is merely that the defendant has reproduced the copyright work in a different form, as in Harman Pictures v Osborne [1967] 1 WLR 723 where the similarity in language was slight but the choice of incidents the same, or in Holland v Vivian van Damm Productions Ltd [1936-45] MacG CC 69, where a ballet was held to infringe the copyright in a short story by Oscar Wilde. This principle extends to compilation cases: Jarrold v Houlston (1857) 3 K&J 708 is relied on by Mr

Mr Carr QC says that this is a description of non-textual copying. That is not so as Houlston had taken the questions and the selection directly from the copyright work. But assume that he had not taken the questions, but merely the arrangement of and selection from the primary sources. That would still have been infringement: Macmillan v Cooper (1923) 93 LJPC 113, and that would be so even if the material abstracted from the prior works had been summarized or abstracted in different terms, provided that the selection had been copied.

What differentiates the present case from those to which I have referred above is that the copyist did not have access to the copyright work: in Jarrold v Houlston the copyist had access to the copyright work and used it. It may be noted that as he initially denied copying altogether it was subsequently difficult for him to identify convincingly the parts he had not copied: compare the Ibcos case (above). Two other cases are particularly relied on by Mr Carr. The first is John Richardson Computers v Flanders [1993] FSR 497 (Ferris J). This is a difficult case to summarise, but for present purposes I need only refer to a few salient facts. Mr Flanders, the defendant, had written the program the copyright in which was asserted against his new program. It was accepted that he did not have access to a copy of his earlier work when he wrote the later; and the judge rejected any contention of deliberate copying. He said this:

Seventeen similarities were relied on. Nearly all of them were rejected, but the ones which survived included the ‘line editor’. Ferris J dealt with this feature in the following way.

The reference to ‘copying of expression as well as idea’ is a clear echo of the United States authorities discussed at length by Ferris J elsewhere in his judgment whose employment for this purpose was criticised by Jacob J in the Ibcos case, itself relied on by Mr Carr. But it is quite correct, as he submits, that it is possible to read the foregoing passage as stating that the concept of ‘expression’ as distinct from ‘idea’ extended to the manner in which the programmed machine worked, in detail. If this was what Ferris J was saying, then I would respectfully suggest that it is based upon a misapprehension as to the meaning of ‘expression’ in this context. But I do not need to go into this in detail, because I would with respect accept what is said by Jacob J in Ibcos:

This does not answer the question with which I am confronted, which is peculiar, I believe, to computer programs. The reason it is a new problem is that two completely different computer programs can produce an identical result: not a result identical at some level of abstraction but identical at any level of abstraction. This is so even if the author of one has no access at all to the other but only to its results. The analogy with a plot is for this reason a poor one. It is a poor one for other reasons as well. To say these programs possess a plot is precisely like saying that the book of instructions for a booking clerk acting manually has a plot: but a book of instructions has no theme, no events, and does not have a narrative flow. Nor does a computer program, particularly one whose behaviour depends upon the history of its inputs in any given transaction. It does not have a plot, merely a series of pre-defined operations intended to achieve the desired result in response to the requests of the customer.

The view in favour of Navitaire’s case is expressed concisely by the authors of The

There is a counter-example that throws some light on the nature of the problem. Take the example of a chef who invents a new pudding. After a lot of work he gets a satisfactory result, and thereafter his puddings are always made using his written recipe, undoubtedly a literary work. Along comes a competitor who likes the pudding and resolves to make it himself. Ultimately, after much culinary labour, he succeeds in emulating the earlier result, and he records his recipe. Is the later recipe an infringement of the earlier, as the end result, the plot and purpose of both (the pudding) is the same? I believe the answer is no.

I think that the answer to the problem is to be gathered from the passage in Lord Hoffmann’s speech immediately following that quoted above (paragraph 119) from the Designers’ Guild case:

The questions in the present case are both a lack of substantiality and the nature of the skill and labour to be protected. Navitaire’s computer program invites input in a manner excluded from copyright protection, outputs its results in a form excluded from copyright protection and creates a record of a reservation in the name of a particular passenger on a particular flight. What is left when the interface aspects of the case are disregarded is the business function of carrying out the transaction and creating the record, because none of the code was read or copied by the defendants. It is right that those responsible for devising OpenRes envisaged this as the end result for their program: but that is not relevant skill and labour. In my judgment, this claim for non-textual copying should fail.

I do not come to this conclusion with any regret. If it is the policy of the Software Directive to exclude both computer languages and the underlying ideas of the interfaces from protection, then it should not be possible to circumvent these exclusions by seeking to identify some overall function or functions that it is the sole purpose of the interface to invoke and relying on those instead. As a matter of policy also, it seems to me that to permit the ‘business logic’ of a program to attract protection through the literary copyright afforded to the program itself is an

I am also confirmed in my view by the evident difficulty that the formulation of the ‘non-textual copying’ or ‘business logic’ case has caused the claimant. The claim was first set out by Dr Hunt in her April, May and June reports and it became clear that her approach to business logic involved creating an abstract view of the functioning of the software at many different levels, together with disregard for features of the systems that were in fact different. She concentrated on the user interface aspect, but ignored the background processing and error processing. By the end of the trial, the claim had undergone a further metamorphosis, being characterised as a claim in respect of the ‘dynamic user interface’. Although a fine concatenation of buzzwords, this phrase is difficult to pin down as a matter of meaning. Although it was mentioned once by Mr Carr at the outset of the trial it appeared little (it is not used by Dr Hunt is her reports) until it was put at the centre of Navitaire’s case in its submissions as to the material findings of fact. What Navitaire say is that they

The claims in respect of TakeFlight are limited. TakeFlight is the program that provides the web interface to OpenRes. It is a ‘web server’ program, in that it sends pages of text in hypertext markup language (HTML) to browser programs running on computers in the homes of the customers. Embedded in these pages are small pieces of code in a language called JavaScript, which provide certain dynamic features of the page. TakeFlight interacts with the reservation system through an interface provided by the ORSVR01 module (Figure 1 above) through an API which is said to be not well defined.

Everything to do with TakeFlight is the concern of easyJet alone. While BulletProof defined and implemented the reservation system API, all the code for this allegedly infringing program was written in-house at easyJet by Mr Pritchard. BulletProof were not concerned with it. This is one of the advantages of a well-defined API: more than one author can write programs for it, as the huge range of programs written for the Microsoft Windows API attests.

It is common ground that TakeFlight was supplied to easyJet pursuant to the obligation to provide a web interface (paragraph 20 above). It was written by Justin Wilde, then a student working impossibly long hours as a programmer. The module is written in a language called Perl which is not compiled into object code but is ‘interpreted’ by a program called a Perl Interpreter. TakeFlight is the only piece of source code with which easyJet were ever supplied.

There are two aspects to the claim. One is a complicated complaint relating to what are alleged to be unauthorised alterations made to the TakeFlight code by easyJet over the years that it was in use. The other was a claim that the software now used by easyJet, referred to at trial for some reason as NIBS for ‘New Internet Booking System’, infringed the copyright in TakeFlight. The program is in fact called easyJet.com.

easyJet.com uses exactly the same API as the VT100 system to interface with the booking system. It also communicates by passing XML messages. So far as the outside world is concerned it looked rather similar to TakeFlight. There is not now any suggestion that the source code of TakeFlight was copied when NIBS was written, the contention having been abandoned in opening. A small piece of unused code remained in part of the site, but that is irrelevant. The complaint of infringement, therefore, is one of non-textual copying, and is based on the contention that the Perl code records a ‘five-step’ booking process which it is alleged was devised by Mr Wilde, and that to copy the ‘five-step’ booking process is to take a substantial part of the copyright code.

TakeFlight is a program whose function is to serve pages to customers in a predefined order so that a booking transaction can be carried out. TakeFlight was integrated into easyJet’s web site, which had been designed by a company called Tableau. This is often described as providing a ‘skin’ for an application, and Tableau had designed the ‘skin’ for TakeFlight. It was, so Mr Pritchard observed, a strongly easyJet look. The task of TakeFlight was to obtain the user’s input; obtain the necessary data from the booking system; combine it with the fixed data forming part of the data for the Perl program, and transmit the resulting page to the user. It is a fairly complex application.

Dr Hunt describes the elements of the transaction thus:

A number of points arise. Dr Hunt’s inability to re-create step 5 means that she could not detect any differences in that stage, and there are some. Second, because these points arise in the ‘similarities’ report, Dr Hunt deliberately omitted points of difference she had detected when she first saw the interface.

Dr Hunt’s Step 2 includes the display of available flights displayed according to the criteria stated in Step 1. Accordingly the five steps are a dialogue: ask for available flights–return available flights–select flight–display details and price of selected flight, inviting booking–book by giving personal and credit-card details–confirm booking. Navitaire contends (relying on Mr Wilde’s evidence) that there is no need for step 3 if one is booking single leg flights. I cannot see why this is the case, and having read Mr Wilde’s evidence I am none the better informed. In fact, the booking sequence mimics the sequence followed by a call centre agent. The cross-examination of Dr Hunt persuaded me that there was nothing in the claim for ‘non-textual copying’. A sequence of obvious booking steps does not amount to a substantial part of the Perl code, which nobody even looked at. Dr Hunt spent some time analysing the various widgets used in the pages, such as scrolling lists, drop down lists, radio buttons and the like, but these are entirely conventional. Indeed, easyJet did not always use the same widgets as did TakeFlight. This claim should have been abandoned.

A problem that was apparent to Mr Pritchard when he joined easyJet in 1999 was that of the need to modify TakeFlight to add new routes, or a new destination, or for short term promotions. easyJet also wanted foreign language versions, which were not available. The program suffered from bugs described by Mr Pritchard, and, apart from comments in the code itself, it was undocumented. It had no manual.

Mr Pritchard observes that a particular problem with TakeFlight lay in the fact that matters relating to presentation, such as language of the site, special offers and so on, were not separated from the program logic, as in a well designed application they

There is no doubt that easyJet copied the Perl code for the following purposes: (1) bug fixes (2) foreign language versions (3) adding and removing promotions (4) adding a new look and feel in the form of a new ‘skin’ and (5) using the program for easyJet Tours, which is a different legal person from easyJet. A degree of customisation to the program was permitted by an initialisation file called tflight_globals.pl. Mr Wilde exhibits this file, which encourages, but does not require, users to contact him to make the adjustments. I am not told in detail what degree of customization it permitted, but, whatever it was, it was not enough for easyJet’s purposes. It is accepted that these modifications involve infringements of copyright unless for some reason Navitaire are debarred from alleging infringement. Two grounds are alleged: express agreement and acquiescence.

When easyJet started using TakeFlight, it was not clear that internet booking would be the way forward. From easyJet’s perspective, it was important to be able to maintain a degree of control over the site to take advantage of new opportunities as they presented themselves. easyJet had always wanted to write their own site, and there were attempts to obtain a definition of the ORSVR01 API for that purpose. These were partially successful in that in either May or August 1998 Mr Padgen sent Mr Just part of the so-called ‘buffer bible’, the document used internally by Navitaire to document the ORSVR interface.

The functional modifications were mainly carried out by Mr Pritchard. He devised the ‘Intelligent route selector’, and produced the copies for promotions. In July 1999, he cloned the program to sell flights in French between Geneva and Barcelona. In November 1999 he introduced email booking confirmations. It is not necessary for present purposes to examine any changes he made after February 2000 since on 23 February 2000 Navitaire wrote to easyJet complaining of the modification of the TakeFlight source code. It is beyond doubt that easyJet were on notice after that date that further modifications were not approved. Thereafter, negotiations between the parties continued, but in the end they reached no satisfactory conclusion.

easyJet allege that there was from the outset an oral agreement that they should be free to modify TakeFlight. This allegation fails. There never was such an oral agreement. None of the witnesses ultimately supported it.

Mr Wilde knew that easyJet were modifying TakeFlight from June 1998. There is no doubt that by May 1999 Mr Wilde, who was a very unimpressive witness, and whose truthfulness I doubted, was aware not only that easyJet were making unauthorised alterations to the code, but had cloned the code to produce multiple running versions to run simultaneous promotions. There was a wide dispute whether there had been any complaint to easyJet about this prior to the disintegration of the relationship between Navitaire and easyJet in 2000. The person alleged to have complained is Mr Wilde. He could produce no emails complaining from before 1999 (his emails had been deleted from the mailserver) and after that time he said he said he sent no emails because he had become frustrated. easyJet produced over fifty emails from early 1998 to mid 1999 originating with Mr Wilde, none of which referred to this complaint. I find that no such complaint was made to easyJet. Indeed, Mr Wilde was assuming a good knowledge of the Perl code on Mr Just’s part when he recruited the latter to a debugging exercise in May 1998. Mr Wilde suggested that he was ‘authorising’ Mr

However, I find that Mr Wilde did nothing actively to encourage easyJet to modify the code, and I am satisfied that if he had told them not to he would have been disregarded. I think that easyJet were anxious to modify the code if it was necessary for a commercially successful operation of the site. Accordingly, there was no reliance by easyJet on any representation that Navitaire’s rights would not be enforced, and no reliance by easyJet on Navitaire’s failure to take any steps. To debar Navitaire from all relief there must at least reliance: see Farmers’ Build v Carier Bulk Materials [1999] RPC 461. There is none here. So Navitiaire is not debarred by acquiescence or otherwise estopped from seeking relief in relation to the unauthorised modifications to TakeFlight.

In respect, therefore, of the claims for unauthorised alterations to TakeFlight, Navitaire are entitled to relief.

There are a number of aspects to this claim. First is the question of reproduction of a part of the OpenRes database before the development of eRes proper took place, in what was called the ‘Proof of Concept’. The Proof of Concept was a system designed to demonstrate to easyJet that BulletProof’s suggested approach to the problem, that is a client/server structure using XML messaging and a database constructed using the Microsoft SQL server database management system, was capable of giving the throughput that easyJet required.

Next is the making of what Navitaire say are illicit copies of parts of the OpenRes database to enable BulletProof to investigate the contents and, Navitaire say, the structure of the database.

Then it is said that easyJet made illegitimate copies of the OpenRes databases for the purpose of ‘migrating’ easyJet’s data from the old system to the new.

Finally it is suggested that eight tables in the eRes database reproduce a substantial part of certain copyright works, the database schemas or creation scripts, for datasets in the OpenRes database. Generally these can be referred to as the schemas, but they also form part of the database itself, where they are ‘data about the data’, or metadata. The programs called Adager and Suprtool can extract all the schema information from the metadata, and no doubt there are others as well.

Some technical understanding of the databases in this case is important to the analysis of the issues, because Dr Chiu maintained, and I accept, that certain technical features of the OpenRes databases mean that it was not possible to extract information as to the logical structure of the database with confidence from the databases themselves without access to the code that manipulated them: and it was common ground that this code was not accessible to the defendants. Dr Hunt had herself analysed the structure of the OpenRes and eRes databases in considerable detail, and presented a substantial body of evidence relating to similarities of structure, without, I have to say, clearly indicating in her reports whether or not those similarities were likely to be due to copying in the particular circumstances of the case. I used the materials supplied to me by the parties, supplemented by a substantial amount of instruction from the experts in the witness box.

In the discussion which follows, I refer to ‘Source Safe’ and to code being ‘checked in’. Visual Source Safe is a Microsoft program that holds a database consisting of all programs ‘checked in’ to it. Every time that a program is checked out and then checked in, a record is kept of the alterations made to it. Using Source Safe, therefore, it is possible to obtain a history of the changes made to the program and of the dates those changes were made. Such dates must be used with care, since programmers differ in their assiduity in checking things in and out, and some source code may lie around for long periods without being checked in. Its utility in the present case was much reduced because many of the relevant records had been irrecoverably destroyed, but in some respects it was helpful.

The case also raises questions of difficulty concerning what the owner of the data in a database is entitled to know about his own data. It is convenient to consider the whole history before considering whether and to what extent the existing eRes system infringes any relevant work.

The claimants rely upon the following:

Document 200 appears to be a set of schemas prepared for some purpose, but the presence of the extraneous numbers which would have prevented this file from acting as the source file for a database compiler means that it is not a document from which any database has ever been derived. I find that it probably does represent the state of the EAIS FLT database in 1994. In its submissions on the material findings of fact, Navitaire advance no case in respect of this document. It has never been formally abandoned, but its place in the history is not properly elucidated. I have checked one detail dataset in it (INVENTORY) which is rather different from the INVENTORY dataset in document 210. I will not consider this document further.

Document 210 is the transcript of a session using the database analysis tool Adager on the OpenRes database. (Footnote: ¹⁷) The tool is asked to output the database schema to the terminal, and this transcript is the result. It cannot be a copyright work on its own, as it was never used to create the databases. It is merely generated from the databases. The actual scripts used to create the databases may have existed, but they have not been produced. The reason I say they ‘may have’ existed is that it is possible to modify the databases without reconstructing them. Adager or some similar tool may also be used to specify the datasets in the first place, the result being recorded in a schema file. I accept that use of Adager in this way created a copyright work. Navitaire seek to treat the schema for each of the datasets as a separate copyright work, and I think this may be right. There are almost no relationships between the individual datasets expressed at the level of the database and thus each dataset may be said to stand alone, but the subdivision of data represented by the various datasets within the database is, of course, a matter of overall design. The relationships are maintained in the mind of the programmers who write the code that accesses the database and are ultimately implicitly expressed in the code. Against this, the fact that certain fields appear in more than one dataset reflects a degree of skill and labour in the design of the group of datasets as a whole. I can see no reason why the script for each dataset should not be considered an individual copyright work, or, alternatively, that the present state of the database records the metadata corresponding to a particular database structure.

Whether the notional scripts for the individual tables are individual works or the whole is a single copyright work seems to me to be quite irrelevant. There is a desire to minimise the size of the individual copyright works because of a concern that a substantial part of a ‘small’ copyright work may not be a substantial part of a larger work of which the small is but a part. Mr Arnold QC’s submissions assume that this is the case. I do not think this can be right. Substantiality is not a question of proportion to the whole but of quality in context. As I have said elsewhere, the division of source code into modules and so on is as much a result of pressures extraneous to writing the software (such as debugging, maintenance and convenient building) as it is a result of deliberate design. Indeed, some methods of writing software may decide the modules for the programmer. I attach no importance to such divisions, although their appearance in allegedly copied code may be a thumbprint left by the copyist. To return to the database scripts, a banal table consisting of, say, a name, address and social security number may not be a substantial part of a large database work: but by the same token, it will be insufficiently original to be a copyright work considered on

When the development of the eRes system started, easyJet’s databases contained records of every reservation that had been effected using OpenRes. This was a large amount of data. The figure of 22 million records was mentioned. These historical records were, as I understand it, held in the live database, and this was a requirement from which easyJet were unwilling to depart. At all times, easyJet were anxious that the historical data was correctly ‘migrated’ to their new system, and this was understood by both parties to be a requirement of the contract. easyJet consulted their auditors on what was required for the migration: and one of the criteria was that eRes would have to produce exactly the same reports from the historical data as did OpenRes.

There is a comparatively limited number of persons who are central to this story. At

The ‘OpenRes database’ consists of five distinct databases called CTL, FLT, VISADB, HISTDB and PEOPLE. The table creation scripts recorded in Doc 210 will generate (among others) five empty databases with these names. Of the datasets

Navitaire contend that the database schema records (a) each table within OpenRes, each field within each table and the order in which the fields are arranged; and (b) information from which it is possible to draw an entity relationship diagram (‘ERD’) showing links between the tables in the database. Proposition (a) is true, although the order of fields is of no interest or significance save that similar ordering may be an indication of copying. Proposition (b) is so inaccurate as to be positively misleading.

Dr Chiu explained the nature of the datasets in a TurboImage database. There are three types of datasets: manual masters, automatic masters and detail datasets. OpenRes stores the attributes of the relevant entities (INVENTORY, for example) in detailed datasets. Many of these datasets are linked through keys (FLIGHT-SEG, for example) defined in automatic masters (FLIGHT-SEG-A) to other datasets (ten, in the case of FLIGHT-SEG). TurboImage does not permit direct relationships to be established between detail datasets. Automatic masters are in the nature of indexes, and they are constructed automatically. Detailed datasets cannot themselves be defined to contain unique keys. I set out the example given by Mr Padgen, on whose second witness statement the claimants rely in this connection:

The ‘!’ before FLIGHT-KEY-A identifies FLIGHT-KEY as the primary key of this table. Thus, data is extracted from this table via an index stored in the FLIGHT-KEYA automatic master. Now consider the INVENTORY dataset:

This is indexed on FLIGHT-SEG, a key maintained automatically in the automatic master FLIGHT-SEG-A. How does one know what the relationship between INVENTORY (what is available to be sold) and FLIGHT-STEP, which equally contains FLIGHT-SEG as a key? Mr Padgen says this:

The reason for the existence of FLIGHT-STEP and how it is used were described by Mr McDaniel, who designed them.

I have no doubt that the analysis proposed by Mr Padgen is perfectly possible but it depends upon a thorough understanding of the function that the table is called upon to perform. Moreover, as Mr Padgen himself acknowledged, part of the analytical process would depend upon watching the database as data was written to it. For this reason, I accept that it is possible to deduce the relationships in the database but to say that the schema contains information from which it is possible to draw an entityrelationship diagram is part only of the truth. To draw such a diagram requires substantial effort. It needs confirmation from observation of the code.

Of course, what the schema does give is a list of the tables and their contents. Mr

The fact that the allegation of copying in eRes is only maintained in relation to a small proportion of the database must also be considered. Furthermore, the tables have very differing degrees of importance. TOPIC and SUB-TOPIC, for example, are part of the help system. Dr Hunt tends to use the word ‘core’ rather frequently, both when talking about the functions that the system has to perform and about the tables, and it is better to ignore it: sometimes I thought that everything identified by her as a similarity was ‘core’. In each case also, the suggested manner in which the copying took place is or may be different.

For these reasons, I accept Dr Chiu’s contention that to draw an ERD of the OpenRes diagram from the schema produced by Adager or Suprtool removing links which may be deduced to be unused, or to have a particular cardinality and without referring to the automatic masters, is not a fair view of the OpenRes schema.

I think it is fair to describe eRes as an orthodox group of relational databases. It has a number of important features. First, and most important, is the ejWorkspace database. This database is designed to support the actual booking process, and it is used so that it is unnecessary to write to the ejReservations database until a particular booking is complete. To do this speeds the system up. The workspace database contains tables identical in structure to those in the main database: WrkContact, WrkReservation, WrkPersonName, wrkPayment and so on. Data is transferred from these tables to the corresponding tables in the main database only when a booking is complete. The workspace database is thus much smaller than the main database, and this greatly helps throughput.

The links and their nature (one to one, one to many) can in great part be ascertained from the schema. This is the major difference from the OpenRes schema, which in this respect is just a starting point for a lengthy investigation. The primary key for each table on the many end of a one-to-many relationship is a unique integer value generated by the so-called keyserver. Where there is a one-to-one relationship, of course, one table represents an entity and the other can be taken to represent further attributes of that entity, and the two tables share the primary key. The obvious example (Footnote: ¹⁹) is Flight and Flight-Following where Flight-Following contains the physical history of each flight defined by a row in Flight.

In addition to the data tables there are many stored procedures. These are stored in the database and are activated by the database server on receipt of the relevant message. There is no equivalent to the stored procedures in OpenRes. The necessary functions in OpenRes are carried out in COBOL code.

Before turning to the details of the history, I should refer to the manner in which database designers go about their work. In paragraph 14.8 of her September report, Dr Hunt said that

I wish to concentrate on the first of these two sentences. When ‘user requirements’ are analysed, the product is a combination of the two computer-generated items (screen layouts and reports) from existing systems and one that is not—business process analysis. It is clear from the very extensive examination of the emails passing between BulletProof and easyJet that BulletProof’s approach was to work using the easyJet manual, the screen shots and the reports. There were many questions relating to the particular data: what was it for, and did easyJet use it? Dr Chiu, also, was in no doubt about the normal approach to systems design:

It is confirmed also by one at least of the textbook extracts with which I was supplied. Section 10.3 of Database Systems: A practical approach to design, implementation and management Connolly and Begg, (1995-2002) suggests that one of the sources of information for the designer of a new system includes ‘various types of flowcharts and diagrams; data dictionary; Database application design; program documentation; User/training manuals’.

It seems clear that the development of eRes was a consequence of a deterioration in the relationship between easyJet and Navitaire, largely contributed to by Navitaire’s reluctance or inability to provide easyJet with the API (applications programming interface) specification that would enable easyJet to write its own internet booking GUI for its website. Always a company that sold flights direct to the public, easyJet started by using a call centre. By 1997 it had 200 call centre staff and twenty aircraft, and the call centre was handling 6m calls per year. It saw in the Web the direction of its future expansion, and considered, therefore, that the web GUI was of primary

The development of eRes started with a call made by Mr Vandertol to the chief executive of easyJet, Ray Webster, in December 1998. Mr Webster, who is very experienced in the airline industry, has substantial programming experience. He wrote the open database connectivity (‘ODBC’) scripts enabling easyJet to access the OpenRes database to extract data for the easyJet reporting database, EZReportDB. He had known Mr Vandertol at Air New Zealand. Mr Vandertol had set up BulletProof in 1995, and appears to have been on the lookout for work.

The following account follows the references given in a helpful chronology prepared by Navitaire from both parties’ submissions on fact. This document taken with the documents to which it refers is invaluable and generally accurate. Mr Vandertol had started in IT in 1985. In 1987, he joined Computer Solutions International, where he taught courses on dBase, rBase and Paradox database systems (none are relational). He also consulted with Air France, principally on issues relating to yield management. His exposure to airline booking systems at Air France was not substantial, as he himself volunteered in cross-examination. Mr Arnold says that Mr Vandertol was exposed to Air France’s reservation system, but Mr Vandertol himself was not prepared to claim that he had derived much from that exposure, such as it was. From 1988-1990, he was employed by Ashton-Tate, manufacturers of the dBase software, and was responsible for writing technical documentation for the use of persons wishing to migrate databases using Ashton-Tate products to Microsoft SQL Server.

In 1990, Mr Vandertol went to Air New Zealand, where he worked for Mr Webster. He was a programmer, and responsible for such things as writing code to ensure network connectivity. He became acquainted with global distribution systems (reservation systems used by more than one airline, travel agents and so on) and with airline reservation systems. He wrote parts of a system for monitoring the sales activity of travel agents, called Telstar, which derived data from a number of sources including Air New Zealand’s reservation system (‘CARINA’) and Sabre (a global distribution system). It retained four years’ worth of financial information relating to 45,000 agents, and was a substantial system. He also devised a system for divergent itineraries which involved writing a relational database and the supporting code. Divergent itineraries arise when a single booking relates to different passengers with different destinations. eRes also supports them, although OpenRes does not, requiring instead the booking to be divided up.

In 1995, Mr Vandertol set up as a consultant under the name BulletProof

In about 1997, Mr Vandertol was approached by April Marenda, the CEO of a company called CIT Tours, who commissioned BulletProof to develop a reservations

Mr Carr QC was anxious to demonstrate two things. One was that at this point, Mr Vandertol had no experience of ticketless booking systems. This was true. A ticketless system depends upon giving a reference number for a particular booking to the customer, and that booking being capable of being called up at the airport of departure and every airport along the itinerary from a central database. It is thus (and was at the outset) suitable for airlines with limited numbers of airports served and becomes suitable for large airlines only as reservation systems can be designed to be centralised, so that data is available in real time across the globe. To globalise access to a central database makes two other things possible: check-in systems can (and must, as there is no ticket with any passenger information) be integrated with the reservation system: and revenue information, and in particular how much each passenger has paid for a ticket, is available in real time to the airline. There is no doubt that ticketless systems are very advantageous when they can be used, but it was not clear to me how precisely the fact that the system was ticketless affected the data to be stored except in two respects, one general and one particular. The general matter is that it is possible to eliminate anything to support the production of printed tickets. The particular matter is that the pricing system can be moved from a per-route to a per-flight system, since the centralisation of the booking system enables all bookings on a particular flight to be priced in real time. Certainly, Mr Vandertol had no experience of booking systems for low-cost airlines before he undertook the development of eRes.

The second matter was that Mr Vandertol had no experience of writing code for large systems. This is not entirely right, since the Countrywide Loans system was on any view a large system but there were three hundred other programmers. In any event, to a certain extent the code is independent of the size of the system, but obviously it has to be robust enough to permit the database to become very large and still operate efficiently. But the main thrust of the point is correct. In a way, what I have to decide is how Mr Vandertol and the other programmers came up with a system that is so different internally from OpenRes and accepted to be so.

No doubt after the failure of DestinationPoint Mr Vandertol was anxious to find work. He telephoned Mr Webster in December 1998, and emailed BulletProof’s business plan to Mr Webster on 18 December 1998. There is no record of any further contact until Mr Webster emailed Mr Vandertol on 12 April 1999 asking him to get in touch. Mr Webster asked Mr Vandertol if BulletProof could develop a reservation system using Microsoft SQL server that would be able to handle large transaction volumes. Mr Vandertol said that the only way to find out was to build a prototype, and easyJet accordingly commissioned BulletProof to construct a prototype. The prototype became known as the ‘Proof of Concept”.

Mr Vandertol visited easyJet on or about 22 June 1999 to discuss the proposal. At a board meeting of easyJet in July, it was agreed to go ahead with the proposal to fund a prototype. Mr Webster felt some misgivings since he knew that IBM had tried to write a reservation system and failed, but it is clear that easyJet wanted a system over which it had control.

Before 19 July 1999, Mr Vandertol wrote a first draft requirements specification for the prototype entitled ‘easyJet EasyRes System: Usage Scenario Document’ (‘the Scenario Document’) which was discussed with Mr Just on the telephone on the 19 July. The agenda for the meeting was set out in the email (it is forwarded, as Mr Vandertol wrongly wrote out Mr Just’s email address on the first occasion):

The Inventory Record Maintenance screen is important. The INVENTORY dataset is one of those alleged to have been copied. It is instructive to compare this screen with the schema.

In addition to the foregoing fields in the schema, there are six Cabin Fares items reported in the screen display, each of which is present in the schema in the form of three arrays of six members, CABIN-CAPACITY, CABIN-LID and CABIN-SOLD. The maintenance screen, which must be used by the airline every time it specifies a flight on which seats are to be sold (i.e. the inventory to be sold) thus sets out all the variables that the system uses to describe it.

Important too is the Fare Maintenance and Pricing screen. I will not set out another table comparing them, but this screen sets out substantially the whole contents of the FARE-CLASS-M dataset.

On 19 July 1999 also, a login was created for Mr Vandertol to enable him to access the user interface of OpenRes directly. There is no satisfactory evidence of this logon having been used, and it seems as though there was little or no direct access of the OpenRes system from BulletProof until February 2000, when a Citrix logon (or at least a logon permitting BulletProof to examine the contents of the database directly) was created and was used by Mr Vandertol to some extent (not as much as 10 times or 20 times) between February and April 2000. (I think that use of this logon is probably responsible for the unused Fares.tbl and FareClass.tbl in the Tables folder of the Proof of Concept source code: paragraph 202 below.)

The second draft of the Scenario Document (version 1.1) was emailed to easyJet on 22 July for a conference call to take place on the same day. Along with the screens are a series of questions about the use of the data to which they refer. In version 1.1 of the Scenario Document, a table rather like the one I have set out above is set out immediately after the Inventory Record Maintenance screen shot. Against each data item in the screen display are two columns, headed respectively ‘Used’ and

I should observe at this point that BulletProof are here investigating the OpenRes system in precisely the manner described by Dr Hunt and by Dr Chiu, to which I have referred above. They are plainly engaged in finding out what data exists about the business and system used by their client.

The next version of the Scenario Document is the result of a further conference call on 29 July 1999. Version 1.2 is called ‘Requirements Fare Pricing’. It is described as ‘Version 1.2 amended by J. Vandertol included comments from John and Clive referenced conference call on Thursday July 29 @ 8 am local time’. It now only has four screen shots. The tables following the Inventory Record Maintenance screen and the Fare Basis Code Maintenance screen have been shortened, the former to some only of the data items (including those described as ‘required’) in the previous draft (paragraph 194 above). It is preceded by the words ‘From the table above the following data points are required.’ The table below the Fare Basis Maintenance screen-shot describes only six fields. A discussion of association of the fare value with the flight in the existing system follows, and is described as working satisfactorily but as requiring some changes. The decision is taken to move tax rules out of the fare basis area. This is a design decision which appears to have been followed in eRes.

The document concludes with the ‘Transaction Requirements’. These specify the number of transactions of various types that the system must be capable of supporting. The Internet and Call Centre requirements are specified separately.

After two minor revisions, version 2.0 of the Scenario Document (again renamed, this time to ‘Prototype Requirements Document’ was produced by Mr Vandertol on 1 September and version 2.1 on 28 September. This now includes screenshots of easyBook (that is, easyJet’s version of the TakeFlight website). Version 2.5, the final version, describes the transaction requirements in some detail, and describes the skeletal website that will be used to test database throughput.

From about September onwards, the database for the Proof of Concept was being designed. Entity-relationship diagrams for this database exist: EZjetFare.er1 was checked into Source Safe on 5 October. On 13 October 1999, Mr Vandertol emailed a third draft of his schema. Navitaire put a great deal of weight on the contents of this email, which I should quote:

In the schema annexed to the email the CabinFare table is obviously closely related to OpenRes’s FARE-CLASS-M, the maintenance screen for which was so extensively discussed in the Scenario Document. It seems as though it has had fields added to it, and certain parts transferred into the FareBasis and FareType tables. It was put to Mr Vandertol that the ‘simple table’ he was talking about was the OpenRes AVAILFARES, which has 137 fields if the array fields are expanded. It is implausible that AVAIL-FARES is the table to which Mr Vandertol is referring, the more so since its essential features are concerned with fare availability (those fares that are active, to be sold and sold) and this has no echo in the CabinFare table in the Proof of Concept database. I do not accept, therefore, that Mr Vandertol had any knowledge of the AVAIL-FARES table at this stage of the development. I find that the CabinFare table had its origins in FARE-CLASS-M through the maintenance screens for the Scenario Document, and this is the table to which he is referring. In coming to this conclusion, I have taken into account Mr Vandertol’s denials: but the maintenance screen was plainly used as a source for ascertaining the necessary data.

Mr Vandertol altered the EZJetFares.er1 again and the new version was dated 15 October 1999. The role which this schema had in the development of the Proof of Concept is not entirely clear, but its version of the CabinFare table is the same as that in the Proof of Concept. The Proof of Concept database was finished by 16 December 1999, when it was made accessible to easyJet on the Internet. The interfaces were completed by early February 2000, and the whole was demonstrated in California on 8 February 2000. It was successful.

The database scripts for the Proof of Concept database (which appear to have been checked into Source Safe in April 2000) include 11 additional table scripts, two of which are SQL-server versions of the OpenRes scripts for the AVAIL-FARES and FARE-CLASS-M tables. They are called Fares.tbl and FareClass.tbl respectively.

The presence of the Fares.tbl and FareClass.tbl scripts was never satisfactorily explained. While they were checked into the same directory in Source Safe as the Proof of Concept table scripts, they are not in any way linked with any of the Proof of Concept tables, which themselves do not contain any keys referencing these two tables. This is a fact that Dr Hunt should have referred to in her reports, as she recognised. They have not been edited to conform to what appears to be BulletProof’s standard form of table, with a unique table identifier as the first field (column). Two of the columns in FareClass.tbl have names (BaseFare, ChangeFee) that are the same as those of columns in one of the actual tables (FareBasis.tbl), but subject to that no name of any column is referred to, as far as I can see, in any of the stored procedures in the Proof of Concept. Navitaire are emphatic that these tables demonstrate that the Proof of Concept was developed from OpenRes. In my judgment they show no such thing. To show that such a development took place, it should be possible to demonstrate something that has been taken from these two tables and finds its way into the Proof of Concept, but it is not possible. The defendants are right when they say that these tables played no part in the Proof of Concept system. However, I am quite satisfied that the tables represent the result of having had either direct access to OpenRes before the date in April 2000 when they were checked in to source safe, probably by the use of Adager or a similar tool, or access to the database over an ODBC link. Whether that access took place before October 1999, when the structure of the CabinFare table for the Proof of Concept was substantially finished is quite uncertain.

A great deal was made of these tables by Navitaire. I think that much of the forensic excitement at the time was generated by the fact that it had not been observed that the scripts were just present in the Tables directory in the Proof of Concept in the Visual

This is full of misapprehensions. There are compelling reasons for supposing that they were never linked to the tables in the Proof of Concept database: I have given the principal reasons above. Next, to check in a table script in a particular directory merely means that it was checked in: it says nothing about where it was or how old it was when it was checked in. Reference has to be made to the scripts for building the whole system to see if they refer to these tables, and they don’t. Mr Nuttall tended to check things in in bursts, and, as Mr Vandertol put it, they may just have been lying around. I have no difficulty in accepting this explanation.

The Proof of Concept system had certain of the principal architectural features of eRes. The database management system was, obviously SQL Server. The API was defined in the same way as it is in eRes, by the use of XML messaging. The tables, as I have indicated, were defined in the house style, and the supporting software in the VT100 software was written in Visual Basic.

The Flight table in the proof of concept database is plainly directly related to its predecessor in EZJetFare and in version 2.5 of the Scenario Document. Indeed, apart from KiloDistance, which does not have any correspondence with any data item in

The next event is the contract for eRes and the development of eRes, and it is convenient to assess what BulletProof in general and Mr Vandertol in particular knew of OpenRes. Dr Hunt, who was quite conscious of the fact that the contents of the FARE-CLASS-M dataset was available through the maintenance screen, said this in paragraph 14.32 of her September report:

This statement cannot be supported. It is absolutely correct that Mr Vandertol was well aware of what was in the maintenance screens that I have discussed. They contain the column names of two datasets in the database, not its structure. If it is appreciated that each maintenance screen is concerned with one dataset in the database, there is no doubt that the maintenance screens give a good idea of the contents of the individual datasets and to that extent some clue as to the structure of the database but there is no information whatever about the interrelationships or links between the tables. Dr Hunt accepted in cross-examination

In fact, it is part of Navitaire’s case that BulletProof did indeed have access electronically to the OpenRes tables, and, as she accepted, it is possible to ‘automatically do it’. Dr Chiu’s criticism, that she tended to underestimate the similarities between DestinationPoint and eRes, but exaggerate those between OpenRes and eRes, is justified. As she said, if you apply the same rules, the result will be different. So the real process of comparison that she undertook is completely unexplained in her report, even though the results are contained in similar tables with red, green and orange highlighting to represent no copying, some copying and a copy. In general, Dr Hunt’s reports are excessively conclusory, and while much of the purely factual material which is presented is accurate, there are omissions (Footnote: ²²) and a great deal of the underlying material is not explained to the reader. Her conclusions are not necessarily reliable, and I have found my labour greatly increased by the need constantly to refer to widely disparate sources in consequence.

Negotiations appear to have begun in February 2000, at about the time that Mr Webster and Mr Just visited BulletProof to see the Proof of Concept system. Clearly,

The matter was discussed by the board of easyJet at their June 2000 meeting. A minute records that the investigation of the feasibility of a replacement system running under Windows NT was well under way, and that the first prototype completed in January proved that the software/hardware platforms selected would exceed the specified demand, which was stated to be thirty times the largest newspaper promotion in 1999. A decision appears to have requested. Perhaps the underlying reason for the whole development is stated in this comment on the status of the OpenRes system: ‘all development is on FlightSpeed and the new internet development system Skylights (which incurs a charge for each transaction handled!)’.

The brief to BulletProof included the requirement that with minimal changes and improvements, the call-centre and check-in VT100 interfaces were to be unchanged, Schedule 1 to the Agreement provides a short specification (this is the whole of it, albeit not final):

The contract contains an indemnity from BulletProof to easyJet against copyright infringement, except in respect of claims by Hewlett-Packard in respect of the user interface. It is not necessary for my purposes further to consider the contract between BulletProof and easyJet.

There is one other matter. It was always an easyJet requirement that the relevant data in the existing system would have to be transferred to the new system. This process is called migration, and the migration of the data in this case not only gives rise to a distinct claim of infringement of copyright but is intimately tied up with the suggestion that the tables complained of in eRes are copied from the OpenRes database.

Dr Hunt expressed the view that eRes specifications were thin, and the cornerstone of Navitaire’s case is that BulletProof had unrestricted access not only to the user interface of OpenRes but also to its accessible internals in the form of the database table scripts in the form that is produced by tools such as Adager or Suprtool. BulletProof is said to have been further assisted by direct access to the database provided by direct links to it contained within a Microsoft Access database called bp.mdb. The sequence of events is as follows.

In February 2000, development of the database structure started. Not only did it not spring into existence, it took a considerable time. As I have mentioned, on 11 February 2000 easyJet created a login for BulletProof to enable the latter to access OpenRes. Shortly thereafter, this login was given supervisor privileges enabling the user to access the system maintenance functions. This logon was used regularly, and I imagine that it was used extensively for the purpose of investigating the user interface. BulletProof was also provided with copies of the OpenRes training manual, and the manual used by easyJet for training staff on making reservations. I think that it is probable also that this logon was used to investigate the database.

On 18 June 1999, John Rybka at easyJet had created a spreadsheet called OpenResStructureMaster.xls, containing information about the OpenRes database. His evidence, not successfully challenged, was that he thought he had produced it at the same time as an Access database called TableDefinitions.mdb, for the purpose of creating a data dictionary (document 210 is a data dictionary) for constructing reports. It is necessary to explain that easyJet maintained a number of systems that needed access to the database. One of the datasets (FLIGHT-FOLLOWING) is largely populated by data inserted by routines written by easyJet. Dr Hunt identified these sources:

Dr Hunt says, and Dr Chiu agrees, that whoever wrote these interfaces had a good understanding of the dataset structure of OpenRes. Each communicates directly with the database over an ODBC connection, and thus can write without any of the validation checks enforced by the Navitaire code. Dr Chiu says that another common way of utilising an ODBC connection is to use Microsoft Access, and of course TableDefinitions.mdb is an Access database.

It was suggested that OpenResStructureMaster.xls and the associated TableDefinitions.mdb were written with a view to supply to Mr Vandertol, the intention being formed at the time Mr Vandertol was first approached. There is nothing to support this suggestion, and if that had been the intention it is surprising that TableDefinitions.mdb, which holds rather more detailed data than does the spreadsheet, was lost and not sent to BulletProof.

Between 7 and 11 February 2000, a copy of OpenResStructureMaster.xls was made and sent to BulletProof, where it was checked into Source Safe on 17 February under the name Openrestables.xls. It appears to have been sent in response to a request from

Openrestables.xls was the subject of considerable evidence. Two tables in it appear to cover the same ground. The first page is a long list of the detail datasets and the automatic masters in OpenRes, with a description of what most of them contain, or a ‘?’. The second page is a shorter list going over the same ground, with the same ‘Table Description’ column, but with a further column identifying only the index fields, that is, those fields with a corresponding automatic master. As will appear, this is part of the study that needs to be done in order to work out the structure of an OpenRes database. There follows a page on which an attempt (incorrect) has been made to work out a relationship between the tables relying on the index fields alone. The final page is of some importance, since it sets out in some detail the overall operation of the database in four different operations: loading and maintaining flights and fares, selling a seat, flight and passenger following and cancellations. Against the description of the operation of selling a seat is a small table setting out two pairs of columns headed ‘Read’ and ‘Write’. The second pair of columns is headed OpenRes. Mr Rybka did not set this table out. It is on the face of it a comparison in database accesses between OpenRes and some other system, on a line by line basis. The speed of operation of a database depends in part upon the number of reads and writes made to it during a particular transaction, and so the numbers are of interest. There was no attempt at the trial to relate it to the operation either of eRes or (more surprisingly) to the Proof of Concept, which was the database intended to show superiority in throughput to OpenRes. Nor was there any attempt to show that it was accurate in respect of OpenRes. It is accordingly suspicious but mysterious.

On 18 February 2000, Mr Vandertol produced Spec2000.mdb, another Microsoft Access database with extensive information relating to the user interface and the maintenance screens of OpenRes. By March, it contained an ‘all users functional report’ which was a detailed analysis of the OpenRes user interface. It contains further queries about OpenRes. It does not contain information expressly relating to the databases, and it can be disregarded for this purpose. What it does contain are screenshots of maintenance screens, one of which (Footnote: ²⁴) Mr Carr QC showed had been used by Mr Nuttall in the design of the Agents table, which appears to have been substantially complete by 19 May 2000, if the date on ZZ/259 is reliable, since this shows substantially the whole table. The fact is that the Agents table, the purpose of which is to record the basic information in relation to Agents, has a forerunner in the DestinationPoint database as well. Thus, the idea of setting out the attributes of a particular entity (the agent) with a distinct table was clearly understood by BulletProof (indeed, it is entirely obvious), and the precise fields came from this screen, although they are very similar to DestinationPoint. There are only so many ways that one can describe a person. However Mr Nuttall got hold of it, it seems to me likely that this is how the table was generated: not from any sort of direct access to the OpenRes database but from precisely the sort of operation that Dr Hunt and Dr Chiu were agreed was normal in finding out what data a client had. I was told by Mr

Mr Nuttall joined BulletProof at the beginning of April. As I have indicated, I consider him to be a satisfactory witness. He had considerable experience writing SQL stored procedures, having started in 1991 on Sybase SQL Server, the product that became Microsoft SQL Server. He too had worked at Countrywide Home Loans. He had only once designed an entire database. Again, Navitaire were faced with the difficulty of deciding whether Mr Nuttall had no relevant skills or whether he was sufficiently skilled to write the 200-odd stored procedures present in eRes in November 2000 and design the database tables. Table design and writing stored procedures go hand in hand. They decided to suggest that Mr Nuttall had insufficient relevant experience.

Appendix 9 to Dr Hunt’s October report sets out the state of the tables of which complaint is made at various dates at which they were checked in to Source Safe. She has highlighted in red the first date on which various fields that she says are equivalent to the fields in the OpenRes table were introduced. These highlightings are incomplete and occasionally inaccurate, and most importantly do not highlight changes that Dr Hunt does not consider relate to fields in the OpenRes INVENTORY dataset. I take the example of the first table shown, Flight. Dr Hunt correctly sets out the content of the table as it was on 19 May 2000, shortly after Mr Nuttall’s arrival. The ‘Lid’ item is, in fact, the same item as ‘MaxSeats’ in the Proof of Concept table, so this column has been renamed to use a term which I was told was commonly used, but of which Mr Nuttall could be expected to be unaware. The other change is to rename LocalDepDtTm and LocalArrDtTm as LocalDepTm and LocalArrTm, and change their datatype from datetime to int. A new field ‘LocalDepDt’ (datatype datetime) is inserted, but Dr Hunt does not highlight it since she does not relate it to OpenRes. Subject to this trivial change, the table is the same as that in Proof of

Flight-following is a different matter. It is not part of the reservations system accessed by the reservations API. It is in the system for easyJet’s own purposes but it is important, since it tracks the progress of a flight. Mr Nuttall says he created it completely in April or May, and did nothing with it. The stored procedures that accessed it were written by easyJet’s own programmers in Luton, and not by Mr Nuttall, who said that he had to change the table slightly from time to time as they ‘tweaked’ those stored procedures. Navitaire say that FlightFollowing was copied directly from the corresponding OpenRes dataset, FLIGHT-FOLLOWING. In order to explain the allegation, I need to describe rather more about the sequence of events.

Mr Nuttall appears to have worked on more than one server, and bundle ZZ contains early tables and procedures that he wrote that could still be recovered from his own personal machine. Their names indicate the machines: BulletProofWKS1 is the workserver and ‘BulletProofSQL1-KKBETA2’ is a machine running a  (pre-release)

It is instructive to see how the project changed over time. Two years later, in the ejWorkspace database as of 24 May 2002, one may find copies of tables with the same names as those I have labelled (c), (d), (e), (k), (l) and (n). The Agents table I have discussed above (paragraph 223). The WrkNotes of 2000 is equivalent to WrkComments in 2002, the fields being very similar. The remaining tables are by no means the same, and the way of identifying the traveller and distinguishing the traveller from the contact has changed. But it is idle to suppose that in some way the 2000 workspace (the idea for which must have come to Mr Nuttall very early) is in some way generally a copy of the schema of OpenRes.

On 12 July 2000, another file called Openrestables.xls was sent by Mr Just to Mr Kleyman. This was a list of the fields that were being accessed by the easyJet reporting functions, compiled by Amjad Khan, a programmer who worked on easyJet’s reporting programs in Luton. The programs EZTODAY and EZREPORT are programmed by easyJet and access the database directly, as was explained by Mr Webster and Mr Just. There was a cross-examination of Mr Webster which I thought was going to support a suggestion that easyJet should not have written EZREPORT. If the suggestion were made, it would be obviously absurd. The data accessed was easyJet’s data, about flights by easyJet aircraft. easyJet wanted to know what it was: how otherwise were they to do so? The spreadsheet refers to six tables:

Then, on 13 July, an event to which Navitaire attach great significance took place. This was the supply by Mr Just to BulletProof of another MS Access database, bp.mdb. bp.mdb contains four Access tables populated with sample data. The tables are AVAIL-FARES, CITY-TABLE, CURRENCY-TABLE-2 and FLIGHT-

The evidence was that if these ODBC links were opened, the field names in the corresponding datasets in OpenRes would be displayed, even though the link was itself non-functional. I accept this, although I cannot reproduce the effect with the copy of bp.mdb supplied to me by Navitaire on a portable computer. It forms the cornerstone of Navitaire’s attack on Mr Nuttall, which I shall now endeavour to explain.

The point is the FlightFollowing table. The hypothesis advanced by Navitaire is that it was written from bp.mdb by Mr Nuttall between 13 July and 19 July, when it was saved to Source Safe. Mr Nuttall’s answers to questions about this table are relied on in support of the contention that Mr Nuttall was not to be believed.

FlightFollowing does not follow the OpenRes table in content or order. Had it done so, I might have accepted Navitaire’s contention. But I have regard to these facts:

The presence of fields whose equivalents are to be found in two OpenRes tables is most significant: how would Mr Nuttall, knowing little or nothing about the airline industry, arrive at this combination working from bp.mdb and why would he include ActDepGate or ActArrGate, which are not present in OpenRes at all? The Navitaire answer is that he must have asked Mr Vandertol, but that does not meet the case. How did Mr Vandertol know? It seems to me that the obvious answer is that Mr Nuttall did not use bp.mdb but was working either from a list provided to him, from a maintenance screen or from a report that combines fields from these two tables: and I

The next obvious possible source is Amjad Khan’s spreadsheet concerning EZREPORT and EASYTODAY, since most of the accessed fields are listed there, albeit attributed to the FLIGHT-RELEASE dataset, since it appears from the OpenRes schemas (summarised by Dr Chiu most helpfully in his comparative table at Figure 7 in appendix 3 to his third report) that there is some duplication between FLIGHTFOLLOWING and FLIGHT-RELEASE (Footnote: ²⁶) and DEPT-TIME and ARRV-TIME appear also in the INVENTORY dataset. It is instructive to compare the order of the fields in Amjad Khan’s spreadsheet and in the eRes FlightFollowing: they are rather similar, in blocks. On the other hand, there is no mention in the Amjad Khan’s spreadsheets of the FIDS-STATUS fields, to which there is an equivalent in FlightFollowing, and (in the context of the movement program) a mention of the STATUS-UPDATE fields, to which there is no equivalent in these tables, but which do find equivalents in the FlightStatus table, of which no complaint is, apparently, made.

I accept Mr Nuttall’s explanation of the origin of his FlightFollowing table: somebody gave him a list of things to go in it. I find it likely that this list came from something like Amjad Khan’s spreadsheets. It is also possible that it came from maintenance screen shots like those exhibited to Dr Hunt’s September report in paragraph 6.112 (footnote 25 to this judgment) or may even have been actual screenshots, marked up to show the fields that easyJet wanted. There is no other explanation for the combination of data items from two OpenRes datasets in a single eRes table. This is, of course, a similar process to that followed for the Agents table and is the process described by Dr Hunt and Dr Chiu. I am satisfied that Mr Nuttall did not use bp.mdb in designing his table. I should add that his observation that the contents are dictated by SITA, that is, the data feed from the service provider at the airport, is no doubt correct but is only a part of the story. It is necessary to consider the selection of data items present in eRes, and I have indicated why I think this selection was directed by easyJet.

bp.mdb was immediately sent to Mr Horbury. Mr Horbury was an independent specialist in data migration who was employed by BulletProof for six months from July 2000 to advise on the data migration problems. He had nothing to do with database design. It seems to me, largely from Mr Just’s evidence under crossexamination, that Mr Horbury managed to access the OpenRes database and to generate some extract files, by operating remotely on the system at Luton and arranging for the files to be sent to him in California. He analysed the data and then sought more: Mr Vandertol emailed Mr Just on the 27 July:

A tape of the entire database was sent in August. It forms the subject of a distinct allegation of copyright infringement, since it is alleged that it was not a backup tape.

I find that the significance of the supply of bp.mdb was in the migration of the OpenRes data to the new system. It seems that Mr Vandertol and Mr Kleyman thought that the best way to migrate the data was to analyse what was held in the existing database so that it could be precisely migrated to the new system. It is important, though, to bear in mind that Mr Horbury did talk to Mr Nuttall, albeit not much. Mr Nuttall gave these answers:

I find that Mr Nuttall’s design of the database tables was not influenced by Mr Horbury, and was not influenced by bp.mdb, which was plainly provided for the purposes of the migration. Although Navitaire criticise Mr Just’s ex post facto explanation for sending bp.mdb, it seems to me that its subsequent use gives the best indication of its purpose. The one person who plainly used it was Mr Horbury, and I entirely accept Mr Nuttall’s explanation.

Mr Nuttall said that his design for the database was fixed by June or July. This gave rise to a vast dispute, since Navitaire wished to demonstrate continued influence on Mr Nuttall’s design of database from bp.mdb and also from his discussions with Mr Horbury and Mr Wallace, the other person involved with migration. (Footnote: ²⁷) The effect of the cross examination was to show that Mr Nuttall’s recollection was not correct other than for (1) the keyserver database, (2) the flight database and (3) part of the workspace database (although the reservations database will be generally the same in structure as the workspace database). There was generally no support for check-in functions by the end of June, but they are added (to the reservations database) in June or July. None of this matters. The other tables of which complaint is made are not copied from the database schemas, with one exception. I shall consider them here.

For the purpose of this analysis, it is necessary to use Dr Hunt’s May report on similarities and Bundle F1A tab 11, which is Appendix 11 to Dr Hunt’s September report and purports to set out the Table Creation Scripts for the tables in Schedule G. This is what was used during the trial, but I must record that it does not contain the whole of the creation scripts for any of the eRes tables. These appear to be drawn from Appendix 9 of Dr Hunt’s report, which purports to set out the ‘Final Table Creation Scripts for eRes 12^th June 2002’. It contains the note that ‘I have removed Go and setuser commands from the scripts to save space.’ Unfortunately (Dr Hunt apologised quite frankly for this) the scripts also all omit the ‘constraint’ clauses that give important information relating to the structure of the database. These should be present in Appendix 11 as well as they help explain certain of the fields. To take an example only, I set out the whole of the relevant part of the script for the FlightFare table:

In this code extract, the constraints are set out (cf F1A tab 11 page 295) and named. The constraint clauses provide that the unique key of the table is FlightFareID. It is standard practice, it seems, with BulletProof, to give the primary key the name of the table followed by ID, and such a key has a defined datatype, EntityIdentifier. All entities (rows) are identified by a primary unique key, provided by the so-called Key server. FlightID is constrained to be a foreign key, defined for each row in the Flight table in the ejFlight database. This can been seen from the naming convention I have described and from the fact its datatype is ‘EntityIdentifier’. The constraint clause on FlightID means that it has to be one of the FlightID’s already defined in the Flight table: this way, the dbms enforces consistency. There may be more than one FlightFare row that refers to a particular FlightID.

The corresponding dataset in OpenRes is as follows:

There are eleven arrays of 12 items in this dataset, meaning that with the other data items it has 137 members. SQL Server does not support arrays. So the whole table would have to be translated by the copyist. The primary key (if that is the correct term) is on the date of the flight (FLIGHT-DATE). No date, as such, is a key in the eRes table.

The evidence on this was given by Ms Antry and Dr Hunt. Both were agreed that the tables occupied the same position in the overall structure of the database, by which they mean that the table associates a fare structure with each flight (i.e. the INVENTORY dataset in OpenRes and the Flight table in eRes). This is done via the multipart key FLIGHT-KEY (which itself contains data) in OpenRes and FlightID in eRes. eRes has further tables for SpecialFare and FareClassCode. From the beginning, Mr Nuttall spent a lot of time working out how the easyJet pricing system worked, as the stored procedures in Bundles ZZ and CC show, and this is reflected in the structure of his tables.

Dr Hunt expresses the view that 7 of the 9 columns in FlightFare correspond to columns in AVAIL-FARES. She does not say how in her September report, but in her October report she describes the FlightFares as a ‘normalised’ version of the OpenRes dataset.

It was put to Mr Vandertol that he had obtained the structure of AVAIL-FARES, and so of FlightFare, from Mr Horbury, the fact being recorded in an email of 24 July. But the table had been in existence since mid-May, so that possibility can be excluded. Mr Nuttall had written a complex stored procedure for availability using Flight, FlightFare and two tables called FareValue and FareTranslation by 31 May (Footnote: ²⁸). easyJet price their fares according to the number of seats already sold, and the price of a seat increases as the number sold. The prices are divided into bands, and the logical problem confronting the programmer is to provide for the correct result when the number of seats sold in a particular booking crosses a band boundary (they are all sold at the higher price) or covers an entire band. The way in which easyJet actually priced their flights had been known to Mr Vandertol since the time of the Proof of Concept. There is no basis, in my judgment, for supposing that the FlightFare table is copied from the OpenRes database.

The eRes table and the OpenRes dataset are remarkably different in appearance. I am asked to conclude that the eRes table was copied from OpenRes although all the column names are different and there is a different number of columns. Mr Sundaram, its author, did not give evidence.

The table supports a function that enables either uncommitted bookings or bookings which need to be altered to be held in a queue for attention. Dr Hunt expresses the view that the OpenRes dataset was copied ‘via the functional specification’. In other

The eRes table is very similar to the OpenRes dataset. This was produced much later in the development process. Mr Nuttall had originally designed a per-booking table history database and the nature of the table can be seen in Dr Hunt’s spreadsheet on evolution of the tables. easyJet asked instead for a simple change log and it turned out to be impossible to migrate the existing easyJet history data into Mr Nuttall’s proposed structure. He then designed two tables called ChangeLog and

There is a difference between the systems here. eRes stores all the topic and subtopic information in the database. OpenRes stores the subtopic information in files outside the database, and the subtopic dataset includes a filename, rather than a text entry. I see no reason to suppose these are copied: their essential nature is immediately apparent from spec2000.mdb.

OpenRes uses two principal keys, FLIGHT-KEY and REC-LOC. They are not pure numbers as are the primary keys in eRes, but contain data. FLIGHT-KEY is a 32character field of which the first eighteen characters identify a single flight: they are composed of date, city pair and flight number. The next 14 characters identify up to two connecting flights. FLIGHT-KEY-A is an automatic master and acts as an index

easyJet added a BookingNumber field to the Reservation table. This is the unique identifier for the reservation and is the booking number given to the customer. Every Reservation has a ReservationID provided by the Keyserver, and the BookingNumber was generated from this number by converting it to base 36 (i.e. digits 0-9 plus 26 alphabetical symbols per digit). The vowels are removed to prevent happenstance

When the existing data was migrated, the REC-LOC, which is another key in

I can cut this discussion short. The only tables which form the subject matter of a complaint of copying are the eight specified. There was an attempt to broaden this out into a general discussion of tables ‘with a medium similarity to OpenRes’—see appendix 11 to Dr Hunt’s January 2004 report. In my view, the conclusions of section 6 of the January report are clearly against any suggestion that the Contact, Comment or TravelerItinerary tables owe their existence or their position in the database to any ‘knowledge of OpenRes’. Indeed, Dr Hunt quite fairly and correctly traces their origins back to DestinationPoint, even showing that one or two of the items upon which she relies as showing similarities between OpenRes and eRes can be traced back to that system. It also demonstrates that the contents of TravelerItinerary were initially decided on before any access is alleged to the relevant dataset (SEGMENT) in OpenRes. FlightCheckin, FlightDelay and FlightStatus, as I have indicated, were

It seems to me when it took place the copying was straightforward. It was from screens, or perhaps from lists of data items like Mr Khan’s spreadsheet. There was one copy from the database itself. The allegation of copying the database structure owes its origins, I think, to what Ms Antry considered the good idea about OpenRes,

As I have already indicated, the OpenRes schemas do not provide any description of the linkage between the various datasets otherwise than inferentially. Thus, if it is known that REC-LOC is the reservation number (as it is) it will be clear that there is a linkage between tables where REC-LOC is a field. The same goes for FLIGHT-KEY and FLIGHT-SEG. These are fields upon which the relevant tables are indexed, and it is the fact that they appear in more than one table which provides the reader with a clue as to their use. But as the database is not a relational one (albeit that it is provided with an SQL interface that interface is not used in OpenRes), no more information is provided. There is a potential many-to-many relationship between datasets sharing keys. The manner in which the datasets are in fact used is a matter for the code that manipulates the data in the datasets. Dr Chiu explained this in great detail and, I thought, most compellingly. The proposition which Navitaire insisted on advancing was that the entity-relationship diagram produced by Dr Hunt reflected something express in the schemas. It did not. What it reflected was an analysis of the schemas with a knowledge of the underlying business requirements and reference to the source code which was not available to BulletProof and easyJet. Thus, Mr David Evans, who

This is an example of a relationship that can only be ascertained by looking at the code. David Evans made the point even more clearly when he said that you did not need the automatic masters. You would still have the entity-relationship diagram as Dr Hunt had drawn it, but all the linkages would be established by the applications code.

Navitaire submit that Mr Nuttall did not know how to link his tables until he had seen the OpenRes data structure (submission on facts paragraph 164). This suggestion is extravagant. He understood linkage between tables (as did Mr Vandertol): you cannot write a stored procedure without understanding linkage, and the submission overlooks the undoubted fact that it is difficult to extract the information from the OpenRes database. In my judgment, the structure of the database was not copied.

At this point, I should refer to the development of the eRes API. This was primarily the work of Brian Milliron. He was a good witness and obviously a highly competent programmer. Mr Milliron studied the OpenRes system by accessing it remotely. He also studied spec2000.mdb. His structure for the API is as follows. It is divided into a number of ‘workflows’. Each workflow represents one of the basic tasks of the system: availability, booking, check-in and so on. The user interfaces (easyJet.com or the VT100 interface module) call the appropriate workflow and pass an XML message. The message is processed, and the appropriate stored procedures to obtain or write the specified data are called using the BPTDataEngine, which contains five standard methods (DBSelect, DBInsert, DBUpdate, DBDelete and Execute) for executing the stored procedures. Mr Milliron had started on the booking and availability workflows soon after he joined, and they were checked into Source Safe in May 2000. The development of the API does not have any direct influence on the database, and, as Mr Milliron says, you can add a column to the table and have no effect on the API. But it shows substantial development going on and, more importantly, programmers with a good knowledge of the processes of the system. It seems to me to be unlikely that against this background there should have been little progress on database design beyond Proof of Concept (now six months old) by midJune 2000, as Navitaire submit.

Finally on this subject I should observe that Navitaire emphasised the opportunity presented to Mr Nuttall to benefit from a study of the OpenRes database to which he was given access during the migration process. I have looked with some care to see when BulletProof actually received a copy of a schema similar to the report relied on by Navitaire as evidence of the copyright work (Document 210). This would, of

I accept entirely that Mr Nuttall had partial access to the OpenRes database itself through bp.mdb, and as a result of his discussions with Mr Horbury, but the two databases are too distinct to be the result of an analysis of the structure of the OpenRes database and its translation into a relational form with an associated largescale alteration in field names and datatypes. Dr Chiu was of the view that such a process was more complex than designing the database from scratch using what he considered to be the usual sources, and I accept this. Moreover, many of Mr Nuttall’s tables went through many variations, and most are not said to be copies at all. The claimant is unable to detect any copying of a substantial part of the OpenRes schemas in the PersonName, Reservation, ReservationCharges, Payment, CreditAccount,

Generally speaking, however, it seems to me likely that screenshots were extensively used to identify the characterising data in the system, together with questions of the ‘What is this for?’ or ‘Is this required?’ kind. The documents show a large number of them. I shall deal with this aspect of the case after I have dealt with the migration of data, since the legal issues are in part common.

I can now return to Mr Horbury’s activities. As I have indicated, he was supplied with bp.mdb, but complained on 17 July 2000 that it needed an ODBC connection that he did not have. He also asked for TableDefinitions.mdb, but never seems to have obtained it. Instead, Mr Horbury obtained access using Citrix to easyJet in Luton, no doubt thereby being enabled to access their database access software. He was warned that he had access to the live system, and was only to do queries on indexed columns. He did some extractions, which left files on the machine in Luton which were subsequently sent to him.

It must have become clear that it was not going to be possible to extract data in this way, and in late July BulletProof engaged Ron Wallace to extract data from the tape to which I have referred (paragraph 238 above). Mr Wallace was asked to extract the

The process of migration is described in detail by Mr Horbury. A number of intermediate databases were devised for the purpose of data migration, at least one of which was a direct SQL Server implementation of some of the OpenRes datasets, that is, a database which mimicked the manual master and detail datasets in OpenRes. The first tape was unreadable, but a second sent directly by easyJet to Mr Wallace could be read, and he transferred the whole database on to his employer’s HP3000. I do not think that there was any discussion of the precise format of this tape, but it appears to have been a complete dump of the database, capable of being restored to an HP3000. It was extracted using Suprtool by easyJet. It would necessarily include all the metadata as well as the data, or it could not be restored. Mr Wallace used Adager to produce a report of all the schemas in the restored database, and on 19 August 2000 he sent it to Mr Vandertol, offering to help with its interpretation. It turned out that Mr Wallace, though a good technician, was not familiar with concepts such as entity relationship diagrams or cardinality, and I am invited to find that his intervention though no doubt well-meant was irrelevant to the task of designing the eRes database. I do not think he could have helped substantially, and I am sure he did not do so.

Mr Horbury used the schema files to identify the datasets which contained data that needed to be migrated into the new database. For the purpose of migration, he designed two intermediate databases. The first was an SQL one-to-one equivalent of OpenRes. The second, called Work Area, was a database into which data from the first, manipulated and then transferred to the eRes database. Mr Horbury initially carried out this operation on the extract files produced by Mr Wallace, but he received data extracts direct from Mr Colin Rees at easyJet in Luton and via Mr Vandertol, extracted some data from specified datasets into ‘comma delimited files’ and sent them to Mr Horbury. Mr Horbury proceeded to create so–called DTS packages to load the data from the bulk files obtained by Mr Wallace (which contained the OpenRes field names) into SQL Server. He ultimately succeeded in doing this. When he had worked out how to migrate this data into eRes tables, it was used as test data. This work provided BulletProof with the schema for an intermediate database (the Work Area) and the necessary packages to load the OpenRes data from the commadelimited files into an SQL database.

Only one technical point arises here. Since the tapes include the metadata of the OpenRes database, that metadata can be extracted from the database once it has been restored from the tape into an HP3000 machine. This was done, and the result emailed to BulletProof in August 2000.

Eventually, Mr Horbury identified a comparatively limited number of OpenRes datasets containing data that needed to be migrated, although he produced in all about 60 DTS packages. Eventually, I think it is accepted that 18 OpenRes datasets were loaded into the OpenRes SQL database, from which 14 were migrated to WorkArea and thence to eRes. They did not include any of the fixed data tables, and AVAILFARES proved impossible to migrate because Mr Horbury could not understand it: its contents were transferred manually. The migration process was slow, and Mr Rees thought it was not well advanced in September 2000.

The system was installed on new servers at Luton in December 2000 (a preproduction version had been first supplied in June). Before this happened, there had

For this purpose, it is necessary to consider sections 50B and 50D of the 1988 Act. It was contended that the tape sent to Mr Wallace was a back-up tape, but this was not shown. It may have been in back-up format, but it was not shown that it was made for back-up purposes, and it was not used for back-up purposes. So section 50A does not assist easyJet.

There are a number of problems. The first is to identify the copyright work.

So far as the OpenRes database is concerned, the ‘database copyright’ subsisting by virtue of section 3A does not, in my view, extend to the schemas or material directly entered at the Adager or Suprtool prompt which has the effect of changing the structure of the database by adding or subtracting fields, or adding or removing datasets. Such scripts, schemas and even directly entered commands seem to me to be properly viewed as computer programs, because that is what they are. The effect of

Whether or not the foregoing is a correct analysis does not seem to me to matter, since the primary obligations placed on easyJet are those of clause 4 of the agreement (paragraph 19 above) and in particular clauses 4a, 4c and 4d. Thus, to the extent that easyJet are entitled to abstract the material they sent to BulletProof, any clause restricting their right to do so is void. I repeat those clauses here for convenience:

The abstractions of data of which complaint is made took place in this jurisdiction, in Luton. I say nothing about what happened in California, since that cannot be an infringement of the UK copyright. However, the crucial event, which is the final migration, took place in this jurisidiction. easyJet should be in no better and no worse position than they would have been had BulletProof been located in Skegness rather than Pasadena, but, of course, BulletProof are not liable for acts done in California which would be infringements if done here.

The primary question is one of necessity. I construe this word so as to exclude the merely desirable or convenient, but not so as to require the merely absurd—cf. Sony Computer Entertainment v Paul Owen [2002] EMLR 34 (page 742) (Jacob J). So far as anything was extracted and supplied to BulletProof, if it was necessary for the purposes of access to or use of the database to extract the field and dataset names either alone or along with the data, then that is enough. Navitaire say it certainly was not necessary. For the purpose of migrating data, Ms Antry says that a neutral file format could be used. For this purpose, the designer of the new database designs the database, having found out what he can about the contents of the old database from legitimate sources. He then tells the user what data to extract into the new database, and provides a file format of unnamed records separated by separators, such as commas. The user extracts the data into this file without telling the designer of the new database what he is extracting. The data is then transferred from this ‘neutral’ file into the new database. There is no doubt that this method is used—indeed, it was accepted by Mr Rees that its use was possible.

It should also be noted that because easyJet did not seek Navitaire’s consent, their only escape from a finding of infringement in relation to the data migration databases is either that no substantial part was taken or that what they have done is a permitted act. It does not matter that Navitaire would have had no grounds reasonably to refuse consent.

I consider the screenshots at this point. While it is possible that to copy a screenshot cannot communicate anything about the structure of the underlying database, it may incidentally do so and did so in the present case, for example in relation to the AGENTS dataset. Thus, it is possible to allege that the schema for the dataset was indirectly copied by copying the names of the data items shown on the screen.

It seems to me that the screen shots tell the user what data was present in the system, but not how it was stored. I think the use of that data is legitimate. It is no more than telling the user what data of his is stored in the system, and he can scarcely access the contents if he does not know what is there. So the use of the screen shots is necessary to find out what data is present, and accordingly permitted by section 50D even if the result of using the screens for this purpose is the reproduction of a dataset schema, or part of it. I am reinforced in this view by the fact that Dr Hunt and Dr Chiu, with long experience in this area, and the textbook, all regarded the use of screen displays as a normal way to find out what data was stored in the system. Indeed, I think any other conclusion would be intolerable. The database would be transformed into a heap of numbers and letters to which only the owner of the copyright held the key.

These are the two tables in the Proof of Concept folder obviously derived from the OpenRes tables. They should not have been extracted by easyJet, if they were, and they should not have been supplied, if they were. Since they were manifestly never used, they are of no concern.

This identifies not only the nature of the data but where it is stored. It does so because this is data used by the external routines, and Mr Khan included the dataset name as well as the nature of the data item, which appears pretty clearly from its name. The names will have to be changed to accommodate the new database structure but he was entitled to tell BulletProof what the data items were. I do not think it was necessary to specify the names of the datasets, and so this is a breach of contract, albeit trivial. I do not think it was an infringement since a substantial part of the work was not taken. bp.mdb

It is of course acceptable for easyJet to extract their own data, and identify what it is to BulletProof. If they use Access to do it, they get Access versions of the OpenRes datasets. I think that this is just ordinary abstraction of data. To provide the ODBC links confuses matters, since they are an invitation to BulletProof to abstract data duly authorised by easyJet, but, of course, they include information about the database fields even when there is no access to the data. It is difficult to shoehorn this into the statutory provisions in an acceptable way, but I conclude that to send the ODBC links was not acceptable, and was an infringement.

There is no doubt that a neutral file format technique would have worked. Dr Chiu and Mr Rees of easyJet agreed. It would not have involved sending the tapes to BulletProof. It would still have been open to easyJet to specify further fields that they wished to see in the eRes database, once they had seen a draft of it, to hold data they wished to have or preserve. There would equally have been no objection to

Finally in this connection I should refer to a contention advanced by Ms Antry, to the effect that ‘screen scraping’ would have enabled the defendants to abstract the contents of the database. I have to say that I regard this suggestion as bizarre and unreasonable. ‘Screen scraping’ is a technique in which the output of, for example, a report is not sent to the screen but instead to a file. It would take forever. Dr Hunt was far from enthusiastic for it. In principle, it is no doubt possible, but the test for necessity in section 50D would be met were this the only alternative to what easyJet actually did.

Except in limited respects concerning the process of migrating the data to the eRes system, and the supply of certain database extracts to BulletProof, this action fails.

The code fragment that identifies the arguments to an availability command seems to be the following in the source module AVAILSCR:

I have emboldened certain passages relevant to the simple A13JUNLTNAMS enquiry. We enter the routine knowing what the operator typed is stored in a location called ans-buff, and the individual characters, counting from the left hand end, can be referred to as ans-buff(1), ans-buff(2) and so on. We know already that the first letter (ans-buff(1)) is ‘A’. We need to know whether the command is the AA, AS or AR variant, and so ans-buff(2) is checked to see: lines 067700 and 068300.

If both the second and third characters are numeric, it is likely to be a date. On the assumption that it is, the program accordingly assumes that the fourth, fifth and sixth characters are a three-character month (JUN) and a routine is called

The code fragment also shows the parsing of the contents of ans-buff to see if the optional characters ‘/’ or ‘+’ are present, and if so sets a flag for return flights on appropriate dates (lines 071900 ff.).

The code to process the availability command in eRes is found principally in the ProcessAvailability.bas source code module and in the AvailabilityObject.cls class module. It is more complex, but it is possible to see that the characters of the command (which in eRes start with the number of passengers immediately following the A, as in A0113JUNLTNAMS) are processed on assumptions as to the structure of the string of characters. In other words, the syntax of the command is implicit in the parser: an error in the syntax of the command should produce an appropriate error message from the parser.

I am satisfied that the only similarity between the two systems in this respect is in the results of the processing, and in the command lines to be processed.

I set out the ‘top level’ of the parser from the file BUILDPNR with comments to indicate what is happening.

The purpose of setting out the piece of code above is to show how the programmer approached the parsing of the command lines. It is a step-by-step approach: start with the first letter. If the first letter is ambiguous, in that other families of commands, or individual commands, also begin with that letter, advance as far along the line as is necessary unambiguously to identify what the command is, and then branch to the code that processes that family of commands. It is in the latter code, as I have discussed above and in Annexe 1 below, that the syntax of the command is implicit.

As I understand it, the parsing system in eRes works like this. The commands are divided up into single letter, two-letter, three-letter and four-letter commands. They are all placed in arrays, by code like this (from the file

The code which does this (I give a single example, the three-character command names) methodically sets them all out:

The array CCFourCharCmdArray() contains all the four-character commands, and so on.

In order to parse a command line, the method used is first to employ a longest match technique: the parser starts by trying to find a match with the four-character commands, then the three-character commands, then the two-character commands and finally the single character commands, stopping as soon as a match is found. This works because all commands (including sub-commands) differ in at least one letter. In this process, all dot commands are recognised only as dot commands, and generally all commands consisting of a prefix and a variable suffix are dealt with after the invariant part of the command is recognised. Thus, at the first stage, A and A- are recognised as distinct commands, one of one character, the other of two characters. AnA, AnS and AnR are recognised as an A command and they are differentiated at a subsequent parsing stage. First I give the relevant part of the parser: it is a succession

I next give an example of the function which does the comparison: it compares the first letter of the command string with each of the single-letter commands stored in the array: if it finds a hit, it calls the ParseCC2char routine to parse the whole command string, placing the result in a variable called strResponse.

If the command is AnA, it is recognised by all the code above as an ‘A’ command, and it is when the ParseCC1char routine is called that AnA, AnR and AnS are ultimately distinguished. If the command is ‘A’ all that ParseCC1char does is call a routine called ProcessAvailabilityCmd. This is very long and is contained in its own source code file, ProcessAvailability.bas. It is this routine that checks that the number of passengers has been entered, and then processes the rest of the command string. The A, the S and the R do appear in the code (more than once), and upon analysis they can be recognised as the so-far-unprocessed characters in the subcommands, but they are never seen as a unit with the initial ‘A’.

This is the output of a ‘.A’ command. It does not affect the booking: it provides the operator with a list of the things that are needed to complete a reservation. The example of the use of eRes that forms Dr Hunt’s walkthrough (the slideshow) demonstrates its use after (1) an availability command A (2) a G1/1 command (Footnote: ²⁹) to grab one seat on flight on line 1 of the results of the availability display command (3) an NT1 command (Footnote: ³⁰) to set the number of travellers. At this point, the operator wants to know what else to do. When ‘.A’ is typed, the things that still need to be done are displayed, with the appropriate codes. There are three parts of the display: the things that need to be done part, the segment (flight) part and the comments part. The code that formats the upper part of the ‘incomplete reservation’ screen in eRes is apparently contained in the function ProcessDisplayCmd in the module ProcessDisplay.bas. This contains all the ‘Needs…’ lines. Each is formatted to include the spaces that mean that the commands (‘N–’ and so on) appear in a neat column on the screen.

The lower part of the screen seems to be generated by the function

Again, therefore, the eRes code does not contain any sections in respect of these commands that look like the picture that appears on the screen. If one reads the code, one can see how the machine will execute it so as to produce a particular appearance. It is possible to recognise parts of the layout. Paragraphs 8.14 ff. of Dr Chiu’s report show this.

I am obliged to consider each of the displays in turn. Numbers 1–15 are supplied marked up in pink, green and yellow, at Appendix 6 to Dr Hunt’s September Report, which is in turn a photocopy of section 5.2 of her May report. The colour coding is explained in paragraph 9.5 of the September report:

There are errors in certain of the markups (see paragraph 10 of the January report) but they do not seem to me to matter all that much. Of rather greater importance is that Dr Hunt occasionally suggests that features are identical in the fixed data, when they are not.

Numbers 16–21 are GUI user input forms, and are dealt with separately. They are described in section 5.3 of the May report, marked up in Appendix 6 of the September report at pages 164.31 ff. (Footnote: ³¹). We revert (numbers 22–27) to the VT100 display. Originally dealt with by Dr Hunt as part of the ‘Business Logic’ of OpenRes and eRes, these screens are found in section 4.

It is common ground that the basic constraint on the design of a VT100 display is that the screen has 24 rows of 80 characters. So if a line is not to be wrapped, or further screen-fulls of data displayed, there must be 24 or fewer lines containing 80 or fewer characters including the displayed data. Dr Chiu described how this can be done when programming on COBOL, by using a coding sheet, but this method does not appear to have been used by the persons responsible for devising the displays.

With that introduction, I can turn to the individual displays starting with the VT100 screens.

The GUI ‘screens’ (items 16-21) are rather different. There is no difference of principle from the VT100 screens, but they are more obviously graphic works in their own right, and they have been rather more closely copied. While the screens are fairly simple, in OpenRes they represent an interface to a program (the Schedule planning program) rather different in concept from the remainder of the system. It is a client module for use by the database administrators at headquarters for changing the persistent data in the database relating to the times and dates of flights and seat prices.

I was told little about the eRes module. The evidence is that it was written in Visual Basic. Mr Wheeler gave evidence that there was much of the OpenRes module that did not relate to eRes. The general similarity of the screens is no doubt in part due to the identity in the features of appearance of User Interface components common to Microsoft products. There was evidence from Mr Salib that it was an unpopular application to work on and that it was not much used in practice, easyJet preferring to modify the relevant database tables by importing Excel spreadsheets, a facility that had been provided for them.

It is the front screen (Item 16: May report page 5.51 (OpenRes) and page 5.50 (eRes)) that contains the icons, which are individually printed out in Schedule F to the Particulars of Claim. The OpenRes screen apparently opens the way to a wide functionality not present in eRes, but, to the extent that the icons relate to functions present in eRes (I do not believe I am told what they are) they have been taken. Mr Haddock’s evidence was unchallenged:

There is a number of kinds of skill and labour here: There is the overall design, in which the structure of the various menus is worked out. No work relied on in this case, apart from the code itself, can be said even to record that effort. Then there is the appearance. This naturally is to be viewed as a graphic work, and the draftsman uses the development environment to move the various elements of the interface around on the screen until they are in a suitable position. If he wants buttons with icons, he can either use the ones supplied (the first two on the screen are standard Microsoft icons) or he draws his own. Mr Wilde in fact drew the icons. I have been supplied with the original bitmap and icon (.ico) files. Eight icons are taken from about 18 devised by Mr Wilde. I am sure that enough skill and labour went into the little icon drawings to entitle them to copyright, and they have been copied exactly by the defendants. Their general positioning on the screen in two toolbars is entirely conventional, as anyone

The eRes screen is much simpler: the toolbars with the icons are shorter, but the four buttons are in the same place. On the whole I think this is an infringement of the OpenRes copyright.

Item 17, the Build Non-Stop screen, and Item 18, Change Schedule, are very simple screens, but parts of them have been copied precisely. Such skill and labour as there is in the original screens has been taken, and there is infringement.

Dr Hunt’s May report refers to a further screen, Build Fare Class (Footnote: ³⁵), that is so different between the two systems that I cannot see how it was relied on as an indication of similarity. There is no reproduction of the OpenRes screen. This screen is not relied on for copyright infringement, but is still relied on as one of the similarities between the systems.

The remaining screens, Items 19, 20 and 21, are in the same case as items 17 and 18. The amount of skill and labour going into them as graphic works is modest, but what has been put in has, equally, been taken.

I have not really considered the source of these screens: but it seems likely that OpenRes Schedule Planning.doc, which is the Navitaire document describing the module, and which was checked into Source Safe on 17 February 2000 by Mr Kleyman is likely.

There are fourteen reports complained of out of 66 in OpenRes version 5.58. Certain of them, in Dr Hunt’s view are ‘key’. There is no challenge to copying, but the results are in no case precisely identical. Again, there is no suggestion that the underlying code is copied, and thus the result depends in part upon the correct characterisation of the work (literary or artistic) and the substantiality of what the defendants have taken. Note that we can here only be concerned with the fixed data as displayed on the screen, and the position of the variable data.

In general, the defendants’ attack on this aspect of the case is that Navitaire are not responsible for the contents of the reports. In nearly every case, it is said that the contents of the report were specified by others (WestJet, Freedom Air and easyJet itself, in a number of cases). Thus, the selection of what is specified originates with others and the effort went into the COBOL code, leaving little taken by the defendants that could amount to a substantial part of the copyright work, that is, the code.

The claimant says (relying on a passage in the cross-examination of David Evans) that to the extent that the contents of the report were specified by WestJet in the person of Don Bell, all that he did was to specify problems. The passage will not support the contention. Taking the reports in order:

The claim in respect of reports specified by easyJet was always going to be difficult to justify. While I might have expressed my views globally, I should make it clear that I have considered all the reports, and I find this claim cannot be substantiated. I am impressed by the amount of programming effort that went into the display of very simple layouts on the screen, and in manipulating the data, but the defendants manipulate the data in a different way and display in a different way. The actual layouts are trivial. What the defendants have taken cannot amount to a substantial part either of the individual modules identified above or of the code as a whole.