Who owns the code: IP and license rights in custom development

Reference article · 6 min read

When an agency pays for software, staff often assume the agency owns it. The contract usually says something more complicated. A typical custom development or configuration project produces a mix of newly written code, vendor tools that existed before the project started, open source libraries under their own licenses, and content the agency supplied. Each category carries different rights, and the contract decides which ones transfer outright, which ones are licensed, and which ones the agency never receives at all.

The practical question is not philosophical. It is whether, several years from now, the agency can modify the system, move it to a different host, hand it to a different firm, or share it with a peer jurisdiction without asking permission or paying again. Fixing the language before award costs far less than renegotiating after the system is in production and the agency has no leverage.

Three arrangements that sound alike and are not

Work made for hire. A concept from federal copyright law under which the commissioning party is treated as the author from the start. It applies only to work by employees within the scope of employment, or to certain categories of specially ordered work covered by a signed agreement. Custom software does not always fit those categories cleanly, so a clause that relies on this phrase alone can leave ownership unsettled.
Assignment. The vendor transfers all right, title, and interest in the deliverables to the agency, including copyright and any patent rights, and agrees to sign whatever documents are needed to perfect the transfer. This is the more dependable mechanism, and good clauses pair it with the work made for hire language as a backstop rather than relying on either one alone.
License to the agency. The vendor keeps ownership and grants the agency rights to use the work. This is normal and often unavoidable, but the adjectives carry the value. A license worth having is perpetual, irrevocable, non-exclusive, worldwide, royalty-free, and transferable to successor agencies, and it includes the right to modify, create derivative works, and let third-party contractors exercise those rights on the agency's behalf.

Vendors frequently ask for a license back to themselves after assigning deliverables. That is often reasonable, since it lets them reuse generic routines. Read it for exclusivity and for any term that would let the vendor resell the agency's distinctive business logic.

Why pure ownership is rare

Almost every modern system sits on top of things the vendor did not write for the agency. Commercial platforms, the vendor's own reusable frameworks, and open source packages all arrive with their own terms. A vendor cannot assign what it does not own, and it will not assign the framework it uses on every project. The realistic goal is complete ownership or a strong license for the project-specific work, plus a durable license to the pre-existing material that is embedded in or required to run the deliverables.

Open source deserves separate attention. Ask for a component inventory listing each package, its version, and its license, refreshed at delivery. Some copyleft licenses create obligations when software is distributed, which matters if the agency plans to share the system with other jurisdictions or publish it. Separately, source code in agency hands may become subject to public records requests. Exemptions for software, security details, and trade secrets vary by state and change over time, so confirm the current rule with counsel before promising a vendor confidentiality the agency cannot deliver.

Name the deliverables you actually need

Ownership language is only as good as the definition of what it covers. Custom code is the easy part. The pieces agencies miss are the ones that make the system usable.

Configurations, workflow definitions, business rules, and form layouts built inside a commercial product
Report definitions, queries, dashboards, and extract logic
Interfaces and integrations, including field mappings and transformation rules
Data models, schemas, and migration scripts, plus the agency's data in a documented, non-proprietary export format
Build, deployment, and infrastructure-as-code scripts, along with test cases and test data
Documentation: administrator guides, runbooks, architecture diagrams, and as-built records

Require delivery on a schedule tied to milestones rather than a single handoff at closeout. Code delivered only at the end tends to arrive without build instructions. Where the vendor retains ownership of a hosted platform, consider a source code escrow with defined release conditions, and recognize its limits: escrowed code without dependencies, build tooling, and documentation is difficult to use.

The license you need to hire a different firm

Many disputes surface at recompete, not at delivery. The agency owns or licenses the code but cannot practically give it to anyone else. Look for the specific rights that make a successor possible: the right to disclose deliverables to another contractor under confidentiality, the right to have that contractor modify and maintain them, and the right to keep using them after the contract ends for any reason, including termination for convenience.

Also check what sits around the license. Transition assistance obligations should be written as duties with deadlines, not as future goodwill. Administrative credentials and hosting accounts should be in the agency's name or transferable. Restrictions on reverse engineering should carve out the work needed for interoperability and maintenance.

Indemnity for third-party infringement claims

If someone later claims the delivered software infringes a patent, copyright, or trade secret, the agency should not be defending that claim alone. A workable clause requires the vendor to defend and indemnify against third-party infringement allegations arising from the deliverables, expressly including open source components, and to fund the remedy if a claim succeeds: procure the right to continue using the software, replace or modify it so it no longer infringes, or refund amounts paid.

Two details matter in the public sector. Liability caps and limitations on consequential damages often swallow the indemnity, so state clearly whether the infringement obligation sits outside the cap. And in many states the attorney general controls litigation involving the state, so conditioning the clause on applicable law and preserving the agency's right to participate in its own defense keeps the provision enforceable.

Questions to ask before award

Which deliverables will you assign, which will you license, and what specifically stays yours?
What pre-existing components are required to run what you build, and what happens to our license to them if we stop buying your services?
Will you provide a full open source inventory with licenses, and confirm none of them restrict how we intend to use or share the system?
Can we give the source code and documentation to another contractor to maintain, and will you say so in writing?
What exactly transitions to us at contract end, in what format, and by when?

Have counsel review the intellectual property, indemnity, termination, and transition clauses together. They interact, and a strong ownership clause undercut by a weak transition provision still leaves the agency stuck. HQT builds and maintains custom software for state and local agencies and works within the ownership and licensing terms each agency sets.

Frequently asked questions

Does the government automatically own software a contractor builds for it?

No. Ownership follows the contract, and in the absence of clear language the developer generally retains copyright in what it writes. State and local agencies are not covered by federal acquisition data rights rules, so each jurisdiction sets its own terms. If the contract does not expressly assign ownership or grant a broad license, the agency may end up with only the limited right to use the software as delivered.

What is the difference between work made for hire and an assignment of copyright?

Work made for hire treats the hiring party as the original author, but it applies only in defined situations and does not always fit commissioned software. An assignment is a transfer of rights from the vendor to the agency after the work is created, and it works regardless of whether the work for hire categories apply. Well drafted contracts include both, using the assignment as the reliable mechanism and the work for hire language as a secondary basis.

Can a vendor keep ownership and still give the agency what it needs?

Often yes. A perpetual, irrevocable, non-exclusive, royalty-free license that includes the right to modify the software, create derivative works, and let other contractors do that work on the agency's behalf delivers most of the practical benefit of ownership. The terms to scrutinize are duration, whether the license survives termination for any reason, and whether it can be transferred to a successor agency.

Who owns configurations, reports, and integrations built inside a commercial product?

That depends entirely on how the contract defines deliverables. Configurations, report definitions, workflow rules, and interface mappings are frequently left out of ownership clauses even though they represent much of the agency's investment. List them explicitly as deliverables the agency owns or holds a broad license to, and require them to be delivered in an exportable, documented form rather than existing only inside the vendor's environment.

What should an infringement indemnity cover in a software contract?

It should require the vendor to defend and indemnify the agency against third-party claims that the deliverables infringe a patent, copyright, or trade secret, including claims arising from open source components. It should also fund a remedy if a claim succeeds, such as obtaining the right to keep using the software, replacing it, or refunding what was paid. Check whether the liability cap applies to this obligation, and confirm the clause fits your state's rules on who controls litigation involving public agencies.