What is Software?

This note is the first of a series about the nature of software, what it means to different interested parties, and an amateur's view of how our legal system interacts with software.

The following is a list of ways in which I interact with software. Some of them are fairly obvious, others are more subtle:

• Text
• Content or Tool
• Collection of Algorithms
• Architecture
• Interaction

A given piece of software has many potentially interested parties, including the author of the program, the business that funded the program (if there was one), users of the program, relevent companies, and, in some cases, the broader public and it's representatives in government. Needless to say, each of these vested interests may focus on different aspects of a given program, and in some cases, may have different perspectives on the same aspect of a program.

This multi-faceted nature of software also gives rise to the application of a wide range of laws to software products. Contracts, patents, copyrights and licenses are all routinely applied to software. We've also seen anti-trust, product liability, freedom of speech, export law and specially crafted laws such as DCMA all target various aspects of software. This situation is only growing more complex as other businesses become more intertwined with software, it's nature and it's legal implications. The impact of the entertainment industry alone on the current and future states of software and the Internet is difficult to fully comprehend.

The following sections examine some of the particular aspects of each facet of software.

Software as Text ("It's just typing")

One day we were in the office discussing a particularly hairy design for something and one of the architects said "I don't know what you're all so worried about, it's just typing."

In it's basic source form, software is one or more files full of carefully constructed text. Other than when we're developing, we often don't get to see the code in this form, but at some point in it's life, software was the result of a bunch of typing. In this form, software is not much different than text in a book. A snippet of it may contain an good idea or may be relatively meaningless or useless without the context of the rest of the code.

What about binary code? In some ways it's still like text, just translated to a very strange language where single words are broken into a series of precise, but obscure words. The result is that it's much more difficult to understand what the author meant, but with appropriate tools and a little hard work people do it all of the time. However, just like a text translation, it is difficult to get back to the specific text that the author originally wrote.

Software as Content or Tool

When it runs, software can do many wonderful things. Sometimes it grinds through calculations we'd never dream of taking on by hand. Other times it interacts with us through games, music, puzzles, simulations, etc. Sometimes it's best described as a tool, organizing information, moving data around, sending email to someone, etc etc etc.

In many ways this facet of software resembles a CD or DVD. I derive value from the content or action of the software when it operates. Furthermore, it's generally possible (though often not legal) for me to make a copy of the bits, give them to someone else, and we can both derive value from them in parallel, without any reduction in the value I derive.

At the Content or Tool level, the Text level is mostly or totally hidden from view. I only see the effects that the author had in mind, I can't tell how she created those affects. If I carefully observe the actions of a piece of software but can't see it's underlying text, I may be able to write a new piece of software which mimics it exactly at a behavioral level. However, that may get me no closer to interoperating with the original (see Software as Architecture for more discussion).

Software as a Collection of Algoriths

Webster's dictionary describes an algorithm as "a rule of procedure for solving a problem", which leads to a description of a software program as a collection of algorithms, each of which is a procedure for solving a problem. For example, a program that manages addresses may need a procedure for alphabetizing a list of them. As most programmers know, there are many ways to do this. Some of them are brutish, others quite elegant. Some are efficient, others are molasses by comparison.

It's important to put this facet of software in context of the last two we covered. First, I may express the same algorithm with many different collections of source code text. I may do something as simple as use a different programming language, or I may express the same algorithm, but with different language primitives and variable names. Similarly, at a machine code level the programs may be more similar for a given architecture, but two compilers could produce very different code that expressed the same algorithm.

Algorithms have an equally odd relationship with the "tool" nature of software. As our example above illustrates, the fact that my address book is sorted tells me nothing about which sorting algorithm was used. In other words, the function of a program may tell us some information about its algorithmic makeup, but it may be a very slight amount of information.

Finally, this category is an important one to call out from a legal perspective. This will be covered in a future note.

More to come...

Software as Architecture

Software as Interaction