Table of Contents
- How to Tell Whether Your Company Actually Owns Its Codebase
- Why Code Ownership Gets Confused So Easily
- What “Owning The Codebase” Usually Means
- Step 1: Identify Who Actually Wrote The Code
- Step 2: Separate Employees From Contractors
- Step 3: Look For Pre-Incorporation And Side-Project Code
- Step 4: Review Whether Any Written Assignment Is Actually Valid
- What To Look For In The Agreement
- What To Look For In The Timeline
- What To Look For In Supporting Records
- Step 5: Audit Repository Control, Not Just Contracts
- Step 6: Check For Open-Source And License Contamination Issues
- Step 7: Don’t Ignore Trade Secret And Confidentiality Gaps
- Step 8: Watch For Red Flags During Fundraising, M&A, And Enterprise Sales
- Step 9: Understand The Difference Between A Manageable Gap And A Serious Dispute
- A Simple Test: Can Your Company Prove Ownership Without Guessing?
- Final Thoughts
Type
Great Grandchild
Status
Approved
Caption
Title (YouTube)
Caption X
Cover
OG Image
Alt Image Text
Minimal flat vector illustration of a software codebase connected to founders, employees, contractors, and external sources, with documents, a magnifying glass, and a highlighted lock showing the question of whether a company truly owns its code.
Images
Videos
Video Published (Blog)
Publish Date (Social)
Apr 21, 2027 14:00
Scheduled (Social)
Scheduled (Social)
Images Posted (Social)
Images Failed (Social)
Videos Posted (Social)
Videos Failed (Social)
Featured
Do not index
Videos Post IDs (Social)
Created time
Apr 8, 2026 06:38 PM
Sub-item
Authors
Images Post IDs (Social)
YT Post ID
YT Embedded
Images Delete (Social)
Videos Delete (Social)
How to Tell Whether Your Company Actually Owns Its Codebase
A lot of software companies talk about “our code” as if ownership is obvious. In practice, it often isn’t.
A startup may have shipped product for years before anyone asks the awkward question: Does the company actually own all of the source code it relies on? If the answer is unclear, the risk can surface at exactly the wrong time — during fundraising, diligence, an acquisition, a cofounder split, a contractor dispute, a security incident, or a customer procurement review.
That uncertainty is more common than many founders expect. Under U.S. copyright law, copyright initially vests in the author, and for a transfer of copyright ownership, a signed writing is generally required unless ownership passes by operation of law. Works made for hire can shift ownership to the employer, but only in specific circumstances defined by statute and interpreted carefully in practice. The U.S. Copyright Office and Circular 30 on works made for hire both frame this issue in formal terms. For software teams, the real-world version is simpler: if the paper trail is messy, the ownership story may be messy too.
In this post you’ll learn how to spot the difference between using code and owning it, what documents and repository controls often matter most, and where companies commonly discover gaps. If you want broader background first, it may help to start with a plain-English overview of software IP issues.
Scroll to the bottom for every post in this series.
Why Code Ownership Gets Confused So Easily
Software products are rarely built by one employee, on one machine, inside one legal entity.
A typical codebase may include:
- code written by founders before incorporation
- pull requests from employees in different states or countries
- work from freelancers and development agencies
- inherited code from an acquired team
- open-source packages and snippets
- AI-assisted output
- infrastructure scripts, CI/CD workflows, and deployment configs
- code living across GitHub, GitLab, Bitbucket, internal mirrors, and local machines
That mix creates two separate questions:
- Who owns the original code your team created?
- What rights does the company actually have in third-party code, dependencies, or contributed material?
Those are not the same thing. The U.S. Copyright Office distinguishes ownership of copyright from possession of the copy itself, and the Copyright Act separately notes that ownership of the material object does not itself convey copyright. In software terms, having admin access to a repository or paying someone to write code does not automatically establish ownership of the underlying rights. 17 U.S.C. §§ 201, 202, and 204
What “Owning The Codebase” Usually Means
When founders say they want to know whether the company owns its codebase, they’re usually asking whether the company can credibly show that it has rights to:
- use the code
- modify the code
- distribute or license the code
- exclude others from copying proprietary portions
- commercialize the product without a hidden claimant appearing later
In general terms, a clean ownership story often includes:
- employment agreements with invention-assignment language
- contractor agreements with present-tense assignment language and confidentiality terms
- assignment documents from founders for pre-incorporation code
- records showing who contributed what and when
- open-source compliance practices
- repository governance showing the company actually controlled development access
- a process for documenting transfers, licenses, and exceptions
This is where legal review and technical audit start to overlap. If you are also looking at the operational side of the issue, it may help to read more about reviewing contractor agreements, repo access, and open-source use during an IP audit. It also helps to understand the broader pattern of common software IP mistakes that create product risk.
Step 1: Identify Who Actually Wrote The Code
The first question is often embarrassingly basic: Who created the code in the first place?
Make a contributor map that includes:
- founders
- current employees
- former employees
- individual contractors
- agencies or dev shops
- open-source contributors
- interns
- advisors with technical access
- acquired teams
- outside collaborators with commit rights
Git history can help, but Git history is not the same thing as a legal chain of title. Commit names, usernames, and emails can be incomplete or misleading. A repository may show who pushed code, not necessarily who owned rights in the code at that moment.
This distinction matters because copyright generally starts with the author unless a valid transfer or work-made-for-hire framework applies. The Copyright Office explains that a non-author claimant typically needs ownership of all rights acquired in writing or by operation of law. Copyright Office claimant guidance
A practical ownership review often starts with a spreadsheet that ties each meaningful contributor to:
- legal name
- role
- dates of contribution
- entity paying for the work
- signed agreement status
- assignment status
- repository usernames
- devices or environments used
- any known reuse of prior code
If this list feels difficult to build, that alone can be a signal that the ownership record is thinner than leadership assumed.
Step 2: Separate Employees From Contractors
This is one of the biggest fault lines in software ownership.
For employees acting within a typical employment relationship, code is often treated as a work made for hire, with the employer considered the author and owner unless the parties agree otherwise in a signed writing. The Copyright Office discusses this directly in Circular 66 on websites and website content and more fully in Circular 30.
Contractors are different.
Many founders assume that if the company paid an independent developer, the company owns the resulting code. That assumption often creates trouble. For independent contractors, work-made-for-hire treatment is much narrower and depends on specific statutory categories and written language. Custom software does not fit neatly into the categories many people assume. Even where licensing rights exist, full ownership may require a separate written assignment. The Copyright Office’s discussion of works made for hire and copyright transfers is often where these issues become clearer.
So if any part of the product was built by freelancers, offshore developers, agencies, or “part-time consultants,” the company may want to examine whether the agreement:
- clearly identifies the contracting entity
- assigns intellectual property to the company in writing
- is signed by the person or entity transferring the rights
- covers deliverables, derivatives, and related materials
- includes moral-rights waivers where relevant internationally
- includes confidentiality and trade secret protections
A missing signature or a vague “client owns work product” sentence may not tell the full story.
Step 3: Look For Pre-Incorporation And Side-Project Code
A surprising amount of venture-backed software started as a side project.
Maybe a founder wrote the initial application before the company existed. Maybe the prototype came out of a prior employer relationship, a university lab, a hackathon team, or a moonlighting arrangement. Maybe an early contractor reused libraries or modules from earlier client work. Maybe a cofounder imported utilities from another startup.
These facts do not automatically destroy ownership, but they can complicate it.
If code was written before the company was formed, the company’s rights often depend on a later assignment into the entity. If that assignment never happened, the founder may still hold at least some of the rights personally. If code was developed using a prior employer’s resources or under a prior invention-assignment agreement, another entity may claim an interest. If code came from a jointly built side project, the company may not be the only stakeholder.
Some of the most uncomfortable diligence questions arise here:
- Was the first production code actually built before incorporation?
- Did every founder assign pre-company IP into the company?
- Did anyone copy code from a prior employer, client, or school project?
- Was any “temporary” borrowed code left in production?
- Are there cofounders or former collaborators who never signed formal assignments?
When these issues surface, an attorney may help determine whether the company has ownership, a license, a partial interest, or an unresolved dispute.
Step 4: Review Whether Any Written Assignment Is Actually Valid
In software deals, people often talk about “assignment” as if the word itself solves everything. It doesn’t.
Under 17 U.S.C. § 204, a transfer of copyright ownership is generally not valid unless it is in writing and signed by the owner of the rights conveyed or the owner’s authorized agent. The Copyright Act text and the Copyright Office FAQ on transfers both make that clear.
That usually leads to a practical document review:
What To Look For In The Agreement
- Is the agreement signed?
- Is the correct company entity named?
- Is the signer the actual rights holder?
- Does the language assign IP, or does it only mention confidentiality?
- Does it cover inventions, source code, object code, documentation, and derivative works?
- Is the assignment present-tense and automatic, or does it merely promise a future assignment?
- Are exhibits, statements of work, or incorporated policies missing?
What To Look For In The Timeline
- Was the agreement signed before the work started?
- If it was signed later, does it cover prior work?
- Did contributions continue after the agreement expired?
- Was the contractor switched to a different entity without a new assignment?
What To Look For In Supporting Records
- invoices
- statements of work
- offer letters
- cap table and incorporation records
- founder assignment agreements
- separation agreements
- acquisition documents
- recordation history where relevant through the Copyright Office’s recordation system
A company can have a signed contract and still have gaps if the signer was the wrong entity, the scope was limited, or the document came too late.
Step 5: Audit Repository Control, Not Just Contracts
Ownership is legal, but control evidence often lives in technical systems.
If a company truly controlled the codebase, there is often a trail in the repository platform showing who had access, who approved changes, and how protected the default branch really was.
For example, GitHub’s organization audit log allows owners to review actions performed by members, with a retention period of 180 days in the organization audit log. GitHub audit log documentation GitLab likewise documents role-based repository permissions, protected branches, and code-owner approval settings. GitLab members documentation GitLab protected branches
A repository ownership audit often asks:
- Who currently has admin, owner, or maintainer rights?
- Who had those rights historically?
- Are there ex-employees or old agencies still in the org?
- Is the default branch protected?
- Can developers force-push or merge directly?
- Are code owner approvals required for sensitive paths?
- Are backups, mirrors, forks, and machine users under company control?
- Is there an audit trail for access changes?
These controls do not replace legal assignments. But when the repository still has a former vendor as the sole admin, or when critical infrastructure lives under a founder’s personal account, that can become evidence of broader ownership sloppiness.
Step 6: Check For Open-Source And License Contamination Issues
A company may fully own its original code and still have serious problems if the codebase includes third-party software used outside license terms.
Modern software almost always includes open-source components. The issue is not whether open source exists in the stack. The issue is whether the company knows what is there, under which licenses, and with what obligations.
NIST has long tied software supply-chain integrity and provenance to secure development practices, including SBOM-related efforts. NIST on software security in supply chains The Secure Software Development Framework, NIST SP 800-218, remains a core reference point for governance around software provenance and control. CISA has also continued updating its SBOM guidance, including a 2025 draft of revised minimum elements. CISA SBOM announcement
For software IP purposes, that means companies often look at:
- package manifests and lockfiles
- copied code snippets
- vendored libraries
- SDKs and models
- build scripts and container images
- transitive dependencies
- internal forks of open-source projects
- notices and attribution files
- software bills of materials
Open-source use does not mean the company does not own its product. It often means ownership and licensing have to be understood together. In some cases, the key legal question is not “Do we own this?” but “What rights did we receive, and what conditions came with them?”
OpenSSF’s recent materials also continue to emphasize SBOM quality, secure open-source use, and governance baselines tied to modern compliance expectations. OpenSSF Vision Brief 2025 OpenSSF OSPS Baseline overview
Step 7: Don’t Ignore Trade Secret And Confidentiality Gaps
Code ownership is not only about copyright.
For many software businesses, core value also lives in proprietary architecture, training data pipelines, deployment methods, internal tooling, customer-specific integrations, and operational know-how. Those assets may be protected in part through trade secret law, but that generally depends on whether the company treated them as confidential.
The USPTO’s trade secret policy page describes trade secrets as a recognized form of IP protection that complements other rights. In practical terms, if contractors were given source access without confidentiality terms, if repos were publicly exposed, or if sensitive build materials were casually shared, the company’s trade-secret position may be weaker than leadership expects.
Questions worth asking include:
- Are all contributors under confidentiality obligations?
- Were private repos ever public?
- Did vendors reuse code across clients?
- Were secrets embedded in code or shared in insecure channels?
- Did departing personnel retain source copies?
- Are internal tools and deployment workflows access-controlled?
A codebase can be “owned” on paper and still be poorly protected in a way that creates litigation or valuation issues later.
Step 8: Watch For Red Flags During Fundraising, M&A, And Enterprise Sales
Ownership issues often stay hidden until someone outside the company asks harder questions.
That usually happens during:
- venture financing
- acquisition due diligence
- enterprise procurement
- cyber insurance underwriting
- government or regulated-sector sales
- founder disputes
- contractor payment disputes
- employee departures
Common red flags include:
- no signed invention-assignment agreements for one or more founders
- contractors who built core features without valid IP assignment
- code sitting in personal repositories
- no formal repo access policy
- unknown open-source inventory
- old agencies still holding admin control
- code copied from prior employers or clients
- undocumented forks and mirrors
- missing chain-of-title records after an acquisition or reorganization
Some founders learn about these problems when a buyer asks for a clean schedule of IP assignments. Others learn when a former contractor claims ownership leverage. Others encounter it when a customer security questionnaire asks about SBOMs, provenance, and software development controls.
Step 9: Understand The Difference Between A Manageable Gap And A Serious Dispute
Not every ownership issue is catastrophic.
Sometimes the fix is administrative: collecting signed confirmatory assignments, migrating repositories into company-controlled orgs, cleaning up contractor paper, or formalizing open-source processes.
Sometimes the issue is more serious:
- a former contributor refuses to assign rights
- a founder’s prior employer may have a competing claim
- key code was built outside any valid agreement
- a development shop reused code across clients
- a copyleft license issue affects distribution strategy
- a missing chain of title threatens a financing or sale
This is often where the legal and business stakes rise quickly. A lawyer with documented experience in software IP, founder disputes, and technology transactions may help distinguish a fixable recordkeeping issue from a real ownership conflict.
If you want a faster self-check before involving counsel, it may also help to review the questions SaaS founders often ask about code, contractors, and ownership.
A Simple Test: Can Your Company Prove Ownership Without Guessing?
One useful thought exercise is this:
If a buyer, investor, or opposing party asked tomorrow for evidence that the company owns and controls its codebase, what would the company actually produce?
A confident answer often includes:
- formation and founder assignment records
- employee invention-assignment agreements
- contractor and agency IP assignments
- repository admin and audit records
- branch protections and code-owner policies
- open-source inventory and license review
- SBOM or equivalent dependency visibility
- confidentiality controls
- a clear explanation of any exceptions
If the answer is “we’d have to piece it together,” that often tells you something important.
Final Thoughts
Owning a codebase is not just about writing code first or paying for development. It is usually about chain of title, documented rights, repository control, and clean handling of third-party components. Companies often discover the difference when growth creates scrutiny.
For founders, in-house teams, and operators, the real issue is less about legal jargon and more about whether the ownership story is documented, consistent, and based on evidence. If it is not, an attorney may help assess the gap before someone else turns it into leverage.
Visit ReferU.AI to get matched with an attorney who has demonstrable experience in cases like yours — for free.
