IP Ownership in a Partnership: Joint Development Guide

Who owns IP in a partnership depends on what the contract says, so decide before you start. Separate what each side already owns (background IP) from what you create together (foreground IP), state who owns each, limit how partners may use your background IP, and cover improvements, publication, field of use and what happens at termination. Do not assume that paying for or contributing to something makes you the owner.

Startup lifecycle A to Z · Letter J · Stage: Grow

By the Revolutionary Startups editors · Reviewed 11 November 2026 · 12 min read · 2,638 words

Why partnership IP goes wrong

Startups often get their biggest opportunities from partnerships: a pilot with a large customer, a joint project with a university or a manufacturer, a development shop that builds the first version of the product. These deals feel friendly and urgent, and the IP terms are the part most often left vague, or accepted as written on the other side's standard form.

The trouble appears later. A partner claims ownership of an improvement. A buyer in due diligence finds that a key component is owned by someone else. An agency that wrote your code still holds the copyright. A larger company that learned your approach during a pilot launches something similar. In each case the fix is a clear agreement made at the start, when everyone is on good terms and you have the most negotiating strength you will ever have.

This guide explains the vocabulary, the common structures, the traps and a checklist you can bring to the negotiation. It is general U.S.-focused information, not legal advice. Because the stakes in partnership IP are high and the details vary so much, plan to have an attorney review any agreement, as covered in how to find an IP attorney for your startup.

Background IP versus foreground IP

Two terms appear in almost every serious partnership agreement. Learn them first, because the rest of the deal builds on them.

Background IP

Background IP is the IP each party owns before the collaboration begins, or develops independently outside it. For you, that includes your existing code, inventions, brand, data, tools and know-how. For the partner, it includes theirs. The usual starting position is that each side keeps its own background IP, and the agreement says so plainly. The key negotiation is how much of it the other side may use during the project and afterwards.

Foreground IP

Foreground IP (sometimes called project IP or arising IP) is what gets created during the collaboration. This is where the fights happen, because it may have been created by one side, by both, or by a mix of both sides' background IP. Common ways to allocate it include:

Each party owns what its own people create.
Both parties own everything created jointly, as co-owners.
One party owns all the foreground IP, and licenses it to the other for defined uses.
Ownership depends on the type of IP, for example the startup owns software improvements while the partner owns improvements to its own hardware.

Worked example

Suppose a startup has software that predicts equipment failures. A manufacturer agrees to a pilot that applies it to its factory data. The startup's software is background IP. The manufacturer's factory designs and raw data are background IP too. During the pilot, they create a new algorithm that works on the combination of the two. That algorithm is foreground IP. Unless the agreement says who owns it, nobody is sure, and each side may assume it is theirs. If it is the startup's core product, losing ownership could be fatal.

	Background IP	Foreground IP
When created	Before the project, or outside it	During the project
Default expectation	Stays with the owner	Depends on the contract
Key question	What can the other side use, and for what?	Who owns it, and who can use it afterwards?
Typical protection	Limited licence for the project only	Ownership clause, assignment, licence-back

Common structures: pilots, joint development and agencies

Pilot programs

A pilot is a time-limited trial in which a larger customer tests your product, often for free or at a discount. Pilots seem low risk, so IP terms are often skipped. They should state that you keep all rights in your product, the customer gets only a limited right to use it for the trial, any feedback or suggestions do not transfer ownership of improvements to the customer, and the customer's confidential data stays theirs. If the pilot involves customising your product, specify who owns the customisations.

Joint development agreements

A joint development agreement (JDA) is a contract in which two or more parties agree to develop something together. A good one names the project, assigns responsibilities, allocates background and foreground IP, sets how costs are shared, covers confidentiality and publication, and says what happens when the project ends. It is longer than a pilot letter because the stakes are higher: it often decides who can commercialise the result.

Joint ventures

A joint venture usually means a separate entity or a defined long-term collaboration. IP ownership may sit in the new entity or stay with the parents under licence. This is a corporate structuring question as well as an IP one, so you need both a corporate lawyer and an IP lawyer. Our guide to LLC versus C-corp explains the entity side at a basic level.

Agencies, dev shops and freelancers

If an outside firm builds your product, the default rule can surprise you. In the U.S., copyright generally belongs to the person who creates the work, with exceptions such as employees acting within their job. An independent contractor is generally not an employee, and many contractor works are not automatically "work made for hire". Paying for code does not by itself transfer ownership. You usually need a signed written assignment, or a licence at minimum. Wysebridge's free copyright guide explains how work made for hire and ownership transfers work. In practice, make sure the contract with any agency or dev shop says that all code and deliverables are assigned to you on payment, that they will not reuse your confidential material, and that any third-party or open source components are listed. See IP assignment agreements for startups and employee and contractor IP agreements for more.

Joint ownership pitfalls

It is tempting to settle a dispute by agreeing to "own it jointly". It sounds fair, and often creates more problems than it solves, because the rules for co-owners are not what most people assume. The details differ by type of IP and by country, so the following is a general outline. Ask an attorney how it applies to you.

Co-owned patents

Under U.S. patent law, as a general rule, each co-owner of a patent can make, use, sell and import the invention without the permission of the other co-owners and without having to share profits, unless they have agreed otherwise. That surprises people. A large partner who co-owns your patent could in principle use the invention itself, or license it to your competitors, without asking you, unless the contract restricts it. Also, as a general rule, all co-owners must join a lawsuit to enforce the patent, so one co-owner who refuses can block enforcement. Many other countries apply different default rules, which makes cross-border co-ownership harder still. Wysebridge's free patent law guide gives the underlying background on patent ownership and assignment.

Co-owned copyright

Co-authors of a joint work in the U.S. generally each hold an undivided interest, can each grant non-exclusive licences, and typically owe the other co-owners an accounting of profits. Granting an exclusive licence generally requires everyone.

Practical problems with co-ownership

No exclusivity. Your co-owner may be free to work with your competitors.
Enforcement. Suing infringers may need everyone's cooperation.
Investor concerns. Investors and acquirers often view jointly owned core IP as a defect, because they cannot be sure of exclusivity. See IP and startup valuation.
Deadlock and exit. If one co-owner is acquired or goes bankrupt, the new owner steps into its shoes.

Better options than plain joint ownership

Consider one side owning the IP and granting the other an exclusive licence in a defined field, or separate ownership of separate improvements with cross-licences, or joint ownership with a detailed agreement covering who may use it, who enforces it and how revenue is shared. See licensing startup IP basics for how licences are structured.

Field of use, improvements, publication and termination

Field of use

A field-of-use limit says that a licence applies only to a defined market, product type or application. If a larger partner needs to use your technology for one purpose, define that purpose narrowly and keep all other fields for yourself. For example, a licence for "factory equipment monitoring" should not quietly cover "all industrial and consumer uses". Vague fields are one of the most common ways a startup gives away more than it meant to.

Improvements

An improvement is a change or addition to existing technology. The question is who owns improvements to your background IP, whether made by you or by the partner. A "grant-back" clause, which requires you to give the partner rights in your improvements, can be harmless in a small field and damaging in a broad one. A fair position for a startup is that improvements to its own technology belong to the startup, and improvements to the partner's technology belong to the partner, with a clear rule for anything that mixes both.

Publication rights

Partners such as universities often need to publish research, and large companies may want to announce the deal. Publication can destroy trade secret status and start patent deadlines, because public disclosure can limit patent rights, especially outside the U.S. Agree on a review period before any publication, so that you can file patent applications and remove confidential information first. Our guide to protecting your startup idea when pitching and your year of IP deadlines explain why timing matters.

Confidentiality and trade secrets

Put the confidentiality terms in the same agreement or in an NDA signed first, and be specific about who may see what. Limit access to people who need it, and make sure the partner's employees and contractors are bound too. Wysebridge's free trade secret law guide explains why handling secrets carefully matters for keeping their legal status. See also NDAs for startups.

Termination and what survives

Plan for the end at the beginning. Decide what happens when the project finishes, a party quits, someone is acquired or the relationship sours. Clarify which licences end and which continue, whether the partner must return or delete your confidential material, whether foreground IP stays with its owner, whether the partner can keep using what it learned, and whether there is a restriction on working with your competitors. Check also what happens if the partner is acquired, since your deal may end up with a competitor.

A negotiation checklist for working with a much larger partner

Larger companies usually start with their own template, written to favour them. That is normal, and you can ask for changes. They may take longer, but they are routinely accepted, particularly if you are clear about what is essential. Work through the list below before signing.

List your background IP in a schedule to the agreement, and state that it stays yours.
Define the project and the field narrowly. A vague scope means vague rights.
Limit the licence you give to what the project needs: purpose, duration, field, non-exclusive, non-transferable.
Decide who owns foreground IP, and avoid default joint ownership of your core technology.
Protect improvements to your technology, and resist broad grant-back clauses.
Exclusivity cuts both ways. If you grant exclusivity, limit it by field, territory and time, and require minimum performance, otherwise you could be locked up while they do nothing.
Control publication and announcements with advance review and the right to remove confidential details.
Protect confidentiality with a mutual agreement and specific handling rules for source code and data.
Check data rights. Who owns the data used and generated, and may each side use it to train models or improve products?
Plan the exit: termination rights, what survives, return of materials, and change of control.
Check indemnities and warranties so that you are not taking on unlimited liability for their IP risk.
Get it all in writing and avoid starting work on a handshake or a promise to sign later.
Have an attorney review before you sign, and ask for time to do so.

Bargaining power you may not realise you have

Startups often believe they have no bargaining power. In fact, the partner wants your technology, speed or focus, so your IP is the thing of value. A realistic approach is to rank your needs: what is essential (ownership of your core technology, a narrow field), what you can trade (non-exclusive access, some data rights) and what is worth giving up for the right deal. If the partner will not accept the essentials, that tells you something about whether to proceed.

Where this fits in the startup lifecycle

Partnership IP typically belongs to the Grow stage, when you have something worth partnering on and larger companies take notice. The guide before this one, international IP protection for startups, matters if the partner operates across borders. The guide after it, licensing startup IP basics, goes deeper on the licence terms that many partnership deals rely on.

See the full sequence in the startup lifecycle A to Z. If you want to understand how patents, copyrights and trade secrets can be owned, assigned and licensed, Wysebridge's self-study course on U.S. IP law is a place to learn the basics. Because partnership agreements carry long-lived consequences, have them reviewed by an attorney who handles technology agreements.

Frequently asked questions

Who owns the IP in a partnership or joint venture?

Whatever the contract says. Without clear terms, the answer depends on who created it, whether employees or contractors were involved and which type of IP it is, and the result may be joint ownership no one intended. State in writing who owns background IP, who owns foreground IP and what each side may use.

What is the difference between background IP and foreground IP?

Background IP is what each party owned or developed independently before or outside the project, such as existing code or inventions. Foreground IP is what is created during the collaboration. Agreements usually leave background IP with its owner and set separate rules for who owns and may use the foreground IP.

What problems can co-owned patents cause?

Under U.S. law, as a general rule, each co-owner may use or license the patent without the others' consent or sharing income unless a contract says otherwise, and all co-owners generally must join to sue infringers. That can undermine exclusivity and enforcement. Other countries have different rules, so get advice before agreeing to joint ownership.

What IP terms should a pilot program with a large company include?

You keep all rights in your product, the customer gets a limited licence for the trial only, feedback does not transfer ownership of improvements, confidentiality covers both sides, customer data stays theirs, and customisations have a stated owner. Also set what happens when the pilot ends, including return of materials and no automatic exclusivity.

Does a dev shop or agency own the code it wrote for me?

Possibly, yes. In the U.S., copyright generally starts with the creator, and independent contractors are not automatically employees, so paying for code does not necessarily transfer ownership. Use a signed written agreement that assigns all deliverables to you, and have the agency list any third-party or open source components it used.

What is a joint development agreement?

It is a contract in which two or more companies agree to develop a product or technology together. It typically defines the project, each side's contributions, who owns background and foreground IP, how costs and revenue are shared, confidentiality, publication, and what happens when the project ends or a party leaves.

Key terms on this page

IP Licensing for Startups: Key Terms and Deal Checklist GuideIP licensing for startups: licensing out and in, exclusive vs non-exclusive, royalty vs flat fee, field of use, key terms and a deal checklist.
Employee Invention Assignment Agreements for Startups GuideEmployee invention assignment agreement basics: what employees, contractors and interns sign on day one so your startup owns the IP they create.
IP Assignment Agreements for Startups Explained IP guideIP assignment agreement basics for startups: founder IP assignment, invention assignment for employees, contractor IP ownership and what to include.
International IP Protection for Startups: A First Guide GuideInternational IP protection for startups: PCT patent filings, the Paris Convention priority year, Madrid trademarks, and when to go global with your IP.
NDA for Startups: When to Sign and When to Skip GuideNDA for startups explained: clause by clause, when to ask for one, when not to, who to ask, mutual vs one-way, how long it should last, and a decision table.

Learn more from Wysebridge

Wysebridge owns, operates and sponsors Revolutionary Startups, so these are links to its own free resources and directories. Read the disclosure.

Wysebridge U.S. IP law courseA 20-chapter self-study course on U.S. patent, trademark, copyright and trade secret law; module 1 is free.
Wysebridge patent law guideFree guide to U.S. patent law: provisional and non-provisional applications, claims, patentability and USPTO prosecution.
Wysebridge trade secret law guideFree guide to trade secrets: what qualifies, the DTSA and UTSA, NDAs and misappropriation.

Part of Protecting Your Startup · All guides · Glossary

Sources

General information, not legal, tax or financial advice. Reviewed 11 November 2026.