Who owns your bespoke software?

If you own a small business, it makes sense to outsource software development so you can focus on your core competencies. But what happens when the developer runs off with the source code and the consulting agreement is no longer being honoured? This happens more often than you may think which is why it is good to think carefully about every term of any contract that defines your relationship with developers.

First, understand that almost most custom software contracts provide that upon full payment the author retains intellectual property rights in whatever work has been delivered. Although there are some exceptions (for example, if you want an Open Source license or public domain dedication), this will probably be true of any custom-developed system unless you negotiate otherwise for your project.

This doesn’t mean that you don’t own it. It simply means that if the developer decides to stop supporting their software, you need to either make changes yourself or switch to another vendor who can support your new platform. This is not a bad thing. Just be aware of what you are buying before you sign on the dotted line.

The best time to negotiate these matters is during the sales cycle. If you already have a relationship with a developer and they submit an invoice for work performed, then immediately getting started negotiating might not be practical (or even possible if time is of the essence). But in any event, at some point it’s essential to understand all terms governing your business relationship so that there won’t be any surprises later when your project is complete.
Here’s what you need to know:

  1. Proprietary Software and Customized Platforms . It is common for developers to build on their own platform using some open-source or “white label” system, and then customize it so that it meets your needs and theirs as well. Sometimes this results in a completely new proprietary piece of software which has commercial value, followed by an amicable handover of all rights at no extra cost—excluding source code ownership (which may be available under another license). More commonly, the resulting software (along with its supporting platform) is considered to be custom work belonging to the customer —even if only because you paid them more for it than they would have charged had they created yours from scratch.
  2. Open Source Licenses . You are probably already aware of the GPL licenses that govern free software, including key pieces used by many popular programming languages and databases. Ordinarily, if you want to use open source code in a commercial product then it needs to be licensed under some other agreement that includes an explicit right-to-use provision (for example, using Apache or Eclipse licensing). What you may not know is that most open source licenses permit commercial distribution provided there is no fee charged for the software itself (i.e., it’s “free as in beer”). If you purchase custom software with its supporting platform built on GPL components, your developer needs to provide what they call an “embedded” license so that your proprietary system can be distributed without losing its commercial value.
  3. Open Source Licenses – Public Domain Dedication . The public domain is a special category of intellectual property rights that applies when copyright or other exclusive rights have expired, been forfeited, expressly waived, or where the owner has disclaimed such rights. In other words, there are some situations where you can take something out of what appears to be the “proprietary” software and place it in the public domain so that anyone can use it without restriction—even for commercial purposes. This is a simple way for developers to share their work with others who may find it useful while still retaining ownership over everything they create (unless they specify otherwise).
  4. Protecting Your IP from the Developer . Even if the customized platform and other elements you end up with are owned by your developer, they should not be allowed to use it as a selling point for their own services or products. If it’s considered “custom work”, then licensing such “inspiration” from the developer could cause problems later on if they talk about how great your system is and how much potential value there might be in making something similar available to others. This also applies to any documentation that will accompany the software (including user manuals, reference guides, training materials, etc.).
  5. Ownership of Custom Code . The code you write may be completely original and therefore yours. But what happens if you change an existing open-source component? What if you make a modification to a GPL system? If the resulting work is considered custom work, then it would be advisable for you to retain ownership of your code in case you need to share this information with future clients. On the other hand, if your developer is making substantial changes that are protected by copyright then they should own whatever they create. This may sound unfair until you understand that developers have their own intellectual property protections to use in order to make money when doing what they do best.

If anything isn’t clear yet, speak with your developer before signing on the dotted line. Don’t take it for granted that things are done or understood based on how easily terms can be misinterpreted—or ignored when there’s no contract in place at all.

Contact us for more info.