Is a work for hire agreement enough on its own to give the client ownership of software?

In the US, often not. The statutory category of specially commissioned works made for hire is a short list and software is not obviously on it. That is why competent agreements add an assignment clause as a fallback. In the UK there is no equivalent category and assignment is the mechanism.

Can I use a generic work for hire template for a software project?

You can, and most of them are written for photographers and illustrators. They tend to lack the assignment fallback, the background IP carve-out, and any treatment of tooling, which are the three things that matter most for code.

Should assignment be conditional on payment?

From the developer's side, yes, and it is a reasonable ask. If ownership transfers only on payment in full, an unpaid final invoice means the client never acquired the code, which is more leverage than a collections letter.

What does the developer keep under a work for hire agreement?

Whatever the agreement carves out. With no carve-out, potentially nothing, including libraries you brought with you. A background IP clause and a licence back are the two clauses that preserve something.

Does signing a work for hire agreement affect whether I can license that code later?

Completely. Code assigned to a client under a work for hire agreement is the client's. It cannot be submitted for licensing by the developer under any circumstances, and doing so would breach the ownership warranty.

Work for hire agreements for software: the five clauses that matter

The templates that rank for this query were written for freelance photographers. They work fine for photographs. For software they are missing the three clauses that decide anything, which is how developers end up unsure, years later, whether they own their own work.

This is not legal advice. It is what the document needs to contain and why. Sample wording is illustrative and should be reviewed by someone qualified in the relevant jurisdiction before it goes in a contract.

The problem with the phrase

In US copyright law, “work made for hire” is a defined term with two branches. Work by an employee within the scope of employment, and specially commissioned work that falls into one of a short list of categories and is agreed in writing to be a work made for hire.

Software is not on the list. It can sometimes be shoehorned in, as a contribution to a collective work or a compilation, and sometimes it cannot. Which means an agreement that says only “this is a work made for hire” may not achieve what both parties assume.

The fix is standard: say it is a work made for hire, and add that if it is not, the developer assigns all rights instead. That second half is the clause that actually moves ownership, most of the time. The distinction is covered more fully in work for hire versus license.

In the UK and most of the Commonwealth, there is no statutory work made for hire category for commissioned work. Assignment is the only mechanism.

The five clauses

work for hire agreement, software
  │
  ├── 1. the deliverables ───────► what exactly is being made
  ├── 2. work made for hire ─────► the designation
  ├── 3. assignment fallback ────► the clause that actually works
  ├── 4. what you keep ──────────► background IP, licence back
  └── 5. when it transfers ──────► on payment, not on creation

1. Define the deliverables

Everything downstream refers to this. Be specific: the application, its source, its documentation. Say what is excluded: build tooling, scripts, infrastructure definitions, and libraries that predate the engagement, unless you intend to assign those too.

Illustrative wording: “Deliverables” means the software application described in Schedule 1, including its source code and documentation, but excludes Developer’s Background IP and any general-purpose tools, scripts, and libraries not created specifically for Client.

2. The work made for hire designation

Short, and include it for the cases where it applies.

Illustrative wording: To the extent permitted by law, the Deliverables are specially commissioned and shall be considered works made for hire, and Client shall be the author and owner of all copyright in them.

3. The assignment fallback

The clause that does the work. Without it, clause 2 may achieve nothing.

Illustrative wording: To the extent any Deliverable does not qualify as a work made for hire, Developer hereby assigns to Client all right, title and interest in and to that Deliverable, including all copyright, effective upon Client’s payment in full of the fees under this Agreement.

Notice the last phrase. It belongs in clause 5 as well and it is worth repeating.

4. What the developer keeps

Two sub-clauses. A generic template has neither.

Background IP. Anything you owned before the engagement or developed outside it stays yours, with the client receiving a licence to whatever is embedded in the deliverable.

Illustrative wording: Developer retains all rights in Background IP. Developer grants Client a perpetual, non-exclusive, royalty-free licence to use Background IP solely as incorporated in the Deliverables.

Licence back. The right to keep using what you assigned. Weak versions cover skills and know-how only, which is close to meaningless. Strong versions let you reuse components.

Illustrative wording: Client grants Developer a perpetual, non-exclusive, royalty-free licence to use general-purpose components of the Deliverables that do not contain Client’s confidential information, for any purpose.

┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐
│                                                                      │
│  Private, finished, owned by you: $500+ each to AI labs.             │
│                                                                      │
│  [ See what my repos are worth ]                                     │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

5. When ownership transfers

On payment in full, not on creation. This is the single most useful sentence a developer can get into an agreement, and clients rarely refuse it once they understand it applies only if they do not pay.

Illustrative wording: Ownership of the Deliverables transfers to Client upon receipt by Developer of payment in full. Until then, Client has a non-exclusive licence to use the Deliverables for evaluation only.

What developers should push back on

“All intellectual property created during the term.” During the term, not under the engagement. That reaches your weekend project. Limit it to work performed under the agreement.

A work made for hire clause with no assignment fallback. Leaves both sides less certain than they think.

Assignment on creation with no payment condition. You have handed over the asset before being paid for it.

No background IP clause. The library you have carried between eleven projects is now, arguably, the client’s.

A licence back that covers only “skills, knowledge and experience”. Nobody could take those from you anyway. Ask for components.

What clients actually need

Ask what they intend to do with the software. The answer, almost always: run it, change it, and not lose it if you disappear.

A broad, perpetual, transferable licence delivers all three and leaves the developer with an asset. Full ownership delivers the same three and costs the developer everything. Clients ask for ownership because the template asks for ownership, not because anyone identified a need. It is worth having the conversation before signing rather than after.

If a client genuinely does need ownership, that is a legitimate position. Price it as the sale of an asset, because that is what it is.

Why this decides what you can license later

Everything on this site about licensing code to AI labs rests on one condition: you own the code or hold the right to license it. Code assigned under a work for hire agreement is the client’s, entirely, and offering it would breach an uncapped ownership warranty.

Code retained under a background IP clause, or reusable under a licence back, may be a different matter. And code from engagements where a plain services agreement was signed with no IP language at all often leaves more with the developer than anyone expected.

Sorting your past engagements into those three piles is the exercise that decides which repositories are yours, and it only needs doing once. The method is in who owns the code you wrote for a client, and what rules a repository out entirely is in what disqualifies a repo.

What should a work for hire agreement for software say?