Who Owns Software Developed by Contractors, Employees, and Founders?

How source code ownership works under U.S. copyright law: who the first owner is, the two ways ownership moves to a company, the founder and co-founder traps most guides skip, and what to gather before you call a lawyer.

Under the default rules of U.S. copyright law, the person who writes the code owns it the moment it is written, with two exceptions: code written by an employee within the scope of the job belongs to the employer, and code covered by a signed written assignment belongs to the assignee (17 U.S.C. §§ 201(a), 201(b), 204(a)). So the short answer to who owns software developed by contractors is that the contractor is the legal owner, until a signed assignment says otherwise. Paying the invoices does not move ownership, and having the idea for the product counts for even less, since copyright never protected ideas (17 U.S.C. § 102(b)).

The question tends to surface at the worst moment: an investor’s counsel asks for the founder IP assignment during a financing, a contractor who was never paid in full claims the code, or a co-founder walks out with a copy of the repository. A gap that a few signatures would have closed at formation can take a lawsuit to close once the parties have fallen out. For how copyright sits alongside trade secrets, patents, and licenses, start with the Protection of Software page.

The default position: the author is the first owner of the code

Copyright “vests initially in the author or authors of the work” (17 U.S.C. § 201(a)). The author is the person who typed the source code, the same way the copyright in a photograph belongs to whoever pressed the shutter. The Supreme Court laid out that rule in Community for Creative Non-Violence v. Reid, and the Fourth Circuit applies it to software in Avtec Systems, Inc. v. Peiffer: rights vest in the programmer unless the work-made-for-hire exception applies.

Two common misconceptions get companies into trouble: that paying for the code makes you the owner (a federal court in Virginia held that a company which commissioned custom middleware, with no qualifying agreement, owned none of it), and that the idea makes you the owner. So a company never gets to assume it owns its own product; ownership has to be traced, contributor by contributor, back to an employment relationship or a signed assignment, and the map that produces is the same one a buyer’s diligence team will ask for.

Employees: when the employer owns code developed within the scope of employment

Code developed by an employee within the scope of employment is a work made for hire, which means the employer is treated as the author and owns the copyright from the start unless a signed agreement says otherwise (17 U.S.C. §§ 101, 201(b)). Whether someone counts as an employee is decided under common-law agency factors, whatever the employment contract calls the relationship; under Reid, courts weigh control over how the work is done, who supplied the tools, and how the person was paid and taxed, so a remote developer with her own equipment, paid per project, looks like an independent contractor however the paperwork describes her.

Scope of employment is where the fights happen. In Avtec, the Fourth Circuit held that code is within scope only if it is the kind of work the employee was hired to perform, it was written substantially within authorized time and space limits, and it was motivated at least in part by a purpose to serve the employer. A developer who writes a module for the company’s product at home, after work hours, has still written it within scope when it is the kind of work she was hired to do, while one moonlighting on an unrelated app can own that code outright even as a W-2 employee. North Carolina adds a statutory limit: an employment agreement cannot require assignment of an invention developed entirely on the employee’s own time without company resources, unless it relates to the employer’s business (N.C. Gen. Stat. § 66-57.1).

Even for employees, a signed IP agreement at hire settles the scope question in advance, assigns anything outside the work-made-for-hire definition, and carries the confidentiality terms and the Defend Trade Secrets Act notice that trade secret protection depends on; the Fourth Circuit held in Samuel Sherbrooke Corp. v. Mayer that such provisions counted, at the pleading stage, as a reasonable measure to protect source code as a trade secret. Drafting that agreement so it stays inside § 66-57.1 is lawyer’s work.

Independent contractors: the contractor owns the code unless a signed agreement says otherwise

A commissioned work can be a work made for hire only if it falls into one of nine categories the statute lists and the parties agree in a signed writing (17 U.S.C. § 101). Standalone software appears nowhere on that list, so an independent contractor’s code is not a work made for hire no matter what the contractor agreement says, and a “work for hire” clause in a software development agreement does nothing for the code. Without a signed assignment, the contractor owns the copyright and the company holds, at best, an implied license with a scope nobody wrote down.

One example from practice: a company’s agreement with its outsourced developer provided that the code would be assigned once the work was completed and paid for, so ownership did not move until the last invoice was paid, and a dispute over the final invoice became a dispute between client and developer over who owned the product. When counsel reviews a software development, contractor, or agency agreement, four things get checked: a present assignment, no payment condition, a further-assurances clause, and a license back for the tools the contractor brought to the project. The Protecting a Software Developer’s Rights case study shows the same rules from the developer’s side.

The assignment language that moves IP rights, and where moral rights fit

A transfer of copyright ownership “is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed” (17 U.S.C. § 204(a)). Intent and payment do not substitute for the writing, though the Fourth Circuit held in Metropolitan Regional Information Systems, Inc. v. American Home Realty Network, Inc. that clicking “yes” to electronic terms can satisfy the signature requirement, and notarization is optional.

The single most important drafting distinction is between a present assignment and a promise to assign. “Hereby assigns” transfers the rights now. “Agrees to assign” is a promise that leaves the developer holding title, and the Supreme Court recounted in Board of Trustees of Leland Stanford Junior University v. Roche Molecular Systems, Inc. how an “agree to assign” clause lost to a later “do hereby assign” clause. A working clause assigns, in the present tense, all right, title, and interest in the deliverables, covers future work under the agreement, schedules the developer’s pre-existing tools with a license back, adds a further-assurances clause, and ties nothing to payment. In the United States, moral rights cover visual art only, so the moral rights waiver that leads many UK and EU guides matters mainly for contractors abroad.

A confirmatory assignment is the standard cleanup tool, since § 204(a) accepts a later “note or memorandum” of an earlier handshake transfer. Recording the assignment with the Copyright Office gives constructive notice and priority over a later conflicting transfer, but only if the work is registered (17 U.S.C. § 205), which is one reason the How to Copyright Software page belongs on the same checklist.

Founders and the code developed before the company existed

Works created by a founder before the entity existed belong to the founder personally, and nothing about forming the company or running the business on the code changes that; a New York federal court held that a founder who wrote software, incorporated, and never signed a transfer “retained his copyrights at all times.” Section 204(a) excuses the writing only for transfers “by operation of law,” such as inheritance or bankruptcy, so a capital contribution needs a signed written agreement. North Carolina’s LLC Act lets a member contribute intellectual property as capital (N.C. Gen. Stat. § 57D-4-01), but a contribution schedule in the operating agreement only identifies the deal; the conveyance is a separate signed assignment, executed at formation, that the operating agreement attaches.

When that paper is missing and the founders fall out, the company’s claim to its own product rests on circumstantial evidence, at a cost measured in months of discovery that a single signed page would have avoided; the founder exit case study shows where the harder version ends up.

Two founders both wrote code: joint works and what co-ownership means

A “joint work” is one prepared by two or more authors who intend their contributions to merge into a unitary whole (17 U.S.C. § 101), and its authors are co-owners from the moment of creation. Two founders who both write code do not automatically become joint authors; the Second Circuit in Childress v. Taylor requires that each contribute independently copyrightable expression and that both intend to be co-authors, and the Fourth Circuit has not chosen among the circuit tests, which makes the outcome in a North Carolina dispute harder to predict.

Co-ownership is an unstable place for a business to rest. Co-owners hold the copyright like tenants in common: each may use the work and license it non-exclusively to anyone, including a competitor, neither can grant an exclusive license alone, and the shares are equal regardless of who wrote more, because copyright does not allocate ownership rights by contribution. The fix is the same as before, everyone who writes code assigns it to the company at the start, and when a joint-work claim appears after the fact, the lawyer’s work is evaluating whether it is real and structuring the buyout or license-back.

Open source and AI generated code: what you own and what you license

Open source code in your proprietary software is something you license. Copyright in a derivative work extends only to the material you contributed (17 U.S.C. § 103(b)), so the company owns its own code and holds an open source license, with conditions attached, to each component; the Federal Circuit held in Jacobsen v. Katzer that using the code outside those conditions is copyright infringement.

AI generated code raises a different problem. Purely machine-generated output has no human author and therefore no copyright and no owner; the D.C. Circuit held in Thaler v. Perlmutter that the Copyright Act requires a human author, and the Supreme Court declined to review the decision. AI-assisted code keeps copyright protection to the extent of the human contribution, and “ownership” of the rest runs through trade secret law and contract, so the employee and contractor agreements should assign and protect all work product whether or not copyright attaches.

Copyright in the code and trade secrets in the code are separate rights

Copyright ownership covers the expression in the code. Trade secret rights cover the confidential architecture, algorithms, and know-how, and they exist only while the company takes reasonable measures to keep the information secret. The Fourth Circuit treats the two as distinct rights in the same code, and in Sysco Machinery Corp. v. DCS USA Corp. it held that depositing unredacted source code with the Copyright Office extinguishes trade secret status, because deposits are open to public inspection. A founder who is an LLC manager and leaves with the code also raises fiduciary questions; the North Carolina Business Court has described secretly building a competing product on company time as “akin to looting.”

The paper trail that settles ownership of developed software

Each document below closes one of the gaps described above.

• An employee invention assignment agreement, signed at hire, with a present assignment, confidentiality, the DTSA notice, and a scope that complies with § 66-57.1.
• A contractor or development agreement with a present assignment, no payment condition, and further assurances.
• A founder technology assignment at formation, attached to the operating agreement, and confirmatory assignments for anyone who wrote code without one.
• An open source inventory, an AI-tool policy, and repository records showing who committed what and when.
• Copyright registrations naming the correct claimant, with recorded assignments.

Producing that file is the ownership audit; for a young company it typically takes a few hours of attorney time, and it is the first thing an investor’s counsel asks for.

Common mistakes with the IP created when software is developed

• Relying on a “work made for hire” recital for contractor code, when only an assignment moves it.
• “Agrees to assign” instead of “hereby assigns,” which leaves title with the developer.
• An assignment conditioned on final payment, followed by a payment dispute.
• Founder code that was never assigned to the entity, or two founders coding together with nothing signed.

How code ownership fits with the rest of your software intellectual property

Ownership is the foundation the other layers of intellectual property law rest on, since copyright registration, trade secret protection, patent rights, and licensing all assume the company can prove it holds the intellectual property rights it is asserting. This page explains the general rules and is not legal advice for a specific situation (the site’s Disclaimer page has the details). When you are ready to talk to counsel about ownership, this is what will move the first conversation fastest:

• A list of all the software developers who have written code, and every agreement with each of them
• Formation documents, including any contribution schedule or founder IP assignment
• Repository access, an open source inventory, and any AI-tool usage
• The event that raised the question (a financing, a sale, a departure, or a demand letter)

If a financing is in diligence, a sale is on the table, or someone has just left with a copy of the repository, who owns the code is worth a conversation with experienced software counsel while the fix is still a signature.

Frequently asked questions