Who Owns Code Written by a Contractor? IP Assignment Guide

Paying a contractor, receiving a ZIP file, or having administrator access to a GitHub repository does not by itself answer who owns the copyright in the code. Ownership, access, licensing, and delivery are separate issues. A sound agreement and a verifiable handoff have to address all four.

Legal note: This article provides general information about U.S. law and software contracting, not legal advice. Copyright, patent, employment, tax, and contract rules depend on the facts and jurisdiction. Have qualified counsel review the agreement for your project.

Last substantive review: August 2026.

The short answer under U.S. law

17 U.S.C. § 201 starts with the rule that copyright vests in the author. An employee's work created within the scope of employment may be a work made for hire, in which case the employer is treated as the author. An independent contractor is different. Unless the work qualifies under the narrower commissioned-work route or the contractor signs a valid transfer, the client should not assume it owns the copyright.

A copyright transfer generally must be in a writing signed by the owner of the rights, under 17 U.S.C. § 204. That is why a contractor agreement should contain an actual IP assignment drafted for the project, not only payment terms, confidentiality language, or a promise to deliver source code.

Ownership, access, license, and assignment

• Ownership means holding copyright or another defined intellectual-property right. For copyright, that can include rights to reproduce, modify, distribute, and authorize those acts, subject to statutory limits.
• Access means practical control of assets such as a repository, cloud account, deployment pipeline, or source-code archive. Access can exist without ownership, and ownership can exist while the owner lacks usable access.
• A license is permission to use rights that another party continues to own. It may be exclusive or nonexclusive and may be limited by purpose, territory, duration, transferability, or other terms.
• An assignment transfers ownership of specified rights from one party to another. The scope and timing depend on the signed language and applicable law.

17 U.S.C. § 202 makes the separation concrete: ownership of a copyright is distinct from ownership of the material object containing the work. In software terms, possession of a laptop, archive, or repository copy does not itself transfer copyright.

What copyright covers in software

The U.S. Copyright Office's computer-program guidance explains that copyright can protect copyrightable expression embodied in a computer program. It does not protect the underlying ideas, program logic, algorithms, systems, methods, or concepts. That distinction matters because a contract may need to address more than copyright: confidential information, data rights, trademarks, domain names, patentable inventions, and operational assets may require separate provisions.

Patent applications and patents have their own assignment rules. 35 U.S.C. § 261 provides for assignment by a written instrument. Counsel should decide whether invention-assignment, further-assurance, and recordation provisions are needed for the work.

Why work-made-for-hire language may not be enough

The statutory definition in 17 U.S.C. § 101 has two routes. The first covers a work prepared by an employee within the scope of employment. The second covers specially ordered or commissioned work only when it falls within one of nine listed categories and the parties sign a written work-made-for-hire agreement.

Computer programs are not named as a standalone category in that commissioned-work list. Some software deliverables may raise questions about a listed category or about whether a contributor is legally an employee, but a contract should not assume that adding the phrase “work made for hire” resolves the issue.

The U.S. Copyright Office's Circular 30 explains the employee and commissioned-work tests. In Community for Creative Non-Violence v. Reid, the U.S. Supreme Court used common-law agency factors to distinguish an employee from an independent contractor. A client's direction over the desired result does not automatically turn a contractor into an employee.

The practical response is an express assignment as a backstop, drafted by counsel for the deliverables and rights involved.

What an IP assignment should address

There is no universal clause that is right for every software engagement. A well-drafted agreement usually resolves these questions:

• Who is assigning? Identify the contracting entity and require the vendor to obtain rights from every employee, contractor, and subcontractor who contributes.
• What is being assigned? Define project deliverables and the covered code, documentation, designs, tests, configuration, infrastructure code, and other agreed materials.
• When does ownership transfer? State whether transfer occurs upon creation, payment, acceptance, or another event, and address partial payments and terminated work.
• Which rights are included? Copyright and patent rights follow different rules. Counsel should define the rights, territories, duration, and any further documents the parties must sign.
• What is excluded? Identify contractor background IP, third-party software, open-source components, standard tools, and client-supplied materials.
• What license accompanies an exclusion? If background IP is embedded in the product, the client may need a license broad enough to operate, modify, host, transfer, and support the product as intended.
• What representations are made? Address authority to assign, undisclosed encumbrances, third-party materials, contributor agreements, and compliance with approved licenses.
• What happens later? Include cooperation for confirmatory assignments, registration, recordation, or diligence if appropriate.

Counsel often distinguishes a present assignment from a future promise to assign. The exact verbs matter, as do governing law and the rights being transferred. Do not copy a clause from an unrelated template and assume it closes the chain of title.

Background IP and reusable contractor tools

Contractors often bring code, libraries, deployment scripts, templates, know-how, or internal frameworks created before the engagement. That background IP should be disclosed rather than mixed silently into the deliverables.

A useful schedule identifies each background component, its owner, its function in the product, and the license the client receives. The business team should ask whether the product can be maintained, sold, transferred, or hosted by another provider if that component remains contractor-owned.

One clean model is to separate materials into four buckets:

• Client materials: code, data, designs, and documentation supplied by the client.
• Project IP: original deliverables created specifically for the engagement and assigned as agreed.
• Contractor background IP: pre-existing or general-purpose material the contractor retains, with a defined license where embedded.
• Third-party material: open-source and commercial components governed by their own licenses.

The schedule is more useful than a sweeping sentence because engineering and diligence teams can trace what the product actually contains.

Open-source components are licensed, not assigned by the contractor

A contractor cannot give the client exclusive ownership of code the contractor received under an open-source or commercial license. The agreement should require an inventory of third-party components and compliance with their license conditions.

At minimum, record the component name, version, source, license, whether it was modified, where it is used, and any notice or source-distribution obligation. Approval rules may be needed for strong copyleft licenses, source-available licenses, or packages with unclear provenance.

A software bill of materials can make this inventory maintainable. NIST's SBOM guidance describes an SBOM as a record of software components and their supply-chain relationships. An SBOM does not resolve every license question, but it gives security, legal, and engineering teams a shared list to review.

AI-assisted and AI-generated code needs its own inventory

When a contractor uses a coding assistant or generative model, ask for more than a general statement that AI was used. The project record should identify approved tools, material AI-generated contributions, the person who reviewed them, applicable provider terms, and the checks used for security, correctness, and third-party similarity.

The U.S. Copyright Office's AI copyrightability report concludes that copyrightability depends on sufficient human authorship; prompts alone do not supply that authorship. Applying those principles to a specific codebase is fact-dependent, and service terms and third-party claims create separate issues.

A practical AI code inventory can include:

• Tool, model, account type, and material terms in effect when used
• Files or features containing material generated contributions
• Human reviewer and the nature of the review or modification
• License, provenance, secret-scanning, dependency, and security checks
• Any client data, code, or confidential information sent to the tool
• Exceptions approved by the client and the approving person

This is not paperwork for its own sake. A later buyer, investor, insurer, or enterprise customer may ask how the code was created and whether the company has the rights and records needed to ship it.

Subcontractors and chain of title

An agency can transfer only the rights it has obtained. If a subcontractor writes part of the system but never assigns the relevant rights, the agency's client agreement may not cure the missing link.

Require a contributor roster and written downstream agreements before work begins. The prime vendor should confirm that each contributor is bound by confidentiality, IP-assignment, security, and third-party-code obligations consistent with the client contract. The client should also know whether subcontracting needs prior approval and which jurisdictions are involved.

At handoff, obtain a certification that the contributor list is complete and that the vendor has secured the rights needed to perform its assignment. For material acquisitions or financing, counsel may request copies or summaries of the underlying agreements.

Source-code and operational handoff checklist

Legal ownership is hard to use if the company cannot build, deploy, or maintain the product. The handoff should cover both rights and operating control.

Repository and build

• Client-controlled organization and administrator access
• All repositories, branches, tags, release artifacts, and relevant history
• Build instructions, dependency lockfiles, supported tool versions, and environment setup
• Automated tests, test data instructions, and known failing tests
• Issue tracker, backlog, architecture decisions, and known defects

Infrastructure and release

• Infrastructure-as-code, deployment pipelines, environments, and rollback steps
• Cloud, domain, DNS, app-store, monitoring, and third-party-service ownership
• A credential inventory and rotation plan; do not transfer long-lived secrets through source files
• Production runbooks, incident history, backups, and recovery procedures

Rights and provenance

• Signed assignment and any confirmatory documents required by the agreement
• Contributor and subcontractor roster
• Background-IP schedule and licenses
• Open-source and commercial-component inventory or SBOM
• AI-use inventory and review record
• Third-party notices, attribution files, and source-offer materials where required

Acceptance should include a clean build and a test deployment performed from client-controlled systems, not only the existence of files in a repository.

Due diligence before signing or acquiring a codebase

• Match every material contributor to a signed employment or contractor agreement.
• Confirm the agreement assigns the intended project IP and deals with work made for hire as a fallback, not the only theory.
• Review payment and acceptance conditions that affect when assignment occurs.
• Reconcile the repository contributor history with the contributor roster.
• Review background-IP schedules, third-party licenses, and the SBOM.
• Ask how AI tools were used and how generated contributions were reviewed.
• Confirm the client controls the repositories, cloud accounts, domains, and release credentials it expects to own.
• Check whether liens, prior licenses, exclusivity promises, or open-source obligations limit use or transfer.
• Have counsel address patents, trademarks, data rights, privacy, and international contributors where relevant.

How Horizon Labs handles code ownership

For Horizon Labs engagements governed by its U.S. contract, project IP is assigned to the client, and engineering work can be delivered in a client-owned GitHub repository. That pairs the legal transfer with day-to-day access and an auditable contribution history.

Prospective clients should still review the operative agreement for their project, including any background IP, third-party software, or special delivery terms. To review the engineering and handoff model, see how Horizon Labs works and its strengths and capabilities.

If you need senior engineers to take over an existing codebase or clear a difficult backlog, request a codebase takeover assessment. Horizon Labs can review repository control, build and release access, contributor records, and handoff readiness; qualified counsel should review the agreement and chain of title.

Frequently asked questions

Who owns code written by an independent contractor in the United States?

The contractor is often the author and initial copyright owner unless the code qualifies as a work made for hire or the contractor signs a valid assignment. The result depends on the contributor's legal status, the work, the agreement, and other facts, so the client should have counsel confirm the chain of title.

Does paying a contractor or receiving GitHub access transfer copyright?

No. Payment and repository access can satisfy commercial and delivery obligations, but they do not by themselves transfer copyright. Under U.S. law, a copyright transfer generally requires a signed writing that identifies the rights being conveyed.

Is work-made-for-hire language enough for contractor-written software?

Not always. Commissioned work must fit one of the statutory categories and be covered by a signed work-made-for-hire agreement. Because computer programs are not a standalone category in that list, software contracts commonly use an express IP assignment as a backstop.

What should a contractor IP assignment cover?

It should identify the assigning parties, project deliverables, covered rights, transfer timing, background IP, third-party components, subcontractors, licenses, representations, and further-assurance obligations. Counsel should tailor the language to the project and governing law.

How should open-source and AI-generated code be handled?

Maintain an inventory of open-source, commercial, and material AI-generated components; record applicable licenses or service terms; require human review; and document provenance, security checks, and approvals. The assignment should not claim exclusive ownership of third-party material the contractor does not own.