Joint Development Agreement (JDA): IP Ownership and Key Clauses

Written by: Prakhar Rai, Advocate | Founder, My Legal Pal | Enrolled with the Bar Council of India | Contracts and IP lawyer

Last reviewed: 12 October 2026


Quick answer

A joint development agreement (JDA) is a contract between two or more parties who build a product, technology or piece of intellectual property together without forming a new company. It exists to settle five things before work starts: what each side brings in (background IP), who owns what gets created (foreground IP), who may use it afterwards, how it stays confidential and when it can be published, and how the project ends.

If the agreement is silent, the default rules of whichever country’s law applies fill the gap, and those rules differ sharply. In the US a co-owner of a patent can usually license it to anyone without asking. In the UK and India the same co-owner cannot. That one difference is enough to wreck a deal, which is why the ownership clause deserves most of your drafting time.

This guide covers the clauses a JDA needs, the traps in each, and sample wording you can adapt. It is written for founders, product teams and in-house counsel working on technology, software, hardware and R&D collaborations.

What a joint development agreement is, and what it is not

In a JDA, two or more parties agree to work on a defined development project, usually a product, a technology or a research outcome. Each contributes something: engineers, code, a patent, data, lab access, money, a manufacturing line, a customer channel. The agreement sets the plan, the contributions, the ownership of the result and the route to market.

Three features separate it from nearby contracts:

  • No new entity. The parties stay independent. Nobody forms a company or a partnership.
  • Shared creation. Both sides contribute to what gets built. That is what makes ownership of the output a live question.
  • A defined project. It has a scope, milestones and an end, even if commercialisation follows.

Typical users are a startup working with a large company that has the scale, two companies combining complementary technology, a company working with a university or research lab, and a hardware maker working with a software firm.

JDA vs collaboration agreement vs joint venture vs development services

People use these terms loosely. The label does not decide the legal result, but it should match the deal.

Agreement Who builds Who owns the result Use it when
Joint development agreement Both parties, together Allocated deliberately: sole, joint or split by field You are co-creating technology or IP
Collaboration agreement Both parties, on a wider range of projects Depends on the project A general project, creative or commercial, with no focus on technology IP
Joint venture A shared entity or a long-term structured venture The venture owns it You are building a lasting business together, with shared equity and governance
Development services agreement One party builds for the other Usually the customer, by assignment One side pays, the other writes the code or builds the product
Licence agreement Already built Stays with the licensor The technology exists and you only need permission to use it

If one party is really commissioning work and the other is delivering it, you probably do not need a JDA. You need a services agreement with a proper IP assignment. Our guide to IP assignment agreements explains how that works.


Six questions to answer before anyone drafts

A JDA fails when it records a handshake that was never actually reached. Settle these first, in plain language, then draft.

  1. What exactly are we building, and how will we know it is done? A vague purpose produces disputes about whether an improvement is inside or outside the project.
  2. What does each side bring in, and what do they refuse to share? List the existing patents, code, datasets, know-how and tools.
  3. Who needs to own, use or sell the result, and in which fields and territories? One side may want the medical field, the other automotive. Say so now.
  4. Are the parties competitors? If yes, competition law enters the picture (see below).
  5. Is any public money, university or customer funding involved? Grants and institutional rules often attach rights to the output that your agreement cannot override.
  6. What happens if it works, and what happens if it does not? Success needs a commercial path. Failure needs a clean exit.

Write the answers into a one-page term sheet. It will make the contract shorter and the negotiation faster. If the deal involves an investor or large customer, the term sheet is also where negotiation support pays for itself.


The clauses a joint development agreement needs

1. Purpose, scope, milestones and governance

Define the project in a schedule, not in a recital. Include the objectives, the deliverables, the milestones, the timetable, each party’s tasks and the resources each commits. Add a short governance mechanism: a joint steering committee that meets on a schedule, decides routine issues and escalates the rest, plus a change-control step so scope cannot drift by email.

Use defined terms consistently. “Project”, “Background IP”, “Foreground IP”, “Improvements” and “Field” should each mean one thing everywhere.

2. Background IP: what each side walks in with

Background IP is anything a party owns or controls before the project starts, or develops independently of it. That covers patents, code, models, data, designs, tools and know-how.

The rule most JDAs need is simple: each party keeps its Background IP, and grants the other only a limited licence to use it for the project. Without that, partners argue about whether contributing a library, a dataset or a process quietly gave the other side rights to it.

Points to settle:

  • A schedule listing the Background IP each side contributes, or at least the key items.
  • A licence limited to the project, non-exclusive, non-transferable, and ending when the project ends unless the agreement says otherwise.
  • No implied licences. Say that nothing else is granted by conduct or estoppel.
  • Whether Background IP incorporated into the final product needs a continuing licence (it usually does, or the product cannot be sold).

Sample wording (illustrative):

Each Party retains all right, title and interest in its Background IP. Each Party grants the other a non-exclusive, non-transferable, royalty-free licence to use its Background IP during the Term solely to perform the Project. No other licence or right in Background IP is granted by implication, estoppel or otherwise. Where a Party’s Background IP is incorporated into a Project Deliverable, that Party grants the other the licence set out in Clause [X] to the extent necessary to use and commercialise that Deliverable.

3. Foreground IP: who owns what you create

Foreground IP is what the project produces: inventions, software, designs, data, documents, know-how. This is the clause that decides the value of the whole agreement. There are four common models.

Model How it works Fits when Watch for
Creator owns Whoever’s people created it owns it; the other side gets a licence Contributions are separable and clearly attributable Hard to apply when engineers from both sides work on the same thing
Joint ownership Both parties co-own everything created Contributions are intertwined and both need freedom to operate Default law on co-owners varies by country and can surprise you
One party owns, licenses back One party owns all Foreground IP and grants the other a licence in a defined field One side commercialises; the other needs limited use The licence-back terms carry the whole deal
Split by field or territory Each party owns, or has exclusive rights to, the results in its own market Parties serve different markets Needs a precise definition of “Field”, and a rule for results that cross fields

Two practical notes. First, do not leave Foreground IP to default law. Second, decide separately for each category: the core invention, improvements to a party’s own Background IP, data generated by the project, and project documentation can each have a different owner.

Improvements to Background IP deserve their own sentence. If Party A’s platform is improved during the project, A will almost always want to own the improvement to its platform. B will want a licence to use it. Agree this early, because it is the commonest source of dispute after a partnership sours.

4. Joint ownership: why the default rules are dangerous

Many founders pick joint ownership because it sounds fair. It is fair on paper and awkward in practice, because the law then decides what each co-owner may do, and the law is not uniform.

Question United States United Kingdom India
Can one co-owner use the patented invention freely? Yes, without the others’ consent and without accounting (35 U.S.C. § 262) Yes, without consent or accounting (Patents Act 1977, s.36) Yes, without accounting (Patents Act 1970, s.50)
Can one co-owner license it to a third party alone? Generally yes, though a licence from one co-owner does not stop the other co-owners from licensing too No, not without the other owners’ consent No, not without the other owners’ consent
Can one co-owner sue infringers alone? Generally not; all co-owners usually have to join Generally each co-owner may sue, but others must be joined Not clearly settled by statute; plan on joining all co-owners

This table is a general guide to default rules for patents, which can be changed by agreement and by later case law. Copyright and trade secrets follow different rules, and trade secrets are especially awkward to co-own. Get advice on the specific jurisdiction before relying on it.

The lesson is not that joint ownership is bad. It is that you must write the rules yourself: whether each co-owner may license without consent, whether they must share income, who enforces, and who pays. A good joint-ownership clause answers those four questions in plain terms.

Sample wording (illustrative):

Joint Foreground IP is owned by the Parties in equal undivided shares. Neither Party may assign or grant an exclusive licence of its interest without the other’s written consent. Each Party may grant non-exclusive licences within its Field without consent, subject to Clause [X] (royalty sharing). Each Party waives any right under applicable law to an accounting for profits from its own use of Joint Foreground IP, except as provided in Clause [X]. Each Party will join any enforcement action reasonably requested by the other, at the requesting Party’s cost.

5. Inventorship and assignment: the mechanics that make ownership real

Ownership clauses on paper mean little if the rights never actually reach the party who is supposed to own them. Three mechanics matter.

Inventorship is a matter of fact, not contract. In most jurisdictions the named inventors are the people who actually conceived the invention. A contract cannot make someone an inventor. It can, however, decide who owns the invention and require everyone to cooperate in filing.

Employees and contractors must assign to their own employer first. Each party needs written assignments from its people before it can promise anything to the other side. The US case Stanford v. Roche (2011) turned on the difference between a promise to assign (“agree to assign”) and a present assignment (“hereby assigns”), which is why present-tense assignment language matters. Our guide on why startups lose ownership of their product and the post on a contractor using code you paid them to build show what goes wrong when this is skipped.

Keep contribution records. Require invention disclosure forms, dated lab notebooks or repository logs, and a rule that each party notifies the other of any new invention within, say, 30 days. These records decide ownership disputes. They are also what investors check in diligence, as we explain in IP due diligence for startups.

6. Licences: field, exclusivity, sublicensing and royalties

If one side owns what the other needs to use, the licence terms are the real commercial deal. Settle:

  • Scope: field of use, territory, products covered.
  • Exclusivity: exclusive, sole (owner can also use), or non-exclusive. Exclusivity usually comes with performance duties.
  • Sublicensing and assignment: can the licensee pass rights to affiliates, manufacturers or customers? Can the licence move in a sale of the business?
  • Money: upfront fee, running royalty, minimums, or none (and then say so).
  • Survival: which licences continue after the project ends or the agreement terminates.

For software-heavy projects, see our guides on software licensing agreements and API licensing.

7. Patent filing, prosecution and enforcement

Decide who files, where, and who pays, before an invention exists. Patents are national rights, so a filing strategy means a country list and a budget.

  • Who files and controls? Usually the owner. For joint IP, appoint one lead with consultation rights for the other.
  • Who pays? Split costs, or have the owner pay and recover through the licence.
  • Step-in rights. If the lead decides not to file or to abandon an application, the other party should get the option to take it over at its own cost.
  • Enforcement. Who may sue, who funds it, how recoveries are divided, and whether the other party must join as a plaintiff.

For background on the filing side, see our patent registration services, patent search and freedom-to-operate work, the explainer on what a patent is and how it works, and the guide to patent registration in the USA. Brands and creative output created in the project may also need trademark and copyright protection. Our intellectual property page shows how these fit together.

8. Confidentiality, trade secrets and publication

Confidentiality does more than keep secrets. In most countries, a public disclosure before a patent filing can destroy novelty and kill the right to a patent. The United States gives inventors a one-year grace period for their own disclosures, but many other jurisdictions give none or only a narrow one, so assuming a grace period is a risk.

A JDA should include:

  • A confidentiality clause (or a separate NDA signed before talks begin) covering information exchanged before, during and after the project.
  • A publication review clause. A party that wants to publish a paper, present at a conference or post code must send it to the other first. The other side gets a fixed period, often 30 to 60 days, to object and to file patent applications. Universities will insist on publication rights, so agree the process rather than a ban.
  • Rules for residual knowledge: whether engineers can use general know-how they retain in their heads. Many partners fight over this clause. Define what “general skills and experience” means and exclude specific confidential details.
  • Trade secret hygiene: access controls, need-to-know, and records of who saw what.

Sample wording (illustrative):

A Party wishing to publish or present any Foreground IP or results of the Project must deliver the proposed publication to the other Party at least [45] days before submission. The other Party may, within that period, (a) require removal of its Confidential Information, and (b) require a delay of up to [60] further days to allow patent applications to be filed. No publication may disclose the other Party’s Confidential Information without consent.

9. Commercialisation: the road from prototype to product

Many JDAs fail not in development but at the moment the product works and nobody has agreed who sells it. Address this directly.

  • Right of first negotiation (ROFN): if one party wants to commercialise, it must first negotiate in good faith with the other for a fixed period. If no deal is reached, the party is free to go elsewhere.
  • Right of first refusal (ROFR): the other party can match any third-party offer before the owner accepts it. This is stronger than an ROFN and more restrictive.
  • Milestone-triggered rights: exclusivity or option rights that begin when a development milestone is hit, and lapse if the holder fails to commercialise within a period (“use it or lose it”).
  • Follow-on agreements: a pre-agreed outline for supply, manufacturing, distribution or licence terms, so negotiations after the JDA are not from scratch.
  • Money: how revenue, margin or royalty is shared, how costs are allocated, and what minimum commercial effort each side owes.

10. Warranties, indemnities and liability

Development is uncertain, so do not warrant results. A sensible package is:

  • Mutual warranties of authority, and that each side has the right to contribute its Background IP.
  • A limited, knowledge-qualified statement about third-party infringement, rather than an absolute guarantee.
  • An express disclaimer that the project will succeed or that Foreground IP will be valid or enforceable.
  • A liability cap, with carve-outs for confidentiality breach, deliberate misuse of the other party’s IP and indemnities.
  • An IP indemnity for third-party claims caused by a party’s own Background IP.

See how a missing cap can sink a young company in our post on limitation of liability.

11. Third-party, open-source and AI components

Modern projects rarely start from a blank page. Add a short clause requiring each party to disclose third-party and open-source components it will use, and to avoid licences that force the combined product to be open-sourced (strong copyleft licences) without agreement. If you use AI tools or train models on project data, say who may use project data for training, who owns the model weights and outputs, and what happens to data after the project. Note that in the US, purely machine-generated material has no copyright, and inventors on patents must be natural persons, so human contribution should be documented.

12. Competition law

If the parties compete, or the JDA restricts what they may do outside the project, competition law applies. Look at:

  • Scope limits: restrictions that go beyond the project (for example, banning each party from developing similar technology alone) attract scrutiny.
  • Exclusivity and field splits: these can be fine if proportionate, and problematic if they divide markets.
  • Information exchange: sharing prices, costs or strategy beyond what the project needs.

In the EU, Commission Regulation (EU) 2023/1066 exempts qualifying R&D agreements from the cartel prohibition, applying from 1 July 2023 to 30 June 2035, and the safe harbour for competitors generally depends on the parties’ combined market share (25% at the time of writing). The UK has its own R&D block exemption. In the US, the FTC and DOJ withdrew their Antitrust Guidelines for Collaborations Among Competitors in December 2024, so the position is now assessed case by case. India’s Competition Act, 2002 also applies to agreements that affect competition. Treat this as a screening check, and take advice if the parties are direct competitors.

13. Term, termination and exit

Termination is where most JDAs are weakest, and it is the part that matters when relations break down.

Triggers. List them: material breach not cured within a set period (say 30 days), insolvency, change of control of a party, failure to hit a milestone by a long-stop date, or either party leaving on notice if the project is no longer viable.

Consequences. Spell out what happens next:

  • Work in progress. Who owns partly finished Foreground IP? A common rule: it goes to the party whose people created it, with a licence to the other.
  • Licences. Which licences survive, and for how long. Licences needed to use delivered results should survive. Licences needed only to build should end.
  • Materials and data. Return or destruction of confidential information and project data, with a certificate.
  • Payments. Accrued fees, royalties and cost sharing up to termination.
  • Survival. Name the clauses that continue: IP ownership, confidentiality, publication, liability, governing law and disputes.

Sample wording (illustrative):

On expiry or termination: (a) each Party retains ownership of the Foreground IP allocated to it under Clause [X]; (b) licences granted under Clause [Y] to use Foreground IP incorporated in delivered Project Deliverables survive on their terms; (c) all other licences end; (d) each Party will return or destroy the other’s Confidential Information within [30] days and certify in writing; and (e) Clauses [list] survive.

14. Governing law and disputes

IP is territorial, but the contract can pick one governing law. Choose a law that both sides understand and that has predictable courts and enforcement. For cross-border JDAs, arbitration under an institutional rule with a neutral seat is common, because arbitral awards are widely enforceable under the New York Convention. Build a ladder: first the steering committee, then senior executives, then mediation, then arbitration or court. Always carve out the right to seek urgent injunctive relief to protect confidential information and IP, so a dispute process does not leave you exposed.

Our post on arbitration vs litigation in cross-border contracts compares the options, and our negotiation and mediation services cover disputes that have already started.


Cross-border JDAs: what changes when parties sit in different countries

  • Governing law is not the same as IP law. The contract may follow English or New York law, while a patent is governed by the law of the country that granted it.
  • Export controls. Sharing certain technology across borders, including with foreign nationals inside a lab, may need a licence. Check this before any technical exchange.
  • Tax. Royalties and service fees can attract withholding tax. A treaty may reduce it, but you must plan for it.
  • Stamp duty and formalities. In India, stamp duty on agreements is state-specific, and unstamped documents cause evidence problems. Other countries have their own execution rules.
  • Data. If personal data crosses borders, data protection law applies on top of the JDA.

If you are in India or the US, see our pages on contract lawyers in India and contract lawyers in the USA.


Quick JDA checklist

Area Have you settled it?
Purpose, deliverables, milestones Written in a schedule, with change control
Background IP Listed, retained, project-only licence, no implied rights
Foreground IP Ownership model chosen per category, including Improvements
Joint ownership rules Licensing, income, enforcement and costs spelt out
Assignments Employees and contractors have assigned to their own employer
Records Invention disclosure and notebook process agreed
Licences Field, territory, exclusivity, sublicensing, royalties, survival
Patents Filing lead, countries, cost split, step-in rights
Confidentiality and publication NDA, review period, residuals clause
Commercialisation ROFN/ROFR or milestone rights, follow-on terms, effort duty
Liability No result warranties, cap, carve-outs, IP indemnity
Third-party and AI Open-source disclosure, data and model ownership
Competition law Scope checked, especially if parties compete
Termination Triggers, work in progress, surviving licences, return of data
Disputes Governing law, escalation, arbitration seat, injunction carve-out

Mistakes that cost the most

Signing without defining Foreground IP. If “jointly developed technology” is undefined, each side argues it means the part they did not build.

Relying on default joint ownership. As the table above shows, the default depends on country and can allow a partner to license your invention to your competitor.

No assignments from staff and freelancers. The agreement promises ownership the party never had.

Forgetting Improvements. A party’s platform is improved during the project and the improvement ends up owned by the partner.

Publishing too early. A conference abstract or open-source commit before filing can ruin patent rights.

No exit terms. The relationship fails and nobody knows who owns half-built code.

Using a template from a different deal. A services-contract template with a few words changed will not govern a co-creation project.


How we can help

My Legal Pal works with startups and businesses on joint development and collaboration deals worldwide, from the first term sheet to a signed agreement.

  • Draft your JDA: a development agreement built for your project, your IP and your countries, on a fixed fee agreed before work starts.
  • Review your partner’s draft: we read the agreement you have been sent, flag the ownership and licence traps, and tell you what to change.
  • Negotiate the terms: counter-language and support through the redline exchange.
  • Protect the output: patents, trademarks and copyright for what the project creates.

Planning a joint development project? Tell us the parties, what each is contributing and where you are on the deal. We will come back with a clear scope and fixed fee. Get a quote or message us on WhatsApp.

This article is general information, not legal advice for your situation. The law on co-ownership, inventorship and competition varies by country and changes over time.


Frequently asked questions

What is a joint development agreement?

A joint development agreement is a contract in which two or more parties agree to develop a product, technology or piece of IP together, without forming a new company. It sets the project plan, what each side contributes, who owns what is created, how it can be used and how the project ends.

What is the difference between background IP and foreground IP?

Background IP is what a party owns before the project or develops independently of it. Foreground IP is what the project creates. Each party normally keeps its Background IP and licenses it for the project, while Foreground IP is allocated by the agreement.

Who owns the IP in a joint development agreement?

Whoever the agreement says. Common models are creator owns, joint ownership, one party owns and licenses back, or ownership split by field. If the agreement is silent, default law decides, and it differs by country. In the US a patent co-owner can usually license without consent, while in the UK and India consent is needed.

Is a joint development agreement the same as a joint venture?

No. A joint development agreement is a contract for a defined project and does not create a company. A joint venture usually involves a shared entity, shared equity and ongoing governance. A JDA can lead to a joint venture if the product succeeds.

Do I need a JDA or a development services agreement?

If both sides contribute to creating the technology, use a JDA. If one party pays another to build something for them, use a development services agreement with an IP assignment to the customer.

Can a JDA be terminated early?

Yes, if it says so. Good agreements list termination triggers such as uncured breach, insolvency, change of control or a missed milestone, and set out what happens to work in progress, licences, confidential information and payments.

Does a JDA need to be registered or stamped?

Registration is generally not required for a JDA on technology development, but stamp duty and execution formalities depend on the country and, in India, on the state. A real estate JDA in India has additional registration and stamping requirements. Check this before signing.

How much does it cost to have a JDA drafted?

It depends on the number of parties, the IP involved and the countries. We quote a fixed fee after seeing the deal, agreed before work begins.


Related reading

Legal references

35 U.S.C. § 262 (joint owners of a patent); Patents Act 1977 (UK), s.36; Patents Act 1970 (India), s.50; Board of Trustees of Leland Stanford Junior University v. Roche Molecular Systems, Inc., 563 U.S. 776 (2011); Commission Regulation (EU) 2023/1066 on R&D agreements; Competition Act, 2002 (India); FTC and DOJ withdrawal of the Antitrust Guidelines for Collaborations Among Competitors (December 2024).

Leave a Reply

Your email address will not be published. Required fields are marked *

Are you human? Please solve:Captcha