Who owns the copyright in software I paid a developer to write?

It depends on jurisdiction and the contract. In most common-law countries the contractor or their company owns copyright in the code unless the contract assigns it in writing. Some civil-law systems treat certain rights as inalienable. Nepal's Copyright Act vests economic rights in the author. Read the signed agreement before assuming anything.

What is the difference between a copyright assignment and a licence?

An assignment transfers ownership outright. A licence grants permission to use the work while the author keeps ownership, and can be exclusive or non-exclusive and limited by territory, duration and purpose. Without a written assignment you likely hold a licence at best, which complicates selling the business or the code later.

Does paying the invoice transfer IP ownership to me?

No. Payment settles the invoice, not the copyright. Ownership moves only through a written assignment signed by the rights holder, or automatically under employment law if the developer was a true employee. Paying in full and receiving the repository gets you the files, not legal title to them.

What should an IP assignment clause contain?

It should assign copyright and, where permitted, waive moral rights; list the deliverables; cover work done by subcontractors; and state when assignment takes effect, on payment or on creation. Add a fallback licence in case the assignment fails, plus a warranty that the code does not infringe third-party rights.

Who owns code written by an employee versus a contractor?

In many jurisdictions work created by an employee in the course of their duties belongs to the employer automatically. Contractors usually retain copyright, so an assignment is required. Side projects outside an employee's duties and all contractor work need separate written terms. Verify the position under local employment law.

Do open-source libraries in my product affect IP ownership?

Your own code stays yours, but dependency licences impose conditions. Permissive licences such as MIT or Apache-2.0 generally require attribution and notice retention. Copyleft licences such as GPL can require releasing derivative source under the same terms. Run a software composition analysis scan before shipping or selling.

How do I verify I actually own the code I paid for?

Check the signed contract for an assignment, then confirm the repository, domain, cloud accounts and credentials sit in your name rather than the developer's. Review commit history and contributor identities, and confirm subcontractors signed over their work. A short legal review of the documents usually costs less than a dispute.

What happens to the IP if the developer or agency goes out of business?

If an assignment was signed, ownership already sits with you and the closure changes nothing. If it was not, the rights may pass to an insolvency practitioner or the founder's estate, and getting a signature becomes difficult or impossible. That is the practical reason to settle ownership at contract time.

What drives the cost of fixing IP ownership after the fact?

Mostly legal time: tracing contributors and subcontractors, reviewing old contracts, drafting confirmations or a retroactive assignment, and clearing dependency licences. Scope depends on how many parties must sign and how old the work is. Getting the assignment clause right at the start costs far less.

What are the common failure modes, and how do I debug them?

Typical failures are no written assignment, an assignment naming the wrong legal entity, missing subcontractor sign-off, and unsigned change orders. The symptom surfaces at due diligence, funding or acquisition. Fix it by tracing every contributor and deliverable back to a signed document, then obtaining written confirmations.

IP Ownership Software: Who Owns the Code You Paid For

Intellectual property when you paid someone to think

You own the software when the contract assigns the copyright to you in writing and you control the accounts it runs in. Payment alone transfers nothing — under most copyright law the developer keeps ownership by default. Almost every dispute about IP ownership in software comes back to that gap.

Key Takeaways

Copyright starts with the author, not the payer. Only a signed assignment clause moves it.
"Work for hire" is narrower than most people assume, and its meaning shifts by jurisdiction. Have a lawyer read the exact wording.
Owning the code is worthless without the repository, the DNS zone, the cloud account and the build secrets.
Third-party libraries, fonts, icons and SDKs are licensed to you, never owned by you.
Verification is practical, not legal: can your team rebuild and redeploy without asking the original developer for anything?
The cheapest fix is a clause signed at kick-off and a handover checklist run on launch day.

The four points where software ownership is won or lost: the contract, the build, the handover, and the years of steady-state operation afterwards.

What does IP ownership actually cover in a software project?

IP ownership covers several separate things: copyright in the source code, ownership of design files, rights to the name and logo, the data in the database, and control of the accounts — repository, registrar, cloud, app stores. Each transfers by a different mechanism at a different moment, so one "all IP transfers" sentence usually leaves gaps.

In practice we see clients assume a single handshake covers everything. It does not. The design files may belong to a freelancer who was never mentioned in the main contract. The domain may be registered under the vendor's reseller account. The logo may have been bought as a stock template. Each of those is a separate thread you have to pull.

Why does ownership matter more in production than on paper?

Because most of the value sits outside the code. A rebuild is possible if you hold the repository, the infrastructure definitions, the DNS zone and the credentials. Lose those and you are not buying software — you are renting access to one person's memory of how it was built, and that memory has a resignation date.

Disputes rarely reach a courtroom. They end as a stalled project: the developer has moved on, the build only works from their laptop, and nobody can rotate a certificate without a phone call. The paper problem becomes an operational one, and operational problems have deadlines attached.

When do you actually need a written assignment clause — and when is a one-liner enough?

You need a written assignment whenever the software is core to the business, is sold or licensed onward, or will be valued during investment or acquisition. A short internal tool for one team can usually live with a simple clause plus a clean handover. A product, a payment system or a regulated workflow cannot.

Situation	What must be in writing	What commonly gets missed
Revenue-critical product	Full copyright assignment, IP schedule, moral-rights waiver	Design files and brand assets left with a subcontractor
Customer portal or internal system	Assignment clause plus an account handover checklist	Cloud billing account still in the vendor's name
WordPress site or theme work	Assignment for custom theme and plugin code; licences for third-party	Assuming a commercial theme becomes yours
One-off internal tool	Simple assignment and a repository transfer	No documented build steps for the next developer
Work done by subcontractors	Flow-through assignment from each subcontractor to the vendor to you	No paper trail between the vendor and their own contractors

How does ownership actually pass from one party to another?

Ownership passes by assignment, not by payment. The contract must identify the IP, state that the assignor transfers all right, title and interest, and be signed by someone with authority to bind the company. Some jurisdictions also require a moral-rights waiver. Without that paper, the developer holds copyright and grants you at best an implied licence.

List the IP before work starts: code, designs, content, brand marks, domain names, data.
Put the assignment clause in the signed contract, not in a proposal or a statement of work appendix.
Have it signed by a director or owner who can actually bind the company.
Add flow-through clauses for every subcontractor and offshore team member.
Include a moral-rights waiver where your jurisdiction recognises moral rights.
Transfer accounts at handover — repository, registrar, cloud, app store listings, analytics.
Record what is third-party, with the licence name and where the licence text lives.
Keep the signed document somewhere you can find it in five years, not in a chat thread.

Which files and accounts actually have to change hands?

Ownership documents are not operational control. You need the Git repository with full history, the CI configuration, infrastructure-as-code definitions and their state, the DNS zone, TLS certificates, the cloud billing account, app store listings and the licence files for every dependency. Miss the state file and the IaC is decoration.

A quick read-only audit tells you a lot. Run these inside the repository you were handed — none of them change anything:

git remote -v
git log --format='%an <%ae>' | sort -u | head -20
terraform state list

The first shows where the repo really points. The second shows who actually wrote the code, which is often not who you paid. The third shows what infrastructure is under management — and an empty result on a live system means the infrastructure was built by hand.

How each asset class in a typical build transfers, and where the transfer actually gets blocked in practice.

How do you verify you really own and control it?

Verify by rebuilding. Clone the repository into an organisation you control, run the pipeline from scratch, and deploy to an environment you own without asking the original developer for a password. If that fails, you do not have ownership in any practical sense — you have a copy of the files and a live dependency on someone else.

Do this before the final payment, while you still have leverage. A rebuild test on a staging environment takes an afternoon. Discovering the gap eight months later takes a fortnight of someone's time and a lot of goodwill you no longer have.

Three moments that decide who really owns the software: the day the contract is signed, the month after launch, and the first time someone else has to maintain it.

What breaks when ownership is unclear?

The usual failure is not a lawsuit, it is a standstill. The original developer is unavailable, the repository sits under a personal account, DNS is held by a reseller, and the build needs a licence key nobody can locate. Recovery means reconstructing the deploy path before you can even fix the actual bug.

Look for these signals early: commits authored by personal email addresses, a terraform.tfstate file stored on a laptop, no README with build instructions, and one shared password used by everyone. Each one is a small thing. Together they mean you cannot operate the system you paid for.

What does unclear ownership cost, and who operates it afterwards?

Cost shows up as engineer time rather than invoices: forensic work to reconstruct a build, legal review to paper over a gap, and in the worst case a partial rewrite because the code cannot be legally reused. The cheaper path is almost always a clause signed at kick-off plus a handover checklist run on launch day.

Think about the operating model too. Someone has to renew the domain, patch the server, rotate credentials and apply dependency updates. If that person is the original contractor and no one else has access, you have outsourced continuity, not just development. Our team can help you set up maintenance you actually control, or put the whole build on a firmer footing with custom software development that hands over cleanly.

What are the security considerations?

Every account you do not control is a credential risk. Personal GitHub accounts, shared registrar logins and a single cloud root user are the usual culprits. Move to named accounts with role-based access, enable multi-factor authentication everywhere, and rotate any secret the previous team could still hold.

Rotating secrets is a state-changing operation: database passwords, API keys and deploy tokens will break every service still using the old values. Do it in a maintenance window, have the new values ready first, and confirm the rollback path before you start. On the repository side, GitHub documents transferring a repository between accounts and organisations, which preserves issues, pull requests and history — far better than pushing a fresh copy. For domains, the registrar can move the registration between accounts; Cloudflare's registrar documentation covers how registration and DNS control are separated, which is exactly the trap that catches people who "own" a domain but cannot edit its records.

What mistakes do teams make most often?

The same four mistakes appear in almost every dispute we are asked to untangle: an assignment clause buried in a proposal rather than the signed contract, accounts left in personal names, third-party licences nobody tracked, and a handover that stopped at "the code is on the server".

Treating the proposal as the contract. A proposal is a sales document; the signed agreement is what a court reads.
Paying the final invoice before the rebuild test. Leverage disappears the moment the money lands.
Forgetting that a subcontractor's work needs its own assignment. Your vendor cannot assign rights they never acquired.
Leaving the domain at the vendor's reseller. Registration and DNS control are separate settings, and both need to be yours.
Assuming an open-source library's licence is irrelevant. Some carry obligations that affect how you can distribute your product.

A realistic scenario

A Kathmandu services company pays a small studio to build a customer portal. The work is good, the invoices are paid, and everyone is happy for two years. Then the studio's lead developer leaves the country, and the client wants to add online payments.

The new developer finds that the portal's repository lives under the departed developer's personal account, the cloud project is on the studio's billing card, DNS is managed inside the studio's reseller panel, and there is no infrastructure code at all — the server was configured by hand. The assignment clause exists, but it is in an email, unsigned, and mentions "the website" rather than the portal, the database schema or the deployment scripts.

Recovery takes three weeks: audit what exists, rebuild the deploy path as code, re-register the domain into the client's account, rotate every credential, and get a proper assignment signed for the parts that were never covered. None of it is glamorous. All of it was avoidable with a paragraph and a checklist.

In short

Get the assignment in the signed contract, not in a proposal.
Move accounts — repo, DNS, cloud, app stores — before final payment.
Run the rebuild test while you still have leverage.
Track third-party licences; they are never yours to own.
Document the build so the next engineer does not need to ask anyone.

If you are about to commission work, or you have inherited a codebase with murky history, read our notes on what a paid discovery phase should produce and how to exit a software project cleanly. Both are shorter than the recovery work.

People also search for

If you want the contract and the handover done properly the first time, talk to our team before the next build starts — and read the rest of our frequently asked questions on how we work with clients in Nepal and abroad.

Frequently asked questions

It depends on jurisdiction and the contract. In most common-law countries the contractor or their company owns copyright in the code unless the contract assigns it in writing. Some civil-law systems treat certain rights as inalienable. Nepal's Copyright Act vests economic rights in the author. Read the signed agreement before assuming anything.
An assignment transfers ownership outright. A licence grants permission to use the work while the author keeps ownership, and can be exclusive or non-exclusive and limited by territory, duration and purpose. Without a written assignment you likely hold a licence at best, which complicates selling the business or the code later.
No. Payment settles the invoice, not the copyright. Ownership moves only through a written assignment signed by the rights holder, or automatically under employment law if the developer was a true employee. Paying in full and receiving the repository gets you the files, not legal title to them.
It should assign copyright and, where permitted, waive moral rights; list the deliverables; cover work done by subcontractors; and state when assignment takes effect, on payment or on creation. Add a fallback licence in case the assignment fails, plus a warranty that the code does not infringe third-party rights.
In many jurisdictions work created by an employee in the course of their duties belongs to the employer automatically. Contractors usually retain copyright, so an assignment is required. Side projects outside an employee's duties and all contractor work need separate written terms. Verify the position under local employment law.
Your own code stays yours, but dependency licences impose conditions. Permissive licences such as MIT or Apache-2.0 generally require attribution and notice retention. Copyleft licences such as GPL can require releasing derivative source under the same terms. Run a software composition analysis scan before shipping or selling.
Check the signed contract for an assignment, then confirm the repository, domain, cloud accounts and credentials sit in your name rather than the developer's. Review commit history and contributor identities, and confirm subcontractors signed over their work. A short legal review of the documents usually costs less than a dispute.
If an assignment was signed, ownership already sits with you and the closure changes nothing. If it was not, the rights may pass to an insolvency practitioner or the founder's estate, and getting a signature becomes difficult or impossible. That is the practical reason to settle ownership at contract time.
Mostly legal time: tracing contributors and subcontractors, reviewing old contracts, drafting confirmations or a retroactive assignment, and clearing dependency licences. Scope depends on how many parties must sign and how old the work is. Getting the assignment clause right at the start costs far less.
Typical failures are no written assignment, an assignment naming the wrong legal entity, missing subcontractor sign-off, and unsigned change orders. The symptom surfaces at due diligence, funding or acquisition. Fix it by tracing every contributor and deliverable back to a signed document, then obtaining written confirmations.