The first computers were used primarily to manage information for large companies and perform numerical calculations for the military. Only a few visionaries saw computing as something for everyone or imagined it could become a basic service like the telephone or electric power. This failure of imagination was due in large part to the fact that the people who controlled computing in the early years weren't the ones actually programming computers. If you worked for a large corporation or industrial laboratory, then you might have strictly limited access to a computer, but otherwise you were pretty much out of luck.

In the early years of computing, users submitted their programs to computer operators to be run in batches. You would hand the operator a stack of cards or a roll of paper tape punched full of holes that encoded your program. An operator would schedule your program to be run (possibly in the middle of the night) with a batch of other programs and at some point thereafter you would be handed a printout of the output generated by your program. You didn't interact directly with the computer and if your program crashed and produced no output, you'd have very little idea what had gone wrong.

The people who ran computer facilities were horrified at the idea of having users interact directly with their precious computers.

Programming languages come in all shapes and sizes and some of them hardly seem like programming languages at all. Of course, that depends on what you count as a programming language; as far as I'm concerned, a programming language is a language for specifying computations. But that's pretty broad and maybe we should narrow our definition to include only languages used for specifying computations to machines, that is, languages for talking with computers. Remember, though, that programmers often communicate with one another by sharing code and the programming language used to write that code can significantly influence what can or can't be easily communicated.

C, Java and Scheme are so-called general-purpose, high-level programming languages. Plenty of other programming languages were designed to suit particular purposes, among them the languages built into mathematical programming packages like Maple, Matlab and Mathematica. There are also special-purpose languages called scripting languages built into most word-processing and desktop-publishing programs that make it easier to perform repetitious tasks like personalizing invitations or making formatting changes throughout a set of documents.

Lots of computer users find themselves constantly doing routine housecleaning tasks like identifying and removing old files and searching for documents containing specific pieces of information. Modern operating systems generally provide nice graphical user interfaces to make such house-cleaning easier, but many repetitive tasks are easy to specify but tedious to carry out with these fancy interfaces.

Programming languages, like natural languages, have a vocabulary (lexicon) and rules of syntax (grammar) that you have to learn in order to communicate. Just as unfamiliar grammatical conventions can make learning a new natural language difficult, unfamiliar programming-language syntax can make learning to program difficult. English speakers learning Japanese have to get used to the fact that Japanese verbs generally come at the end of the sentence. With computer languages, the problem is made worse by the fact that computers are much less adept at handling lexically and syntactically mangled programs than humans are at grasping the meaning of garbled speech.

If you want to talk with computers, however, you're going to have to learn a programming language. Just as you learn new natural languages to communicate with other people and experience other cultures, you learn a programming language to communicate with computers and other programmers and to express computational ideas concisely and clearly. The good news is that learning one programming language makes it a lot easier to learn others.

When you start learning to program, you may find yourself consumed with sorting out the lexical and syntactic minutiae of the programming language. You'll have to look up the names of functions and operators and memorize the particular syntax required to invoke them correctly. You may end up spending obscene amounts of time tracking down obscure bugs caused by misplaced commas or missing parentheses.

While writing the previous chapter, I got to thinking about concepts in computer science that connect the microscopic, bit-level world of logic gates and machine language to the macroscopic world of procedures and processes we've been concerned with so far. In listing concepts that might be worth mentioning, I noticed that I was moving from computer architecture, the subdiscipline of computer science concerned with the logical design of computer hardware, to operating systems, the area dealing with the software that mediates between the user and the hardware.

In compiling my list, I was also struck by how many “computerese” terms and phrases have slipped into the vernacular. Interrupt handling (responding to an unexpected event while doing something else) and multitasking (the concurrent performance of several tasks) are prime examples. The common use of these terms concerns not computers but human information processing. I don't know what you'd call the jargon used by psychologists and cognitive scientists to describe how humans think. The word “mentalese” is already taken: the philosopher Jerry Fodor postulates that humans represent the external world in a “language of thought” that is sometimes called “mentalese.” Fodor's mentalese is more like machine language for minds. I'm interested in the language we use to describe how we think, how our thought processes work – a metalanguage for talking about thinking.

One consequence of inexpensive computer memory and storage devices is that much less gets thrown out. People who normally wouldn't characterize themselves as packrats find themselves accumulating megabytes of old email messages, news articles, personal financial data, digital images, digital music in various formats and, increasingly, animations, movies and other multimedia presentations. For many of us, digital memory serves to supplement the neural hardware we were born with for keeping track of things; the computer becomes a sort of neural prosthetic or memory amplifier.

However reassuring it may be to know that every aspect of your digital lifestyle is stored on your computer's hard drive, storing information doesn't do much good if you can't get at what you need when you need it. How do you recall the name of the restaurant your friend from Seattle mentioned in email a couple of years back when she told you about her new job? Or perhaps you're trying to find the recommendation for a compact digital camera that someone sent you in email or you saved from a news article. It's tough remembering where you put things and you'd rather not look through all your files each time you want to recall a piece of information.

In 1999, when NASA launched the first of its Earth Observing System (EOS) satellites, they knew they would have to do something with the terabytes (a terabyte is a billion bytes) of data streaming down from these orbiting observers.

With all my mumbo-jumbo about conjuring up spirits and casting spells, it's easy to lose track of the fact that computers are real and there is a very precise and concrete connection between the programs and fragments of code you run on your computer and the various electrical devices that make up the hardware of your machine. Interacting with the computer makes the notions of computing and computation very real, but you're still likely to feel shielded from the hardware – as indeed you are – and to be left with the impression that the connection to the hardware is all very difficult to comprehend.

For some of you, grabbing a soldering iron and a handful of logic chips and discrete components is the best path to enlightenment. I used to love tinkering with switching devices scavenged from the local telephone company, probing circuit boards to figure out what they could do and then making them do something other than what they were designed for. Nowadays, it's easier than ever to “interface” sensors and motors to computers, but it still helps to know a little about electronics even if you're mainly interested in the software side of things.

I think it's a good experience for every computer scientist to learn a little about analog circuits (for example, build a simple solid-state switch using a transistor and a couple of resistors) and integrated circuits for memory, logic and timing (build a circuit to add two binary numbers out of primitive logic gates).

This chapter has two main parts. The first part examines the application of existing international copyright agreements to the protection of databases. In the course of that examination, the argument is made that the Member States of the EU may be in breach of their international copyright obligations to accord national treatment and most favoured nation status to other members of relevant international agreements, by not providing the same sui generis protection for foreign databases as that provided to EU databases. This argument is based on the points made in Chapter 3 concerning the overlap between the sui generis right and copyright. The Directive's sui generis protection may be categorised as copyright and, consequently, national treatment must be accorded to all databases, regardless of their geographical origin. In turn, this has implications for the argument that other countries, such as the United States, should provide similar protection in order to obtain reciprocal protection from the EU. If the EU is already obliged to accord national treatment, that argument loses all merit.

The second part of the chapter examines the steps taken to date towards a multilateral treaty that would deal specifically with database protection. It also discusses the myriad of bilateral agreements entered into by the EU with other countries that effectively ‘export’ the sui generis right of the Directive to those countries as part of the acquis communitaire of the EU. The very nature of the discussion concerning databases requires some consideration of these international legal dimensions.

We live in the Age of Information. Information is money. So is time. The economies of the First World are dominated by the creation, manipulation and use of information and the time it takes to do so. These economies do not suffer from a shortage of information; they suffer from the difficulties associated with collecting, organising, accessing, maintaining and presenting it. Databases are designed to help deal with these difficulties. They are collections of information arranged in such a way that one or more items of information within them may be retrieved by any person with access to the collection containing those items. Therefore, databases are big business because they contain important and copious amounts of information and they reduce the time taken to access that information. And where there is big business, the law and lawyers inevitably follow.

But information is more than money and databases are more than big business. Information and databases are critical to science, the legal system itself, education and all those aspects of life that are improved by them. Consequently, there are important issues of social and political policy to be considered in the regulation of access to, and use of, databases. Again, where there are such critical issues at stake, the law has a role to play.

There is an inevitable tension between the commercial and the socio-political role of databases that leads to complexities in developing an appropriate model for their legal protection.

This chapter examines the transposition of the Directive into the domestic laws of the EU Member States. It does so by focusing on the protection of databases in nine of the Member States: Belgium, France, Germany, Ireland, Italy, the Netherlands, Spain, Sweden and the UK. The section below describes the legislation and case law of those countries relating to copyright and unfair competition as they relate to databases and the sui generis right. In order to avoid repetition, only particular features of the transposing legislation that are of note are discussed.

These nine countries were chosen for a number of reasons. First, they represent a broad range of pre- and post-Directive approaches to protection of databases. For example, Ireland and the UK had sweat of the brow copyright protection for databases prior to transposing the Directive. Most other countries did not have such copyright laws but had other schemes in place that conferred at least some protection on the non-original aspects of databases. For example, Sweden had its catalogue laws that influenced the Directive. Germany and other countries had, and still have, unfair competition laws that prevent parasitic copying by a competitor. Second, these nine countries represent the vast majority of the population of the EU and, finally, the vast majority of EU investment in databases and publishing occurs in those countries.

After examining the nine individual countries, the main issues raised by the transposing legislation and related case law are summarised. The chapter begins with three tables.

Mark Davison's book on database protection covers a vital aspect of the digital revolution. Indeed, the whole issue cries out for a place in this series. Databases stand at the juncture between information as such and the expression of literary and artistic ideas. From the first perspective, information appears to be a necessary element in social existence and so arguably it should be freely accessible to all. From the second, the need to provide an incentive for the costly business of assembling large databases argues for an equivalent appropriation to that given to creators and their producers by copyright. Deciding how to structure this crossroads – be it with filter lanes or with stop signs – calls for refined legal engineering. What has been done so far to regulate this space has in considerable degree depended on attitudes towards traffic which were formed in a horsedrawn era. Now, motorised vehicles bearing enormous loads of information bear down and have somehow to be accommodated. Hard-pressed legislators and courts have done what struck them as best, but it is far too early to say whether anything like a reasonable balance has been reached between free flow and controlled access.

It will be some time before we can see whether by and large we are offering stimulants to investment in data accumulation which are what is needed, but not evidently more than that. Mark Davison draws on the experience to date in the United States, the British Commonwealth and the European Union.

There are three basic models for legal protection of databases that can be easily identified.

1. Copyright protection is provided at a low level of originality. Under this model, copyright protection is provided for compilations on the basis that a substantial investment has been made in the compilation. This model presently applies in a number of common law countries such as Australia. The effect is that a database user cannot take a substantial amount of the data contained within the database.

2. Copyright protection is provided if there is some creativity in the selection or arrangement of the database material, coupled with a sui generis right. Copyright prevents the taking of the selection or arrangement. The sui generis right protects the investment in obtaining, verifying and presenting the data within the database. It does so by prohibiting the unauthorised extraction or re-utilisation of a substantial part of the data, conferring exclusive property rights in the data as it exists in the database upon the owner of the database. The Directive contains this model.

3. Copyright protection is provided for the creativity in the selection or arrangement of the database material. No protection is provided for the data contained within the database. At the time of writing, this model operates in the United States. Various bills have been placed before Congress to provide additional protection, but none has been passed as yet. The latest bills have proposed protection for the contents of databases where the database owner can demonstrate that a defendant's actions have materially harmed its primary or related market for the database.

This chapter examines the history of the Directive and its final form. It provides an overview of the official process leading up to the adoption of the Directive, and emphasises its changes in direction from the first EU documentation suggesting separate protection for databases through to the final version. In so doing, it demonstrates the myriad of potential models for sui generis protection. The initial proposals were firmly based on unfair competition principles, while the final version of the Directive draws very heavily upon copyright principles. The chapter also undertakes an analysis of individual provisions of the Directive and examines some of the difficulties associated with their interpretation. Particular emphasis is placed upon the relationship between copyright in the structure of databases and the individual contents of databases on the one hand, and the new sui generis right provided by the Directive on the other. In the course of this analysis, reference is also made to the justifications provided by various organs of the EU for the Directive's approach to particular issues and the various provisions implementing that approach. Finally, the last section of this chapter discusses the provisions of the recently adopted EU Directive 2001/29/EC of 22 May 2001 on the harmonisation of certain aspects of copyright and related rights in the information society (“the Copyright Directive”). The Copyright Directive contains provisions concerning the prohibition of circumvention of technological protection devices designed to protect copyright material.