Who owns the code? Software development contract terms in plain English

Most business owners sign a software development contract after reading the price and the timeline, and skimming the rest. The rest is where the expensive surprises live: who owns the code, what happens to your accounts if the relationship ends, and how changes get paid for.

This post walks through the software development contract clauses that matter most, in plain English. It is not legal advice. Contracts depend on your state and your situation, so have a lawyer review anything you sign. The goal here is to help you know what to ask about.

Who owns the code

This is the clause to read first. There are two common arrangements.

Assignment. The developer transfers ownership of the code written for you, usually once you have paid for it. You own it outright and can change it, sell it or hire someone else to work on it.

License. The developer keeps ownership and gives you permission to use the code. A license can be broad or narrow, and it may limit changing the code, using it in another business, or moving to another developer.

For custom work you pay for, assignment is the normal expectation. So if the contract says license, ask why, and ask exactly what you can and can't do.

Pre-existing code and tools

Developers reuse their own building blocks across projects, such as a sign-in module or a deployment script. Reasonable contracts let the developer keep owning those, while giving you a permanent, free license to use them as part of your software. What matters is that you can keep running and changing your software without asking permission.

Open-source components

Almost all modern software includes open-source libraries. That is normal and healthy. A good contract says the developer will use only components whose licenses allow commercial use, and will tell you if anything unusual is included.

Who owns the accounts

Code is only part of it. Your software also lives in accounts: the code repository, hosting, the domain name, app store listings, email sending, payment processing and analytics.

Every one of these should be in your name and billed to you, with the developer given access. If the developer owns the hosting account, they effectively own your running business software, whatever the contract says about code.

So ask for a list of every account the project will use, and who will own each.

Payment and acceptance

Look for how and when payment is due, and how you accept the work.

• Milestones tie payments to delivered pieces of working software.
• Acceptance says how long you have to review a delivery and what counts as approval.
• Deposits are common, especially for smaller firms. Make sure the contract says what the deposit covers.

Watch for ownership transferring only on final payment. That is usual, but it means a dispute at the end can leave ownership unclear. Some contracts transfer ownership piece by piece as each milestone is paid.

Changes and scope

Every project changes as people see working software. The contract should say how you and the developer handle changes. Usually a written change request describes the new work and its price or time, and nothing starts until you approve it.

Read the scope carefully. A good scope lists what is included and also what is left out on purpose. Vague scopes cause most disputes.

Warranty and bug fixes

Many contracts include a period after launch, such as 30 or 90 days, where the developer fixes defects in delivered work at no charge. Know what counts as a defect: something that doesn't work as specified, as opposed to a new feature you'd like.

After that period, fixes and updates usually fall under a maintenance agreement or an hourly rate. Also ask what happens if a security issue appears in year two.

Confidentiality and data

Your developer will see business data, customer records and plans. The contract should commit them to keep it confidential and to handle personal data properly. If you are in a regulated industry, such as health care, you may need specific agreements on top of this.

Leaving cleanly

Relationships end for ordinary reasons. The contract should say what you get when they do:

1. All source code, in a repository you control.
2. Access to every account, transferred to you if it isn't already yours.
3. Documentation: how the system fits together, how to deploy it and how to restore a backup.
4. A reasonable handover period, such as answering questions from a new developer for a few weeks.

If a developer resists these terms, treat it as a warning sign.

Our own terms, briefly

On our projects, the repository, the hosting accounts and the domain are in the client's name from the first day, and handover documentation is part of the work, not an extra. Every project starts with a written scope that says what the first release does and what it leaves out, with a price, and we bill nothing before the client approves it.

A short checklist before you sign

• Does the contract assign the code to us once paid?
• Are all accounts in our name?
• Is it clear how changes are requested and priced?
• How long is the warranty, and what does it cover?
• What do we receive if we part ways?
• Has our lawyer read it?

The web applications page describes how we hand over a project another engineer can pick up.

Questions about a contract in front of you?

We can't give legal advice, but we are happy to explain what a technical clause means in practice. Send us your question, and we reply within one business day.

Cover photo by Scott Graham on Unsplash.