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.
<aside> 💡 Scroll to the bottom for every post in this series.
</aside>
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:
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.
The first step in reviewing contractor agreements is not reading contracts. It is building a contributor map.