C
REATIVITY IN SOFTWARE CODE
THE CJEU’S ORIGINALITY TEST ON TRIAL
Marco Caspers
Student number: 5898994 October 30, 2015
Master thesis
Information Law (Research Master) University of Amsterdam
T
ABLE OF
C
ONTENTS
1. Introduction ... 1
1.1 Background ... 1
1.2 Research design ... 4
1.2.1 Research question and hypothesis ... 4
1.2.2 Research methods ... 5
1.2.3 Social relevance ... 10
1.2.4 Structure ... 10
2. Computer programming ... 13
2.1 Introduction ... 13
2.1 Introduction to computer programs ... 13
2.1.1 Definition... 13
2.1.2 Programming languages ... 14
2.1.3 Computer generated software ... 15
2.2 Software development ... 17
2.2.1 Traditional development model ... 17
2.1.1 Dynamic development models ... 18
2.1.2 Considerations in programming... 18
3. The software market and its threats... 29
3.1 Introduction ... 29
3.2 Development of the software industry ... 29
3.3 Need for legal protection ... 32
3.3.1 Recoupment trhough marketing and threats... 32
3.4 Interim conclusion ... 37
4. Legal framework ... 40
4.1 Introduction ... 40
4.2 Computer programs in the international copyright framework ... 40
4.3 EU legal framework for copyright in software ... 43
4.3.1 Introduction ... 43
4.3.2 Objectives of the Software Directive ... 43
4.3.3 Overview of the Software directive ... 45
4.3.4 The originality requirement ... 46
4.3.5 Computer Generated programs ... 53
5. CJEU’s rulings on originality... 56
5.1 Introduction ... 56
5.2 Originality as addressed by the CJEU ... 56
5.2.1 Originality under InfoSoc ... 56
5.2.2 Originality under the Term Directive and Database Directive ... 58
5.3 Creativity in the specific subject-matters ... 59
5.4 Intermediary findings ... 61
6. Analysis: CJEU’s originality standard v. Software Directive’s objectives ... 62
6.1 Introduction ... 62
6.2.1 Harmonisation before Infopaq ... 63
6.2.2 Harmonisation after the Court rulings... 64
6.2.3 Interpretation of the AOIC criterion ... 65
6.2.4 Applying the findings to computer programs ... 70
6.3 Does the new standard suffice in the context of the Software Directive? ... 79
6.3.1 Objectives of the Software Directive ... 79
6.3.2 AOIC v. Software Directive ... 80
6.4 Solutions for investments in non-original programs ... 81
6.4.1 Protection by other areas of IP law ... 81
6.4.2 Non-legal protection ... 83
6.4.3 A Database Directive inspired sui generis regime ... 83
6.4.4 Translation right ... 85 7. Conclusion ... 87 7.1 Main findings ... 87 7.1.1 Final conclusion ... 89 7.2 Suggested solutions ... 89 Bibliography ... 91 Literature ... 91 Web sources ... 97
EU Legislative and policy documents (chronological) ... 98
Other legislative and policy documents ... 99
Treaties ... 99
policy documents ... 99
Cited case law ... 99
Court of Justice of the European Union ... 99
1. I
NTRODUCTION
1.1 B
ACKGROUNDSoftware is inextricably linked with computer hardware. It is crucial to the utilisation of the computer’s functionality. In the early days of the computer, software was developed together with the hardware and specifically written for that hardware. The hardware manufacturer sold the software with the hardware as one product. No concept of one size fits all existed for software as general purpose computers were yet to emerge. In the 1960s, the first signs of a software market that separated from the hardware market started to show. This was paralleled by a growing need for the legal protection of software. Software development is a costly endeavour, but, since “[t]here is no steel to cut or bend, no wires to attach, and no parts to be cast in plastic or rubber”,1 the making of verbatim copies thereof
is not. Piracy and misappropriation by competitors of software are therefore always lurking and therefore some legal protection seemed legitimate.2 The legislator had to find an appropriate (legal) system to protect software that finds a proper balance between protection of software and the use and further development – innovation – thereof. The choice for a legal protection system consisted of three ready available ones – i.e. copyright law, patent law and protection of trade secrets – and a yet to be developed sui generis protection for computer programs.
A global trend to protect software under copyright law emerged. Like copyright law in general, the copyright protection for computer programs was mainly a domestic affair. The European legislator, following the U.S. government,3 explicitly recognised the copyright protection of software when it issued Directive 91/250/EEC, which harmonised copyright on software in the European Union.4 It was replaced in 2009 by the almost identical Directive
2009/24, which will be referred to as the Software Directive hereafter.5 The 1991 directive was the first in a series of harmonisation acts that seeks to harmonise certain aspects of copyright law in the Member States. It obliges Member States to protect computer programs by virtue of copyright law as literary works within the meaning of the Berne Convention,6 and it grants to the author of a computer program the exclusive rights to
1 Pamela Samuelson and others, ‘A Manifesto Concerning the Legal Protection of Computer Programs’ (1994)
94 Columbia Law Review 2308, 2333.
2 Also Breyer, who was initially not in favour of copyright protection of software, acknowledged that such
protection may become necessary when an independent software market would develop: Stephen Breyer, ‘The Uneasy Case for Copyright: A Study of Copyright in Books, Photocopies, and Computer Programs’ (1970) 84 Harvard Law Review 281, 347 <http://www.jstor.org/stable/1339714> accessed 13 January 2015.
3 Pub. L. No. 96-517, 94 Stat. 3007, 3028, which added the definition of computer program to 17 U.S.C. §101 and
provided for a fair use limitation for the benefit of user of computer programs in 17 U.S.C. §107.
4 Council Directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC) [1991] OJ
L122/42.
5 Directive 2009/24/EC of the European Parliament and of the Council of 23 April 2009 on the legal protection
of computer programs [2009] OJ L111/16.
make reproductions or adaptations of the program and to authorise the distribution thereof.7
Originality is a sine qua non for copyright protection of literary works: copyright law exclusively protects original works. This is not any different in relation to computer programs as works: a computer program must be original in order for its author to enjoy copyright protection. Unfortunately, there is no universal concept of originality and, traditionally, this concept is interpreted and explained differently among states and even among categories of works. While copyright laws in common law countries generally refer to originality as originating from the author, copyright laws in civil law traditions also require some reflection of the author’s personality in the work.8 This difference is reflected within the EU: Member States on the European Continent traditionally tend to require more from a work than the UK’s requirement of “skill, labour and effort”.9 The latter is more prone to
make copyright a safety “net for any subject-matter worthy of protection or requiring substantial investments” and not protected by other fields of intellectual property law.10 This status quo has recently been put at risk by developments in EU case law interpreting the directives on copyright law. The Software Directive expresses its own notion of originality. It requires that a computer program is “original in the sense that it is the author’s own intellectual creation” – which will also be referred to as AOIC in this thesis – in order to be protected by copyright.11 The concept of author’s own intellectual creation can also be found in the Database Directive with regard to copyright protection in databases,12 and in
relation to photographic works in the Term Directive.13 On the contrary, the directive that harmonises certain aspects of copyright of works in general, the InfoSoc Directive,14
7 ibid, Article 4.
8 Paul Goldstein and P Bernt Hugenholtz, International Copyright. Principles, Law, and Practice (3rd edn, Oxford
University Press 2013) 192.
9 Eleonora Rosati, ‘Towards an EU-Wide Copyright ? (Judicial) Pride and (legislative) Prejudice’ [2013]
Intellectual Property Quarterly 47, 51.
10 Quote translated from Till Kreutzer, Das Modell Des Deutschen Urheberrechts Und Regelungsalternativen: Konzeptionelle Überlegungen Zu Werkbegriff, Zuordnung, Umfang Und Dauer Des Urheberrechts Als Reaktion Auf Den Urheberrechtlichen Funktionswandel (Nomos Verlagsgesellschaft 2008) 190: “In Ermangelung eines
ergänzenden Wettbewerbs- oder Leistungsschutzes dient das Copryright als Auffangbecken für jegliche Form schützenswerter, also "investitionsträchtiger" Immaterialgüter, die nicht anderen (gewerblichen)
Schutzrechten wie dem Patent- oder dem Designschutz unterfallen).”
11 Article 1(3) of Directive 2009/24/EC of the European Parliament and of the Council of 23 April 2009 on the
legal protection of computer programs [2009] OJ L111/16.
12 Article 3(1) of Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal
protection of databases [1996] OJ L77/20.
13 Article 6 of Council Directive 93/98/EEC of 29 October 1993 harmonizing the term of protection of copyright
and certain related rights [1993] OJ L290/9, which was replaced by Directive 2006/116/EC of the European Parliament and of the Council of 12 December 2006 on the term of protection of copyright and certain related rights [2006] OJ L372/12 and amended by Directive 2011/77/EU of the European Parliament and of the Council of 27 September 2011 amending Directive 2006/116/EC on the term of protection of copyright and certain related rights [2011] L265/1.
14 Directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the harmonisation of
remains completely silent on the topic of originality. The directives therefore suggest that copyright laws in the EU are not harmonised on the aspect of originality, at least not for works in general. The originality requirement would only be harmonised for the subject-matters falling under the scope of the three directives that are a lex specialis in relation to the InfoSoc Directive.15
The CJEU’s Infopaq decision kicked off a series of rulings by the Court that disrupted this point of view.16 The Court applies the notion of author’s own intellectual creation to works under the regime of the InfoSoc Directive, thereby transplanting the concept from the realm of computer programs, databases and photographic works, into the system of copyright protection of works in general. It suggests a common originality criterion for all kinds of works under EU law and a new standard that might replace existing originality standards in Member States’ copyright law. To a certain extent, this is what the Software Directive already did for computer programs. For example, the originality requirement in the directive, and in particular the prohibition of the involvement of other criteria in the originality assessment, was perceived to be particularly addressed at Germany. 17 This put an end to the criteria developed in the Inkasso-programm18 and Betriebssystem19 case law,
which required that computer programs show an above average degree of skills and labour in order to be protected. Thereby, the Software Directive had introduced upper limits as to the originality threshold that Member States may apply. This corresponds with the general view that the directive’s originality criterion lowered the threshold on the Continent.20
On the contrary, in its recent decisions, the CJEU seems to touch upon on the lower limits of the originality requirement. In its interpretation of the the concept of author’s own intellectual creation, creativity and freedom appear to play a decisive role in assessing a work’s originality. When one concludes that originality is a harmonised criterion for all works under copyright law, then the same criteria applies to assess the originality in computer programs. This may become problematic, especially where the Court finds that technical and functional considerations constrain creativity and freedom, since computer programming is of a highly technical nature.
15 Cf. CJEU 23 January 2014, C-355/12 (Nintendo v. PC Box), §23: “[…] that Directive 2009/24 constitutes a lex
specialis in relation to Directive 2001/29 […]”.
16 CJEU 16 July 2009, C-5/08 (Infopaq); CJEU 22 December 2010, C-393/09 (Bezpečnostní softwarová asociace);
CJEU 4 October 2011, joined cases C-403/08 & C-429/08 (Murphy); CJEU 1 December 2011, C-145/10 (Painer), CJEU 1 March 2012, C-604/10 (Football Dataco); CJEU 2 May 2012, C-406/10 (SAS Institute); CJEU 23 January 2015, C-355/12 (Nintendo).
17 Michael Lehmann, ‘Die Europäischen Richtlinie über Den Schutz von Computerprogrammen’ in Michael
Lehmann (ed), Rechtsschutz und Verwertung von Computerprogrammen (2nd edn, Verlag Dr Otto Schmidt 1993) 8.
18 German Supreme Court 9 May 1985, GRUR 1985, 1041 (Inkasso-programm), §42. 19 German Supreme Court 4 October 1990, ZUM 1991, 246 (Betriebssystem), §32.
20 Bernt Hugenholtz and others, ‘The Recasting of Copyright & Related Rights for the Knowledge Economy’
This raises several questions as to what consequences this will have on the copyright protection of computer programs in Europe.21 First, it raises some legal questions relating to the extent of harmonisation – horizontally and vertically – and the interpretation and concrete application of the originality standard. Overall, at issue is to what extent computer programs are able to pass the originality standard in order to be subject to copyright protection. Second, it raises more policy related issues. For example, is the new standard appropriate to assess the copyright eligibility of computer programs? Does it provide the desired scope of protection for software? Is the requirement of creativity as applied by the Court suitable for the nature of software programming? And, flowing from these questions, what can be regarded suitable? The answer depends on the normative framework one takes into consideration. Taking the Software Directive and the European lawmaker’s policy objectives as a normative framework, it is questionable whether the Court’s originality test is able to comply with these objectives. They appear to be highly economic in nature and particularly focus on the protection of investments in software development, while simultaneously allowing competition to decompile protected software and to create own programs that are interoperable with the protected software.22 To protect investments in
the creation of software, an originality test requiring a certain amount of labour or other forms of investment would seem appropriate, while the Court’s terminology revolves around creativity and personality. This thesis will focus on the extent to which that is problematic. Insufficient protection of software could result in (mis)appropriation by other parties, while overprotection might stifle healthy competition.
Whether copyright protection is the appropriate protection mechanism for software at all has been at discussion since the emergence of the software market. This thesis does not adopt a position in that discussion and will rather take copyright protection, and its underlying principles, as a given. This thesis seeks to find how to apply the Court’s originality standard in relation to computer programs and, in that light, whether this (new) standard meets the European legislator’s original objectives for the Software Directive.
1.2 R
ESEARCH DESIGN1.2.1 RESEARCH QUESTION AND HYPOTHESIS
The research question in this thesis is as follows:
Does the CJEU’s originality standard, as applicable to software, comply with the objectives of the Software Directive?
21 Note that Europe will be equated with European Union for the purposes of this thesis.
22 See, for example, Recitals 2, 3 15 and 16 of Directive 2009/24/EC of the European Parliament and of the
The following sub-questions support the main question and also shape the structure of the thesis:
• What is the nature of computer programming and of the decisions made in computer programming?
• How has the software market developed?
• Is the need for legal protection of software still relevant?
• What is the legal system on the EU level for copyright protection?
• What are European legislator’s policy objectives, in particular in relation to the copyright protection of software?
• To what extent has the CJEU harmonised the originality standard?
• What is the Court’s interpretation of the author’s own intellectual creation and how must this be applied in the context of software?
1.2.2 RESEARCH METHODS
From the research question and its sub-questions, it follows that the research has two main focal points:
• the objectives of the Software Directive, and • the interpretation of the originality requirement.
The latter provides the normative framework against which the CJEU’s originality concept is tested. Both components call for their own set of methods and are therefore discussed in the section below, which lays out a step-by-step description of how the research question is answered.
1.2.2.1 Objectives of the Software Directive
Establishing the objectives
The first focal point, the objectives of the Software Directive, partly consists of doctrinal legal research: the body of European legislation regarding the copyright protection of computer programs is treated as a legal system on its own, with its own purposes and objectives. The EU legislator’s objectives with the enactment of the Software Directive can be derived from several – hard law and soft law – EU sources. Evidently, the Software Directive itself is the central source, in particular its recitals. They communicate what the legislator sought to achieve when harmonising the copyright protection of computer programs and allow to establish the rationale for such protection. The soft law sources primarily consist of:
• the directive’s legislative history, in particular the initial proposal for the Software Directive, the opinions of other bodies of the EU and the amendments made by the European Parliaments;
Those documents, and in particular the proposal for the Software Directive, elaborate on the rationale behind the protection of computer programs and the protection thereof, and therefore reflect why the EU legislator sought to protect computer programs under copyright on the level of the EU.
Examining the relevance of the objectives
The directive was enacted under particular circumstances: a growing software market in which investments in software simultaneously faced the threats of (mis)appropriation by competitors (fair and unfair competition) and piracy. The Software Directive’s objectives were shaped by these developments, finding a balance between the protection of investments in the development of software and allowing for some appropriation to encourage (fair) competition. These objectives are based on market developments that existed more than twenty years ago and, therefore, the current situation needs to be taken into account to examine whether they are still relevant. This involves an empirical research. How the software market has developed to date, is partly found in market reports describing the market shares and revenues of software companies. These indicate the importance of the different types of software businesses in the entire software market. Additionally, existing empirical studies on the emergence of new software business models provide insight into the new kinds of models that have developed since the early 1990s, complemented by companies’ annual or quarterly reports and own observations of the market.
These findings are used to examine whether these business models are still prone to the threats of misappropriation by competitive parties and piracy, which justified the protection of software in the early 1990s. It could be that the certain aspects of the way software is distributed or marketed make the software (partly) immune to those threats. For example, if software is delivered as a service, the client does not have access to the executable or source code. As a result, reverse engineering of the object code or copying of the source code by competitors or software pirates is impossible or at least obstructed. Depending on the findings, it may lead to the conclusion that legal protection is either necessary or no longer needed. This thesis is aware of economic advantages, such as vendor lock-in or first-mover advantages, that may also take away the need for legal protection, despite possible misappropriation by competitors. However, in the context of originality, it is more relevant to discuss the balance between protected and unprotected elements of software, rather than the economic arguments that reject economic justifications for copyright protection if computer programs in general – regardless of the Software Directive’s objectives. After all, at the heart of this thesis is the threshold for protection that divides protected software from unprotected programs (or elements). Therefore, when software marketing and distribution models are addressed, the discussion is limited to establishing whether software is already (technically) protected in a way and thereby takes away the need for protection as an original work.
Studies on current threats of piracy, also in relation to new software business models, are examined to establish whether piracy threats are still relevant nowadays. The underlying assumption is that the existence of these threats in themselves establish the need for copyright protection. Questions as to the effectivity of (software) copyright protection – and enforcement – do not fall under the scope of this research, although they deserve a thorough examination in other research. For example, it would not be relevant for this research whether the software market has grown despite existing piracy activities. This would require a more extensive (economic) analysis.
1.2.2.2 Interpretation of originality
Interpreting originality according to the legislator and the Commission
The second focal point of this thesis, the CJEU’s interpretation of originality, involves doctrinal legal research as well as comparative research and a conceptual analysis. The originality requirement is not only found in the Software Directive, but also in the Database Directive and the Term Directive (concerning photographs). None of these directives refer to Member States’ laws in relation to originality. This thesis therefore treats originality as an autonomous and uniform concept on the EU level.23 In principle, the perspective adopted in this thesis is therefore primarily that of a “Europeanist”:24 as if there is a separate “European
legal system”.25 It may be difficult to speak of such a system in a field of law – i.e. copyright
law – that is traditionally attached to a national (legal) culture, since the boundaries of this European system are not always clear.26 Nevertheless, concepts that should be interpreted as autonomous and uniform can be studied as being part of that autonomous legal system and may on themselves be – or should be – delineated. It does not necessarily mean that the originality requirement as applied by national courts is entirely replaced, if at all, by the European concept. This depends on the flexibility of the concept. Hence, it rather means that national concepts of originality are affected by this harmonised concept, which may leave some room for national interpretations that may turn into “hybrid” concepts of originality.27
23 This thesis thereby follows the reasoning used, with reference to its earlier decisions, in para. 27 of the
CJEU’s Infopaq decision: “It should be noted as a preliminary point that the need for uniform application of Community law and the principle of equality require that where provisions of Community law make no express reference to the law of the Member States for the purpose of determining their meaning and scope, as is the case with Article 2 of Directive 2001/29, they must normally be given an autonomous and uniform
interpretation throughout the Community”.
24 Christina Eckes, ‘European Union Legal Methods – Moving Away From Integration’, European Legal Method - Towards a New European Legal Realism? (2013) 174.
25 Martijn Hesselink, ‘A European Legal Method? On European Private Law and Scientific Method’ (2009) 15
European Law Journal 20, 43; Justine Pila, ‘A Constitutionalized Doctrine of Precedent and the Marleasing Principle as Bases for a European Legal Methodology’, The Europeanization of Intellectual Property Law:
Towards a European Legal Methodology (Oxford University Press 2013) 231. 26 ibid 232.
As a result, in the context of this research, the interpretation of the originality requirement must be primarily found “within the logic and framework of the EU”.28 Hence, the main sources to study are those originating from the bodies of the European Union. First, indications for the interpretation of the requirement might be found in the Directives themselves, including their recitals. Second, their legislative history, in particular explanations in the proposals, may provide further background on what the Commission intended to cover with the originality criterion. This is also true for the third kind of sources which consists of all other policy documents in which the Commission has elaborated on the originality on several occasions, such as green papers and evaluations on the directives. These three categories of sources provide insight into the legislator’s interpretation of the originality requirement and will serve to make horizontal comparisons with the later findings on the Court’s interpretation thereof. These comparisons are used to both establish the Court’s interpretation as well as to check it against the legislator’s and the Commission’s elaborations on originality.
Examining the Court’s criteria
The final source for the autonomous ‘European’ interpretation of originality is the CJEU’s case law, which is also the primary cause for this research. The Court has ruled on originality in copyright law on seven occasions.29 It elaborated on originality in several categories of subject-matter, but the Court has never ruled on originality in computer programs within the meaning of the Software Directive. However, this thesis concludes that the Court harmonised the originality requirement for all categories of subject-matter in these decisions. Therefore, the way the Court has dealt with other subject-matter provides guidance on how to deal with software in terms of originality. It appears from these rulings that free and creative choices are key to originality in a work, which are therefore at the heart of this thesis. The Court has provided indications of where those choices might be found in relation to other subject-matters, which will be mapped and analysed.
Extrapolating a benchmark for computer programs
The CJEU’s points of references, as identified according to the method set out above, will be used in this research to synthesize a set of criteria that can be applied to computer programs. This also calls for an interpretation of creativity, which the Court itself has not clarified sufficiently. This entails a more conceptual analysis of creativity in general. Support is therefore mainly found in legal theories on creativity and originality, in particular in relation to software and technology. Furthermore, comparisons with national case law are made using both top-down and bottom-up approached. Citing national case law provides top-down insights by exemplifying the past influence of the EU directives on copyright law on the originality standard applied by national courts. Bottom-up insight are gained from national case law by illustrating how creativity is assessed on a national level and the
28 Eckes 166.
difficulties that arise when the creativity or originality threshold is increased. These insights are also compared with the findings on creativity from the literature review. From these findings, a benchmark is synthesised that is consistent with the criteria set by the CJEU. Applying the benchmark to computer programs
The established benchmark will be applied to software to examine to what extent the creation thereof involves free and creative choices. Therefore, this benchmark is compared with the findings on the nature of the choices that are made in the creation of computer programs. These findings are supported by empirical research in handbooks and scholarly literature on software programming, as well as web sources and statistics on the use of certain types of programming languages and alternative methods to create a computer program. They provide insight as to how programmers make choices, as well as to what extent decisions are dictated by external factors and to what extent programmers have a certain freedom to make decisions on subjective grounds. This research establishes whether these decisions can be qualified as creative and therefore contributing to the originality of a computer program.
Reviewing the benchmark in the light of the objectives of the directive
The final step is to compare the CJEU’s originality test, and the extent to which it is able to cover computer programs, with the objectives of the Software Directive: does the CJEU succeed to protect computer programs sufficiently to enable the directive to achieve its objectives? Since originality is dealt with as an autonomous European concept, it is assessed whether the Court’s interpretation itself is able to meet these objectives, regardless of any possible leeway for national courts to give stricter interpretations. If the Court’s
interpretation turns out not to comply with the Software Directive’s objective, then there is no leeway for the national courts to interpret the test in a way that does comply.
Conversely, if one concludes that the CJEU’s test does comply, it does not necessarily imply that the application thereof by national courts would comply as well. This will depend on the extent to which the test allows for stricter interpretations. Although this thesis will make conclusions as to the possible flexibility of the Court’s test, it does not assess the existence or the risk of gold-plating of the originality requirement by national laws or courts. The conclusion will be rather on whether the Court’s interpretation, as an autonomous concept of EU law, is able to comply with the objectives of the Software Directive.
While national courts are bound by the decisions of the CJEU,30 it may be less predictable how they apply originality, taking into account the CJEU’s decisions, in practice on a factual level.31 When EU law is considered to be a separate legal system, the transplantation of a
30 Article 288 of the Treaty on the Functioning of the European Union.
31 Cf. Christian Heinze, ‘Software Als Schutzgegenstand Des Europäischen Urheberrechts’ (2011) 2 Jipitec 97,
norm from this system into national law is prone to be reshaped by a national court to fit in the respective legal culture.32 This might also apply to the concept of originality.
1.2.3 SOCIAL RELEVANCE
The legal protection of computer programs is central to the protection of investments that are made in the development of software, and which the Software Directive seeks to protect. The concept of originality as a key aspect to copyright protection influences the extent to which computer programs fall under the exclusive rights of their authors and to which extent they are free to appropriate by any other party, whether this concerns a competitor or a software pirate. It is for that reason that the interpretation of the CJEU, which at first glance seems to have altered the originality threshold, needs to be analysed in the context of software. Its interpretation might affect or even distort the existing balance between the interests in the protection of computer programs on one side, and the
competitive appropriation and free use of (unprotected elements of) software on the other side. If it would appear that the extent of protection of software has decreased, this may have impact on the investments that are made and will be made in the development of software. On the other hand, if the extent of protection has proven to have increased by the current interpretation of originality by the CJEU (which is counter to the hypothesis),
software may be overprotected and stifle competition since elements that would otherwise have been in the public domain are protected under copyright law.
1.2.4 STRUCTURE
The general structure of this thesis can be broken down into three parts:
• a non-legal part on software, the software market and the need for protection; • a legal part on the EU legal framework and policy on originality and copyright
protection on software;
an analysis of the findings in the foregoing two parts.
1.2.4.1 Non-legal part
The non-legal part describes different aspects of computer programs. It contains a description of what software is, including a definition, and elaborates on the different categories of software that exist. This provides a background to consider the nature of computer programs and to consider the choices that are made in programming software. Insight into this process is necessary for the final analysis on the originality standard in relation to computer programs. It anticipates on the more legal question whether such choices contribute to the originality according to the Court’s interpretation. This part further provides for a description of the software market and the need for protection for different categories of software producers and distributors in order to illustrate the circumstances under which copyright policy in relation to software has developed. It is
32 Andreas Rahmatian, ‘Originality in UK Copyright Law: The Old “Skill and Labour” Doctrine under Pressure’, International Review of Intellectual Property and Competition Law (2013) 24.
especially relevant in the context of the Software Directive’s objectives, since developments in the software market might affect the need for protection and, thereby, the extent to which the directive’s objectives are complied with. For this purpose, the need for protection is also discussed in this chapter.
The non-legal part is partly descriptive and relies on several sources: legal and non-legal scholarly literature on software, the software market, and the need for protection thereof, textbooks on software programming, reports on the software market, and Internet sources containing useful background information on several aspects of software. The descriptive elements serve as a basis for the several analyses made as to how to characterise the decisions made in programming, the categorisation of software providers and the need for protection.
1.2.4.2 Legal part
As for works in general, the originality requirement is a crucial factor in copyright protection of computer programs and is therefore a main issue for the legal part to address. This part is concerned with three matters: the European legal framework for copyright protection on computer programs and in particular on the originality requirement, the history and background of this framework, and the originality requirement as interpreted by the Court. It consists of two chapters. The first considers the legal framework and its history and background, which will provide the normative framework against which the Court’s interpretation will be tested.
Prior to the examination of the European legal framework, the first chapter shortly sets out the international framework of copyright on computer protection to illustrate the international context. It then comes to the core of the legal framework for software, which consists of the Software Directive and its legal and policy history. It discusses the objectives of the directive and provides an overview of its contents. Subsequently, it examines how originality is addressed by the Commission prior to, and after, the Software Directive, and how the criterion was dealt with from the first proposal for the directive. The findings will provide insight into what the EU legislator has sought to protect with the Software Directive and what role it had in mind for the originality criterion in the directive and the other directives on copyright that followed.
The second part of the legal section examines how the CJEU has addressed the originality requirement and how it has brought this criterion into the framework of the InfoSoc Directive. Following this, it provides an overview of how the Court applied the standard in relation to the specific subject-matters.
1.2.4.3 Analysis
The foregoing findings will form the basis for the final analysis, in which the research question will be answered in four steps. First, it looks into the extent a uniform originality standard applies. Second, the substance of the applicable originality standard for computer
programs is established through an analysis of the Court rulings. This will depart from the principle of autonomous and uniform interpretation of EU law, which will be further addressed in the respective chapter. This means that only the Court’s decisions and EU law will serve as a point of reference to establish and synthesise an originality test to assess software. Legal theories on originality and national notions of originality are also discussed to support the analysis. The findings will be applied to explore the possibilities of originality in computer programs according to the findings in the chapter on software. This will be subsequently, tested against the objectives of the Software Directive. If the hypothesis is confirmed and the CJEU’s originality test does not seem to comply with the directive’s objectives, solutions are suggested that might overcome this problem and deserve further research and considerations.
2. C
OMPUTER PROGRAMMING
2.1 I
NTRODUCTIONSince this thesis discusses the copyright protection of software, and in particular the originality criterion in the creation of software, a description of software is indispensable. This chapter aims to provide an understanding of software, its functioning, and the nature of programmers’ considerations. It therefore describes what software is and does and looks into the considerations a programmer has to make when writing software: what kind of choices does the programmer face?
2.1 I
NTRODUCTION TO COMPUTER PROGRAMS2.1.1 DEFINITION
There is no consistent definition for computer programs and the use of the term is often alternated with the use of the term software. While the meaning of the terms may differ, they are often used interchangeably. The definition of a computer program as defined below will apply to both computer program and software in the context of this thesis.
In the many attempts to define ‘computer program’, most definitions end up similar to one another, if not identical. They generally have in common that they define a computer program as a ‘set of instructions’33 or ‘statements’34 that are meant to cause some results or
enable functions in computer hardware. This thesis will apply the European Commission’s definition of a computer program in its Green Paper of 1988:35
“A computer program is a set of instructions the purpose of which is to cause an information processing device, a computer, to perform its functions.”
This definition is, however, not equal to the concept of a computer program applied by the Software Directive, which defines a computer program to also include a computer program’s ‘preparatory design material’.36 Considering that this thesis will focus on the
protection of software in the EU legal framework, it is important to be aware of this difference when discussing that framework.
33 Aswin van Rooijen, The Software Interface between Copyright and Competition Law. A Legal Analysis of Interoperability in Computer Programs (Kluwer Law International 2010) 11; European Commission, Green Paper
on Copyright and the Challenge of Technology - Copyright Issues Requiring Immediate Action, COM(88)172, 7 June 1988 170.
34 17 USC §101: “[..] a set of statements or instructions […]”. 35 ibid 170.
36 Recital 7 & Article 1(1) of Directive 2009/24/EC of the European Parliament and of the Council of 23 April
2.1.2 PROGRAMMING LANGUAGES
Just as works of literature or fine art are immaterial and only become tangible once incorporated in some kind of medium, e.g. a book or canvas, computer programs are in themselvesimmaterial. They are traditionally embodied in hard-drives, CD-ROMs, Blu-ray Disks, or in random access memories when being executed on a computer. There is, however, a major difference between ordinary literary works and computer programs. A literary work has as its ultimate and sole purpose to be read by the reader. That of a computer program is to be ‘read’ by the computer in order to be executed and to let the computer perform the (un)intended tasks. However, as programs are generallycreated by human beings, they should also be readable and intelligible by human beings. A computer program can therefore be said to communicate in two ways: it communicates with the computer hardware as a primary objective, but it also communicates with programmers as a means to develop and modify the program.
As a result, a distinction is made between object code and source code. Put simply, the object code is the version of the computer program that is ‘read’ by the computer hardware, while the source code is the version that is written and readable by (expert) human beings. The source code is written in a specific programming language. As the word ‘language’ suggests, it resembles daily language to some extent: programming languages are bound by certain syntax – ‘grammar’ – rules and generally contain English words.37 The object code, also called the binary, executable or machine code, contains the instruction for the computer program. It comprises of the instructions for each specific task that the central processing unit (CPU) of a computer has to perform. For different kinds of CPU architectures, different sets of instruction are required to perform the same functions in the end. Object codes are therefore tied to a specific CPU architecture.
A program may be written directly in machine code or in a source code that has to be ‘translated’ into machine instruction later on. Programming languages in which source codes are written are generally classified according to their level of abstraction. They range from very low-level languages to very high-level languages. Machine languages, i.e. binary code, are the lowest possible, as they directly instruct the computer hardware without any level of abstraction. Programs written assembly languages are the closest to binary code, since their statements directly relate to CPU instructions. Like binary code, they are specific to a certain CPU architecture.38 They do not really abstract from the machine code, but
rather have a direct, one-to-one, relationship with the machine language. All higher-level languages are abstracted from the machine and assembly language. They are more concerned with the functions of the program itself, rather than the manner in which those
37 Rooijen 12.
38 Xuejun Liang, Loretta A Moore and Jacqueline Jackson, ‘Programming at Different Levels : A Teaching
Module for Undergraduate Computer Architecture Course’, Proceedings of the International Conference on
Frontiers in Education: Computer Science and Computer Engineering (FECS). (2014) 1
functions are achieved through the program’s execution on the hardware. Expressions in those higher languages are generally independent from any CPU architecture.
Among the most popular general purpose programming languages are C, C++, Java and Python, while JavaScript and Ruby prove to be popular for web developers.39 When classifying these languages on a gradual scale, C would rank below C++, which is on its turn lower than Java, and so on.40 Even higher may be considered those computer programs that are expressed graphically, in contrast to the textual languages mentioned before. Some visual languages, such as Visual Basic, allow the developer to program a GUI graphically, which saves considerable time compared to the use of a textual language for that purpose.41 Visual languages also enable to create the computer program by making graphical representations of algorithms or data flows.
Higher textual and visual languages need to be translated into machine instructions – the binary code – in order to be executable. Such translations are carried out by a compiler, i.e. a computer program that converts higher languages into lower ones. Especially in the case of a code translated into machine code, a lot of original data, such as names of variables or objects, get lost in the process of optimising the program for a certain hardware;42 they are
relevant for the programmers to understand the code, but not for the CPU instructions. Assembly languages are converted into machine code by an assembler. This can be considered a translation rather than a conversion since the source code already concerns the machine instructions. The reverse process, decompiling, exists of converting a lower language into a higher one. Since information gets lost in the compilation of a program, compiling source code into binary code and decompiling it back into source code, either in the original or another language, will not produce the original source code.
2.1.3 COMPUTER GENERATED SOFTWARE
Computer generated software (CGS) is not an official term to categorise certain types of software. In the context of this thesis, it is used to refer to software which is produced by other software. One kind of CGS was already described above: the compilation of source code into machine code. A computer generated code does not come out of thin air, but is the result of what the program generating the code (hereafter: generator) is commanded to do. These commands can be found both within the generator, as programmed by its creator, and in the input provided by the user of that generator. For example, when a source
39 Tegawendé F Bissyande and others, ‘Popularity, Interoperability, and Impact of Programming Languages in
100,000 Open Source Projects’, 37th Annual International Computer Software and Applications Conference
(COMPSAC) (2013) 307 <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6649842>; ‘TIOBE
Index for October 2015’ <http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html> accessed 28 October 2015.
40 Daniel Spiewak, ‘Defining High, Mid and Low-Level Languages’ (Code Commit, 2008)
<http://www.codecommit.com/blog/java/defining-high-mid-and-low-level-languages> accessed 28 October 2015.
41 C V. Ramamoorthy and Wei-Tek Tsai, ‘Advances in Software Engineering’ (1996) 29 Computer 47, 54–56. 42 Ed Felten, ‘Source Code and Object Code’ (2002)
code written in C is compiled into binary code, the latter is the result of user’s input – the program in C – and the way the compiler interprets and converts the program into binary code.
Graphical methods to create a computer program emerged in the 1980s as an aspect of computer aided software engineering (CASE). CASE entails software tools that seek to simplify computer programming in every stage of software development, including the debugging and testing phase. 43 Some of these tools provide for a graphical programming environment allowing to visually ‘write’ a computer program, either by drawing visual representations of the algorithm or the data flow, or by creating a prototype of the GUI. The tools subsequently generate a code, machine code or other textual code, according to the visual ‘code’. The advantage of such tools and graphical programming in general is that they take away the time-consuming and costly activity of manually writing code and are able to prevent errors made in low language codes that might result in (security) leaks and other hardware errors.44
The lack of customisability is a disadvantage of graphical programming. Some graphical languages are translated into a proprietary language, which the programmer cannot customise at all,45 even where the programs are generated in more common languages, such as C or Java. The programmer can easily lose sight of all the dependencies within the computer program. Changing something in the code can therefore unexpectedly cause other dependent behaviour of the program as well. This limits possibilities to debug and enhance the generated code or to reuse it in other future programs. This may explain the relatively limited impact of graphical programming, and computer aided software programming in general, with regard to the development of commercial software packages.46 However, it proves to be useful for industrial or academic purposes, which is
illustrated by the successful market penetration of the LabVIEW software.47 It enables users to create programs for instruments used in industrial applications, for example, to control and process inputs from sensors and other measurement equipment for the purposes of automation. Users can establish dataflow through graphical representation, a graphical language that is called G. The result, a source code ‘written’ in G, is compiled into a machine language that fits the instruction set architecture of the CPU it is intended to instruct.
Since visual programming allows even lay persons to design and produce a computer program, the recent trend in user generated content – especially in the context of music and (short) movies – may also spread to software: several tools exist to program applications for
43 Rajiv D Banker and Robert J Kauffman, ‘Reuse and Productivity in Integrated Computer-Aided Software
Engineering: An Empirical Study’ (1991) 15 MIS Quarterly 375, 375 <http://www.jstor.org/stable/249649>.
44 Douglas C Schmidt, ‘Model-Driven Engineering’ (2006) 39 IEEE Computer 25, 25. 45 ibid.
46 ibid.
47 ‘National Instruments 2013 Annual Report’ <http://www.ni.com/nati/annual/13/letter.htm> accessed 30
smartphones and tablets in a graphical way with possibilities to export them into stand-alone executables, after which they might be published through an application store. Examples of app builders are App Inventor,48 initially developed by Google and resumed by MIT, or more commercial services such as appSpotr.49 All these programs are generally limited in their possibilities as to the functionalities and user interface of the created computer program, since they are restricted to the libraries of components available in the software tool. Dataflow, GUIs and functions can be added and arranged through a graphical interface. Whether further customisation through editing written source code depends on the ability to generate such code. Although the codes resulting from such tools may not turn out to be ground breaking, the application as a whole might be. The user of the tool may add visual, sound and – in the case of a game application – gameplay elements that add to the success of the app, but in these cases the ground breaking elements (and the added skills) are not found in the code itself.
Any program that is written in non-machine language must thus be converted to machine code and, as a consequence, involves a computer generated code. This is the case with the vast majority of computer programs, meaning that there is a large number of computer generated code on the market. While most of those are compilations of textual source code, as discussed in this section, a considerable amount also originates from graphical ‘source code’.
2.2 S
OFTWARE DEVELOPMENT2.2.1 TRADITIONAL DEVELOPMENT MODEL
Computer programs vary in size and range from a few lines in source code to millions. As a consequence, it is evident that programming can turn into a very complex activity and may involve large teams of programmers working in collaboration. Programming therefore requires a structured approach and traditionally follows the following pattern.50
First, there is an idea of what a computer program should do or what problem it should solve. For example, its purpose can be to instruct a robotic arm in assembling a car, to print a PDF document on paper or to enable a user to modify and store a digital text file. Subsequently, the idea has to be materialised in a more concrete outline of the computer program, generally involving the development of an algorithm that is visually represented in a flowchart.
Since most computer programs consist of thousands to millions of lines of code, it is evident that mistakes are virtually omnipresent. Errors in computer code are called bugs and removing bugs from a program is referred to as debugging. Different kinds of bugs can occur, some easier to detect than others. For example, bugs in the syntax of a system, such
48 ‘MIT App Inventor’ <http://appinventor.mit.edu> accessed 2 October 2015. 49 ‘appSpotr’ <http://www.appspotr.com> accessed 2 October 2015.
as forgetting to write a closing bracket or defining rather than equating a variable, are relatively easy to detect and debugging software might detect them automatically. On the contrary, logic errors may be harder to identify, as they might first appear when the software is actually run in its aimed environment.51 The syntax of the code may be correct and the program may run smoothly, but it does not provide the desired output. Testing and debugging of computer programs thus forms a crucial phase in programming and requires program that is written in an intelligible way.
If the software is considered stable, it is ready for completion. This is not the end for the software development process. New bugs may still come to light as the program is used, the customer’s needs and requirements may change over the course of time, or a security leak is found.52 Thus even after completion of the computer program, patches, i.e. software updates fixing the issues, may still have to be written.
2.1.1 DYNAMIC DEVELOPMENT MODELS
The outline of the development stages in the previous section suggests that software development always involves a static sequence of isolated phases, apparent in the waterfall model53 and the stagewise model54 for software development. In practice however, many other models of software development are drafted, describing or prescribing the process. In 1988, Boehm introduced a spiral model in which requirements analysis, software design and coding are performed in cycles and recur until the software is completed.55 A more modern approach is agile software development, a more general term, referring to a group of software development methods that has gained popularity since the late 1990s.56 As
opposed to traditional development models, documentation plays a much less important role in agile development models.57 Rather than implementing needs and requirements for documents into software, it is more focused on changing requirements for software: it is “adaptive rather than predictive”.58 This enables programmers to act in dynamic
environments in which the needs and requirements by users are constantly changing. 2.1.2 CONSIDERATIONS IN PROGRAMMING
2.1.2.1 Nature of computer programming
As is apparent from the previous section, software development entails higher and lower level considerations. Those concerned with the overall structure and organisation of the
51 ibid 35–36. 52 See also ibid 36.
53 Royce 1970; see also Ramamoorthy and Tsai 47.
54 Barry W Boehm, ‘A Spiral Model of Software Development and Enhancement’ (1988) 21 IEEE Computer 61,
63.
55 Ramamoorthy and Tsai 47;see in detail Boehm 1988.
56 Christof Ebert, ‘A Brief History of Software Technology’ (2008) 25 IEEE Software 22, 23.
57 Torgeir Dingsøyr and others, ‘A Decade of Agile Methodologies: Towards Explaining Agile Software
Development’ (2012) 85 Journal of Systems and Software 1213, 1213.
58 Frauke Paetsch, Armin Eberlein and Frank Maurer, ‘Requirements Engineering and Agile Software
Development’, WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on Enabling Technologies:
program and its functionalities and components are rather high level, while the practical implementation thereof in code may be considered to be more low level.59
Comparing computer programs to writing literature shows some major differences. While writing a novel is – most often – a highly individual task, developing a modern software package generally requires whole teams of programmer to cooperate. And while literature may in itself be the ultimate goal of the author, a computer program is primarily a means to enable a hardware system to perform the desired functions such as assembling a product or displaying a video from a digital file. It is the programmer’s purpose to create a computer program that runs without problems (virtually bug-free), is efficient in use of hardware resources, and is usable for the purposes for which it is created. The process of writing a computer program therefore appears to be a purely rational and technical activity by nature.
This may be true for embedded systems, i.e. computer hardware inside another product to achieve specific goals and thereby different from general purpose systems such as a personal computer;60 examples are chips in cars regulating fuel injection or those in mobile phones handling calls. As timing is often a crucial aspect in those systems,61 they were
usually written in assembly language for optimising the execution of the code. In those cases, it could be said that such programs are written from a purely rational and technical perspective. However, even programs for those systems have grown in average the last decades, multiplying a 100 times every decade. 62 This has increased the need to write
programs for embedded systems in higher languages, putting more weight on compilers to produce an efficient – object or assembly – code.63 This also applies to Internet-of-Things (IoT) devices (‘things’), of which the future expectations for the market of are high: Gartner has estimated that 26 billion ‘things’ will be connected to the IoT by 2020.64 These devices
may range from heart rate monitors to refrigerators or from thermostats to garage door openers. A common feature of these devices is their low hardware capacities and the need for a low energy use as they often run on batteries.65 This brings technical concerns that
require very efficient programming, either by the programmer writing in machine (or assembly) code or the compiler.
59 See also Ramamoorthy and Tsai 53.
60 Aviral Shrivastava and Nikil Dutt, ‘Compiler-Aided Design of Embedded Computers’ in YN Srikant and Priti
Shankar (eds), The Compiler Design Handbook: Optimizations and Machine Code Generation (2nd editio, CRC Press 2008) III–1.
61 Tulika Mitra and Abhik Roychoudhury, ‘Worst-Case Execution Time and Energy Analysis’ in YN Srikant and
Priti Shankar (eds), The Compiler Design Handbook: Optimizations and Machine Code Generation (2nd editio, CRC Press 2008) I–1.
62 Shrivastava and Dutt III–1. 63 ibid.
64 ‘Gartner Says the Internet of Things Installed Base Will Grow to 26 Billion Units By 2020’
<http://www.gartner.com/newsroom/id/2636073> accessed 28 October 2015.
65 Steven Fraser and others, ‘The Future of Programming Languages and Programmers (Panel)’, Companion Proceedings of the 2015 ACM SIGPLAN International Conference on Systems, Programming, Languages and Applications: Software for Humanity (2015) 64.
However, when computer programs are written in higher languages, computer programs are not only directed at machines; they are also meant to be intelligible by human beings. Not only must the programmer himself be able to read and understand his code later on in, for example, the process of debugging or another development cycle; it must also be comprehensible for other programmers., as software is often made in collaboration. A program that is burdensome to understand for another programmer is also difficult and time absorbing to debug, update or review by the latter.66 Programming is thus not only about accomplishing the end purpose of the software, but it is also about communicating to other individuals for the purpose of software development itself. This communication is facilitated by the ability to write comments in the code itself, but also by the fact that, especially higher, programming languages borrow words and syntax from everyday language.
There are many theories on what constitutes ‘good software’ and they do not only address the actual functioning of the software, but also the written code itself. Although these theories vary in terminology, they commonly recognise important aspects such as utility, functionality, performance, reliability, portability, maintainability, ‘understandability’, reusability and modifiability.67 These criteria do not only deal with the execution of the programs, but are also closely related to the fact that the software code is looked at and modified many times after it is initially written, e.g. for purposes of improvement, debugging or re-use of the software in new software packages. They thereby emphasise the human oriented communication function of computer programs.
To conclude, it is argued that software development is – like hardware engineering – merely a form of technical creativity,68 and is more akin to engineering than to the arts.69 While this may be partly true, there is also a communicative aspect in programming that is not always present in hardware engineering,70 although many other criteria on what is good software also apply in the context of hardware engineering. The communication aspect draws immediate comparison to functional texts, such as manuals or operating instructions. As software engineering has developed to a disciplined collaborative – and social71 – activity,72
66 Raoul-Gabriel Urma and Alan Mycroft, ‘Source-Code Queries with Graph Databases—with Application to
Programming Language Usage and Evolution’ (2015) 97 Science of Computer Programming 127, 128 <http://linkinghub.elsevier.com/retrieve/pii/S0167642313002943>.
67 Maryoly Ortega, María Pérez and Teresita Rojas, ‘Construction of a Systemic Quality Model for Evaluating a
Software Product’ [2003] Software Quality Journal 219, 221–222; Paetsch, Eberlein and Maurer 6; Gurudatt Kulkarni and R Sathyaraj, ‘A Survey on Graphical Programming Systems’ (2014) 3 709, 709; Ramamoorthy and Tsai 51.
68 Sean E Gordon, ‘The Very Idea! Why Copyright Law Is an Inappropriate Way to Protect Computer Programs’
(1998) 20 European Intellectual Property Review 10, 10.
69 See for example Vandenberghe 38.
70 See also Gilles Dubochet, ‘Computer Code as a Medium for Human Communication: Are Programming
Languages Improving?’, Proceedings of the 21st Working Conference on the Psychology of Programmers Interest
Group (2009) 174, 186.
71 More on the social aspect of computing, see e.g. Joy Rankin, ‘Toward a History of Social Computing:
the communication aspect in computer program must definitely be taken into account when considering choice making and originality in computer programming.
2.1.2.2 Choices in computer programming
As discussed earlier, programming involves both high level and low level considerations. On a high level, the programmer deals with the overall structure and characteristics of the program, as well as the organisation of all the single elements – i.e., inter alia, single lines of codes, grouping of objects, functions, methods, statements of variables, or comparisons. Choice of language
The programmer will start with choosing the language(s) to write the software in. The programming languages that are most suitable for a certain program depend on several technical criteria, e.g. the importance of timing, need for a GUI, fault tolerance, required reliability, technical possibilities and limitations of a computer program, and the capacity and purpose of the hardware. These factors affect whether it is more appropriate to write directly in assembly code, to write in an object-oriented language or to work with a graphical programming language or representation. However, non-technical factors may also be relevant, such as the type and amount of training, knowledge and experience of the programmer (or his colleagues), industry convention, or the time and money available for the development of the software. This choice is a very basic one and could be compared to the choice of language in which to write a novel in. However, it may indicate the nature of the considerations that will be made in the programming progress; for example, writing in object or assembly code will indicate that decisions will be generally of a technical nature, while writing source code in higher languages implies that other considerations may play a role.
Structure and organisation of program and code
To discuss the structure and organisation of a code, it is important to distinguish between machine or assembly languages and higher programming languages. When a program is written in machine or assembly language, it consists of direct instructions to the CPU. As a result, technical and functional considerations are predominant and considerations as to the human communication will be almost completely absent as this may affect the efficient execution of the code. The instructions must follow the technical and functional requirement for the program and, while multiple options may be available to implement them. There will be one optimal solution that is most efficient to execute on the machine; all other solution are suboptimal. 73
This is different when a program is written in a higher language. Programming in most higher-level programming languages involves decisions that do not directly relate to the
72 Ebert 25. 73 Kreutzer 221.
technical impact or result of the program, because it abstracts from the machine level. In these cases, it will be hard to say which solution will be technically the optimal one after compilation into object code; it is the compiler’s objective to generate the optimal machine instructions from the source code. What is regarded optimal in those cases does not only depend on any efficient execution of the computer program itself, but also on other factors which the programmer has to balance. For example, one solution may be shorter and quicker to write for a programmer, but hardly intelligible for others or even the original programmer himself when he consults his code later on; and vice versa. Other factors that might also influence the choice of the programmer are, for example, his training and education, or common practice or convention (e.g. within the field, company or team). A source code in a higher language consists of several elements, such as functions, (declarations of) variables and its values, calculations of variables and values, methods, and comparisons. All those elements in isolation are not of any value. It is the programmer that selects and organises them to create a computer program that is executable and delivers the right result on a computer. Herein, the programmer is first bound by the rules, syntax and ‘vocabulary’ of the programming language. For example, the language prescribes how to formulate a comparison, how to call certain functions and methods, how to define a variable or what sort of value – e.g. text, number or a Boolean (a binary value of true or false) – may be given to variables. In many programming languages, it is possible to put variables, data structures or functions in a module (or object), which can be called in other parts of the program or even in other software. The organisation of those objects and the contents thereof can simplify the software code and make it more comprehensible, which also saves time in future operations to modify the code or to build (new software) upon the code. The use and organisation of those software modules may be determined by factors relating to the available time and resources, to what extent certain functions, data structures or variables are necessary in other contexts, and to what extent certain functions, variables or data the programmer wants to call separately in the computer program.
So the way the programmer selects, organises and arranges the different elements in a computer program does not only affect the efficiency and functionality of the program, but also the comprehensibility thereof. It is up to the programmer to balance these factors and to decide what prevails in each specific case. There is no predetermined optimal code. The computer program is, at least in part, the end result of his personal vision: the result of subjective choices of the programmer or a team of programmers jointly working on the code.
For a very simple computer program, the structure of the code may – more or less – directly follow from the algorithm that is implemented. Take for example the program for speed indicating traffic sign, which must read the input value concerning the driving speed of a car and compare this with the maximum speed value of 50. Based on a true or false output from that comparison, it will indicate that the driving speed is either correct or too fast. The main
