Who owns your code: employees, contractors and agencies

Who owns code by default?#

Code ownership by default depends on the contributor's relationship with the company, not on who paid or whose repository holds the files. Under US copyright law the author owns a work unless the work made for hire rule or a written transfer moves ownership to someone else.

The table below shows where ownership usually starts for each kind of contributor and what moves it to the company. It is a starting map for a review with counsel, not a conclusion for any specific contributor.

When does employee code belong to the company?#

Employee code belongs to the company when it is written within the scope of employment, which generally means the work is the kind the person was hired to do, done substantially within working hours and workplace limits, and done at least partly to serve the employer. A backend engineer writing the billing service fits squarely. A support agent building a reporting script on a weekend is less clear.

Whether someone counts as an employee for this rule depends on how the relationship actually worked, not on the title in the contract. Who controlled how the work was done, how the person was paid and taxed, whether they received benefits and how long the relationship lasted all point one way or the other, so a person labeled a contractor can turn out to be an employee for copyright purposes, and the reverse.

Most software companies also have employees sign a proprietary information and invention assignment agreement. That agreement covers the gray cases, but several states limit how far such clauses can reach into inventions made on the employee's own time without company resources, so the clause should be read against the law of the state where the employee worked.

The practical risk is not the typical engineer. It is the first hires who joined before anyone had a standard agreement, the employee who converted from contractor status without signing new paperwork, and the personal project that became a product module.

Why contractor code is the usual gap#

Contractor code is the most common ownership gap because a contractor keeps copyright in what they write unless a signed writing assigns it. Paying the invoice does not transfer ownership; at most it may give the company an implied license to use the code, which is usually too narrow to support licensing it onward. Many early-stage companies hired freelancers with a short statement of work or an email agreement.

Contracts that only call the work made for hire often fail for software, because US law lets commissioned work by a non-employee qualify only in a short list of statutory categories, and only with a signed written agreement, and software often falls outside those categories. That is why careful agreements add a present assignment as a fallback. Wording also matters: hereby assigns transfers rights now, while will assign is a promise that may need a further document.

• 1A present assignment of all rights in the deliverables and any work product created for the company.
• 2A fallback assignment if the work made for hire characterization fails.
• 3A license to any pre-existing contractor material built into the deliverables, broad enough to cover licensing the code onward.
• 4A waiver of moral rights where foreign law recognizes them.
• 5A further assurances clause obliging the contractor to sign confirmatory documents later.
• 6Confidentiality terms and a statement of which repositories and projects the contractor touched.

What agencies usually keep#

Development agencies usually keep their pre-existing materials, such as starter templates, UI component libraries and internal tooling, and grant the client a license to use them inside the delivered product. The client typically owns only the custom deliverables, and some agreements transfer even those only after full payment.

The license to agency background material is where code licensing for AI training gets complicated. A grant to use the material for the client's internal business purposes may not stretch to delivering copies to an AI developer. If the agency's library sits in your repository, it is often simpler to exclude that directory than to negotiate a new grant.

Agencies also use subcontractors. Ask whether the agency obtained written assignments from its own freelancers, because the agency cannot assign rights it never received.

How to audit chain of title before licensing code#

A chain of title audit for code matches every contributor in the repository history to a document that gives the company ownership or a sufficient license. The git log is the starting point because it lists commit authors and email addresses across the whole history, including people nobody remembers hiring.

The steps below build that map, and the table that follows shows the gaps the audit most often turns up and how companies usually close them.

• 1List every commit author name and email across all branches and tags, for example with git shortlog -sne --all, and merge aliases that belong to the same person.
• 2Match each author to the HR roster, payroll records and the accounts payable vendor list, and classify them as employee, contractor, agency staff or unknown.
• 3Pull the signed document for each person: invention assignment agreement, contractor agreement, agency MSA and statements of work, or marketplace terms.
• 4Check that each assignment names the right legal entity, especially after a reincorporation, a holding company reorganization or an acquisition.
• 5Use git blame on the files in scope to find paths where unknown or unassigned authors still wrote a large share of the current code.
• 6Record the result in a contributor map that counsel reviews before any ownership warranty is drafted.

Illustrative: a workflow software company traces its contributors#

Illustrative: a fictional workflow software company preparing a code license exports its GitHub commit history and finds three groups of authors. Most commits come from employees with company email addresses. An early web front end came from a design and development agency. A mobile app was built by freelancers hired through a marketplace, two of whom later worked off-platform under an email thread.

The general counsel reads the agency MSA and finds that custom deliverables were assigned on payment but the agency's component library was only licensed for operating the product. The marketplace terms covered on-platform work. One off-platform freelancer signs a confirmatory assignment; the other cannot be reached.

The company excludes the agency's library directory and the mobile modules written mainly by the unreachable freelancer, and licenses the core platform history. The contributor map and signed confirmations go into the deal file so the licensee and any future acquirer can see the basis for the ownership warranty.

How SourceX handles code ownership#

SourceX treats code ownership as part of the Rights step in the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check collects metadata only, such as repository names, date ranges and contributor types, so no code is shared while ownership questions are still open.

When a package proceeds, the contributor map, the agreements relied on and any excluded paths are recorded in the SourceX Evidence Packet under licensing rights, alongside provenance, permitted use, the privacy record and release authorization. The supplier approves the final scope before anything is delivered.