Who owns the source code when you hire a developer

This question almost never gets asked at the right time. It gets asked eighteen months later, when the relationship with the developer has cooled and somebody wants to move the project elsewhere, or a buyer doing due diligence asks for a chain of title and nobody has one.

The uncomfortable part is that the answer is often not the one the person paying expects. Paying for work and owning the copyright in that work are two separate things, and only one of them happens automatically.

What work made for hire actually means

The phrase gets used as though it means "I paid for it, so it is mine". It has a much narrower meaning. The US Copyright Office sets it out in Circular 30, Works Made for Hire, and there are exactly two situations in which a work is made for hire.

The first is a work prepared by an employee within the scope of their employment. The second is a work specially ordered or commissioned, but only if it falls within one of nine listed categories and the parties expressly agree, in a written instrument signed by them, that it is a work made for hire.

When a work is made for hire, the circular says the hiring party "is considered the author and the copyright owner". Note what that means in reverse: when it is not made for hire, they are not.

The nine categories, and the word missing from them

Here are the nine categories a commissioned work must fall into: a contribution to a collective work, a part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas.

Read the list again. Software is not on it. Neither is source code, nor a computer program, nor a website. The list is closed, and a commissioned work that is not in one of those nine categories cannot be a work made for hire no matter what the contract says.

The circular is blunt about the arithmetic. A commissioned work qualifies only if it satisfies all four criteria: it falls in one of the nine categories, there is a written agreement between the commissioning party and the people who actually created the work, that agreement expressly says the work is a work made for hire, and it is signed by all parties. "If a work fails to satisfy any of these requirements, it is not a work made for hire."

So the work made for hire clause sitting in most development agreements, by itself, does not do what the person who signed it thinks it does. For software written by a contractor, it fails at the first of the four criteria.

What you hold without a written assignment

If the developer is an independent contractor and there is no assignment, the developer owns the copyright. You will usually hold an implied, non-exclusive licence to use what you paid for, which is enough to run the thing and not enough to stop the developer reusing it, sell it with the business, or transfer it cleanly to another team.

The fix is a copyright assignment, and the form matters. The Copyright Office's Circular 1, Copyright Basics states that any or all of the owner's exclusive rights can be transferred, but "the transfer, however, generally must be made in writing and signed by the owner of the rights conveyed or the owner's authorized agent".

The same page adds the detail that explains why so many people end up in the weak position by accident: "Transferring a right on a nonexclusive basis does not require a written agreement." A non-exclusive licence can arise from conduct. An assignment cannot. That asymmetry is the whole problem in one sentence.

Employee or contractor is not your label to assign

A common move is to decide that the developer is "basically an employee" and treat the first situation as settled. That is not how it is determined. Circular 30 notes that the Copyright Act does not define employee, employer or scope of employment, and that the Supreme Court held those terms are to be understood in light of agency law, relying on the general common law of agency rather than the law of any particular state.

The questions the circular lists are the ones that actually decide it, and they are mostly about control and economics rather than job titles:

• What skill was required, and who provided the space, materials and tools
• How long the relationship ran, and whether you could assign other projects
• Whether you could direct when and how long they worked
• How they were paid, whether you offered benefits, and whether you withheld taxes
• Whether the creator has their own business and could hire their own assistants

Read that list against a typical arrangement with an agency or a freelancer and the answer is usually clear. They brought their own tools, invoiced you, paid their own taxes, and have other clients. That is a contractor, whatever the working relationship felt like.

What to put in the contract, and when

Before the first invoice, not after the last one. A developer who has been paid in full and has moved on has no particular reason to sign anything, and that is the moment most people discover they need to.

• A present assignment of copyright in the deliverables, signed, not a promise to assign later
• Signed by the individuals who actually wrote the code, including the agency's subcontractors
• A clear carve out naming any third party or open source components and the licence each carries
• Whatever the developer is permitted to reuse, stated honestly rather than left to be argued about

That third point is where honesty serves you better than maximalism. No serious developer will assign you the copyright in their internal libraries, and demanding it either gets refused or gets agreed and then quietly ignored. Name what is yours, name what is licensed, and the document survives contact with reality.

Repository access is a separate question

Ownership and access get conflated constantly, and they fail in opposite directions. You can own the copyright and have no copy of the code. You can have full repository access and own nothing.

So treat them as two items on the same checklist. The organisation account should be in your name with your billing, you should be an owner rather than a collaborator, and the same goes for the domain, the DNS and the production environment. If a developer offboards tomorrow, the test is whether anything stops working or becomes unreachable, and that test has nothing to do with copyright.

This is the same category of decision as the rest of the commissioning questions worth settling up front. Whether to commission at all is covered in custom software versus off the shelf, decided in the right order, and how you pay for it in fixed price versus hourly software development.

It also matters more than people expect at the far end of a system's life. The options for an ageing codebase narrow sharply if you cannot establish who owns it, which is worth knowing before you get to when to rebuild versus refactor legacy software, and the ongoing cost of keeping it alive is in software maintenance cost after launch.

The honest limits

This note describes the United States framework, because that is where the rules are published clearly and where most commissioning agreements borrow their language from, including the phrase work made for hire. It is not the law everywhere. Several jurisdictions treat commissioned software differently, some give the commissioning party more by default, and moral rights are not assignable in a number of countries regardless of what the contract says. If your contract names a governing law, that is the law that decides, not this page.

It is also not legal advice, and the fact pattern does the work in disputes like these. Two arrangements that look identical in an email thread can land differently once someone examines who directed the work and how it was paid for. Before a transaction that depends on the answer, such as a sale or an investment round, have a lawyer in the relevant jurisdiction look at the actual documents.

One further detail from Circular 30, in case the question is about something that is genuinely made for hire: the copyright term runs 95 years from publication or 120 years from creation, whichever expires first, and the termination provisions that let authors claw back transfers after a few decades do not apply to works made for hire at all. That cuts both ways, and it is another reason the classification is worth getting right rather than assuming.