Which repositories to include in a code history license

Start from a repository inventory, not memory#

Scoping a code history license starts from a full repository inventory, because most engineering organizations hold more repositories than anyone can list from memory. Export the list from your GitHub organization, GitLab groups or Bitbucket workspace, including private and archived repositories.

For each repository, record its name, purpose, creation date, last activity, main languages, archived status, the issue tracker it links to, and who wrote it: employees, contractors, an acquired team or an outside project. That last column drives most of the include and exclude decisions that follow.

Archived repositories deserve a second look rather than a quick cut. A retired product or a replaced service often carries years of reviewed changes and closed issues, and age alone is no reason to leave it out.

The include and exclude checklist#

The include and exclude checklist sorts repositories by who owns the code and what its history adds. Use the default column as a starting position, then let the rights review confirm or override it repository by repository.

Ownership questions to settle for every repository#

Ownership is the first gate because a license can only grant rights the company actually holds. A repository the company cannot show it owns stays out of scope, however useful its history looks.

These questions are answered with counsel, and the answers can differ from client to client and from one acquisition to the next.

• 1Employee IP assignment agreements: do they cover everyone who committed, including founders who wrote code before the company was formed?
• 2Contractor and agency agreements: do they assign the code to the company, or only grant a license to use it?
• 3Client contracts and statements of work: does any client own its custom work or treat that code as its confidential information?
• 4Acquisition documents: did the purchase agreement assign the acquired company's code and history, and were any repositories carved out?
• 5Open-source licenses: which components came from outside projects, and under what terms?
• 6Joint development or partner agreements: was any code written together with another company?

How to scope a monorepo#

A monorepo is scoped by path, not as one unit, because a single repository can hold the core product, vendored dependencies, client-specific modules and infrastructure side by side. Draw the scope as a list of included and excluded directories.

Ownership files such as CODEOWNERS help map paths to teams, and dependency folders are usually easy to spot by name. The harder part is history. A commit that touches both an included and an excluded path has to be filtered so only the included changes are delivered, or dropped altogether. Agree that rule before preparation starts, because it changes how the delivery copy is built.

Keep the working repository untouched. Scoping and filtering happen on a separate copy, so day-to-day engineering never depends on licensing decisions.

What makes one included repository worth more than another#

An included repository is worth more when its history connects code changes to the reasons for them. Commits that reference issue keys, pull requests with review comments, continuous integration results and tagged releases let an AI developer follow a change from request to outcome.

Long-lived repositories with many contributors usually rank above short projects, and repositories with meaningful tests rank above those without, because tests let a buyer check whether a proposed change actually works. A small service with clean issue links can outrank a large repository whose history was squashed into a single commit during a past migration.

Secrets and personal details inside included repositories#

Every included repository is scanned for secrets across its full history, because a credential deleted from the current branch still sits in old commits, in other branches and in tags. Revoke and rotate anything found first; cleaning it out of the delivery copy does not make a leaked key safe.

Open-source scanners such as Gitleaks, an MIT-licensed tool that looks for passwords, API keys and tokens in git repositories and files, are a common first pass. Check the status of any scanner you rely on: the Gitleaks README was updated in May 2026 to say the tool is feature complete, that future releases will be security patches only and that its maintainer is shifting focus to Betterleaks. Default rules also miss formats unique to your company, so add patterns for internal token prefixes and connection strings.

Personal details hide in code history too. Commit author names and email addresses, customer records copied into test fixtures, and support emails pasted into code comments are removed or replaced with consistent pseudonyms before delivery.

• 1Scan every branch and tag, not only the default branch.
• 2Include configuration files, notebooks and committed environment files in the scan.
• 3Rotate each live credential before the delivery copy is cleaned.
• 4Record what was found and removed for the privacy record.
• 5Re-scan the final delivery copy, not just the working repository.

Illustrative: a logistics software company scopes its GitLab estate#

Illustrative: a fictional transportation management software company keeps its code in GitLab. Its inventory lists the core TMS application, carrier integration services, Terraform modules, a fork of an open-source routing library, EDI adapters built for individual shippers, a driver app from an acquired company and a repository of data science notebooks.

The CTO includes the core application, the integration services, the test suites and, after a full-history secrets scan, the Terraform modules. The routing fork and vendored folders are excluded. The EDI adapters are held: counsel finds that some client agreements give the shipper ownership of custom work and others do not, so only adapters built under the company's standard terms move forward. The driver app is included once the purchase agreement confirms its code was assigned. The notebooks are excluded because they hold extracts of customer shipment data.

The result is a written scope, a list of repositories and paths with an ownership note for each, ready for the rights review.

How SourceX approaches repository scope#

SourceX handles repository scope within the Rights and Preparation steps of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. At the fit check SourceX sees a repository list and descriptive metadata, never code, and nothing leaves company storage until the company approves delivery.

For each package, the SourceX Evidence Packet records provenance, the licensing rights behind each repository, permitted use, the privacy record of what was removed and the release authorization. SourceX's rights in a deidentified dataset are set out in the signed supplier agreement, and the company licenses its history rather than selling its code.