Set code of code conduct

For the London Free Press – November 29, 2010

Read this on Canoe

It’s important to document your intentions before any code is created

It is not unusual for a business to hire someone to create computer code, such as a specialized program, website, or iPhone app.

It’s important to agree in writing who owns what’s created. Many people don’t realize that with nothing in writing saying the person who commissioned it owns it, the creator owns it.

Problems can result later if the intended ownership is not documented at the outset.

On the other hand, people sometimes get too hung up on ownership. It is not unusual for two parties each to want to own the same software.

For example, code creators often reuse existing code to create parts of their end product. It doesn’t work for the buyer of the end product to own everything in it to the exclusion of the creator. At the same time, the buyer may want to own the product as a whole, and not want the creator to reuse or resell it.

The buyer may feel that it paid for it, and the creator shouldn’t otherwise profit from it. The creator may feel that since the buyer got the benefit of existing code, it’s not right to deny others the benefit of parts of the new code. And too many restrictions on the creator can limit its ability to provide services to others.

To some extent, it depends on the novelty of the code, its intended use and competitive value. The buyer may not want competitors to use the new software. And if the whole idea is to create a product for the buyer to exploit commercially, it makes no sense for the creator to be able to do that as well.

Often, the focus should be less on who owns the software, and more about what the parties can do with it. At very least, considering the issue in that light will help sort out ownership.

The parties should think about what they need to do with the product and its parts and what they do and don’t want the other to do with them.

Sometimes, the issue can be resolved by creating broad licence rights, and perhaps restricting what the other party can do. For example, the buyer might get a licence letting it do whatever it wants with the product internally, but not sell it to anyone else.

But the time to deal with and document this issue is before the work starts. The longer it waits after that, the more difficult it becomes to reach consensus and document the result.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>