Software IP ownership checklist for a company sale

Map the assets before assessing ownership

Start with the products and capabilities a buyer believes it is acquiring. Map production applications, libraries, mobile apps, APIs, scripts, models, documentation, designs, databases, domains, brands and trade secrets. Connect every material asset to its repository or custody location, creator or provider, first-use period and business owner.

The Swiss Federal Institute of Intellectual Property explains that source code can receive copyright protection, while ideas, concepts, algorithms and instructions are not protected as such. Copyright is therefore only one layer. Contracts, licences, confidentiality, trademarks, domains and operational control need separate evidence.

Trace founders, employees and contractors separately

The starting point matters. Record work created before incorporation, founder contributions, employment dates and job duties. For every contributor, connect identity, relationship, dates, deliverables and repository activity to the governing agreement.

The Swiss IPI guidance for businesses notes a statutory exception for computer programs created by employees in the course of their contractual duties. Article 17 of the Swiss Copyright Act addresses the employer's exclusive rights of use in that defined setting. It does not justify assuming that the company automatically controls contractor code, pre-existing founder code or every non-software work. Ask Swiss counsel to apply the rules to the actual facts.

For freelancers and agencies, review signed terms, definition of deliverables and background materials, rights granted, territory, duration, sublicensing, further development and handover. Payment alone is not a substitute for clear rights language.

Separate owned, licensed and third-party components

A company does not need to own every dependency. It needs to know what it owns, what it licenses, under which conditions and whether the expected transaction and future operation fit those conditions. Inventory commercial SDKs, cloud services, datasets, fonts, media, models, APIs and embedded technology.

For each dependency, record vendor, product, version, purpose, licence, term, fees, user or deployment limits, transfer or change-of-control language, termination and replacement plan. Reconcile procurement records with actual repositories and production. A licence bought by one employee, customer or affiliated entity may not cover the company.

• Confirm who is the contracting party.
• Match the licence to actual use and scale.
• Identify customer-owned and customer-licensed inputs.
• Flag services essential to build, deploy or operate.
• Record notices and attribution obligations.

Make open-source use visible and governed

Create a software component inventory from repositories and build artefacts, then add package, version, source, licence, use, modifications and distribution model. Automated scans help discover components but do not replace review of ambiguous or custom code.

Different licences impose different conditions. Do not label all open source as a problem or assume a permissive licence removes every obligation. Preserve copyright and licence notices, document review and exception processes, and escalate components that are modified, distributed, embedded in customer deliverables or missing reliable provenance.

The useful buyer answer is not "we use no open source." It is "we know what we use, why we use it and how we meet the applicable conditions."

Build an IP provenance ledger

Use one ledger with component, author or provider, relationship, creation dates, contract, rights granted, territory and duration where relevant, open-source licence, evidence link, exception and remediation owner. Link it to the technical inventory instead of maintaining an isolated legal spreadsheet.

Illustrative example: an agency built a reporting module five years ago. The repository and paid invoices exist, but the agreement gives the company a limited right to use the deliverable and says nothing about source-code modification. Mark the item amber or red pending legal review. Possible responses may include a confirmatory agreement, a licence clarification, replacement or transaction disclosure. The appropriate action depends on the facts and counsel's advice.

1. Identify material assets and repositories.
2. List every human and third-party source.
3. Attach executed agreements and licences.
4. Compare legal records with code and production.
5. Classify gaps by operational and transaction impact.
6. Assign remediation and preserve disclosure history.

Reconstruct the product history and corporate perimeter

Ownership gaps often arise when the product predates the current company. Reconstruct incorporation, founder activity, previous entities, asset contributions, restructurings and acquisitions on one timeline. Note when repositories, domains, cloud accounts and customer contracts moved. If one entity paid developers while another signed customers, identify the agreement that connects them.

For acquired products, retain the purchase agreement, schedules, assignments, consents and closing evidence. Compare the acquired asset list with what the current product still uses. For founder contributions, distinguish an assignment from a promise to assign later. Record signatures and effective dates. Do not fill a historical gap with a present-day assumption.

Review brand and domain control alongside code. Confirm registrant, administrative access, renewal method and the company named in any registration. Record trade names used without registration and the territories in which the business operates. Qualified advisers can determine whether searches, filings or corrective instruments are appropriate.

Keep ownership evidence current after the review

Make provenance part of onboarding and procurement. New employment and contractor engagements should use approved terms before work begins. New third-party software should have a named business owner, licence record and security review. Contributions should be linked to an identified account, reviewed and retained in company-controlled repositories.

Define an exception process. Engineers need a clear route when a package has no licence, a customer supplies code, an employee wants to reuse prior work or an agency proposes its own framework. Record the decision, restrictions and follow-up. Periodic scans should be compared with the approved inventory, not filed without action.

Before signing transaction documents, refresh the ledger and confirm that remediation evidence is complete. Keep factual ownership evidence separate from legal conclusions. This allows technical, legal and commercial reviewers to work from the same component list while remaining responsible for their own analysis.

Prepare evidence for controlled diligence

Keep executed contracts, amendments, contributor lists, repository records, release history, licence inventories, notices, registrations and exception logs in a structured index. Redact personal and sensitive commercial data where appropriate and stage access. A data room does not override confidentiality or data-protection duties.

Coordinate legal and technical owners. Lawyers can interpret rights; engineers can show which components actually ship; finance and procurement can confirm suppliers and payment. The technology due diligence checklist connects this work to security, resilience and releases. The guide to confidential sale preparation explains progressive disclosure.

Do not promise perfect ownership. State the known position, document the evidence and address material gaps early enough to preserve options.

The pack is ready for controlled review when every material shipped component maps to a creator or supplier, governing contract or licence, repository or build evidence, exception owner and legal-review status.