B e f o r e :
THE HONOURABLE MR JUSTICE PUMFREY
____________________
Between:
| |
NAVITAIRE INC
|
Claimant
|
| |
- and -
|
|
| |
EASYJET AIRLINE COMPANY BULLETPROOF TECHNOLOGIES INC
|
Defendants
|
____________________
Henry Carr QC, Mark Vanhegan and Anna Edwards-Stuart (instructed by Field Fisher Waterhouse) for the Claimants
Richard Arnold QC and Brian Nicholson (instructed by Herbert Smith) for the Defendants
Hearing dates: 4-7, 10-14, 17-21, 24-28 November 2003, 2-6, 9-13 February 2004
____________________
HTML VERSION OF JUDGMENT
____________________
Crown Copyright ©
Mr Justice Pumfrey :
Introduction
- 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. and the Open Skies Division of Hewlett Packard) as 'Navitaire' for convenience.
- 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 sub-options, 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 'non-textual 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 one-sided 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 Inc, a subsidiary of Accenture (formerly Andersen Consulting), on 10 November 2000. Delaware law permits the merger of companies with assumption of all rights and liabilities of the merged companies by the resulting entity. Open Skies was merged into PRA Solutions, and the resulting entity was renamed Navitaire Inc, the claimant in these proceedings.
- easyJet was one of the first companies to take a licence of the OpenRes system. Mr Ray Webster, the managing director of easyJet, knew Mr David Evans and Mr Neeleman, and approached Mr Neeleman with a view to obtaining a licence, which was granted. easyJet were at the time using a system called AVOPS. AVOPS was a Unix-based system running on PC-type hardware. It was written using a tool called FilePro and was provided by a small company in the United States called Sysops. AVOPS was unreliable and incapable of supporting easyJet's expansion.
The easyJet licence
- 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.
1. Grant of License. Subject to the terms and conditions set forth hereafter, Open Skies hereby grants to easyJet a non-exclusive license to use OpenRes. (Attached at Exhibit A hereto is a functional description of OpenRes). This license shall be perpetual unless terminated by Open Skies in accordance with the provisions of paragraph 12 below.
2. License fee [the licence is fully paid up within thirty days of completion of installation of OpenRes. There is no continuing payment provision]
3. Customization of Data Uploading
a. Attached as Exhibit B hereto is a letter from Farrukh Khan of Open Skies to easyJet dated October 3, 1996. This letter divides customization work that will be required by easyJet into three phases: Phase I, Phase II and Phase III. The [] license fee described in section 2 above shall cover all the Phase I and Phase II customization work described on Exhibit B. Phase III customization, as well as any other customization not described on Exhibit B shall not be covered by the license fee. The charge for such non-covered customization shall be $85 per hour (easyJet may apply the 35 hour per month credit described in section 9 below towards Phase III customization or any other customization desired by easyJet.)
b. The license fee also covers Open Skies' time incurred in uploading data from AVOPS and easyJet's phone system, provided that easyJet supplies such data in the agreed upon format.
4. Conditions of License. This license is granted subject to the following conditions:
a. Title to and ownership of OpenRes shall remain with Open Skies. (easyJet, however, shall own and retain title to all underlying easyJet data generated by OpenRes). easyJet acknowledges that OpenRes is the property of Open Skies and that easyJet's rights in and to OpenRes, or any portion thereof, may not be assigned, licensed, sub-licensed or transferred (whether by operation of law or otherwise) without the prior written consent of Open Skies, which consent shall not be unreasonably withheld. This restriction on transfer shall not apply to (a) a merger in which easyJet is the surviving entity or (b) a change in the ownership or control of easyJet.
b. Because the license being granted to easyJet is non-exclusive, Open Skies retains the right to sell or license OpenRes or any portion thereof to any other entity or individual.
c. Any OpenRes software that is supplied to easyJet in machine-readable form may be copied, in whole or in part, by easyJet only for back-up or archive purposes. No other form of copying is allowed.
d. easyJet agrees not to disclose or otherwise make available OpenRes or any portion thereof, or any related material or information, to any person or entity outside of easyJet without the prior written consent of Open Skies. The granting or withholding of such consent shall be entirely within the discretion of Open Skies; however, such consent shall not be unreasonably withheld by Open Skies. Open Skies agrees that it shall not disclose any commercially sensitive information relating to easyJet without easyJet's prior written consent.
…
13. The license granted hereunder shall terminate in the event of a default by easyJet that is not cured within thirty days after written notice.
- 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 form of TakeFlight, largely developed by a programmer called Justin Wilde. There is no dispute between the parties that TakeFlight was supplied pursuant to the obligation contained in clause 3a and Phase III of Exhibit B.
- 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.
The OpenRes system
- 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.
.png)
Figure 1: Overall view of OpenRes system
- 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 system that (1) take the commands typed at an Agent's terminal and recognise them, and format the results of those commands to be displayed on the 'green screen' (the 'terminal user interface') (2) the appearance of the graphical user interface at the database adminstrator's terminal (the 'Fares and Scheduling Interface') (3) the appearance of the screens produced at the Internet user's personal computer by the TakeFlight programs (the 'Internet user interface' or 'TakeFlight interface') and (4) the structure of the OpenRes database and the names of certain of the objects that are stored within it.
- Dr Chiu also produced a diagram of the software modules making up the OpenRes system[1]
.png)
Figure 2: software modules in OpenRes
The user interfaces
- 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. non-internet) 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 IRCLNT01. The first two make up the reservation system; the third the checkin system and the last is concerned with 'irregular operations' ('IROPs').
- 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:
i) 'the literary works comprising the title, form and nature of each of the literary codes…' represented by the user command codes set out in Schedule A and response 14 of the Further information provided by Navitaire on 22 November 2003. I shall refer to these as the 'individual command sets', as they have in common that they consist of a common prefix followed by optional suffixes and arguments. Each prefix thus identifies a set of commands. A simple example is the notepad command set. The prefix is NP: if the user types NP... at the prompt (I use the ( for carriage return) the contents of the 'notepad' are displayed on the screen. There are two other notepad commands: NP.( which clears the notepad, and NP-( which permits the operator to add to it.
ii) The 'complex commands'. Navitaire divide the 'literary codes' into the simple and the complex. They differ chiefly in that the 'complex' commands allow varying arguments. Dr Hunt described them this way:
'Complex commands are those where the user enters a mixture of command characters and data and has a number of sub-options or choices. The exact combination of command and data determines the response that the system will give. These complex commands are equivalent to the screen templates or windows that are more commonly used in business applications in that they allow the user to enter values for a number of different data elements at once. These complex commands are set out in Schedule A of the Re-Amended Particulars of Claim.'
The A command (for 'Availability') is an example (I take this from Schedule A to the Particulars of Claim):
| 12 |
A |
| 12.1 |
A[departure date][city pair] (optional +[days] .[fare class]) |
| 12.2 |
A[departure date][city pair]/ (optional +[days] .[fare class]) |
| 12.3 |
A[departure date][city pair]/[return date] (optional +[days] .[fare class]) |
| 12.4 |
A[city pair] (optional +[days] .[fare class]) |
| 12.5 |
AA[days] |
| 12.6 |
AS[days] |
| 12.7 |
AA[days]/S[days] |
| 12.8 |
AR |
| 12.9 |
AR[return date] (optional +[days] .[fare class]) |
| 12.10 |
A[day of week][city pair] (optional +[days] .[fare class]) |
| 12.11 |
A[day of week][city pair]/[ return day of week] (optional +[days] .[fare class]) |
| 12.12 |
A[city pair]/[return day of week] (optional +[days] .[fare class]) |
| 12.13 |
A[city pair]/(optional +[days] .[fare class]) |
| 12.14 |
A[city pair]/[return day of week] (optional +[days] .[fare class]) |
| 12.15 |
AA[days]/A[days] |
| 12.16 |
AS[days]/A[days] |
| 12.17 |
AS[days]/S[days] |
The command character is 'A'. Dr Hunt's explanation is somewhat obscure. All it means is that 'A' will give you different results depending on what you follow it with. If you follow it with something that is not allowed, you get an error, or should do so. Note that the square brackets denote an entry which is generally obligatory. Thus, if the operator types 'A' followed by a date and a city pair, available flights satisfying those criteria will be displayed on the screen. For example, in OpenRes, the command A13JUNLTNAMS(, where the flight date is 13 June, the originating airport is Luton (LTN) and the destination airport Amsterdam (AMS) should produce a screen displaying the available flights on that day:
1 EZ 13JUN Fr 9 103 LTNAMS 1445 /1605 0 L#0035:9 W#0120:9
2 EZ 13JUN Fr 9 204 LTNAMS 1735 /1900 0 L#0035:9 W#0120:9
The ':9' is the number of seats available: if more than nine are available, only the digit 9 is displayed.
iii) All the OpenRes user command codes, considered as a 'compilation'. As I understand this allegation, it is merely an alternative legal basis for supporting the complaint in fact, which is that all the eRes commands are either the same or very similar to the corresponding OpenRes commands.
iv) The layouts of particular screens of the terminal user interface. They are set out in section 5.2 of Dr Hunt's Report of 2 May 2003. An example (the reservation screen) suffices:
(a) eRes
| (3) Reservation Display |
Agent:1900 Booked:13JUN02 10:39 Modified:13JUN02 EZ Rec Locator E0789UF Received:GILL Lang:EN Curr:GBP Dist:A 01-EZ 225 Q 15JUN Sa LTNAMS 0 HK01 1355/1600 Q20.00 GBP 20.00 ->01 Fare: 20.00 Tax: 5.00 Fees: .00 Tot: 25.00 GBP Total-cost Payments Balance GBP : 25.00 25.00 0.00 ----------------------------------------------------- mod: 0.00 0.00 0.00 Names:01 01.HUNT/GILL MRS+INF Comments:01 G TERMS AND CONDITIONS EXPLAINED 0613 1036 1900
Payments: 01)VI_4000300020001000-0603 A 25.00 GBP CC020613 934172 25.00 History on file.
|
(b) OpenRes
| (3) Reservation Display |
Agency: / Ag:LL Booked:01MAY03 14:12 Modified:01MAY03 EZ Rec Locator H6C6AG Received:GILL Lang:EN Curr:GB Dist:M 01 EZ 103 L 15JUN Su LTNAMS 0 HK01 1445/1605 L35GB 35.00 35.00 02 EZ 104 L 17JUN Tu AMSLTN 0 HK01 1410/1530 L35GB 35.00 35.00 ADT-GB 70.00 Dep 12.30 Arr .00 Tot 82.30 82.30 1 -GB 70.00 Dep 12.30 Arr 0.00 Tot 82.30 GB 82.30 Total-cost Payments Balance GB : 82.30 82.30 0.00 mod: 0.00 0.00 0.00 Names:01 Invoice/IATA#: 01.HUNT/JOHN MR Comments:01 + 00 - ANOTHER ONE 0501 1412 LL Payments: 01)VI_4938446101286528-0303 $375.00 0.00 CC000723 76490 164.60 History on file.+001
|
v) Certain reporting functions, and the corresponding screens. The term 'report' in this context means a display of useful data extracted from the database and formatted in a useful manner, either for immediate reference or for ultimate supply to other systems, such as financial systems.
vi) The Fares and Scheduling interface. This module is provided to enable the database administrator to make long-term alterations to the database, by providing a new fare structure or a new flight schedule. The screens are set out in section 5.3 of Dr Hunt's report of 2 May 2003. I show her second example: the build non-stop screen, that controls a function that constructs a schedule for a flight, and stores that schedule in the database. The first screen is the eRes screen, and the second the OpenRes screen:
eRes:
.png)
OpenRes:
.png)
The claimant says that the eRes screen contains all the material from the corresponding OpenRes screen that is appropriate for a single cabin aircraft. OpenRes contains facilities that are suitable for airlines using more than one class. easyJet is not such an airline, and the refinements have been omitted. As part of the case on copying in this area, Navitaire also rely on the undoubted fact that the detailed designs on certain of the buttons used on this GUI have been copied, and I set out a table showing them.
.png)
Where the commands are listed
- 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.
How the commands work
- 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 flights from Luton to Amsterdam on 13 June, and types 'A13JUNLTNAMS('. What then happens?
- 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:
'Q. Nowhere in the code is the fact that that part of the argument at the A command is going to be a city pair is recorded. It is just what the code does. Do you understand the distinction which I am drawing? A. I think I do. There is nowhere in the code where it says a city pair in those terms. What it says is when A, treat this as a city pair.
Q. Treat what is coming as a city pair, but what it does is it inserts an appropriate code to read the next six characters, assemble them on the assumption they are a city pair. A. Yes.
Q. And then do whatever it needs to validate them as a city pair. A. Yes.'
- 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:
Q. Let us look at just identification of the leading A. How was it done? A. It would look for an A, it would fall to a case logic, so it is ----
Q. You would have a branch statement, or something like that, a series of cases. A. A series of cases and the first case would be A.
Q. So it would be case A, case B, case C, case D, and so on. A. That is correct.
Q. Each of them would have a branch, or whatever, underneath it. At that point, it would branch out to the appropriate sub-[process]. Let us look at the next in 12.7. You have got a date. The date was entered by the operator in a particular format. Is that right? That is to say, year, month, date. Have I got it the wrong way round? A. It was actually just the day and the month.
Q. That was the difference, in fact. It was just the day and the month. OK. We are now in the [process] appropriate for A commands. How did you parse the string corresponding to a date? Do you remember? A. I would find the bits that are like the 30 APR. I would pass them to a function and say, "Now, tell, me first of all, what year they are referring to?", and then I would make an 8 digit date out of it.
Q. How did you make the 8 digit date? A. Using a routine to figure out what the month number was and with that I would go through some logic to say OK, is this month before the month we are in today? If it is, I am assuming that is next year's date and then I would string it all together and I return, "here is a date".
Q. So if we are in November and we have got somebody saying October, we can reasonably assume it is October next year. A. Yes.
Q. So we have got the year. A. Something like that, yes.
Q. October. It is typed in by the operator as OCT. How was the how did the code recognise an OCT? As it happens, it is the only month that begins with O, but that does not matter. How was it actually done? A. All the months would have been in a string, so JAN ----
Q. Each of them consecutively? A. Consecutively. You do a positional to it and then divide by or something and get the number.
Q. You jump down. You move down frame by frame, as it were? A. Yes. There is a function find the position of where OCT is in the string and derive the number from that.
Q. Somewhere there was a fixed things with things to compare? A. Yes.
Q. We now have the date. We now have a city [pair]. The city pair is typed in again as a 6 character, IATA standard names for the two airports. A. That is correct.
Q. How did you parse the city pair, do you remember? A. I think I would grab it as a city pair.
Q. You would just grab it as a city pair? A. Yes.
Q. Without further processing? A. Without further processing.
Q. So, in fact, all you do is just drop that one straight through because you know that that is what you need and it is readable as a city pair? A. Yes.
Q. Then you have a return date. That is parsed in the same way As we have already discussed dates being parsed, and it is separated by a slash. How do you recognise the slash? A. With a positional function.'
- 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.[2] 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 286 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 292 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 'a-commands' section of code which is entered when the first letter is 'A':
[redacted]
At line 263400, the whole line is checked to see if the first 5 characters are 'ARNK/'. This is the whole of a command (amended Schedule 2 number 13.) The programmer also checks for the whole of the address prompt command 'A-' (amended Schedule 2 number 10)[3]. But he doesn't bother to check for the whole of the additional information command 'AI' (amended Schedule 2 number 11)[4], perhaps because he has remembered that at this point in the code the first letter must be A. So he just checks the second, to see if it is I. The consequence is that 'AI' is never recorded in the code as such. It is a consequence of running the code that if a command line beginning AI is processed, the 'display-additional-info' code is performed.
- The same point may be seen in the code extract in 292 in the processing of the 'F' commands. The 'F--' (amended Schedule 2 number 48)[5] 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)[6].
- 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.
Development 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:
'During the course of the last 9 years of involvement with OpenSkies I have performed both of the previously mentioned roles. I have spent extensive time on-site with our customers, during which I have worked directly with them to identify their particular business needs. Then I would turn this 'needs assessment' into a form of business processing logic (generally in collaboration with other team members) in order to formulate detailed requirements for the programming staff. This step in the process is where we would brainstorm and flesh out the details, including the logic, of each step or function required in order to meet the customer's specific business needs. The output of this process would typically result in the creation of a particular command syntax, input requirements, output formats, (either report or screen layouts), the need for a particular command sequence or not, and often specific recommendations regarding database storage and retrieval locations. The result of this process would generally be communicated orally to a particular programmer who may have been part of the brainstorming team. They would then write the computer program. Sometimes however, the results or portions of the results would be written into a more formal specification document. Often times, I would then actually perform the programming duties myself, due to my previous years of experience as a programmer.'
- 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 the copying of the user interface, in eRes also), which is that S is a synonym for A, although the reason is not explained: it too provides an availability command.
- 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.
'1. Each of the complex commands constitutes a family or collection of sub-commands based upon one main command code. All of the individual commands within the family are inter-related or interlinked in their expression, syntax and functional meaning.'
- 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 'inter-related or interlinked in their expression, syntax and functional meaning' is just another way of saying they are a family of commands, and adds nothing.
'2. Each of the commands was encoded in the same section of the source code.'
- 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 292. 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.
'3. Each complex command required skill and judgment in the choice of letters, symbols and syntax to represent the main command and the inter-related family members. Thus when devising sub-commands or making changes and additions each sub-command had to be consistent with the other family members, so that the compilation remained easy to use and memorable to the user as a family group.'
- 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[7], and so on) do not, on their own, seem to me to require much skill or labour. Ms Antry accepted that QEP[8] 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.
'4. All of the particular complex commands listed in the Re-Re-Re-Amended Schedule A were created in the manner set out above [sc by Ms Beesley, and programmed by David Evans (Reservations module), Greg McDaniel (Check-in) and Mike Padgen (IROP)] and by the authors listed in the Schedule.'
- 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.
'(5) Each of the complex commands was original in that as a family of main and sub-commands it was not copied from any pre-existing command, nor as a matter of fact was it the same to any pre-existing complex command.'
- 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.
'(6) The totality of the command codes in IROPS was objectively novel and unique as well as original'.
- 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.
'(7) The collection of all the user commands as set out in the Re-Re-Re-Re-Amended Schedule B was original, was not copied from any pre-existing group of commands and involved creative skill and labour by the authors set out in the schedule.'
- 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 points in common with pre-existing systems above. I readily accept this, but for the reasons I have given I cannot accept that there is here a 'command set'.
'(8) Skill and labour had been expended in creating each of the complex commands and in the compilation of all the commands in OpenRes.'
- 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.
THE OpenRes SYSTEM: THE DISPLAY ASPECTS OF THE USER INTERFACE
- 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 0 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.[9]
- 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. Cross-examination 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:
286. As explained above, I also assisted in the production of the screen layouts and in the layout of most of the reports listed in Amended Schedule C and Schedule E respectively to the draft Re-Amended Particulars of Claim. I sometimes drew sketches which I talked through with the programmer, and the programmer then prepared a mock-up of the screen layout. The mock-up was a screen with no interaction with the database. The programmer would then give me a mock-up of the screen, and I would comment on it. If I had further suggestions, the programmer would go away and amend the code until we were happy with the final result.
287. By way of a specific example, I refer to the .incomplete reservation" screen at page 5.4 of Dr. Hunt's Report of 2 May 2003. I designed this screen with Dave Evans when EARS was created in October 1994 when we were working on the process for booking a flight, and I subsequently worked with Greg McDaniel in early 1996 to update the screen in OpenRes to take into account the order in which the information would be collected during a call. As explained in section F above, we first discussed on a general level the facility that we wanted to introduce, and I then visualised how this would work in practice on a step by step basis. During this brainstorming process, we discussed what should appear on screen, and we often sketched out our ideas.
288. When we discussed the reservations process, I knew from my own experience that there is certain information that an agent needs to input into the system, such as the passenger's name and address. When we worked out the different types of information that needed to be input, I realised that there would be a number of different commands for these, and so thought that it would be a good idea to display on screen the commands used for bookings as an aide-mémoire for the agents. For example we first needed to input the language for the booking and the itinerary, then the name, phone, address and so on. I thought it would be helpful to list these commands in basic booking order, so when telephone agents were taught how to make a reservation, the commands would be in the relevant order. This screen could be customised for each customer. For example, if an airline wanted to have a 'comment' section at the beginning (such as a comment to advise the customer what time to check in) then the comments section could be inserted higher up the list.
289. We probably discussed whether the system should prompt the agent to input the different information. We decided against this, as I knew from my own experience that customers can impart this information at different stages, and prompts do not offer this level of flexibility. Therefore I asked Dave to set up the system so that the agents can enter these commands in any order. Displaying all the information that was required to complete a booking was a new concept. I am not aware of any other system which does this.
- 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.
THE eRes SYSTEM: OVERALL STRUCTURE
- Dr Chiu again provided a useful diagram showing the overall structure of the eRes system.
.png)
Figure 3: Overall view 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).
.png)
Figure 4: Software modules in eRes
- 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.
THE eRes SYSTEM: COMMANDS AND USER INTERFACE
- 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:
.png)
Figure 5: OpenRes availability syntax diagram
.png)
Figure 6: eRes availability syntax diagram
- 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]). 294 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 EzVT100CmdParser.cls source code module. The syntax of the commands is never expressly described: it is implicit in the techniques used by the programmer to analyse the command entered at the keyboard. The result of the parsing is always a message in XML that is sent to the Application Server. I reject the suggestion advanced by Navitaire[10] that the 'portions of the source code of eRes in which the respective commands exist' are to be found set out in Appendix 14 of Dr Hunt's second supplemental report. The commands do not 'exist' as identifiable objects in the code. Appendix 14 contains a great deal of code (some portions of which are repeated many times) that recognises the commands, but that is all.
THE eRes SYSTEM: THE DISPLAY ASPECTS OF THE USER INTERFACE
- 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 300 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 OpenRes code displayed the data in a particular layout with particular fixed data (column titles and so on) it recorded an artistic or literary work consisting of the screen layout: and because the fixed data and the layout appeared in the same place on the eRes screen, that artistic or literary work had necessarily been copied. It did not matter that the work could not be discerned from the code. The work was a design for an essentially transient object, a computer display; it was recorded in the software which, when executed, displayed it; it was therefore a copyright work, and any other similar screen copied from the first transient display infringed the copyright.
SUBSISTENCE OF COPYRIGHT AND INFRINGEMENT—THE LAW
- 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 of Computer Programs ('the Software Directive'), but must be intended to implement it, so far as UK law did not already do so; the 1997 Regulations expressly provide that they implement Council Directive No 96/9/EC of 11 March 1996 on the Legal Protection of Databases. It will be necessary to return to these Directives, because easyJet submit that they recognise and reflect a dichotomy between ideas on the one hand and the expression of ideas on the other that has not found much support in the English cases[11] thus far.
- 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[12]: 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 same. Another way of putting the same point is that it is a claim to the functional idea of the program, rather than to the expression of that idea in software.
- It is convenient to set out all the statutory provisions here.
Literary, dramatic and musical works
3.—(1) In this Part—
"literary work' means any work, other than a dramatic or musical work, which is written, spoken or sung, and accordingly includes—
(a) a table or compilation other than a database,
(b) a computer program,
(c) preparatory design material for a computer program and
(d) a database;
…
(2) Copyright does not subsist in a literary, dramatic or musical work unless and until it is recorded, in writing or otherwise; and references in this Part to the time at which such a work is made are to the time at which it is so recorded.
Databases
The acts restricted by copyright in a work
16.—(1) The owner of the copyright in a work has, in accordance with the following provisions of this chapter, the exclusive right to do the following acts in the United Kingdom—
(a) to copy the work (see section 17);
…
(e) to make an adaptation of the work or do any of the above in relation to an adaptation (see section 21);
and those acts are referred to in this part as the 'acts restricted by the copyright'.
(2) Copyright in a work is infringed by a person who without the licence of the copyright owner does, or authorises another to do, any of the acts restricted by the copyright.
(3) References in this Part to the doing of an act restricted by the copyright in a work are to the doing of it—
(a) in relation to the work as a whole or any substantial part of it, and
(b) either directly or indirectly;
and it is immaterial whether any intervening acts themselves infringe copyright.
…
Infringement of copyright by copying
17.—(1) The copying of the work is an act restricted by the copyright in every description of copyright work; and references in this Part to copying and copies shall be construed as follows.
(2) Copying in relation to a literary, dramatic, musical or artistic work means reproducing the work in any material form.
This includes storing the work in any medium by electronic means.
…
(6) Copying in relation to any description of work includes the making of copies which are transient or are incidental to some other use of the work.
…
Infringement by making adaptation or act done in relation to adaptation
21.—(1) The making of an adaptation of the work is an act restricted by the copyright in a literary, dramatic or musical work.
For this purpose an adaptation is made when it is recorded, in writing or otherwise.
(2) The doing of any of the acts specified in sections 17 to 20, or subsection (1) above, in relation to an adaptation of the work is also an act restricted by the copyright in a literary, dramatic or musical work.
For this purpose, it is immaterial whether the adaptation has been recorded, in writing or otherwise, at the time the acts is done.
(3) In this Part, 'adaptation'—
(a) in relation to a literary work, other than a computer program or a database, or in relation to a dramatic work, means—
(i) a translation of the work;
(ii) a version of a dramatic work in which it is converted into a non-dramatic work, or, as the case may be, of a non-dramatic work in which it is converted into a dramatic work;
(iii) a version of the work in which the story or action is conveyed wholly or mainly by means of pictures in a form suitable for reproduction in a book, or in a newspaper, magazine or similar periodical;
(ab) in relation to a computer program, means an arrangement or altered version of the program or a translation of it;
(ac) in relation to a database, means an arrangement or altered version of the database or a translation of it;
…
(4) In relation to a computer program a 'translation' includes a version of the program in which it is converted into or out of a computer language or code or into a different computer language or code.
(5) No inference whall be drawn from this section as to what does or does not amount to copying a work.
- A further provision has been added to the statute by reg 15 of the Copyright and Related Rights Regulations 2003:
50BA.—(1) It is not an infringement of copyright for a lawful user of a computer program to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.
(2) Where an act is permitted under this section, it is irrelevant whether or not there exists any term or condition in an agreement which purports to prohibit or restrict the act (such terms being, by virtue of section 296A, void).
- 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 WORKS RELIED ON
The complex commands
- 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:
'Now, a literary work is intended to afford either information and instruction, or pleasure, in the form of literary enjoyment. The sleeve chart before us gives no information or instruction. It does not add to the stock of human knowledge or give, and is not designed to give, any instruction by way of description or otherwise; and it certainly is not calculated to afford literary enjoyment or pleasure.'
- 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 sub-parsers 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 A13JUNLTNAMS... as requiring the display of available seats on 13 June between Luton and Amsterdam. But this 'syntax' is recorded without being stated. The reason it is recorded rather than stated is that the reader, in effect, has to turn him- or herself into a machine in order to work out what the machine will recognise when operating according to this program.
- 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 record the command names and their syntax expressly and use a program (a 'parser generator') automatically to construct a parser that recognised such commands accompanied by arguments according to such a syntax. The commands and their syntax would, in such a case, be recognisable as such in the source code for the parser generator. In such a case the copyright owner could point to a written work describing exactly how the alleged infringer's program parsed the code and the consequences would be very different. I am most reluctant to come to a conclusion that depends upon the happenstance of the manner in which the programmer decided to set about constructing his parser. In either case, the ultimate result is a computer program which recognises the input according to the prescribed rules.
- 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 'expression', and, Navitaire contends, that is not a distinction known to English law and is entirely contrary to the observations of Jacob J (as he then was) in the leading case of Ibcos Computers Limited v Barclays Mercantile Highland Finance Limited [1994] FSR 275.
- 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[13] of the Software Directive are as follows:
[13] Whereas, for the avoidance of doubt, it has to be made clear that only the expression of a computer program is protected and that ideas and principles which underlie any element of a program, including those which underlie its interfaces, are not protected by copyright under this Directive;
[14] Whereas, in accordance with this principle of copyright, to the extent that logic, algorithms and programming languages comprise ideas and principles those ideas and principles are not protected under this Directive.
[15] Whereas, in accordance with the legislation and jurisprudence of the Member States and the international copyright conventions, the expression of those ideas and principles is to be protected by copyright.
- 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, the Directive alone need be consulted: if it departs from the Directive, then the latter has been incorrectly transposed into UK law.[14] The recitals quoted are said by Laddie & al., Modern Law of Copyright and Designs, (3rd Edn) paragraph 34.19 to make it clear that 'computer languages are not included in the protection afforded to computer programs'. With this conclusion I agree, although the point cannot be said to be entirely clear and will require to be referred to the Court of Justice. In my view, the principle extends to ad hoc languages of the kind with which I am here concerned, that is, a defined user command interface. It does not matter how the 'language' of the interface is defined. It may be defined formally or it may be defined only by the code that recognises it. Either way, copyright does not subsist in it. This is of course not to suggest that the expression of a program in a particular language is not entitled to copyright. Quite the reverse. What this recital, and the associated dispositive provision of Article 1(2), appear to be intended to do, is to keep the language free for use, but not the ideas expressed in it:
Art 1(2): Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive.
- 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 compilation of commands
- 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 holes, pegs and a clamp. Various collections of forms were sold by the plaintiffs, each collection being adapted for a particular purpose, and Thomas J in the Supreme Court of Queensland held that each collection or group of forms, designed to be used with each other, was entitled to protection as a compilation of the constituent forms even though the constituent forms were not wholly literary. Neither of these cases establishes any general proposition, save that (so far as the Kalamazoo case is concerned) if the quantum of skill and labour utilised in making a compilation of business forms themselves of a common nature is more than negligible, that is sufficient for copyright to subsist, although it may be noted that the judgment proceeds upon the footing that the line of US cases originating in Baker v Selden (1879) 101 US 99 is of application in Australia.[15] Baker v Selden, in which it was held that blank account books were not the subject of copyright, has given rise to the clear distinction drawn in the US between ideas and expression, and to its refusal to permit copyright to enter the field of the purely functional. For the reasons convincingly expressed by Jacob J in Ibcos (above) Baker v Selden is of limited utility in this jurisdiction, the development of the law of copyright having diverged from that in the US.
- 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
- 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 and the shading in the places selected, and act appropriately when the mouse moves over them or they are selected. The programmer does not write this code: it is the scaffolding for his or her own window design.
- 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.
THE REPORTS
- 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.
THE 'HISTORY APPLICATION' OF OpenRes, AND COPYING IN eRes
- 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 apart) the case is exactly the same as the case for business logic (see below) since a copyright is not claimed in the two .H commands.
- 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.
THE OpenRes SYSTEM: "BUSINESS LOGIC" AND NON-TEXTUAL COPYING IN eRes
- 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.
A. I think the problem with "Business Logic" and .... Perhaps we can just take a step back to where it came from. When I discussed this case with my instructing solicitors, we had drawn the lines that surround commands and screen layouts very tightly. Commands were, in my head anyway, really quite a limited feature. They are the text of the commands and what they do, but not in a detailed sense of what they do. Similarly, the screen layout is just the screen layout and very little else. It was obvious to me that there was something that has been copied in this case which is more than that. Now, I used the term "Business Logic". It may have been an error to use the term "Business Logic" and not pin it down more tightly at that stage, but it seemed to me that there is something which is the interaction between the commands and what you get and how you get the right data out at the right time in the process which I dubbed "Business Logic". "Business logic" does not have, like a lot of computer terms, a very precise meaning. It is not something that you would call a term of art. It does tend to be used.
- 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:
i) The relationship between the commands and the screens. No doubt this is obvious, but it is worth pointing out that the screens and commands do not exist in a vacuum. They are connected by invisible chains, and I do not think that in this context they should be considered separately.
ii) The ability to carry out the operations of reservation, check-in, irregular operations and so on, with much the same commands and screens with a successful result.
iii) Making the same data about all transactions as OpenRes provides available, and in substantially the same form.
iv) At easyJet, at least, accordingly providing a 'drop-in' replacement for OpenRes.
- 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:
Many different methodologies have been defined in the IT industry to help standardise and improve the way that these tasks are done and how the information they produce is presented. In some methodologies, such as SSADM (Structured Systems Design and Analysis Methodology) the assumption is that all details of a system will be documented, as a result of interviews with relevant client staff, before programming s