Ownership and IP Clauses to Negotiate with a Software Partner

Under U.S. copyright law, an independent contractor who writes code owns that code the moment it's written. That's the default rule, and it trips up a lot of founders, because most of them figured payment alone settled the question. Payment alone doesn't settle it, unless a specific clause sits in a signed contract.

The legal mechanism here is called "work made for hire," and it's narrower than most people think. Work made for hire applies automatically to employees, but for contractors, it only applies within nine categories written into the Copyright Act: things like contributions to a collective work or parts of a motion picture. Custom software isn't one of them, so when a founder hires a freelance developer or an agency to build an app, the work-for-hire doctrine doesn't reach it, no matter what anyone calls the arrangement on the invoice.

That means the fallback is a written assignment, and 17 U.S.C. § 204(a) is specific about what counts. It has to be a signed writing that transfers the copyright. Labeling an invoice "work for hire" doesn't do it, an email that says "we own all work product" doesn't do it, and paying the final invoice in full doesn't do it either, because the statute cares about the words on the page and the signature underneath them.

This gap shows up most with founders who used a freelancer or an AI-assisted MVP builder to get a first version running fast, then never circled back to formalize IP terms once things got serious; with teams that hired an agency, checked the price and the timeline, and skipped the IP clause entirely; and wherever a verbal handshake stood in for paper, because courts enforce the contract that was signed. The software development agreement is the signed writing the law is asking for, and everything below is about what has to be inside it.

Present assignment vs. agreement to assign — the drafting distinction that decides ownership

Two verb tenses separate a founder who owns their code from a founder with a lawsuit waiting to happen, and getting this wrong means no amount of goodwill or invoice-paying fixes it later. If a lawyer hands back a contract and says "will assign" needs to become "hereby assigns," that's worth paying close attention to, because it's the whole ballgame.

"Hereby assigns" transfers ownership the moment the contract is signed, or the moment a payment condition is met; it's present tense, done and complete. "Will assign" or "agrees to assign" is a promise about the future, and promises break. If a developer signs a contract with "will assign" language and later refuses to hand over the code, the founder doesn't own that code automatically, and what the founder has instead is a breach of contract claim: a lawsuit, legal fees, months of delay, none of which ship the product any faster.

Courts have drawn this line before, and the split is instructive. In Filmtec Corp. v. Allied Signal Inc., the Federal Circuit read "will assign" as a promise to assign in the future, not a transfer that had already happened. In Omni MedSci, Inc. v. Apple Inc. (2021), the same court read "shall be the property of" as a present, completed assignment. Same general subject, opposite outcomes, because the words chosen did different legal work, and that's the exact kind of parsing a court applies to a founder's contract too, so the phrasing can't be an afterthought, and it shouldn't be left to whatever template a developer happened to find online.

Strong assignment language covers source code across every version built, not just the final one, along with design files, documentation, and any other IP created under the engagement. It should take effect on final payment, and it needs a fallback: if some piece of IP can't legally be assigned outright, the developer instead grants an exclusive, irrevocable, royalty-free license to use it. That fallback matters more than it looks like it does, because a few categories of IP, moral rights among them, resist outright assignment in some jurisdictions.

Tying the assignment moment to full payment gives both sides something concrete to hold: no payment, no assignment. That's leverage the developer keeps until paid, and clarity the client keeps about exactly when ownership lands.

The five categories of IP in a software agreement and what each clause needs to do

Not all code in a deliverable was created equal, and a contract that treats it that way leaves gaps a lawyer finds later, usually at the worst possible time.

Background IP is what the developer brings with them: internal frameworks, utility libraries, methods built up over years of prior projects. The developer keeps ownership of this, and that's normal. What the client needs is a license: perpetual, royalty-free, irrevocable, and sublicensable, covering any background IP built into what gets delivered. Skip this license, and a founder can end up owning the "foreground" code on paper while being legally unable to run it, because it depends on a library the developer still owns outright. Worth asking for, before work starts, is a list of every piece of background IP the developer plans to use, by name.

Foreground IP is everything built new during the engagement: the custom features, the original code, the written deliverables. This should transfer fully to the client using present-assignment language, and it usually does in well-negotiated agreements, and a contract that departs from full foreground IP assignment to the client needs a reason on the table.

Derivative works and improvements sit in a gray zone that default law doesn't resolve cleanly, and the rules shift by jurisdiction. If a developer improves their own background tool while working on a client project, does the client own that improvement as a deliverable, or does the developer own it as an enhancement to something they already had? Silence in the contract doesn't answer that; it just guarantees an argument later, usually once the tool has become valuable enough to fight over.

Open-source components bring a different kind of risk entirely, and this is the one most contracts still get wrong. Some open-source licenses carry terms that can restrict how proprietary software built on top of them may be distributed — consequences that carry real business-model risk for a SaaS product if nobody flagged which library the login flow depended on. A contract needs a clause requiring the developer to disclose every open-source component used, and to get written approval before pulling in anything under a license that would force disclosure of the client's own code.

Joint ownership looks fair on paper and causes trouble in practice, and it's worth avoiding if there's any other option. In the U.S., each co-owner can generally license the IP independently, without asking the other or sharing what they earn from it. In many other jurisdictions, the rule flips, and co-owner consent is required for anything. Either way, enforcement gets complicated fast; if someone infringes the IP, it's not even clear who has standing to sue. A licensing arrangement almost always gets the same practical result without the ownership tangle, so there's rarely a good reason to reach for joint ownership in the first place.

How IP ownership breaks down specifically in MVP-to-production transitions

This is where the gap costs real money, not just legal tidiness, and the pattern tends to repeat in predictable ways.

A founder pays a freelancer or small agency to build an MVP. Speed matters more than paperwork at that stage, so the contract either has no IP clause or leans on "work for hire" language with no signed assignment behind it, and nobody notices, because nobody's looking. Then the founder raises a round, or brings on a technical co-founder, or gets a term sheet from an acquirer, and due diligence turns up the gap: the original developer may still own the codebase, in whole or in part, that the founder thought was already paid for and owned outright.

What changes once real users show up? Production reliability usually means rebuilding parts of the MVP, not just patching them, because shortcuts that were fine for a demo become structural problems under real load. If IP wasn't cleanly assigned during the MVP phase, that rebuild now carries an extra job: sorting out who owns the original code before any new engineering partner can safely touch it, extend it, or replace it. Unresolved background IP from the original developer can block a new team's ability to work on the codebase at all, and that's how a six-week rebuild turns into a three-month standoff.

The fix is structural. A Master Services Agreement should govern the overall relationship, with individual Statements of Work covering each phase. Every SOW should specify what IP is being created in that phase, what background IP from either side is in scope, and exactly when assignment takes effect. A transition clause should state plainly that the client owns everything built up to any termination date, and that the developer will help hand over materials, credentials, and documentation, rather than simply shipping a zip file and disappearing.

One more gap worth naming: scope creep. Features added after the original agreement was signed often fall outside the original IP clause entirely. A formal, written change request process, one that ties every new addition back to the same assignment terms as the original work, closes that gap. Without it, incremental features can sit in ownership limbo for months before anyone notices, and by then three more features have been built on top of the unresolved one.

Technical debt clauses — what the contract can require before shortcuts become your problem

Technical debt is an IP problem wearing a different hat. The Software Engineering Institute at Carnegie Mellon defines it as design or implementation choices that save time now but raise the cost of changes later. Owning code buried in undisclosed technical debt means owning a liability that happens to compile: no test suite, no documentation, a database schema nobody wrote down, three different logging systems because three different contractors touched it. That debt eats budget for years after the original invoice gets paid.

A code quality standards clause spells out coding standards, documentation requirements, and minimum test coverage, and it treats failure to meet them as a deliverable defect. That distinction matters, because defects trigger remediation obligations, while best-practice misses tend to just get shrugged off and forgotten.

A technical debt register clause requires the partner to keep a running, shared log of debt as the project moves along: missing documentation, no test suite, code written to be thrown away rather than extended, weak handoff habits between team members. Non-disclosure of known debt should count as a material breach, given what's actually at stake.

A remediation responsibility clause decides who pays when debt has to be paid down. If the partner cut a corner to hit a deadline they set, remediation is on them. If the client pushed the timeline or changed scope mid-build, remediation cost sits with the client. This has to get written down before work starts, because sorting it out afterward, once both sides remember the same events differently, rarely goes well for anyone.

A post-launch warranty period rounds this out: a defined window, 90 to 180 days is a reasonable starting range depending on how complex the system is, during which the partner fixes bugs at no extra charge, paired with actual response-time service levels. A warranty with no SLA attached leaves the obligation with no teeth behind it.

IP clauses that matter differently for nonprofits

Nonprofits carry a complication most commercial contracts don't have to plan for: a funder in the room who isn't a party to the software contract but still has opinions about the IP it produces, and sometimes a contractual say in it.

Grant-funded development often comes with strings attached. Some grant agreements require that foreground IP be assigned to the funder under certain conditions, or that the resulting software be released under an open license. A nonprofit signing a development contract without checking the grant terms first can end up with two signed documents that contradict each other, one promising the software to the funder, the other assigning it to the nonprofit outright, and nobody wins that argument quickly. Check the grant terms before the development contract goes out for signature, not after.

A mission-use perpetual license clause guarantees the organization can keep using the software for its charitable purpose even if the engineering partner gets acquired, pivots into something else, or shuts down entirely. This should survive termination of the development agreement itself, and it pairs well with source code escrow: if the developer stops operating, the source code releases to the nonprofit automatically, no negotiation required in the middle of a crisis that already has enough moving parts.

Data sovereignty deserves its own line item, too. Nonprofits often handle sensitive information about the people they serve, and that creates compliance exposure when the data lives inside a vendor's proprietary system rather than something the nonprofit controls directly. Owning the software, including the data layer, removes dependence on a vendor's pricing decisions or platform choices down the road. The development contract should explicitly assign the data models, schemas, and any automation logic, along with the visible application code sitting on top of them.

Employee IP assignment inside a nonprofit deserves a second look, too. Standard invention-assignment clauses, requiring staff to assign anything they build on the job, work cleanly at a for-profit company. At a nonprofit, where staff sometimes contribute to a product as part of a broader mission role rather than a straightforward employment deliverable, a license to the organization can be a cleaner, more defensible structure than full assignment. And co-ownership between staff and the nonprofit creates the same enforcement headache as co-ownership between contractor and client: unclear standing, unclear responsibility for defense, best avoided here too, for the same reasons laid out above.

Structural clauses in an engineering partner agreement that protect IP beyond the assignment

Assignment language answers who owns the code, but several other risks stay wide open even after that question gets settled.

The MSA and SOW structure does more than organize paperwork. The Master Services Agreement sets the IP rules for the whole relationship, assignment terms, background IP license, open-source policy, indemnification, once. Each Statement of Work then scopes what's being built, what background IP is involved, and when deliverables land. Set up this way, IP terms don't need renegotiating every time a new phase starts, since new work is automatically covered by terms already agreed to, which saves everyone a legal-review cycle each time scope changes.

An enforcement rights clause confirms that if the client owns the foreground IP, the client also holds the sole right to go after anyone who infringes it. Skip this, and a developer might retain standing to bring their own enforcement action, or worse, decline to cooperate with one the client wants to bring.

IP indemnification has the developer certify that the deliverables don't infringe on anyone else's IP rights, and the indemnification itself should cover legal defense costs and damages if a third party claims otherwise. Caps and carve-outs vary contract to contract, so this is worth negotiating directly rather than accepting whatever boilerplate shows up in the first draft a lawyer sends over.

Source code escrow matters most where background IP is licensed rather than owned outright, since it provides a release mechanism if the developer goes out of business or stops supporting the product. Trigger events need to be spelled out clearly: insolvency, material breach, acquisition, an end to ongoing support, so nobody's arguing about whether the trigger happened after it already has.

A termination and transition clause should say, in advance, what happens to code access, login credentials, and licensing rights when the relationship ends, for whatever reason. A genuinely values-aligned engineering partner should welcome this clause rather than resist it, since it signals they're building toward handing the client a stronger position. The clause should require the developer to cooperate in transitioning materials and institutional knowledge to the client or to a successor partner, regardless of why the relationship is ending, and regardless of whether the ending is friendly.

Clean IP documentation is often the difference between a due diligence process that closes on schedule and one that stalls for weeks while lawyers untangle who actually owns what got built.