Who Owns the Code? Founders, Employees, Contractors and Agencies

Most owners of old code own less, or more, than they think. The short version: code your employees wrote as part of their job usually belongs to the company; code you wrote yourself before the company existed usually belongs to you personally; and code written by freelancers, contractors or an outside agency usually belongs to them unless they signed a written assignment. That last group is where most problems sit, and it is usually fixable.

This is general information, not legal advice. Ownership turns on your contracts and your country’s law, so for your specific case, ask a qualified lawyer.

Why does ownership matter before anyone talks about value?

You can only sell what you own. A buyer of source code is buying the copyright in it, and a clean sale needs a clear line from the people who wrote each part to the person or company signing the deal. That is why “the seller owns the rights or can sign for the company that does” is one of the conditions we check, and why it appears on our methodology page.

The good news is that copyright does not need paperwork to exist. The US Copyright Office says your work is protected “the moment it is created and fixed in a tangible form”, and the Berne Convention makes protection automatic without any formality. So the question is never “is it protected?”, only “who holds it?”

Who owns code written by employees?

In the three regions most of our sellers come from, the default rule points the same way: the employer.

In the US, a work made for hire is defined in part as “a work prepared by an employee within the scope of his or her employment,” and for such a work “the employer or other person for whom the work was prepared is considered the author.” The UK and EU reach a similar result by different routes. The EU directive also protects programs “as literary works,” so software is treated much like a book.

Three details catch people out. First, “within the scope of employment” matters: a developer who built a side project at weekends on their own laptop may have a claim to it. Second, the label does not decide who is an employee: a long-term “contractor” may count as one, and a person on payroll may not, depending on the real relationship and local law. Third, the rule can be changed by contract, in either direction, so read the employment agreements you actually signed. In much of the EU, authors also keep personal “moral rights” (such as being named as the author) that cannot be sold; these rarely block a sale of the economic rights, but a lawyer will know how your country treats them.

Who owns code written by the founders?

Founders are often in a gray zone. A founder who wrote the first version before the company was incorporated was not an employee at the time, so the default rule is that copyright “vests initially in the author”, which means the founder personally.

Most funded startups fixed this early with a founder IP assignment, often signed at incorporation or at the first investment round. If you have one, the company owns that early code. If you never signed one, the early code may still belong to each founder who wrote it. For a sale, that is usually simple to resolve: the founders sign a short assignment to the company, or sign the sale agreement directly alongside it.

Co-founders who left on bad terms are a harder case. Check what they signed when they left. Many leaver agreements include an IP clause.

Why is contractor code the most common gap?

Because the employee rules do not reach it. In the US, a commissioned work counts as work made for hire only if it falls in one of nine listed categories (things like a contribution to a collective work, a translation or a test) and both sides agree in a signed writing. Software is not one of the listed categories. So code from a freelancer or an outsourced team is usually owned by the person or firm that wrote it, unless they signed an IP assignment.

The UK and EU rules above also cover employees only. An outside developer is not your employee, so the default does not help you there either.

Transfers have to be in writing. US law says a transfer of copyright is not valid unless it is in writing and signed by the owner, and UK law says an assignment “is not effective unless it is in writing signed by or on behalf of the assignor”. An email saying “sure, it is yours” may not be enough. A paid invoice is not an assignment.

What about code from an outside agency?

The same logic applies, often with a better outcome. Most agency contracts include an IP clause that transfers ownership of the finished work to the client once the invoice is paid. Look for words like “assigns,” “intellectual property,” “deliverables” and “upon full payment.”

Watch for two common exceptions. Agencies often keep ownership of their own pre-existing tools and libraries and give you a license to use them, and some contracts transfer ownership only of the “deliverables,” not of internal code. If you are an agency yourself and wondering which of your own code you can sell, our guide to agency and freelancer code covers the other side of this question.

How do you check ownership of an old codebase?

You do not need a law firm to do the first pass. Work through it in this order:

1. List who wrote the code. Your git history shows every author. Run a contributor summary on GitHub or with git itself and note each name.
2. Sort each person into a group. Founder before incorporation, founder after, employee, contractor, agency.
3. Find the paperwork for each group. Founder IP assignments, employment contracts, contractor agreements, agency statements of work.
4. Mark the gaps. Anyone with no signed document that assigns their work.
5. Size the gaps. Use git to see how much of the code each gap person wrote. A contractor who fixed three CSS bugs is a very different case from one who wrote the backend.

Note that open-source libraries inside your repository are a separate question: they stay under their own licenses, and nobody needs to own them for you to sell the code your team wrote. Our guide on open source inside your codebase explains that part.

How are ownership gaps usually fixed?

The usual fix is a short written assignment, signed now, covering past work. Many former contractors sign readily, because they were paid and the product is gone; some ask for a small payment for their time, which is reasonable. Keep the document short but complete: the project name, the period, a statement that all rights in the code they wrote are assigned (including any claims for past infringement), a waiver of moral rights where the law allows it, and a signature. Have a lawyer draft it, because a document that is too narrow can leave the gap open.

If someone cannot be reached, the options depend on how much they wrote. A small, self-contained part can sometimes be left out of a sale. A core part needs a lawyer’s view before any agreement is signed. If the company itself no longer exists, ownership may have passed elsewhere entirely, which our guide to selling code after dissolution or liquidation covers.

When you do sell, the source code purchase agreement will ask you to confirm ownership in writing, in what is called a warranty. That is why sorting this out first protects you as much as the buyer. Again, this is not legal advice, and a qualified lawyer should review any assignment or warranty you sign.

What to do next

• Pull the list of authors from your git history and sort them into founders, employees, contractors and agencies.
• Find the signed document for each group, and note any gaps with how much code they cover.
• Once you know where you stand, send us a few details for a free code valuation; ownership questions are discussed on the call before any code is shared.