Who Owns the Code? Copyright in Software Development

When you hire a contractor to build your product, you may not own what they create. Here's how copyright ownership really works in software.

Founders are often surprised to learn that paying for software does not automatically make them its owner. Under copyright law, the default rule is frequently that the creator — not the person who pays — owns the work. For companies whose entire value rests on their software, that gap between what you assume you own and what you actually own can be existential. It usually stays invisible until the moment it matters most: a financing, an acquisition, or a dispute with the very person who wrote the code.

Employees Versus Contractors

The distinction that trips up most young companies is the one between employees and independent contractors. Work created by an employee in the ordinary course of their employment generally belongs to the employer. Work created by an independent contractor, however, usually belongs to the contractor unless there is a written assignment transferring it, regardless of who paid for it. Many startups build their first product with freelancers, agencies, and part-time collaborators precisely because it is fast and affordable, and then discover, often years later, that the people who actually built the product still hold the rights to it.

Get the Assignment in Writing

The fix is straightforward, but it must be done deliberately and, ideally, early. Every contractor, freelancer, agency, and collaborator should sign a written agreement that assigns copyright in everything they create for you and, where the law recognizes them, waives their moral rights. This should be in place before work begins, not negotiated after a relationship has soured or a deal is on the table. Retroactive assignments are possible, but they hand leverage to the other side: a contractor who realizes you need their signature to close a round is in a very different bargaining position than one signing a standard agreement on day one.

Open Source and Third-Party Components

Modern software is assembled, not written from scratch. Almost every product incorporates open-source libraries, third-party APIs, and off-the-shelf components, each carrying its own licence. Some open-source licences are permissive and ask little of you. Others are far-reaching and can impose obligations on the code you combine with them — including, in some cases, requirements to disclose your own source. Incorporating the wrong component in the wrong way can quietly attach conditions to the software you thought was entirely yours. A clear-eyed ownership and licensing review maps exactly what you own outright, what you license from others, and what obligations travel with each dependency.

Mind the Pre-Company Gap

Some of the most valuable code a startup owns was written before the startup legally existed. A founder tinkering on a prototype in the evenings, two co-founders building a first version in a shared repository, an early collaborator who drifted away before anything was formalized — each of these can create ownership that never quite made it onto the company's books. When the company is later incorporated, the rights in that early work do not automatically transfer to it; they stay with the individuals who created them until a written assignment moves them across. This is why founder assignment agreements, signed at or near incorporation, are a standard part of getting a company's house in order.

The same logic applies when a co-founder leaves. A departing founder who contributed code, designs, or documentation still holds rights in that work unless they have assigned it, and a clean, well-documented separation is far easier to arrange while the relationship is amicable than after it has broken down. Closing the pre-company gap early removes a category of risk that is otherwise easy to forget until it resurfaces at the worst possible moment.

Why Clean Ownership Matters

Clean intellectual property ownership is one of the first things investors and acquirers examine, and for good reason. A company that cannot demonstrate an unbroken chain of title to its core technology is a company whose central asset is uncertain. Diligence that uncovers unassigned contractor work, undocumented open-source use, or ambiguous joint-development arrangements can reduce a valuation, delay a closing, or unwind a deal entirely. Establishing ownership early turns what could become a deal-breaker into a non-issue that never even reaches the negotiating table.

By SRM Intellectual Property Law — SRM Insights