Background, foreground, sideground: the IP map
Every joint development dispute reduces to a map-reading error: the parties never agreed which IP layer a given asset sits in, or what rule applies to that layer. Draw the map first — three layers, three different drafting jobs:
| Layer | What it is | Who owns it | What the agreement must do |
|---|---|---|---|
| Background IP | Everything each party brings to the project — existing code, algorithms, datasets, designs, know-how, patents. It exists before (or outside) the collaboration. | Stays with its contributor. The collaboration never transfers it. | A licence to the other party to use it for the project: scope, duration, whether it survives termination, and whether it extends to exploiting the finished product. |
| Foreground IP | Everything the project itself creates — the jointly built software, inventions, designs, documentation and data generated in performing the project plan. | Owned according to the rule the parties agree. There is no reliable default — for software, statutory authorship turns on who controlled the making. | An express allocation model (single owner, field split, or a regulated co-ownership), plus written, signed assignments under section 22(3) of the Copyright Act wherever ownership must move. |
| Sideground IP | Improvements, bug fixes and extensions to a party's background IP made during the collaboration — the layer most agreements forget. | Usually allocated to the background owner, so each party's core asset stays whole. | An improvements clause assigning sideground to the background owner, with a licence back to the project (and, if needed, to the other party) so the collaboration can keep using it. |
The reason the foreground layer cannot be left to the law's defaults is specific to software. Section 1(1) of the Copyright Act defines the author of a computer program as the person who exercised control over the making of the program — the test the Supreme Court of Appeal applied in Haupt t/a Soft Copy v Brewers Marketing Intelligence. In a genuine collaboration, control is shared by design: both parties direct sprints, both contribute developers, both shape the specification. The statutory default is therefore ambiguous in exactly the situation where the asset is most valuable — which is why express allocation, executed through written and signed section 22(3) assignments, is non-negotiable.
Foreground ownership models
Once the map is drawn, the foreground needs an ownership rule. Three models cover almost every SA tech collaboration — in rough order of how often they end well:
Single owner + broad licence-back
One party owns all foreground IP; the other receives a wide, irrevocable, royalty-free (or royalty-bearing) licence to use it in defined ways. The cleanest model: one party can register, enforce, license and sell without asking permission, and the other still gets everything it commercially needs. Works best where one party is the natural home for the asset — the software house, the party funding the build, or the party whose product the technology extends.
Split by domain or field of use
Foreground IP is divided along a commercial seam: party A owns what relates to its industry or product line, party B owns what relates to its own, each cross-licensing the other where the seam blurs. Avoids the consent problem of joint ownership while letting both parties walk away owning something. The drafting burden sits in defining the fields precisely — a vague field definition just relocates the dispute.
Joint ownership + an express co-ownership regime
Both parties own the foreground together — but only ever with a full exploitation regime attached: who may license to third parties and on what consent rules, how revenue is shared, who may enforce against infringers and who funds it, what happens on sale or insolvency of a co-owner. Never agree bare "jointly owned" wording: under SA law co-owners of copyright generally cannot exploit or license the work without each other's consent, so an unregulated joint asset is one neither party can use.
The eight clauses that matter
Project plan, contributions + governance
What is being built, in what phases, who contributes which people, money and technology, and how decisions get made — a steering committee, voting rules, and change-control for the plan itself.
Background IP licences
Each party licenses its background into the project: exact scope, permitted users, whether the licence is needed to exploit the finished product (it usually is), and whether it survives termination. A product you cannot ship without the other party's background is not a product you own.
Foreground allocation + section 22(3) assignments
The chosen ownership model, expressed as present assignments in writing and signed — section 22(3) of the Copyright Act makes an unsigned or oral assignment of copyright invalid. Moral-rights waivers and patent/design filing rights belong here too.
Sideground + improvements
Improvements to one party's background made during the project are assigned back to that party, licensed to the collaboration, and carved out of the foreground definition — otherwise the foreground rule quietly captures slices of each party's core asset.
Confidentiality + publication controls
Mutual confidentiality over background, foreground and project information, plus publication and publicity controls — critical where one party wants to publish or demo and the other is keeping patentable subject matter unpublished.
Commercialisation rights + revenue share
Who may take the result to market, in which fields and territories, on what revenue-share or royalty terms, and what each party may do unilaterally versus only jointly. Field-of-use splits live or die on how precisely this clause is drawn.
Exit + abandoned-project rights
If one party withdraws, defaults or becomes insolvent: who may carry the project on, what licence the continuing party gets over the leaver's background and share of foreground, and what the leaver retains. An abandoned half-built asset that neither party can use is the default outcome without this clause.
Dispute escalation + deadlock
Collaboration disputes are governance disputes first: escalation from project leads to executives, mediation, then arbitration — plus a deadlock mechanism for the steering committee, because a 50/50 collaboration with no casting vote stalls by design.
When to use a JV company instead
A joint development agreement is the right vehicle for a bounded project: a defined build, a defined timeline, each party carrying its own costs and walking away with allocated rights when the work is done. It is the wrong vehicle for a sustained business. The moment the collaboration needs its own revenue, employees, premises, funding rounds or a brand the market will deal with, the contractual structure starts to strain — every new activity needs another clause, the IP allocation gets renegotiated by stealth, and neither party's balance sheet properly reflects the venture.
The cleaner answer for an ongoing venture is a joint venture company: the foreground IP is assigned into the company, the parties hold shares, and governance, funding, deadlock and exit live in a shareholders' agreement built for exactly those questions. Many collaborations sensibly do both in sequence — a joint development agreement for the proof-of-concept phase, with an agreed option to incorporate and contribute the foreground into a JV company if the technology works.
POPIA + data in collaborations
Tech collaborations increasingly run on shared datasets — customer records to train a model, transaction data to validate a product, user telemetry to tune a feature. Where that data includes personal information, each collaborator typically uses it for its own project purposes and makes its own processing decisions, which makes both parties responsible parties under POPIA — not a responsible-party-and-operator pair. That calls for responsible-party-to-responsible-party sharing terms: defined datasets and permitted purposes, a lawful-ground warranty from the contributing party, section 15 further-processing discipline, security minimums on both sides, and section 72 mechanics if either party or its infrastructure sits offshore.
Those terms can live in a data schedule to the joint development agreement or in a standalone data sharing agreement alongside it. Either way, decide the data questions with the IP questions, not after them: who owns the derived datasets and trained models the project produces is a foreground allocation issue, and what happens to shared personal information on exit belongs in the same termination clause as the IP wind-down.
Frequently asked
Who owns what we build together if the agreement is silent?
There is no good default. For computer programs, section 1(1) of the Copyright Act makes the author the person who exercised control over the making of the program — the test applied in Haupt v Brewers Marketing Intelligence. In a genuine collaboration, control is shared or ambiguous by construction: both parties direct the work, both contribute developers, both shape the specification. That ambiguity means ownership is decided after the fact by a court reconstructing who really controlled what — the most expensive way to answer the question. Express allocation in the agreement, supported by signed section 22(3) assignments, is the only reliable answer.
What is the difference between background and foreground IP?
Background IP is what each party brings into the collaboration — pre-existing code, algorithms, datasets, know-how and registered rights. It stays owned by its contributor and is merely licensed for the project. Foreground IP is what the collaboration itself creates — the jointly developed software, inventions and documentation. Background is about licensing (scope and survival); foreground is about ownership (who ends up holding the new asset). A third category, sideground, covers improvements to background made during the project, and is usually assigned back to the background owner so nobody's core asset gets fragmented.
Is joint ownership of the foreground IP a good idea?
Usually not — and never as a bare statement. Under SA copyright law, co-owners generally cannot exploit, license or assign the work without each other's consent, so "jointly owned" without more produces an asset neither party can use the moment the relationship sours. If joint ownership is genuinely the right commercial answer, it must come with an express co-ownership and exploitation regime: consent rules for third-party licensing, revenue-sharing, enforcement rights and cost-sharing, and exit mechanics on sale or insolvency. In most deals, single ownership with a broad licence-back, or a field-of-use split, gets both parties what they want with far less friction.
What happens if one party abandons the project?
Without an exit clause, the project dies with the partnership: the leaver's background licences typically lapse, the foreground sits half-owned or ambiguously owned, and the continuing party cannot lawfully finish or ship the product. A well-drafted joint development agreement answers this in advance — the continuing party gets the right to carry on alone, a surviving licence over the leaver's background to the extent needed to complete and exploit the product, and either ownership of (or an exclusive licence over) the foreground, sometimes against a royalty to the departed party. The time to negotiate abandonment rights is before anyone wants to use them.
Can each party use what we build in its own separate products?
Only if the agreement says so — this is the field-of-use question. The common pattern: each party receives a licence (or ownership slice) covering its own industry, product line or territory, so the fintech partner exploits the result in financial services while the logistics partner exploits it in logistics. The drafting lives in the field definitions: precise fields produce a clean coexistence, vague ones produce a dispute with extra steps. Where one party owns the foreground outright, the other's position depends entirely on the breadth and irrevocability of its licence-back.
Does anything change if a university or the CSIR is involved?
Yes — significantly. The Intellectual Property Rights from Publicly Financed Research and Development Act 51 of 2008 applies to IP arising from R&D funded with public money, which covers universities and science councils such as the CSIR. It imposes default institutional ownership, NIPMO oversight, restrictions on offshore assignment, and benefit-sharing duties to the institution's researchers — and a private partner does not escape it just because it co-funded the work, although full private funding at full cost can take a project outside the Act. Collaborations with publicly financed institutions need the Act assessed at term-sheet stage by a specialist; the general principles on this page do not substitute for that analysis.
How is confidential information different from foreground IP?
They overlap but do different jobs. Foreground IP clauses allocate ownership of protectable rights — copyright in the code, patentable inventions, registrable designs. Confidentiality clauses protect information regardless of whether it is protectable IP: roadmaps, negative results, datasets, pricing, the existence of the project itself. Much of a collaboration's real value (especially know-how and data) is protected only by confidence, not by copyright or patent — so the confidentiality clause needs to survive termination for a meaningful period and to bind each party even in respect of foreground the other ends up owning.
What does a joint development agreement cost in SA?
From R16,000 for a bilateral agreement with a defined project plan, background licences, an express foreground allocation with section 22(3) assignments, and exit mechanics. Multi-party collaborations, agreements with a co-ownership exploitation regime, and deals involving publicly financed institutions (IPR-PFRD Act analysis) are quoted on scope.