The legal battle between Oracle and Google over Java and Android code could have huge ramifications for open source software. But the biggest lesson it highlights is the inexorable difficulty of defining what code actually is — and what it is not.

The details of the case between Google and Oracle, and their consequences for open source software development, have been covered elsewhere. We won’t rehash them here.

Suffice it to say that Google’s main argument in the case is that Java APIs are not really code, so software licensing doesn’t apply to them. Oracle contends the opposite and wants Google to pay up for having used Java APIs in Android without licensing them from Oracle.

What is Code?

The outcome of the case is likely to have big consequences for the extent to which open source programmers can legally borrow other people’s code or ideas and incorporate them into their own software. But the even more interesting aspect of the case is what it says about what the very nature of code and software itself.

It’s easy enough to define what code is — if you have 38,000 words and plenty of animations, at least, as Paul Ford did in his masterful article “What is Code?” The essay is probably the most brilliant explanation to date of the history of software engineering, its current state and how software affects the rest of the world.

Yet the greater question, at least for Oracle and Google right now, is identifying what is not code. That’s a difficult task in an age when we are surrounded by computers and software, and code seems to run our lives. Amid all the digital complexity of the Internet age, code — especially open source code, which is available for anyone to read — may seem to be the one thing we can still control. As long as you can read code, you can understand what the computers and devices around you are doing by examining the code that runs them, right?

Code is not Control

Well, not really. As powerful as code seems, mapping the relationship between code and what computers actually do is not at all straightforward, as Wendy Chung argued in her 2010 book Programmed Visions. In other words, controlling code does not mean you control the way your computer (or smartphone, or whatever) behaves. There are several reasons for this.

For starters, code almost always contains bugs. They can be introduced not only in the code itself but also by a compiler, the environment in which code runs, hardware problems or any number of other issues. No matter the source of a bug, bugs assure that code cannot be guaranteed to make a computer do what a programmer intended.

Also significant is the fact that there is no direct, constant relationship between source code and the software that actually runs on a computer. Different assemblers or compilers could take the same source code and make it look very different as object code. Different operating systems may execute software based on the same source code in different ways. And so on.

Then, of course, there is the issue of having so many different types of code and coding languages. Reading code written in today’s popular high-level programming languages may be easy enough for experienced developers. Yet making sense of assembly code, or source code programmed in obscure languages, is much tougher. No one can be a master of all code.

Oracle, Google and Code Control

None of these observations help to decide the question of whether Google improperly used Java APIs in Android takes on a different meaning. But they highlight the ways in which the obsessive focus on code itself distracts from the bigger picture of how people actually use computers.

However the court interprets Google’s use of Java APIs, neither Google nor Oracle will enjoy full control over the way Java runs on Android devices or anywhere else. Full control is not possible, because software behavior is not fully predictable.

If there is a lesson here for the open source community, it’s that the question of code ownership is less important than cases like the one between Oracle and Google imply. Yes, determining who owns code and how code can be shared matters for legal reasons. But technically, these are very blurry issues. They’re also of relatively little importance, because producing and using software requires attention to the complete environment, not just code itself. That’s what the narrow focus on Java APIs in this case, and all the similar legal battles about code ownership, misses.