Who Owns the Code You Write?

Ask ten developers who owns the code they wrote last week and you will get several different answers. The question stays theoretical until something forces it: someone quits and takes a tool with them, a weekend project starts earning, or a client stops paying while the repo is still on your machine.

Whose laptop you used does not, by itself, determine who owns the copyright, and neither does the repo being private. Ownership runs on rules most engineers have never read. If you work for yourself, the commercial side of this matters as much as the code, and we covered part of that in 7 Python skills that help freelancers get better clients.

Where copyright comes from

Under U.S. law, copyright generally arises automatically when original, copyrightable code is fixed in a tangible form, such as saved to a file. There is no registration step for ownership and no notice requirement. Two limits matter: saving a file does not make every element in it protectable, and copyright covers expression rather than the ideas, procedures or methods behind it.

For most developer engagements, two questions decide ownership: whether the code is a work made for hire, which settles who counts as author from the start, and whether the copyright has been assigned. On the second, 17 U.S.C. 204(a) says a transfer of copyright ownership is not valid unless it is in writing and signed by the owner of the rights, with transfers by operation of law excepted.

Employment sets the default

The U.S. Copyright Office describes a work made for hire as, among other things, work prepared by an employee within the scope of employment. Where that applies, the employer is the author unless the parties expressly agreed otherwise in a signed writing. Nothing needs to be signed for the default to operate, which is why "but I never signed anything" rarely helps. Whether you are an employee for this purpose depends on the actual working relationship rather than the label in the contract.

The argument, when there is one, is over scope:

• Code written against a ticket in the tracker, on company time, sits squarely inside it.
• An internal tool you wrote on a work laptop during work hours because it made your job easier, without being asked, very likely does too.
• A project in a different domain, on your own hardware, on your own time, is the open question, and your agreement plus your state's law decides it.

Side projects and the limits on assignment clauses

Many technology employers require an invention assignment clause, and a broadly drafted one appears to sweep up anything you create while employed. Several states cap how far it can reach. California's version, Labor Code section 2870, says an assignment provision does not apply to an invention the employee developed entirely on their own time without using the employer's equipment, supplies, facilities, or trade secret information. Two exceptions pull work back in: inventions that relate, at conception or reduction to practice, to the employer's business or its actual or demonstrably anticipated research and development, and inventions that result from work performed for the employer. Section 2872 requires employers with such clauses to give written notice of that limitation, and puts the burden of proof on the employee claiming it.

Read the exceptions before relying on the rule. If you work on payments infrastructure and your side project is a payments library, the "relates to the employer's business" exception works against you. The statute speaks in terms of inventions, so the copyright side still turns on the scope questions above. Other states have similar statutes, so check your own.

Hiring someone else to write it

This is where small teams fail to secure ownership. Payment alone does not transfer copyright. An independent contractor is not an employee, so the employee route to work made for hire is closed, and the commissioned route covers nine narrow categories that standalone software usually falls outside, and even then requires an express signed agreement. That leaves a written assignment, signed by the contractor, as the realistic path. Without one the contractor generally keeps copyright in their original contributions, and the client's permitted use depends on the license, express or implied.

Shops that bring in one contractor a quarter rarely have counsel on call, which is why legal platforms such as ConsumerShield keep service and contractor agreements next to NDAs and invoice forms. A template is a starting point, and the question to ask of any of them is whether it includes an effective assignment and separates three things usually treated differently: the deliverables created for you, pre-existing code the contractor brings along, and third-party components they pull in. That is the document you will be reading if the relationship ends badly.

What to check before you sign

1. What the assignment clause covers. Inventions only, or all works of authorship? Does it reach backwards to things you made before you started?
2. Whether there is a carve-out. List existing side projects in the disclosure schedule at signing, because doing it later looks like a reaction to a dispute.
3. Outside activity and moonlighting terms, which are separate from ownership. You can own your side project and still be fired over it.
4. For contract work, a signed assignment clause that states when ownership passes and what use is permitted before then. Tying the transfer to payment favors the contractor, and a commissioning business often wants it earlier.
5. Which dependencies and licenses are allowed, in the agreement or a written policy and in the review process.

The code you did not write

Dependencies are somebody else's copyrighted code, used under a license. Permissive licenses such as MIT and Apache 2.0 still require attribution, and copyleft licenses can impose obligations on what you distribute. Pasting a snippet from a forum into a proprietary codebase is the same problem in miniature.

Model output sits in a different category. The Copyright Office's report on copyrightability treats purely AI-generated material as unprotectable while human contributions to AI-assisted work can be protected. Separate questions arise about whether an output reproduces protected material and what the tool's terms allow.

Where disputes start

Ownership arguments almost never begin with the code. They begin with money, a firing, or a deal. By then some of the most useful evidence is what was written down at the start: the agreement, the commit history, and the hours. Later emails and conduct can matter too, but the early material is cheap to get right while everyone is still happy and expensive to reconstruct later.