Skip to content
Who Owns the Code You Paid For? A Software Ownership Checklist for Mid-Market Owners and Operators

Who Owns the Code You Paid For? A Software Ownership Checklist for Mid-Market Owners and Operators

2026-11-02 · By the Yellow Coop Team

The takeaway: Paying a developer or agency to build software does not, by itself, make your company the owner of that code. Under U.S. copyright law, ownership starts with whoever wrote it, and it moves to you only through employment or a signed written agreement. Fix the paperwork, the repositories, and the account logins now, while everyone is still friendly.

Why “we paid for it” isn’t the same as “we own it”

The U.S. Copyright Office’s Circular 30, Works Made for Hire (revised August 2024) lays out the default plainly: ordinarily, the author is the person who actually created the work. The Copyright Act says the same thing in 17 U.S.C. § 201(a): copyright “vests initially in the author or authors of the work.”

There are two ways your company becomes the author or owner instead:

  1. Your employee wrote it as part of their job. Code written by an employee within the scope of employment is a “work made for hire,” and the employer is treated as the author (17 U.S.C. § 101; § 201(b)).
  2. Someone signed a written transfer. A transfer of copyright ownership “is not valid unless” it is in writing and signed by the owner of the rights being conveyed (17 U.S.C. § 204(a)).

The contractor trap

Most mid-market software is built by freelancers, agencies, or offshore partners, not employees. That matters for two reasons.

First, “employee” is a legal test, not a job title. Circular 30 notes that the Supreme Court, in Community for Creative Non-Violence v. Reid (1989), told courts to use the general common law of agency to decide who counts as an employee. The factors include who supplied the tools, how long the relationship ran, how the person was paid, whether taxes were withheld, and whether they ran their own business. A contractor billing your company through their own LLC usually looks a lot less like an employee.

Second, writing “work made for hire” in a contractor agreement may not do what you think. For commissioned work, the label only works if the work fits one of nine categories listed in § 101: 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. Circular 30 is blunt: if a work fails any of the requirements, “it is not a work made for hire.” Standalone custom software isn’t on that list. That is why it’s worth asking your attorney whether your contracts also include a signed assignment clause (a written transfer of ownership under § 204), not only the work-for-hire label.

This is a practical checklist, not legal advice. Have your attorney review the contracts.

The software ownership checklist

1. Paper: contracts that actually transfer rights

  • A signed agreement with every outside developer, agency, and subcontractor that assigns copyright in the work to your company.
  • Language covering the agency’s own subcontractors. If the agency hired a freelancer, you need rights flowing from that person through the agency to you.
  • A clear license for any pre-existing tools or code the developer brings in and keeps owning, so you can keep running and changing the product if you part ways.

2. Code: repositories in your company’s name

  • Source code lives in a repository owned by your company’s account, with the vendor added as a collaborator, not the other way around.
  • At least two people at your company hold admin access.
  • The build and deploy steps are written down, so a new team could ship a change without calling the old one.

3. Accounts: the keys to production

  • Cloud hosting, domains, app store listings, email-sending services, and payment processors are registered to company accounts and company email addresses, not a developer’s personal Gmail.
  • Passwords and API keys sit in a company-controlled password manager or secrets vault.
  • Billing for each service runs on a company card, so nothing lapses when a vendor stops paying.

4. Components: know what you didn’t write

  • Ask for a list of the open-source and third-party components in the product and their licenses. Some licenses carry obligations if you distribute the software. Your attorney can tell you which ones matter for your situation.

5. Handoff: rehearse the breakup

  • Once a year, ask: if this vendor disappeared tomorrow, could we get the code, deploy it, and log into everything? If the honest answer is “probably,” that’s a no.

When to do this

The best time is before the first invoice. The next best time is before something forces the question: a due diligence request from a buyer or investor, a vendor dispute, or a key developer leaving. Cleaning up ownership in the middle of a sale or a fight costs more and gives you less leverage.

Conclusion

Ownership of your software comes down to three things you can check this quarter: signed paperwork that transfers rights, repositories and accounts in your company’s name, and a handoff you’ve actually tested. None of it is glamorous. All of it is cheaper than finding out the hard way.

If an outsourced team builds your product and nobody in-house can vouch for the contracts, the code, or the access, that’s squarely the kind of outsourced partner oversight Yellow Coop covers in its fractional CTO work. Get in touch to talk it through.

Sources