Table of Contents
- How to Review contractor agreements, repository access, and open-source use in a software IP audit
- Why These Three Areas Matter So Much
- Step 1: Map Who Actually Contributed To The Codebase
- Step 2: Separate Employees From Contractors And Vendors
- Step 3: Review Contractor Agreements For The Clauses That Actually Matter
- IP Assignment Language
- Work-Made-For-Hire Language
- Preexisting Materials And Background IP
- Confidentiality And Trade Secret Protection
- Subcontracting And Delegation
- Governing Law, Venue, And Entity Identity
- Step 4: Compare The Paper Trail Against The Repository History
- Step 5: Audit Current Repository Access Like It Is Part Of IP Ownership
- Current Human Users
- Former Human Users
- Bots And Service Accounts
- Integrations And CI/CD Connections
- Step 6: Review Whether Access Controls Reflect “Reasonable Efforts” To Keep Code Secret
- Step 7: Build An Open-Source Inventory Before You Try To Judge Compliance
- Step 8: Identify The Open-Source Risks That Matter Most In Diligence
- License Obligation Risk
- Provenance Risk
- Security Risk
- Policy Risk
- Product Architecture Risk
- Step 9: Look For Mismatches Between Policy And Practice
- Step 10: Create A Remediation List, Not Just An Issues List
- What Founders, CTOs, And In-House Teams Often Miss
- Short Summary
Type
Great Grandchild
Status
Approved
Caption
Title (YouTube)
Caption X
Cover
OG Image
Alt Image Text
Flat vector blog cover showing a laptop with a code repository, a contract document, a lock and key for access control, and connected software components symbolizing open-source review in a software IP audit.
Images
Videos
Video Published (Blog)
Publish Date (Social)
Jun 23, 2027 12: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:39 PM
Sub-item
Authors
Images Post IDs (Social)
YT Post ID
YT Embedded
Images Delete (Social)
Videos Delete (Social)
How to Review contractor agreements, repository access, and open-source use in a software IP audit
Software IP audits often sound technical, but the underlying questions are surprisingly practical: Who created the code? Who can access it? What third-party code is inside it? And does the company actually own what it thinks it owns?
Those questions come up in financing rounds, M&A diligence, enterprise sales, founder breakups, employee departures, internal compliance reviews, and security incidents. They also come up when a company starts asking a more uncomfortable question: If we had to prove ownership and control of this codebase tomorrow, what documents would we show?
In this post you’ll learn how to review three of the most important areas in a software IP audit: contractor agreements, repository access, and open-source use. Along the way, we’ll cover where software companies often discover gaps, what documents tend to matter most, and how legal and technical review usually fit together.
If you want a broader foundation first, it may help to start with this overview of how software ownership, SaaS rights, open-source obligations, and product protection fit together.
Scroll to the bottom for every post in this series.
Why These Three Areas Matter So Much
A software IP audit is not just about patents or copyright registrations. In many businesses, the bigger risk sits in the day-to-day mechanics of development:
- a contractor built a key feature without a signed IP assignment
- a former developer still has repository credentials
- an outside collaborator has access to private forks
- open-source components were added without license tracking
- proprietary code may have been mixed with code from another employer or client
- no one can produce a reliable inventory of dependencies
From a legal perspective, ownership of software is not always automatic. Under 17 U.S.C. § 204, a transfer of copyright ownership generally is not valid unless it is in writing and signed by the owner of the rights conveyed. That issue becomes especially important when code was written by independent contractors rather than employees. And while “work made for hire” concepts are often mentioned casually in startup documents, the U.S. Copyright Office explains that the doctrine is narrower than many founders assume, particularly outside standard employee relationships and certain limited commissioned works (U.S. Copyright Office).
At the same time, source code can also function as a trade secret if it derives value from not being generally known and is subject to reasonable efforts to keep it secret, according to the USPTO’s trade secret guidance. That is where repository controls, access logs, confidentiality language, and offboarding practices start to matter.
Open-source review adds another layer. Modern software almost always includes third-party components, and a Software Bill of Materials, or SBOM, is increasingly treated as a core transparency tool by CISA. Organizations also increasingly look to formal open-source compliance frameworks such as OpenChain ISO/IEC 5230, which focuses on the key requirements of a quality open-source license compliance program.
In general terms, these are not separate issues. They tend to overlap.
Step 1: Map Who Actually Contributed To The Codebase
The first step in reviewing contractor agreements is not reading contracts. It is building a contributor map.
That map usually includes:
- founders
- employees
- current contractors
- former contractors
- agencies or dev shops
- offshore teams
- interns
- advisors with code access
- outside collaborators in GitHub, GitLab, Bitbucket, or similar systems
The goal is to match people, entities, repositories, and time periods. A software company may believe “all code belongs to the company,” but an audit often reveals a more fragmented history:
- the MVP was built before incorporation
- a founder coded through a personal LLC
- a contractor reused boilerplate from prior projects
- one team committed through personal accounts
- another team delivered zip files outside the main repository
- the company acquired a product but never integrated the records cleanly
At this stage, legal review and technical review often run side by side. Someone reviews contracts and onboarding documents while someone else reviews repository metadata, commit histories, access logs, branch permissions, and archived collaboration records.
Step 2: Separate Employees From Contractors And Vendors
This distinction matters because ownership analysis often changes depending on who created the code and under what arrangement.
For employees acting within the scope of employment, U.S. law often treats the employer as the author of a work made for hire under 17 U.S.C. § 201. For contractors, that assumption is much less reliable. The Copyright Office notes that a work made for hire can apply to certain specially ordered or commissioned works only if the parties expressly agree in a signed writing and only for specific categories of works (U.S. Copyright Office).
That is why software audits often focus heavily on whether contractor paperwork includes:
- present-tense IP assignment language
- confidentiality obligations
- waiver or handling of moral rights where relevant
- further-assurances language
- obligations to disclose preexisting materials
- restrictions on using third-party or previously developed code
- return or deletion obligations at the end of the engagement
A surprising number of businesses have contractor agreements that talk about confidentiality but never clearly transfer IP. Others rely on statements of work, invoice language, or email threads that do not fully solve the ownership issue.
Step 3: Review Contractor Agreements For The Clauses That Actually Matter
When people say “review the contractor agreement,” they often mean “confirm the company owns the work.” But in a software IP audit, several separate clauses matter.
IP Assignment Language
The central question is whether the agreement contains a clear written assignment of rights. Under 17 U.S.C. § 204, a copyright transfer generally requires a signed writing. If the agreement only says the contractor “will assign” rights later, counsel may want to examine whether additional assignment documents were ever executed.
Work-Made-For-Hire Language
This language is common, but it is not always enough by itself. In software matters, many attorneys treat work-made-for-hire language as useful backup language rather than a full substitute for an express assignment, especially when the creator is an independent contractor.
Preexisting Materials And Background IP
A careful audit often asks:
- Did the contractor bring libraries, templates, scripts, or frameworks from prior projects?
- Did the agency retain ownership of reusable tools?
- Did the contract carve out “background technology” or “vendor tools”?
- If so, did the company receive a sufficiently broad license to use those items?
This area can become especially important in SaaS deals and acquisitions, where a product depends on internal tooling that the company does not fully own.
Confidentiality And Trade Secret Protection
Trade secret protection generally depends on reasonable efforts to maintain secrecy, as the USPTO explains. In an audit, that often leads to practical questions:
- Was there an NDA or confidentiality clause?
- Was source code access limited to people with a legitimate business reason?
- Were credentials revoked at offboarding?
- Were repositories segmented by sensitivity?
Without those controls, trade-secret arguments can become harder to maintain.
Subcontracting And Delegation
If a contractor was allowed to subcontract, the next question is obvious: Did the subcontractor sign equivalent IP and confidentiality terms? Some companies have a signed MSA with a vendor but no visibility into who actually wrote the code.
Governing Law, Venue, And Entity Identity
Audits also uncover agreements signed by the wrong party:
- signed before the company existed
- signed by a founder personally
- signed by a parent instead of the operating entity
- signed by a foreign affiliate not tied to the product owner
That does not always make ownership impossible to establish, but it can complicate diligence.
Step 4: Compare The Paper Trail Against The Repository History
A contract review without a repository review can miss major problems.
Some of the most useful cross-checks include:
- comparing named contractors against commit authors
- identifying commits from unknown email addresses
- finding personal accounts used for company code
- confirming whether offboarded users still appear in access history
- reviewing private forks and mirrors
- identifying repositories outside the company organization
- checking whether acquired code was ever imported from external systems
Repository history often tells a more accurate story than organizational memory.
This is one reason software acquirers and enterprise customers frequently ask detailed diligence questions about source code control, contributor history, and access restrictions. Public-company disclosure rules also reflect growing attention to cybersecurity risk management and governance; the SEC’s small business compliance guide notes structured disclosure requirements tied to cybersecurity governance and incident reporting for registrants (SEC).
Step 5: Audit Current Repository Access Like It Is Part Of IP Ownership
Repository access is often treated as a security issue, but it is also an IP issue.
If source code is proprietary and potentially protectable as a trade secret, access governance becomes part of the ownership-and-control story. In practical terms, an audit may look at:
- who currently has access
- what level of access they have
- whether access matches current job function
- whether outside collaborators are still present
- whether service accounts are documented
- whether 2FA is enforced
- whether private forks exist outside the organization
- whether access is reviewed on a recurring schedule
GitHub’s own documentation states that when an organization requires two-factor authentication, outside collaborators who do not use 2FA are removed and lose access to repositories, and members cannot access organization resources until they meet the 2FA requirement (GitHub Docs). That is a useful reminder that access control is not just policy language on paper; it can be configured and enforced.
In an audit, repository access review often covers four categories.
Current Human Users
Who can read, write, administer, or export code today?
Former Human Users
Who used to have access, and when was that access removed?
Bots And Service Accounts
What automation has persistent credentials, and who maintains them?
Integrations And CI/CD Connections
What third-party tools can pull, scan, build, mirror, or deploy the code?
A company may discover that only a handful of people can log into the repository directly, but many other tools effectively have code access through tokens, deploy keys, mirrored environments, package managers, or CI pipelines.
Step 6: Review Whether Access Controls Reflect “Reasonable Efforts” To Keep Code Secret
The USPTO describes trade secrets as information that derives value from not being generally known and is subject to reasonable efforts to maintain secrecy (USPTO). In a software audit, “reasonable efforts” often turns into evidence questions.
For example:
- Are private repositories actually private?
- Are access approvals documented?
- Are contractor accounts time-limited?
- Are personal devices or unmanaged devices allowed?
- Are secrets scoped narrowly in CI/CD?
- Are logs retained?
- Is code copied into shared drives, chat tools, or ticketing systems?
Some organizations also use least-privilege principles for repositories and build systems. That approach aligns with broader supply-chain security thinking, including CISA’s emphasis on software transparency tools such as SBOMs (CISA) and industry practices around access minimization.
Step 7: Build An Open-Source Inventory Before You Try To Judge Compliance
Open-source review often goes wrong when teams jump straight to license conclusions without first building an accurate inventory.
A better starting point is usually a dependency and provenance map that identifies:
- direct dependencies
- transitive dependencies
- package versions
- embedded code snippets
- copied Stack Overflow or forum code where identifiable
- vendored libraries
- containers and base images
- front-end packages
- mobile SDKs
- AI-generated code with third-party provenance concerns
- legacy code copied from prior systems
CISA describes an SBOM as a nested inventory or list of ingredients that make up software components (CISA). For audit purposes, that concept is helpful even if the company does not yet produce formal SBOMs for every release.
The open-source inventory phase often includes both automated scanning and manual follow-up, because scanners may not catch everything, especially:
- copied snippets
- modified vendored code
- code with removed notices
- dual-licensed components
- dependencies introduced outside normal package manifests
Step 8: Identify The Open-Source Risks That Matter Most In Diligence
Not all open-source use creates the same risk. In general terms, auditors often focus on several buckets.
License Obligation Risk
Does the license require attribution, notice preservation, source-code disclosure, copyleft treatment, or specific distribution terms?
Provenance Risk
Can the company identify where the component came from and what version is in use?
Security Risk
Is the component outdated, vulnerable, abandoned, or unsupported?
Policy Risk
Did developers follow the company’s internal approval process, if one exists?
Product Architecture Risk
Was the component linked, embedded, modified, distributed, or offered only as a hosted service? The way software is used can affect how license obligations are analyzed.
Organizations looking for a more formal compliance structure often refer to OpenChain ISO/IEC 5230, which defines key requirements for a quality open-source license compliance program, and to the broader OpenChain project resources, which also cover security assurance frameworks.
Step 9: Look For Mismatches Between Policy And Practice
A lot of software companies actually do have policies. The problem is that the policies may not reflect reality.
Common examples include:
- a handbook says all code goes into the company GitHub org, but major modules live in personal repos
- the contractor agreement prohibits third-party code without approval, but no approval workflow exists
- an open-source policy exists, but engineering has never seen it
- the company says offboarding is immediate, but repository access lingers for months
- the business claims all dependencies are tracked, but no one can generate a current list
That mismatch matters in diligence because buyers, investors, and enterprise customers usually care less about what the policy says in abstract and more about whether the company can demonstrate consistent practice.
If you are also evaluating whether ownership issues reach beyond contractors and into the core product itself, it may help to read more about whether a company really owns its codebase in the first place. Likewise, teams spotting multiple weak points at once may want to compare their findings against this broader discussion of common software IP mistakes that can create product risk, as well as these practical questions founders often ask about code, contractors, and ownership.
Step 10: Create A Remediation List, Not Just An Issues List
A useful software IP audit usually ends with two outputs:
- an issues list
- a remediation plan
The issues list may identify missing assignments, excessive access, poor offboarding, untracked dependencies, or inconsistent notices. But the remediation plan is where the audit starts becoming valuable.
That plan might include:
- getting confirmatory assignments signed
- replacing unclear contractor templates
- centralizing repositories
- revoking stale access
- enforcing 2FA
- documenting bot and service accounts
- building an SBOM process
- adopting an open-source intake workflow
- preserving license notices
- segmenting sensitive repositories
- documenting founder pre-incorporation transfers
- reviewing whether prior employer or client restrictions exist
Some gaps are easy to fix. Others may require careful legal analysis, especially if the code was created years ago or by people who are hard to locate now.
What Founders, CTOs, And In-House Teams Often Miss
In many software IP audits, the biggest surprise is not one catastrophic problem. It is the stacking effect of several smaller ones:
- incomplete paper assignments
- informal development history
- broad repository access
- limited offboarding controls
- weak open-source tracking
- uncertain provenance for legacy modules
Individually, each issue may look manageable. Together, they can affect fundraising narratives, acquisition diligence, enterprise contracting, and internal confidence in the product’s legal footing.
That is often the point where a company starts looking for counsel with documented experience in software ownership disputes, technology transactions, open-source compliance, trade secret protection, diligence cleanup, or founder-contractor IP issues. General business counsel can be helpful, but highly similar matters often benefit from attorneys who have seen the technical and evidentiary details before.
Short Summary
Reviewing contractor agreements, repository access, and open-source use in a software IP audit is really about proving three things:
- the company has rights in the code
- the company controls access to the code
- the company understands what third-party code is inside the product
The strongest audits are not purely legal or purely technical. They connect signed agreements, contributor history, repository governance, and dependency tracking into one evidence-based picture.
If your audit is turning up missing assignments, unclear ownership history, former contractors in private repos, or uncertain open-source obligations, an attorney with demonstrable experience in software IP and technology diligence may help you sort out what is fixable, what is urgent, and what may affect future deals.
Visit ReferU.AI to get matched with an attorney who has demonstrable experience in cases like yours — for free.
