Who owns the source code?

For the non-technical reader, the “source code” can be one file but much more often multiple computer files containing text from which the binary files (consisting really of just ‘1’s and ‘0’s recognized by the computer) are created. This “text” is really, of course, the computer program itself. It is written following strict rules of syntax based on the particular language selected for developing the program. Though the source code files contain text, and can generally be read with Notepad or other text reader programs, they are not generally simple text files and are typically accessed only through the software development environment.

The binary files created from these program files are what the computer actually executes. Anyone who has the source code and the appropriate software development tools (primarily a compiler) can recreate the binary code that makes up the solution.

In summary, the “source code” provides in a human readable form the intellectual property that the software vendor is providing to the customer.

So the question of “who owns the source code” could be rephrased as “who owns the intellectual property”.

This question is relevant to any discussion of the reusability of custom software code.

Equally clearly this is not an issue with standard software programs. In those cases, the vendor pays for the development of the software so they own the intellectual property and, therefore, they own the source code. (Obviously I am ignoring open source code programs with that statement.)

But in the case of a custom software development project, the issue is a bit more complicated. In such cases the customer is paying for the custom code that is being developed. So shouldn’t they have a right to a copy of that code?

If you buy a custom-designed house directly from an architect, you are surely allowed to have a copy of the blueprints!

In my mind, the answer is “Yes!” The customer does have a right to a copy of the source code. I ran my own consulting company for a number of years and I never hesitated to give any customer who asked a copy of the source code that I developed. (I was only asked once to do so.)

While this is my opinion, other custom software developers have a different view.

It is important to note that there are some inherent dangers and genuine complications in giving this code to the customer.

The first danger is that the customer may make changes to the program, unknown to the vendor, but still expect the vendor to support it.

I personally saw an example of this.

In the early 1980’s, I provided consulting support for a number of small companies. That was back in the computer Dark Ages when personal computers were first becoming generally available. Much of what I provided used a program called dBase III. That program was “interpreted” meaning that it was compiled into ‘1’s and ‘0’s as it ran (during ‘run-time’). There are multiple disadvantages to such programs (including needing to purchase a copy of the dBase program for every workstation and the fact that such programs run much slower). But the biggest disadvantage of such programs, relative to the current discussion, is that the source code is readily available to the user (as long as they know a few basic rules about how to access it).

If they have access to it – then they can change it.

I had a customer call and complain about a problem that they were having with one of the programs that I wrote. I stopped into their office to fix it. I quickly found that someone had modified the source code that I provided! It was those modifications that weren’t working. I found out why they wanted those changes and repaired the program appropriately.

In a large corporate environment, there is a clear and present danger in allowing the customer to make such changes. Fortunately, most customers understand these dangers and don’t have any more desire than the vendor to allow such changes by the customer’s representatives. Moreover this sort of problem tends to be easy to spot (the size of and the date-and-time stamp on the binary files will be different, for example). In addition, I can’t imagine a customer who would argue with a vendor who billed for fixing a problem caused by someone working for the customer who modified the program.

A second potential danger in providing the customer with a copy of the source code is that you are possibly enabling the customer to become a competitor of yours. The customer can potentially take what you wrote and resell it, possibly making small changes as they do so but still using the intellectual property that the vendor created as the basis for what they sold. I believe this danger to be minimal. People interested in such custom software are probably people who compete with the customer who has the original code. The customer is unlikely to wish to enable their competitors.

But this possibility, however unlikely it is, can be handled by contract terms within the contract agreed to between the customer and the vendor.

A third problem is that the source code will generally include reused code that was developed initially for another customer. In that case portions of the source code were paid for by other customers. So if you provide all of the code for the customer, it is likely that you are giving the customer intellectual property that they didn’t pay for.

Once again, there is a solution. It takes a bit more work, but the source code that the customer did not pay for can be provided in a binary form rather than in the original source code form.

A final problem is that the source code can be given to another vendor and that vendor can take over the development and support of the program. Again I consider this to be a relatively small danger. The original vendor is bound to be much more familiar with that source code and should, therefore, be able to be very competitive with anything that any other vendor could provide.

But clearly there are dangers and complications in providing this source code to the customer. That is why many vendors believe that the customer should NOT be given that code.

But there is a legitimate reason for the customer to want a copy of the source code is that there is a dangerous situation: the customer needs to have some reassurance that their program can be modified if the vendor goes out of business.

How do you handle that situation?

There are companies that provide the ability to put the source code into escrow. The source code is hidden until (and unless) the vendor gets out of the business.

There is a cost associated with this. That cost should be built into the quotation provided to the customer.

The biggest danger of such escrow accounts that I have witnessed is that while the initial solution is safely put into escrow, any updates are not necessarily included. It should be the responsibility of the project manager to make sure that all updates are put into escrow if such an account has been established for a particular customer.