Skip to main content
Cayley | Independent Technology Assurance & Advisory

Digital IP and provenance

Digital IP and software provenance review

A software provenance review tests whether the company can demonstrate ownership of the code it runs in production, by examining contributor records, agreements, licence obligations and commit history.

Who uses this service

Lawyers
An independent technical view of who owns production source code, before advising on a transaction, dispute or warranty position.
Accountants and transaction advisers
Confirmation that code ownership and licence obligations support the deal, and identification of anything that affects terms or completion.
Acquirers
Evidence that the target holds clean title to the code and dependencies it relies on, and a register of the ownership and licence risks that remain.

When to commission it

  • An acquisition or funding round where code ownership is unclear or has not been documented.
  • Contributions by contractors or former employees where the IP assignment position is uncertain.
  • A concern that open-source licence obligations attach to code used in the product.
  • A dispute over who owns source code or a specific component.
  • Verification of software escrow deposits before relying on them.

Questions the review answers

  • Who owns the production source code?

  • Do contractor and former-employee contributions have executed IP assignments?

  • Do open-source licence obligations affect the product or the transaction?

  • Is there a clean chain of title from each contributor to the company?

  • Do third-party dependencies carry terms that restrict use or distribution?

Evidence normally requested

We request the evidence needed to test the technical position. The exact list depends on the matter.

  • Source repositories and full commit history
  • Contributor identities and the email addresses recorded against commits
  • Employment and contractor agreements for people who contributed code
  • Executed IP assignment and deed documents
  • The software licence register and third-party dependency manifests
  • Escrow deposit materials and release conditions where escrow is relied on

Method

  1. Define the ownership question

    We agree the code, components and time period in scope, and the specific ownership and licence questions the review must answer.

  2. Preserve and collect the evidence

    We collect repository history, contributor records, agreements, assignment documents and dependency manifests, and record how each was obtained.

  3. Test the ownership and licence position

    We match contributions to contributors, check each contributor against an executed agreement or assignment, and assess the obligations attached to open-source and third-party components.

  4. Rate risk and confidence

    We classify each finding by risk and by confidence, and state the evidence that supports it and the evidence that was missing.

  5. State the next action

    We set out the practical steps to close each gap, such as obtaining an executed assignment or addressing a licence obligation before completion.

What you receive

Document
Provenance report with an ownership and licence risk register
Intended reader
Instructing counsel, the acquirer and the board relying on the review
Risk classification
Each finding is classified as material risk, attention or information.
Confidence classification
Each finding is marked Confirmed, Supported, Indicative or Unknown, with the basis stated.
Includes
  • An executive summary of the ownership and licence position
  • A risk register listing each ownership and licence finding, its impact and its confidence
  • An evidence appendix recording the repositories, records and documents reviewed
  • An action plan setting out the step, owner and timing to close each gap
Verbal briefing
A verbal briefing to counsel or the deal team is included, to walk through the findings and their effect on the matter.

Typical timing

Typically 2 to 3 weeks, depending on repository size and how complete the contributor records are

Commonly excluded from this matter

Potential add-ons

The review covers the full agreed scope; it is bounded by the evidence made available and does not warrant that every ownership gap will be found. Where the matter needs more, the engagement can extend to include:

  • Technology-perspective view of codebase value: rebuild cost and key-contributor dependence
  • Open-source licence compliance review across the full dependency tree
  • Provenance evidence pack for counsel or a data room
  • Full technology due diligence: architecture, security, team and technical debt

Definition

Clients sometimes refer to this as a software IP audit. The engagement is an independent technical review. It does not provide a statutory audit or a legal opinion on title or infringement.

Independence and reliance

We act as an independent reviewer. We do not write the code we assess, and we do not remediate the gaps we identify, so our findings carry no incentive to understate or overstate the position.

We record the evidence behind each finding and mark the confidence in it, so counsel and the board can judge the basis for every conclusion and where the evidence was incomplete.

The report is prepared for the party that instructs us. We state any conflict before accepting the engagement and confirm the reliance position in the engagement terms.

Read how we maintain independence and reliance

Related services and reading

Technology Due Diligence

An independent review of software, architecture, team, security, scalability and technical debt before an investment or transaction decision.

Methodology

How we scope a review, preserve evidence, and classify each finding by risk and confidence.

Independence

How we manage conflicts, reliance and the separation between reviewing work and remediating it.

Discuss a matter

Provide a short outline of the decision, transaction or dispute. Do not submit confidential source code, credentials or personal information through the form.