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.
<aside> 💡 Scroll to the bottom for every post in this series.
</aside>
Software products are rarely built by one employee, on one machine, inside one legal entity.
A typical codebase may include:
That mix creates two separate questions: