Free software development agreement template

Work made for hire does not give you the code

This is the most consequential misunderstanding in custom software, and it is written into a large number of free templates. US copyright law recognises two routes to a work made for hire. The first is a work prepared by an employee within the scope of employment. The second is a work specially ordered or commissioned, and 17 U.S.C. 101 lists exactly which kinds qualify: a contribution to a collective work, 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. Software is not on that list. So when a client commissions an independent developer to write an application, the work-made-for-hire route is simply unavailable, no matter how emphatically the contract says otherwise. Ownership stays with the developer unless the contract assigns it, and under 17 U.S.C. 204(a) that assignment has to be in a signed writing. Whether the developer counts as an employee is not decided by what the contract calls them either. In Community for Creative Non-Violence v. Reid (5 June 1989) the Supreme Court held that courts apply general common law of agency principles, weighing control over the manner and means of the work, who supplies the tools, how the person is paid and taxed, and roughly a dozen other factors, with no single one deciding it. Clause 7 of this template handles it the way careful software contracts do. It assigns first, and treats the work-made-for-hire language as a fallback that only operates where a deliverable happens to qualify. Read in that order, the clause works whether or not the categorisation is available.

The California trap in work-made-for-hire wording

If your developer is an individual in California, the words themselves carry a cost that has nothing to do with copyright. Two statutes attach to any contract in which the parties expressly agree that a commissioned work of authorship shall be a work made for hire.

• California Labor Code 3351.5(c) brings that person within the definition of "employee" for workers' compensation purposes. The commissioning party is expected to carry cover.
• California Unemployment Insurance Code 686 goes further and states that the ordering or commissioning party "shall be the employer of the author of the work for the purposes of this part", which pulls in unemployment insurance contributions.
• The practical result is that boilerplate meant to secure copyright can convert your contractor into a statutory employee for two state programmes, while doing nothing for the copyright question because software is not a qualifying category anyway.
• The fix costs nothing. Strike the work-made-for-hire sentence and rely on the assignment, which reaches the same ownership outcome. Clause 7 carries a bracketed drafting note saying exactly this, and Schedule 1 asks whether the developer is a California individual so the question gets raised before signing rather than after.
• California is the clearest example and may not be the only one. If your developer is an individual elsewhere, spend five minutes on that state's workers' compensation and unemployment insurance definitions before keeping the wording.

Deciding who owns what

Clause 7 makes you elect. Both options are legitimate and the right answer depends on what the client is really buying.

• Client owns, option (a). The normal choice for bespoke work built to a client's specification. The client gets the copyright in the deliverables on payment in full, which matters because it can then sell the business, license the software, or hire someone else to maintain it without asking permission.
• Developer owns and licenses, option (b). Common where a development shop is building something it intends to reuse or productise. The client gets a licence rather than ownership, and pays less for it. Say so plainly in the pricing conversation, because a client who discovers this at exit is going to be unhappy.
• Payment as a condition. Both options tie the transfer or the licence to payment in full. That is the developer's real security, and it is a fairer lever than withholding the source code, which clause 10 forbids.
• Background materials are separate. A developer who has spent years building internal libraries should not hand them over because they were used on one project. Clause 8 keeps ownership with the developer and gives the client a perpetual licence to whatever is embedded in the deliverable, which is what the client actually needs.
• Whichever option you pick, the developer's own personnel and subcontractors need to be under matching terms. Clause 15 requires it. A developer cannot assign what its own contractor never assigned to it, and this is a common gap in a chain of freelancers.

Open source is the risk nobody prices

Almost every modern application is assembled partly from third-party packages, and most of those licences are permissive and harmless. The problem is the small number that are not. A copyleft licence can require that software distributed with the component be made available in source form under the same terms, which for a client that intended to sell a proprietary product is a serious problem discovered at the worst possible moment, usually during diligence on a funding round or an acquisition. Disclosure solves this better than a blanket ban would. Clause 9 requires the developer to list every third-party and open source component in Exhibit B with its name, version and licence, and bans components carrying source-disclosure obligations unless the client consents in writing. That turns an invisible risk into a decision someone made on purpose. Exhibit B is deliberately a table with a consent column, because the useful artefact is a record of what went in and who agreed to it. An empty Exhibit B is itself a statement, and clause 11(b) makes the developer warrant that the deliverables are original except for what is disclosed there. The same disclosure logic now has to cover generative AI coding tools, and most free templates are silent on them. The contractual question is not whether the developer may use one. It is who carries the risk if AI-produced code turns out to reproduce someone else's licensed work. Clause 9 requires the developer to record in Exhibit B whether such tools were used and which ones, and it makes clear that the originality and non-infringement warranties in clause 11 and the indemnity in clause 17 apply to that output the same as to hand-written code. A developer who cannot stand behind what a tool produced should say so before signing.

Acceptance is where these projects actually fail

Disputes over custom software are rarely about ownership in the first instance. They are about whether the thing that got delivered was finished. An acceptance clause without objective criteria just relocates the argument.

• Write testable criteria into Exhibit A per milestone. "The client is satisfied" gives the client a veto and calls it a standard. Something a third party could run and get the same answer is.
• Set a review period and a consequence for silence. Clause 6 gives 10 business days and then deems the milestone accepted, which stops a project stalling because nobody signed anything off.
• Require rejections to be specific enough to reproduce. A rejection that says "it doesn't work" gives the developer nothing to fix and starts an argument instead of a correction.
• Close the scope-creep route. Clause 6 says a deliverable cannot be rejected for missing a requirement that is not in the acceptance criteria. That is a change order under clause 3, priced accordingly.
• Decide in advance what happens after repeated failure. Clause 6 has a bracketed election between the client terminating and recovering that milestone's fees, or the developer having to continue at its own cost. Pick one at signing, because negotiating it during a failed project is not realistic.
• Fill in the OUT OF SCOPE box in Exhibit A. Listing what is not included prevents more disputes than any other single line in these contracts.

If you are the developer rather than the client

The template is balanced, but most commentary on these agreements is written for the buyer. Some terms deserve your attention before you sign one, including a version of this one.

• Protect your background materials. Clause 8 does this, and it is the clause most often quietly deleted in a client's redraft. Without it, an aggressive ownership clause can be read to sweep in libraries you built over years and use on every project.
• Do not accept unlimited liability. Clause 18 caps it and carves out the usual exceptions. A cap at the fees paid is standard for development work, and an uncapped indemnity on a fixed-fee build is a bad trade at any price.
• Insist on client dependencies being written down with dates. Clause 5 exists because the most common cause of a missed milestone is a client who has not supplied access, test data or a decision.
• Tie the assignment to payment. Clause 7 does. It gives you real security for the fee, which withholding source code only appears to do.
• Push back on "time is of the essence" unless the schedule is genuinely realistic. Clause 2 offers it as an election, and agreeing to it turns a short delay into a material breach.
• Get the warranty period and its remedy bounded. Clause 11(e) is 90 days with a stated exclusive remedy in clause 12. An open-ended obligation to fix whatever the client dislikes is unpaid maintenance wearing a warranty label.
• If you use subcontractors, get assignments from them first. Clause 15 obliges you to, and you cannot pass on rights you never received.

This template, or a service agreement or SOW

These overlap and the right pick depends on what is being bought and who ends up owning the output. Use this one when someone is commissioning software that does not exist yet, and the questions of specification, acceptance and code ownership all need answering. Use a general service agreement when the work is a service being performed rather than an artefact being created and transferred, such as ongoing support, hosting or consulting advice. Use an independent contractor agreement when the relationship itself is the point and the deliverables vary from month to month. A statement of work is not an alternative at all: it is the technical annex that sits under a master agreement, and Exhibit A of this template is exactly that. A reasonable rule: if the argument you fear is about who owns the source code, you want this document. If the argument you fear is about hours and invoices, a service or contractor agreement is closer. For a long relationship with repeated projects, sign this once as the master and issue a new Exhibit A for each engagement rather than a fresh contract each time.

Source code, documentation and the developer disappearing

A client who owns the copyright but not a usable copy of the source is in a weak position, and this happens more often than it should. Clause 10 requires delivery of the source, the build and deployment scripts, the configuration and enough documentation that a competent developer could take over without help from the original one. Setting the delivery target as a repository the client controls, rather than a handover at the end, is the version that survives a relationship breaking down badly. Clause 10 also stops the source code being used as a bargaining chip in a fee dispute. That protection is deliberately paired with clause 7's payment condition and clause 19's termination rights, so the developer still has real remedies for non-payment. For larger engagements, or where the developer is a small shop and the software is business-critical, source code escrow with a third party is worth considering, released on defined trigger events such as insolvency or a sustained failure to support. This template does not include escrow terms, since they are usually a separate tripartite agreement with the escrow agent.

When to get a lawyer involved

A straightforward custom build between two US businesses is well covered by this template. Several situations are not, and the numbers involved usually justify advice.

• The software will process regulated data, including health information, payment card data, or personal data of EU or UK residents. Clause 14 is a starting point and those regimes need their own annexes.
• You are commissioning something that will be central to the value of your company. Ownership, escrow and diligence-readiness deserve real attention rather than a template.
• The developer is offshore or the parties are in different countries. Enforcement, tax and IP transfer formalities all change.
• The deal involves equity, revenue share, or the developer retaining a stake in the product.
• Patentable subject matter is likely. Copyright assignment does not cover patents, and the invention assignment and filing obligations need drafting.
• An existing codebase, prior developer or unresolved ownership history is involved. Chain of title problems get harder to fix over time, not easier.

A note on what this page is

This is a general-purpose template and general information, not legal advice. Software development contracts sit on top of federal copyright law, state contract law and sometimes state employment law all at once, and as the California example shows, wording that is harmless in one state can have consequences in another. Read it against your own situation and take advice on anything you are unsure about before signing.