IP Assignment vs License in Custom Software Agreements

Assignment transfers ownership, while licensing grants permission, and the contract must match what the buyer needs to control. For founders moving from an MVP to a lasting product, Quwa Labs is one option for rebuilding with clear IP terms and ongoing maintenance, but any engineering partnership starts with understanding who owns the existing code.

Why paying for custom software does not make you its owner

The founder’s starting assumption is simple. Paying someone to build a product should mean owning what they build. Under US copyright law, however, the developer generally owns the code unless the rights are assigned in writing or the work qualifies as work made for hire. The invoice records payment. Without a written assignment, a client may have only an implied, non-exclusive license to use the software.

That gap matters because using a product is not the same as controlling its future. A founder may need to change it, switch vendors, raise funds, or get ready for an acquisition. WIPO’s July 2026 guide explains that developers keep IP ownership unless a software development agreement assigns it to the client. Ownership is therefore a contract issue from the start.

How assignment and licensing differ as legal mechanisms

Assignment transfers ownership from the assignor to the assignee. The creator gives up all right, title, and interest in the IP covered by that transfer, and the recipient becomes its owner. A license does something different. The creator keeps title and grants defined permissions, which may be restricted or revocable depending on the terms. A contract that only licenses software does not make the client its owner, however much the client paid.

The practical distinction is between holding a right and having permission to exercise it. Buyers generally want assignment because it removes an ownership dependency on the creator. Creators generally prefer licensing because it preserves their title while allowing others to use the work. A license can support a working product without giving its buyer the control an assignment would provide.

The scope of either mechanism matters as much as its name. Software IP is a bundle that includes copyright, patents, trade secrets, and trademarks. An assignment or license may cover some of those rights without covering the others. The phrase “IP rights” therefore needs a precise definition rather than an assumption that it captures everything.

Why "agrees to assign" is not the same as "hereby assigns"

The wording “agrees to assign” or “shall assign” creates a promise to transfer rights later. By contrast, “hereby irrevocably assigns” makes the assignment in the agreement itself. Present-assignment language can make ownership vest as the code is created, with no need for a later signature.

A further-assurances covenant should accompany that transfer so the vendor must provide confirmatory documents when needed. A power-of-attorney clause can also support the process if the vendor dissolves or refuses to cooperate. These provisions matter most when a relationship ends or a project changes hands before completion. For a handoff to a long-term partner such as Quwa Labs, they help keep an unfinished paper trail from becoming a title dispute.

“Work made for hire” is a narrow copyright-only rule under 17 U.S.C. § 101, and most software deliverables do not fit its nine enumerated categories. Where the designation is valid, it can avoid the copyright-termination right that arises 35 years after an assignment under 17 U.S.C. § 203. It is therefore a backstop to layer with assignment.

Timing is a separate choice that the contract must make clear. When transfer happens upon full and final payment, the vendor has leverage in disputes over payment. When transfer happens continuously as code is created, it protects the client’s build pipeline. A present-tense verb cannot resolve that commercial choice if another provision postpones when ownership passes.

What a well-structured IP clause actually contains

A complete IP clause has four levers. The first is ownership of the foreground IP created under the engagement. A present assignment and further-assurances covenant establish the transfer and support its documentation. Its scope should cover “patent, copyright, trade secret, and other Intellectual Property Rights”. Otherwise, the client may receive less than the full set of rights the work requires.

The second lever separates background IP from those deliverables. Each party keeps what it owned before the contract, including the vendor’s pre-existing tools, libraries, frameworks, and methodologies. That reservation is commercially reasonable, but its boundaries matter. A carve-out broad enough to cover the custom deliverable defeats the assignment above it. Open-source libraries built into the software also need attention because their licenses may have restrictions that ownership language cannot remove.

The third lever is the license-back for vendor background IP embedded in the deliverable. It should be irrevocable, non-exclusive, perpetual, and royalty-free, with rights to use, modify, and maintain the result. Without those permissions, a client can own custom code but lack the rights to run it. The fourth lever addresses feedback, data, and improvements. In bespoke services, the client owns its data, while usage and AI-training rights are still up for negotiation in 2026.

What vendors actually retain when the contract is silent or vague

Consider the commercial consequence of paying for code that the vendor still owns. Without an explicit IP transfer, the vendor can retain the right to reuse that code for competing clients. The buyer has funded development without necessarily securing exclusivity over its result. A weak clause therefore does more than leave an abstract question unanswered. It leaves powers with the vendor that the buyer may have assumed were part of the purchase.

Those powers matter most when the client wants to have development done elsewhere. If the client holds only limited permission to use the software, the contract may not permit another team to modify it. The client needs authority to authorize the work without further vendor cooperation. Silence has left a dependency where the buyer expected an asset.

Developer bankruptcy adds a different risk because vendor-owned IP may become part of the developer’s estate and be liquidated. Reversion-upon-insolvency language is therefore a protection to address in the agreement. Undisclosed open-source dependencies create another kind of exposure. WIPO warns that restrictive licenses may get in the way of entering a market and raising funds.

How weak IP terms interact with technical debt to compound the risk

An MVP built under time pressure can carry architectural shortcuts into the next stage of the business. Cutting the scope, using freelancers, and working with AI-assisted builds can all be part of that rush to launch. Technical debt then demands changes just as real users make reliability more important. If the client does not own the code or have broad enough license rights, fixing that debt may need the original vendor’s permission. A technical problem has acquired a legal constraint.

The founder needs authority to authorize a third party to refactor and maintain the code. Ownership can supply that control, but a broad enough license can also permit the work. Conversely, restrictions that survive termination may prevent independent remediation even after the original development relationship ends. That is why the IP review and the rebuild cannot be treated as unrelated tasks. The legal scope determines what the engineering team is allowed to change.

Quwa Labs works at this transition by rebuilding products on solid foundations and continuing as a long-term technical partner. A founder might instead bring development in-house or engage another provider, but each approach needs the same permission to modify and maintain the product. The shift from getting to launch to staying live requires both a stronger engineering foundation and the rights to sustain it. Neither can substitute for the other.

The bespoke-services regime versus the SaaS regime, and why confusing them is dangerous

The right ownership model depends on what the client is buying. In bespoke services, the market-standard structure assigns custom deliverables to the client, reserves the vendor’s background IP, and licenses any retained materials embedded in the result. This is a negotiated allocation.

SaaS starts from a different position. The vendor owns the platform and its improvements, while the client owns its uploaded data. Client feedback is licensed to the vendor. Those terms fit access to a vendor-owned platform. They do not answer the same commercial need as ownership of software built to a client’s specification.

The useful test is therefore whether the buyer is commissioning a custom product or buying access to an existing platform. Trouble begins when a bespoke development agreement imports SaaS-style ownership terms. The client pays to have software built but receives only subscription-style permission to use it. Nonprofits and early-stage founders are especially at risk when they accept terms written by the vendor without seeing that shift. The label on the agreement matters less than the rights it actually allocates.

The vendor's legitimate objection to full assignment, and where the line sits

Vendors rely on starter kits, UI frameworks, and internal boilerplate to deliver work efficiently across engagements. Assigning those materials exclusively to one client would undermine that business model. The buyer gains little by pursuing ownership of tools that are not what makes its product distinctive. Negotiating effort is better spent on the custom logic, data model, and differentiating features.

The practical boundary is between a specific reservation and a blanket one. Vendors should enumerate retained tools in a contract exhibit rather than claim a broad category that could swallow most of the deliverable. A named set of tools is auditable. It lets the buyer see which elements are assigned and which remain subject to a license. It also helps both parties decide more clearly whether a component they disagree over is background IP.

The remaining negotiation concerns the scope of the license-back. A client does not need exclusive ownership of a shared framework if it has durable rights to use and modify the deliverable containing it. But a license that prevents modification or sublicensing can obstruct maintenance and handoff. The reasonable compromise preserves the vendor’s reusable assets without preserving a veto over the client’s product.

What to check in your existing MSA before the next milestone, hire, or acquisition conversation

Before the next milestone, hire, or talk of an acquisition, check the existing MSA with four questions in mind. First, establish whether it says “hereby assigns” or merely “agrees to assign” or “shall assign”. Next, check whether the scope covers patents, trade secrets, trademarks, and copyrights. Then check whether the vendor keeps background IP only in named tools or through a broad reservation. Finally, check whether the license-back allows modification and maintenance as well as use.

WIPO says to ask for source code, documentation, and access credentials. Title is of limited operational value if the next engineering team cannot reach the materials it needs. Termination provisions should make clear what happens to code access, licensing rights, and ongoing support when the relationship ends. For nonprofits, volunteer-created work also needs a written assignment signed by the contributor to transfer copyright.

For a founder whose MVP came from freelancers or AI tools, understanding the existing contract comes before engaging a new engineering partner. A long-term agreement, including the ongoing maintenance plan offered by Quwa Labs, can set clear IP terms and spell out who is responsible for keeping the product running. An in-house team or another provider still needs the same legal foundation. The audit prepares the client to reach the next stage with both the rights to evolve the product and an engineering arrangement that can carry that work forward.