Source Code Selling Glossary

The terms

These are the terms owners meet when they sell the code of software they no longer use. They are listed alphabetically. Where a term needs more than a paragraph, the entry links to the guide that covers it fully. The entries on ownership, contracts, data protection, insolvency and tax are general information, not legal or tax advice; for your own case, speak to a qualified lawyer or accountant.

API key

A secret string that lets one piece of software use another service, such as a payment provider, a mapping service or a cloud account. Whoever holds the key can usually act as your product. Old code often has API keys typed directly into source files or config files, and they stay in git history even after the file is changed. Before any sale, revoke or rotate every key that was ever committed. The guide on removing API keys and passwords from old code explains the order of steps.

Archived repository

A repository that has been frozen so nobody can change it. On GitHub, archiving makes a repository read-only for all users, including its issues, pull requests and commits, and it can be undone. Archiving keeps the code and its history safe while you decide what to do, but it does not earn anything or remove secrets. The comparison of selling old code versus leaving it archived weighs the two.

Asset purchase agreement

The written contract in which a buyer agrees to purchase specific assets, here the source code, its history, docs and related project material, rather than the company that owned them. It lists exactly what is included, the price, when it is paid, what each side promises about ownership and originality, and who removes secrets and personal data before transfer. This is general information, not legal advice: have a lawyer review any agreement before you sign. See what is in a source code purchase agreement.

Bona vacantia

Latin for “ownerless goods.” In the UK, when a company is dissolved, all property and rights it still held pass to the Crown, and that includes the copyright in its code. A founder who let the company be struck off may no longer own the code at all. Restoring the company is sometimes possible. This is general information, not legal advice. The guide on selling code when the company is dissolved or in liquidation covers the options.

Capital gains

The profit from selling an asset for more than it cost, often taxed at lower rates than ordinary income. Whether a code sale counts as a capital gain depends on the country, on who wrote the code and on whether it was a business asset. In the US, for example, a copyright you created yourself is not a capital asset. This is general information, not tax advice; ask a qualified accountant. The tax guide by region summarizes official sources.

Code review

The step where another developer reads a proposed change before it is merged, comments on it and approves or rejects it. Reviews usually happen inside pull requests. They record why a change was made, what was wrong with the first attempt and how it was fixed, which makes them some of the most informative material in a repository. If your history still holds reviews, keep it intact. See why git history makes old code worth more.

Codebase

The whole collection of source code for one product, usually with its configuration, build scripts, tests and documentation. A codebase can live in one repository or several, for example a web app, a mobile app and a backend API. When you sell old software, the codebase is the core of what changes hands, ideally with its history. The guide on what old source code is still worth explains why a complete codebase matters more than snippets.

Commit

A saved snapshot of changes in git, with a short message, an author and a date. A product’s commits, read in order, show how it was built step by step: the first prototype, the features, the bug fixes, the rewrites. Commit messages such as “fix race condition in invoice export” tell a reader why a change was made. Commits are the building blocks of git history. See why git history makes old code worth more.

Copyleft license

An open-source license that lets you use and change the code freely, but requires that if you distribute software built on it, you make the source code of your version available under the same license. The GPL is the best-known example; the AGPL extends the duty to software offered over a network. The GPL FAQ says that using a GPL program privately, without giving copies to others, places no conditions on you. See open source inside your codebase.

Copyright

The legal right to copy, change and distribute an original work, including software. It arises automatically: in the US, a work is under copyright protection the moment it is created and fixed in a tangible form, with no registration needed. Copyright in code can be sold, partly sold or inherited. Who holds it first depends on who wrote the code and on what terms. This is general information, not legal advice. See who owns the code.

Data minimization

The principle of keeping only the personal data you actually need. GDPR says personal data should be “limited to what is necessary” for the purpose. For a code sale, it means personal data should not travel with the code at all: no real customer records in seed files, fixtures, logs or test emails. We never take databases or user records. This is general information, not legal advice. See personal data in old code.

Environment file

A file, usually named .env, that holds settings a program reads when it starts: database addresses, passwords, API keys and other secrets. It is meant to stay out of the repository, but in old projects it often slipped in at some point, and deleting it later does not remove it from git history. Check for .env files, and for copies such as .env.production, before any sale. See how to remove API keys and passwords from old code.

Generated code

Code produced by a tool rather than written by a person: compiled bundles, minified files, client libraries generated from an API schema, scaffolding from a framework, database migration stubs. It is useful to the product but shows little original work, so it is usually left out when you count lines of code. A repository that is mostly generated code is something we pass on. The guide on how to count lines of code shows what to exclude.

git-filter-repo

A free tool for rewriting git history, used to scrub secrets or large files out of every past commit. GitHub’s documentation recommends it and says to rewrite the repository locally, using git-filter-repo. A rewrite is a careful job: anyone with an old copy still holds the old history. Rotate the secret first, then rewrite. See how to remove API keys and passwords from old code.

Git history

The full record of every commit in a repository, along with its branches and, on platforms such as GitHub, its pull requests and reviews. It shows not just what the code is, but how and why it changed. Full history adds value to old code; code without it is still sellable. A zip download usually carries only the latest files, so keep the original repository. See why git history makes old code worth more.

Intellectual property

The legal rights in creations of the mind, such as copyright, trademarks, patents and trade secrets. For old software, the key intellectual property is usually the copyright in the source code. Selling code means transferring those rights in writing to the buyer, which is why you must own them, or be able to sign for the company that does. This is general information, not legal advice. See who owns the code.

IP assignment

A signed written document that transfers intellectual property from one person or company to another, for example from a contractor to the company that paid for the code. In the US, a transfer of copyright is not valid unless it is in writing and signed by the owner. Missing assignments from early contractors are a common gap in old codebases, and they can often be fixed later with a signed confirmatory assignment. This is general information, not legal advice. See who owns the code.

Lines of code

A simple count of how big a codebase is, usually excluding blank lines and comments. Free tools such as cloc and tokei count lines by language. The useful number is lines of original code, so leave out copied libraries, vendored dependencies, generated files and minified files. Size is one of the factors behind value. See how to count lines of code.

Liquidator

A person appointed to wind up a company, usually an insolvency practitioner, who collects and sells its assets to pay creditors. In the UK, a liquidator has the power to sell any of the company’s property, and that can include the copyright in its code. If a company is in liquidation, the liquidator, not the founders, usually decides whether its code is sold. This is general information, not legal advice. See selling code when the company is in liquidation.

Open-source license

The terms under which code is shared publicly so others can use, change and distribute it. Licenses come in two broad families: permissive and copyleft. Almost every commercial codebase uses open-source libraries: Black Duck found open source in 98% of the codebases it audited for its 2026 report. Using them does not stop a sale; they stay under their own licenses. See open source inside your codebase.

Ordinary income

Income taxed at your normal income tax rates, such as wages or business profit, as opposed to capital gains. In the US, the IRS says a creator’s sale of a copyright they made themselves results in ordinary income. Other countries have their own rules, and a company selling code is taxed differently from an individual. This is general information, not tax advice; ask a qualified accountant. See the tax guide by region.

Original code

The code your own team wrote for the product, as opposed to third-party code such as libraries, templates and frameworks, and generated code. Original code is what we buy, and it is one of the main factors behind value. A codebase built on many open-source libraries can still be mostly original in the part that matters: the product logic your team designed. See how codebase value is measured.

Permissive license

An open-source license that lets anyone reuse code with few conditions, usually just keeping the copyright and license notice. The MIT License, for example, requires that the notice be included in all copies or substantial portions; Apache 2.0 also asks you to mark changes. Permissive libraries inside your product are normal and do not stop a sale. Keep their notices in place. See open source inside your codebase.

Personal data

Any information relating to a person who can be identified, directly or indirectly. Under GDPR, that includes a name, an identification number, location data or an online identifier. In old code it hides in seed files, fixtures, logs, test emails and hard-coded customer records. Personal data is removed before transfer, and we never take databases or user records. This is general information, not legal advice. See personal data in old code.

Pull request

A proposal to merge a set of changes into the main code, with a description, a discussion and, usually, a code review. On GitHub and similar platforms, pull requests keep the conversation around each change: what problem it solved, what reviewers asked and what was fixed. That record is part of a repository’s value. Pull requests live on the hosting platform, not in a plain git clone, so export them if you leave. See why git history matters.

Repository

The folder, managed by git, that holds a project’s code and its full history. It often lives on GitHub, GitLab or Bitbucket, with issues and pull requests around it. One product can have several repositories. If you are shutting a product down, do not delete its repositories: secure admin access, back them up and keep them, history included. See what to do with the code when you shut down a software company.

Research and development

Work that tests new ideas, measures them and turns the ones that work into something repeatable. Odys Global has close to twenty years of research and development behind the Blue Ocean services. Odys AI Labs is the research and development arm of Odys: it works on AI training and R&D with real-world software, and it buys code for that purpose. See why real-world code matters for AI training and R&D.

Sanitization

Cleaning a codebase before it changes hands: removing secrets such as API keys and passwords, removing personal data from seed files, fixtures and logs, and leaving out databases and user records. Sanitization covers the git history too, not only the latest files. With us, it happens after a written agreement is signed and before transfer, and we help. The guide on preparing a codebase for sale walks through it.

Secret

Any value that grants access: an API key, a password, a token, a private key or a database connection string. Secrets often sit in environment files, config files and old commits. GitGuardian found that 32.2% of internal repositories contain at least one hardcoded secret. The first step is always to revoke or rotate a secret, then remove it from code and history. See how to remove API keys and passwords from old code.

Source code

The human-readable instructions programmers write, in languages such as JavaScript, Python, Java or C#, before they are turned into a running program. Source code shows how a product actually works, which is why it can be read, changed, studied and learned from. Odys AI Labs buys the source code of software people no longer use, for AI training and R&D. See what old source code is still worth.

Sunset product

A product a company has retired on purpose: no new customers, then no support, then shut down. Its code often stays in a repository nobody owns any more, still costing hosting, security attention or simply worry. A sunset product that no longer makes money can be a fit for a code sale, provided the company can sign for the rights. See what companies can do with the code of retired products.

Technical documentation

Written material that explains how software works and how to run it: a README, architecture notes, API references, setup guides, runbooks and decision records. Documentation is not required for a sale, but it adds to value, because it shows what the code was meant to do and why it was built that way. Keep it with the code, and leave out anything containing secrets or customer data. See why docs, tests, tickets and designs add value.

Test suite

The collection of automated tests that check a product’s code still works: unit tests for small pieces, integration tests for how pieces fit together, end-to-end tests for whole user journeys. A test suite shows what the team expected the software to do, which makes it useful alongside the code. Tests are not required for a sale, but they add to value. Check test fixtures for real personal data. See why docs, tests, tickets and designs add value.

Third-party code

Code in your codebase that your team did not write: open-source libraries, frameworks, SDKs, templates and snippets copied from elsewhere. It is normal, and it stays under its own license, so keep its license notices in place. What is sold is the code your team wrote. A repository that is mostly third-party code is something we pass on. See open source inside your codebase.

Ticket export

A file of the issues, bugs and feature requests a team tracked while building the product, exported from a tool such as Jira, Linear or GitHub Issues. Tickets show what users asked for, what broke and how the team prioritized fixes. An export adds to the value of a codebase. Leave out anything with customer personal data or private chat logs. See why docs, tests, tickets and designs add value.

Trade secret

Valuable business information kept confidential, such as an unpublished algorithm, a pricing model or private source code. It stays protected only while it stays secret and the owner takes reasonable steps to keep it so. Unpublished code is both copyrighted and secret, so a buyer gets exclusive access to it; once code has been open-sourced, the secrecy is gone, anyone can read it under the license, and exclusive access cannot be sold. This is general information, not legal advice. See selling your old code versus open-sourcing it.

Training data

The examples an AI model learns from. For models that read, write and fix software, real-world code is training data, especially with its history, reviews and tests. Researchers at Epoch AI estimate the public stock of human-written text could be fully used between 2026 and 2032. Private code is not in public datasets at all. Odys AI Labs uses the code it buys for AI training and R&D. See why real-world code matters for AI.

Vendored dependency

A third-party library copied directly into your repository, often in a folder such as vendor/, third_party/ or lib/, instead of being installed by a package manager. Vendoring is common and harmless, but it inflates the lines of code count, so exclude those folders when you measure size. The library stays under its own license. See how to count lines of code.

Warranty

A promise in a contract that a statement is true, for example that you own the code, that your team wrote it, or that it holds no undisclosed personal data. If a warranty turns out to be false, the other side may have a claim. In a code sale, warranties usually cover ownership and originality. Read them carefully and only give promises you can keep. This is general information, not legal advice. See what is in a source code purchase agreement.

Work made for hire

A US legal term for work the law treats as created by the employer, not the person who wrote it. Code an employee writes as part of the job is “a work prepared by an employee within the scope of his or her employment”, so the company owns it. Code from outside contractors is usually not work for hire by default and needs a signed IP assignment. This is general information, not legal advice. See who owns the code.