Source Code as a concept

There are two technical terms that you will often encounter when going through the pages of a software licensing agreement or a software development agreement. These are source code and object code.

Nevertheless, before elucidating those concepts of source code and object code, it would make sense to first clarify what software is. Like many other terms which are frequently used in an automated manner in everyday communication, its exact meaning might have become somewhat diluted.

Simply stated, a computer program is a set of instructions. Those instructions are capable, when fed as an input to a machine, to cause that same machine to perform a specific function or achieve a specific result. (Or if you prefer a more academic flavored definition, one that I like is the wording from the WIPO Model provisions on the protection of computer software from 1978 – ”computer program means a set of instructions capable, when incorporated in a machine-readable medium, of causing a machine having information-processing capabilities to indicate, perform or achieve a particular function, task or result”).

In other words, it is software that makes your computer act and look smart. Without these sets of instructions the underlying hardware would pretty much be a useless pile of plastics and metal with close to zero practical value. It is this critical interplay between software and hardware that underpins the two concepts that are the focus of our attention – source code and object code.

Let’s move a step further now and ask ourselves how exactly software is created by developers.

 

 

When computer programmers create software (i.e. write those sets of instructions) they operate in the realm of source code. Simply put, source code is an expression of the computer program that is created in human readable form through a programming language (such as JavaScript, Python, PHP, C++, Ruby, etc). Thus, the key characteristic of source code is that it is intelligible to humans. The programming languages comprise of a set of predefined commands which cause certain actions to be performed. Similar to natural languages, they also have a defined syntax which must be followed for the program to be executed correctly.

Nonetheless, the source code cannot directly cause the computer to perform a given task as computers can only understand machine language. In order for the human-readable source code to become executable it needs to be compiled into binary form (1s and 0s) and thus become intelligible to the CPU (the processor) of the computer. It is this binary form that we call “object code”.

The transformation of source code into object code is done through a computer program, called a “compiler”. It checks for errors in the source code. Importantly, the compiler replaces the instructions expressed in a programming language with machine-readable instructions. The result of the transformation is the object code appearance of the program which can now be used to direct the functions of a computer.

It must be noted that the reverse process (decompilation) is also technically possible so that a reconstruction back into source code can take place. This is done through a “decompiler” – a programming tool which takes the executable file of the software as input and attempts to recreate its source code.

 

 

Despite this duality in nature when it comes to code, the legislative approach is certainly practical. Both appearances of the program – human-readable and machine-readable – are given equal legal protection. We can see this explicitly mentioned in the text of the TRIPS Agreement (Agreement on Trade-Related Aspects of Intellectual Property Rights). Article 10, paragraph 1 reads that “computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention (1971)”. It might be a little counterintuitive to consider the machine language of 1s and 0s a literary work but as we saw this machine language is derived directly from the textual essence of the software (its source code) and can be reconstructed back to it.

Undoubtedly, the source code is one of the most important and most valuable assets of a software vendor. The source code and its structure and sequence are the essence of each piece of software. It is the result of creative efforts and it is the substance that can make the difference between a highly successful product and a mediocre one. In other words, when it comes to software, high quality source code is a key ingredient in the recipe for success. Accordingly, if the source code is disclosed or becomes accessible for third parties, the know-how and all the specific knowledge and unique developments of the vendor will be out in the open and up for grabs. Such a situation could result in irreparable harm to a software vendor.

Then comes the question what can you do to protect yourself. There are two simple tweaks you can apply in a software licensing agreement to guarantee the protection of the source code.

⇒ First, it is a standard rule in the software world that a proprietary product (especially COTS – commercial off-the-shelf software) should be licensed in object code. This is directly related to the mentioned fact that the source code is a critically important asset for the software vendor that should never be given away. Therefore, it is advisable when drafting a software licensing agreement to go through your text one more time and make sure that there is an explicit statement in the contract that the software product is licensed in object code only. Another way of achieving this same result is by cleverly phrasing your definition of the Software Product. After mentioning the name and the version of the product you can add that it comes in object code. Then, when you afterwards formulate the license grant you will refer to that same definition of the Software Product. In any event, do not rely on the presumption that an object code license would be implied based merely on the prevailing market practice for proprietary software. Instead, just add a short and simple explicit statement.

⇒ Second, it is recommended to add one more layer of protection for your source code. This can be done through a provision which explicitly forbids the licensee to reverse engineer or decompile the software. To ensure that the provision has a real impact you should also tie it to the validity of the license grant. In this way the license would be conditional on the licensee complying with certain predetermined restrictions, one of which is the decompilation ban. Accordingly, if the licensee breaches the provision by performing decompilation, the vendor will be in a position to revoke the license immediately.