Private equity and portfolios
Customer-funded development: who owns the code?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
In customer-funded development, the contract decides who owns the code, and ownership often stays with the software company that wrote it unless the statement of work or master agreement assigns it to the customer. Read both IP clauses for every funded project, and exclude customer-owned work, and work built from customer confidential material, from any license.
Key takeaways
- Paying for development does not by itself make the customer the owner; the contract's assignment language decides.
- Read the MSA together with every SOW and change order, because a later document can change what an earlier one said.
- Code written by contractors needs its own assignment trail before the company can treat it as company-owned.
- Customer-owned deliverables and anything built from customer confidential material are excluded from code or engineering licenses.
- When ownership is unclear, hold the repository out of scope until counsel resolves it.
Who owns code a customer paid you to build?#
Ownership of code a customer paid for is decided by contract first: the master services agreement, the statement of work, the order form and any change orders. Under 17 U.S.C. 201(b), the employer is treated as the author of a work made for hire and owns the copyright unless the parties agree otherwise in a signed writing, so code your employees write within the scope of their jobs generally starts with your company. A customer usually acquires ownership only when the contract assigns it.
Scope of employment is a factual test. The Ninth Circuit's model jury instruction asks whether the work is the kind the employee was hired to do, was done substantially within authorized hours and places, and was meant at least partly to serve the employer. Side projects and off-hours tools may fall outside it, which matters when a funded feature grew out of one.
In practice, software companies often keep ownership and give the customer a license to use what was built, especially when the work extends the core product. Customers with bargaining power push the other way and ask to own deliverables they funded. Both patterns are common, and the wording of each agreement controls, so no portfolio-wide assumption is safe.
For a sponsor or holdco general counsel, the question usually surfaces in diligence or when an acquired company wants to license code reviews, tickets or repositories. Either way, the answer has to be assembled contract by contract.
Common IP clause patterns and what they usually mean#
IP clause patterns in custom development contracts fall into a handful of recognizable types, and each carries a different consequence for licensing. The table describes general tendencies, not conclusions about any specific contract.
| Clause pattern | Usual effect on ownership | Consequence for a license |
|---|---|---|
| Vendor owns all IP; customer receives a license | Developer keeps ownership | Can be considered, subject to confidentiality review |
| Customer owns defined deliverables; vendor keeps pre-existing IP and tools | Split according to how deliverables are defined | Deliverables excluded; shared tools need tracing |
| Customer owns everything created under the SOW | Customer likely owns the funded work | Excluded |
| Work for hire label with no express assignment | Uncertain for code built by an outside vendor | Held pending counsel review |
| Joint ownership | Rights depend on the contract and applicable law | Held; often needs the other owner's agreement |
| No IP clause at all | Uncertain; other terms and conduct matter | Held pending counsel review |
| Customer data, specs or configurations marked confidential | Customer keeps its own material | Removed or excluded wherever it appears |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Where to find the documents that decide ownership#
The documents that decide ownership of customer-funded code are spread across sales, legal, finance and engineering, so the search has to cover all of them. Acquired companies often store contracts differently from the platform, which makes a written list of places to look worth the effort.
- Master services agreements, with their IP, confidentiality and license sections.
- Statements of work, order forms and change orders for each funded project.
- Customer purchase order terms and vendor agreements written on the customer's paper.
- NDAs and data processing agreements covering customer material shared during the project.
- Contractor agreements and employee invention assignment agreements for the people who wrote the code.
- Acquisition agreements, IP representations and disclosure schedules listing customer-owned work.
- Open source licenses for components in the funded code, especially copyleft terms.
Missing contracts and contractor gaps#
A missing contract is treated as an exclusion until the signed copy turns up. CRM attachments, e-signature archives, finance invoices that reference SOW numbers and old shared mailboxes are where lost agreements usually surface.
Contractor gaps are the other common hole. Early versions of many products were written by freelancers or development shops, and if their agreements lack an assignment to the company, the company may not own that code outright. Counsel can often fix the gap with a confirmatory assignment, but until then the affected modules stay out of scope.
Tracing funded work inside a merged codebase#
Funded work is hardest to trace when customer-specific code was merged into the core product rather than kept in a separate repository. Branches, forks, feature flags and configuration modules named after a customer are the usual clues.
Commit history helps. Match commits and pull requests to the dates and scope of each SOW, follow ticket references in commit messages back to the project, and record the directories and files touched. Then ask whether the contract's definition of deliverables reaches a shared component, or only the customer-specific layer on top.
Engineering records carry the same issue in another form. Tickets, design documents and code reviews about a funded feature may quote the customer's requirements, data samples or internal system names. Even where the developer owns the code, those passages are customer confidential information to remove.
Illustrative: a holdco reviewing an acquired inspection software company#
Illustrative: a fictional software holdco, Velloran Software Holdings, acquires a field inspection software company that sells to utilities and pipeline contractors. Two customers funded major features. One SOW assigns a custom asset-system integration to the customer as a deliverable. Another customer's MSA keeps all IP with the vendor and licenses a reporting module to the customer.
Holdco counsel and the CTO map both projects to repositories and commits. The integration repository, its tickets and its code reviews are excluded from any license. The reporting module stays in scope, with customer names, sample data and configuration files removed from code reviews and tickets. An early module written by a contractor lacks a signed assignment, so it is held out until a confirmatory assignment is signed.
The result is a license scope defined by repository and directory, with a written reason for every exclusion that the holdco can show a buyer or a future acquirer.
Decision rules for licensing code and engineering records#
Decision rules turn the contract review into a consistent scope across a portfolio. Apply them project by project and record the outcome against each repository.
Ownership is necessary but not sufficient. A customer contract can leave IP with the developer and still restrict how project records, such as requirements documents or meeting notes, may be used.
| Situation | Scope decision |
|---|---|
| Developer owns the code, with no customer material in it | Eligible for review in the licensable scope |
| Developer owns the code, but customer configurations or data appear in it | Eligible after the customer material is removed |
| Customer owns the deliverable under the SOW or MSA | Excluded, together with related tickets and reviews |
| Ownership unclear, joint, or written by an unassigned contractor | Held out until counsel resolves it |
| Customer contract restricts use of project records, regardless of ownership | Excluded or limited as the contract requires |
How SourceX handles customer-funded code#
SourceX handles customer-funded code in the Rights step of the SourceX five-step transaction, where scope is defined by repository, directory and record family rather than by the company as a whole. The fit check needs only metadata, such as repositories, ticket systems and date ranges, so no code is shared at that stage.
SourceX does not decide ownership; the supplier's counsel does. The SourceX Evidence Packet records licensing rights and exclusions, so a buyer sees what was in scope and why customer-owned work was left out.
Frequently asked questions
Does a work for hire clause make the customer the owner?
Not necessarily. Under 17 U.S.C. 101, a commissioned work made by an outside party counts as a work made for hire only if it falls into one of a short list of statutory categories, such as a compilation or a contribution to a collective work, and the parties agree in a signed writing. Custom software often does not fit neatly, so a work for hire label alone may not transfer ownership the way the parties expect, which is why many agreements add an express assignment. Counsel should read the full clause, its definitions and the governing law before concluding either way.
If the customer owns a deliverable, can its tickets and code reviews still be licensed?
Usually they are excluded along with the deliverable. Those records describe customer-owned work and often contain the customer's requirements and confidential details. Separating general engineering discussion from customer-specific content is rarely worth the risk.
Does an acquisition change who owns customer-funded code?
Generally no. The buyer steps into the position the seller held under each customer contract, subject to assignment and change-of-control terms. If the seller had assigned code to a customer, the buyer did not acquire it. Disclosure schedules and IP representations are the first place to check.
What about know-how the team gained on a customer project?
General skills and experience usually stay with the developer, and some contracts say so in a residuals clause. Specific code, documents and customer information are a different matter. Licensing records of how the team works is not the same as licensing customer-specific deliverables.
Who should lead this review inside a holdco?
Holdco or sponsor counsel usually leads, with the portfolio company's CTO mapping projects to repositories and finance confirming which SOWs were billed. Outside counsel joins where contracts are ambiguous or the customer relationship is significant.
Sources
- 17 U.S.C. 201(b) provides that in the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author and, unless the parties have expressly agreed otherwise in a written instrument signed by them, owns all of the rights comprised in the copyright. Source
- The Ninth Circuit model jury instruction states a work is within the scope of employment if it is the kind of work the employee is employed to perform, occurs substantially within authorized work hours and space limits, and is actuated at least in part by a purpose to serve the employer. Source
- 17 U.S.C. 101 defines a work made for hire as a work prepared by an employee within the scope of employment, or a specially ordered or commissioned work in listed categories if the parties expressly agree in a signed written instrument. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.