developer.law / Knowledge

Work for hire vs. code licensing in 2026

The client paid, so the client owns it — right? Not by default, and not because the contract used the words "work for hire." Here's the structure that actually transfers ownership, and the one that keeps your toolkit yours.

A key whose head is cut with a code bracket, illustrating who holds the rights to the code

Who owns the code you write for a client?

Under U.S. copyright law, you own the code the moment you write it. That is the default rule, and it does not change because a client hired you, paid a deposit, or called the arrangement a "work for hire" in an email or a one-line contract clause.

Ownership transfers away from you only through one of two mechanisms: a statutory work-made-for-hire relationship under 17 U.S.C. § 101, or an express written assignment that you sign. A license is a third option entirely — it leaves ownership with you and grants the client defined rights to use the code.

Each of these three structures carries very different consequences for what you can do with the code afterward, whether you can reuse it on your next project, and what leverage you have if the client stops paying. Knowing which one is actually in your contract, not which one your client assumes is in your contract, is the single highest-leverage thing you can check before you write a line of code. For the underlying concepts this guide builds on, start with what IP is and what background technology is.

Why "work for hire" almost never applies to you as a contractor

The phrase "work made for hire" shows up in nearly every template contract a client will hand you, and in most of those contracts, it does nothing.

Under 17 U.S.C. § 101, a work only qualifies as made for hire in two situations. First, it is created by an employee within the scope of employment — which you are not, if you are an independent contractor. Second, it is specially commissioned work that fits into one of nine narrow statutory categories: things like contributions to a collective work, parts of a motion picture, translations, and compilations. Custom software is not on that list.

The U.S. Supreme Court settled the employee-versus-contractor line in Community for Creative Non-Violence v. Reid, using common-law agency factors — not the label in the contract. That cuts both ways. A client cannot make you an "employee" for copyright purposes just by controlling how, when, and where you work, but they also cannot make a work-for-hire clause valid just by writing it into the agreement if you are genuinely independent and the deliverable is not one of the nine statutory categories.

Work for hire, assignment, or license: which structure protects you?

The three ownership frameworks look similar on paper but produce very different outcomes for you as the developer, especially around reuse rights and what happens if a client stops paying.

Factor	Work Made for Hire	Copyright Assignment (Conditional)	Perpetual License
Who owns the copyright	Client, from the moment of creation — if the statutory test is even met	You create it; ownership transfers to the client only when a defined trigger is met (typically full payment)	You retain ownership permanently
Your right to reuse the code	None, unless you negotiate a license-back	None after the assignment vests, unless you carve out pre-existing IP in a background IP schedule	Full — you can reuse the code in every future project
Your leverage if the client does not pay	Minimal, if work-for-hire genuinely applies — the client may argue ownership arose at creation	Strong — you retain title until the payment trigger is met, giving you a copyright claim, not just a contract claim	Strong by default — you own the code, and the license can be structured to terminate on nonpayment
Risk if the clause is ambiguous	High — most contractor arrangements do not actually qualify, so the clause may be legally empty	Low, if drafted correctly with a specific trigger and a fallback assignment	Medium — scope of permitted use must be defined precisely or disputes arise over modification rights

Most practitioner-grade dev contracts today use a hybrid: work-for-hire language for any deliverable that happens to qualify under the statute, paired with an express conditional assignment for everything else, and a background IP schedule that keeps your reusable libraries out of the transfer entirely. This is the structure developer.law generates by default for every agreement.

The ownership mistakes that cost developers the most

Assuming payment equals ownership transfer. You may believe — and your client almost certainly believes — that a paid invoice transfers copyright the way a closing transfers title to a house. It does not. Payment settles a debt; it does not, by itself, move ownership. A written assignment is the only mechanism that does that. If yours is missing or defective, you may still hold the copyright even after the client has paid and deployed the product, which sounds like an advantage until you realize it means your contract failed to do what both sides intended.
Signing a broad assignment clause that swallows your toolkit. A clause that assigns "all results and proceeds" with no carve-out can give a client a colorable claim over the authentication modules, testing frameworks, and internal tools you built before this engagement and plan to reuse on the next one. Sign this without a background IP schedule, and you have effectively sold your professional toolkit along with the custom deliverable — for one client's fee.
Relying on a work-for-hire clause that does not apply to you. If the deliverable is custom software and you are a genuine independent contractor, the statutory criteria for work-for-hire status are almost never met. A clause that says "work for hire" without a fallback assignment can leave the ownership question genuinely unresolved.
Losing your leverage the moment you deliver. Without a conditional assignment clause, a developer who ships a completed project and then goes unpaid has limited contract remedies and may still be contractually required to hand over the code. The stronger position: structure the assignment so title does not pass until full payment clears, which gives you a property-law remedy, not just a breach-of-contract claim.
Incorporating open-source code without disclosing it. If you build GPL-licensed components into a proprietary deliverable without telling the client, you may be creating a copyleft obligation that could force the client to open-source the whole combined work — a problem that tends to surface at the worst possible time, during a funding round or acquisition, and lands back on you.

developer.law's agreement generator builds in a conditional assignment tied to payment, a background IP schedule, an open-source disclosure requirement, and a license grant for any background IP incorporated into the deliverable — so these five problems are addressed before you sign, not after a dispute starts.

The clauses that actually protect your code and your payment

A contract that protects you does not need to be long. It needs these provisions, specifically.

A conditional assignment clause tied to payment, not delivery or acceptance. Copyright in the deliverables should vest in the client automatically upon receipt of full payment — not at delivery, and not at "acceptance," which is a squishier trigger a client can use as leverage. If a client deploys the software without paying the final invoice, they are using your intellectual property without a license. That is a copyright infringement claim, not just an unpaid invoice.
A background IP schedule that names your assets. List your pre-existing code, frameworks, libraries, authentication modules, API wrappers, and internal tools by name in an attached schedule. State that these remain your property and that the client receives only a non-exclusive, perpetual, royalty-free license to use them as incorporated in what you delivered — not a right to extract, modify, or sublicense them independently.
An open-source disclosure requirement, done before you sign. Disclose every open-source component in your deliverable and the license governing it before or at signing. Prohibit incorporation of copyleft components — GPL, AGPL — without written client approval obtained in advance. This protects you from liability for a surprise the client did not agree to, and protects the client from inheriting an obligation they did not know about.
A fallback assignment for anything that is not statutory work-for-hire. Because work-for-hire status is uncertain for nearly all software deliverables, include an irrevocable assignment of all right, title, and interest in anything that does not qualify — on the same payment trigger. This is the clause that closes the statutory gap the work-for-hire recital leaves open.
A termination-for-nonpayment clause. This lets you revoke any license you granted pending the assignment if the client stops paying, converting a stalled invoice into an enforceable IP claim instead of a waiting game.
A cooperation clause that survives termination. If the client later wants to register the copyright or perfect the assignment with the U.S. Copyright Office, they may need you to sign additional documents — sometimes years later. A cooperation clause obligates you to do that without reopening the whole agreement.

How developers structure ownership in practice

Protecting payment on a large, milestone-based build. If you are taking on a client with a history of scope creep or slow payment, use a milestone-based schedule with staged assignment triggers: copyright in each completed module vests in the client only upon receipt of payment for that milestone. Unpaid milestones remain your property. That gives you a property-law remedy for nonpayment, not just a breach-of-contract claim.
Protecting a shared framework across multiple clients. If you build client work on top of a proprietary framework you reuse across engagements, structure it as a partial assignment — the client owns the custom code built specifically for them, and receives a perpetual, non-exclusive license to the underlying framework as incorporated in their product. You retain ownership of the framework and keep using it on every other engagement.
Licensing a productized component instead of assigning it. If you have built a proprietary tool — an analytics engine, a compiled library — that you license to multiple clients rather than building bespoke for one, use a perpetual license instead of an assignment. No single client owns the underlying code; each gets a non-exclusive right to use the compiled output, and you retain the ability to license it again.
Disclosing open-source risk before it becomes the client's problem. If your build uses an AGPL-licensed component you chose for performance reasons, disclose it before the project ships. That gives the client the chance to approve it, ask for a substitute, or get a commercial license — and it protects you from a claim that you hid a compliance risk.

Best practices for protecting your code ownership

Draft the IP clause before the first commit, not after something goes wrong. The assignment trigger, the background IP schedule, and the open-source disclosure requirement all need to be agreed before any code is written. Ownership is determined by what the contract says at the time of creation, not at delivery.
List your background IP by name, not by category. "Developer's pre-existing libraries" is too vague to enforce cleanly. Naming specific repositories, packages, or tools by version resolves a dispute before it starts.
Tie the assignment trigger to payment — not acceptance, not delivery. An assignment that vests on "acceptance" gives the client leverage to withhold acceptance as a negotiating tactic. An assignment that vests on delivery gives you no leverage at all once the code is handed over. Payment is the cleanest trigger because it is binary.
Run your own open-source audit before you sign anything about it. If you are going to represent that your codebase is clean, know that it actually is before you sign the disclosure requirement — not after.
Use a license-back for background IP, not an assignment-then-license. The correct structure for code you bring to an engagement is to retain ownership and grant a license from the start — not to assign it away and then get a license back, which can carry different legal characteristics depending on how it is drafted.

What getting this right is worth to you

A real payment remedy, not just a lawsuit. A breach-of-contract claim for an unpaid invoice requires you to sue for damages and then collect a judgment. A copyright infringement claim — available when the assignment has not vested because payment was not made — is faster and more powerful. Statutory damages for willful infringement can be substantial, and you do not have to prove actual damages to seek them.
Your toolkit stays yours. If you reuse authentication modules, testing frameworks, API wrappers, and logging tools across every engagement, those are productive capital. A background IP schedule keeps a single client's broad assignment clause from stripping that capital out from under you.
You scale revenue instead of giving it away once. If you retain ownership of a productized component and license it to multiple clients, you are building a recurring revenue asset instead of a one-time fee — and the perpetual license model lets you keep licensing it indefinitely without any one client controlling it.

How developer.law builds this into your agreement

developer.law by Story LLP is built specifically for developers and agencies who need these protections without a bespoke legal engagement for every contract. The platform walks you through each provision in plain English: which deliverables might actually qualify for work-for-hire treatment, how to structure a conditional assignment that is specific and enforceable, how to draft a background IP schedule that holds up, and how to handle open-source disclosure in a way that protects you.

If you want to hold your code until you are paid, the platform generates a precise conditional assignment clause with a termination-for-nonpayment provision — a license-revocation remedy that applies before the assignment ever vests. You can specify your payment milestones and have the assignment trigger reflect your project's actual structure. You can list your background IP assets by name and have them appear in a formatted schedule attached to the agreement.

Solopreneur — $49/mo — a client agreement with the background-technology carve-out already drafted, so the libraries and tools you reuse on every engagement stay outside the assignment.
Consultant — $69/mo — the same protections plus subcontractor paper, so the IP your subcontractors create is assigned up to you before you promise it downstream to a client.
SMB — $99/mo — the full structure across unlimited clients and subcontractors, for agencies running many engagements against one background IP schedule.

Story LLP's attorneys designed the underlying clause library, and the platform makes it accessible at an affordable price point, without the cost or delay of a bespoke legal engagement for every new contract.

FAQs about work for hire and code licensing

Q: Does work for hire apply to me if I'm an independent contractor developer?

A: Rarely. Under 17 U.S.C. § 101, work made for hire for an independent contractor requires that the deliverable fit one of nine enumerated statutory categories and that both parties sign a written agreement to that effect. Custom software does not appear on that list. A contract that calls itself a "work for hire" agreement but does not meet these requirements does not transfer copyright — which means you may still own the code, and your client may not have what they think they paid for. developer.law addresses this gap with a belt-and-suspenders assignment clause that covers deliverables outside the statutory work-for-hire categories.

Q: Can I keep rights to my source code until the client pays in full?

A: Yes — this is one of the most effective protections available to you. A conditional assignment clause vests the copyright transfer only upon receipt of full payment. Until that trigger is met, you hold legal title to the deliverables. A client who deploys the code without paying the final invoice is using your intellectual property without a license, which is a copyright infringement claim, not just a breach of contract. developer.law structures the assignment trigger around your project’s specific payment milestones.

Q: How do I stop a client from claiming they own everything I built when they haven't paid?

A: Use a conditional assignment that ties ownership transfer explicitly to full payment, combined with a termination-for-nonpayment provision that lets you revoke any license granted pending the assignment. Without both clauses, a client may argue that a broad work-for-hire or assignment clause transferred ownership at creation or delivery, regardless of payment status. With both in place, you retain a property-law remedy, not just a contract claim.

Q: How do I keep ownership of the code libraries and tools I reuse across different clients?

A: Use a background IP schedule attached to and incorporated into the main agreement. List your pre-existing code, libraries, frameworks, and tools by name. State that those assets are excluded from the assignment and that the client receives only a non-exclusive, perpetual, royalty-free license to use them as incorporated in the delivered software — not a right to extract or sublicense them independently. developer.law's agreement generator prompts you to list your pre-existing assets before the agreement is finalized.

Q: What is a perpetual license and when should I use one instead of an assignment?

A: A perpetual license grants the client an indefinite right to use the delivered software without transferring copyright ownership to them. You retain all ownership of the source code, and the client receives authorization to use the compiled or delivered output under defined conditions. Use this structure when you are licensing a productized component, a proprietary framework, or code you will reuse across multiple clients — not when the client needs clean title for a fundraise or exit, since a license leaves your continued cooperation as part of their risk picture.

Q: What open-source obligations do I need to disclose to a client?

A: Any code you incorporate that is governed by a copyleft license — GPL or AGPL — carries obligations that can extend to the combined work. Under the GPL, distributing software that incorporates GPL-licensed code generally requires the combined work to be GPL-licensed with source available. The AGPL extends this to software users interact with over a network, which captures most SaaS applications. Disclose all open-source components before signing, and do not incorporate copyleft components without the client’s written approval — this protects you as much as it protects them.

Hold your code until you're paid.

Get an agreement with a conditional assignment, a named background IP schedule, and an open-source disclosure requirement already built in.

We're lawyers, remember? Please read this important note:

Story LLP is a law firm, and Story's lawyers built Aegis to deliver better, standard legal services at scale so founders can choose between top-tier specialized lawyers and standardized process automations that replicate those lawyers according to their needs and budget. By definition, a standardized process may not be perfect for you. Please review our Policies page to better understand the difference, as well as how we use AI and how we manage conflicts, privilege, etc.

As a law firm, we must screen clients for conflicts of interest, and we treat all correspondence with clients seeking legal advice as privileged and confidential to the maximum extent possible in consideration of any conflicts. However, Story's law firm or our Attorney Allies do not represent you or your company as your lawyer, do not have an attorney-client relationship with you or your company, and do not provide you with legal advice absent a formal Engagement Letter signed between you and the Story LLP law firm. Please don't confuse the free knowledge we offer on this site with legal advice for you.

Solopreneur — $49/mo Consultant — $69/mo SMB — $99/mo