How to run an open source license compliance audit before licensing a private codebase

What the audit has to prove

The audit answers one question for the company's counsel and for SourceX's rights review: which parts of the codebase the company can license, and which parts must be carved out. That is a different question from ordinary product compliance. Shipping software asks whether the product honors its dependencies' licenses; licensing a repository for AI training asks whether the company has the right to license the text of each file, its full history and the engineering records around it.

Buyers care because commit history, pull requests, review threads and linked tickets show how engineers actually diagnose and fix problems, which is the record of work that coding agents are trained and evaluated on. Third-party code inside those repositories belongs to someone else, and unclear rights stop a deal at review. The US Copyright Office's report series on copyright and AI, whose training-focused part was released as a pre-publication version in May 2025, discusses licensing approaches for training material; treat it as context, not as law.

Prerequisites before you scan

• Read-only access to every Git host the company has used, including archived organizations and old self-hosted servers.
• A list of contractors, agencies and offshore teams that committed code, with their agreements.
• Any existing SBOM, open source policy or report from a prior financing or acquisition diligence.
• Client contracts, if the company builds software for customers, as IT services firms, agencies and custom development shops do.
• A software composition analysis (SCA) tool with snippet matching, and access to counsel who can interpret the results.
• The CEO's agreement that the audit is internal and that nothing leaves the company.

The audit, step by step

1. Map repositories and history. Count repositories, languages, years of commit history, contributors and linked issue trackers. Include archived and forked repositories. Record metadata only.
2. Run dependency SCA on every manifest. Generate an SBOM, in SPDX or CycloneDX format, for each repository so declared dependencies, versions and declared licenses are listed. Packages fetched at build time are usually not stored in the repository; vendored copies are.
3. Hunt for vendored and copied code. Search folders named vendor, third-party, lib or external, minified bundles, checked-in binaries and license headers naming another copyright holder. Run snippet matching to catch code pasted from public projects or forums.
4. Scan the whole history, not only the default branch. A file removed years ago still sits in Git history, and a license to the history includes it. Scan all branches and tags, or plan to offer a cleaned snapshot instead of full history.
5. Build the license inventory. One row per component: name, location, detected license, how it entered (manifest, vendored copy or snippet) and the proposed action.
6. Classify each row. Group results as permissive, weak copyleft, strong copyleft, network copyleft, commercial SDK, or unknown. Unknown is not permissive: code with no license grant gives you the fewest rights of all.
7. Check authorship and assignment. The Copyright Office's Circular 30 on works made for hire explains that work an employee creates within the scope of employment belongs to the employer, while commissioned work qualifies only in specific statutory categories with a signed written agreement. Collect the IP assignment clause for every contractor and agency that committed code; gaps go on the exclusion list or get fixed with a written assignment.
8. Screen for secrets, personal data and controlled technical data. Flag API keys, credentials, customer records in test fixtures or logs, and anything that may be export-controlled. The guide on ITAR and EAR technical data explains why that material stays out of a license.
9. Write the exclusion list. Third-party directories, copyleft components counsel flags, client-owned code, controlled data and unassigned contractor work. Exclusions are normal; a well-documented core of company-owned code is what matters.
10. Summarize on one page. Repositories in scope, years of history, contributor counts, exclusion categories and open questions for counsel. The CEO decides on this summary, not on the code.

How license categories translate into decisions

The category tells you which question to put to counsel. It does not answer it.

Read each license text with counsel rather than relying on category labels; terms differ between versions.

Common mistakes and how to avoid them

Illustrative example

Illustrative: a fictional 140-person B2B accounting software company has eleven years of history across 64 repositories, plus Jira projects and code review threads. The fractional CTO's audit finds a vendored charting library, two GPL utilities copied into an internal tools repository, a payments SDK under a commercial license, and three years of work from an offshore agency whose contract contains a broad IP assignment. The exclusion list removes the vendored library, the GPL utilities and the SDK; the agency's work stays in scope once counsel confirms the assignment. The CEO reads the one-page summary and asks for an introduction. No code leaves the company until an agreement is signed and the company authorizes delivery.

Where the audit fits in an introduction

The audit is not a prerequisite for an introduction; it is what a well-prepared company brings to the rights review. A software company is a fit when it is US-based, has 50+ full-time employees at peak (contractors excluded) and several years of documented operations, holds the rights to what it would license, and has an owner, CEO, CFO or authorized representative to sponsor it. The who qualifies page sets out the full baseline, and the page for fractional CTOs covers how technical advisers raise licensing with a CEO.

The same preserve-before-change discipline applies beyond code, from CMMS migrations to call recording purges. Your role stays the same in each: introduce the company and give basic fit information. SourceX and the company handle the inventory, rights review, redaction terms, contracting and delivery, and de-identification and redaction requirements are agreed before any work begins.

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company. Payment follows only after the buyer pays and SourceX receives its fee, and no reward is guaranteed. If you hold an advisory or board role, check your engagement terms on outside fees before registering.

This is general information, not legal, tax or financial advice. Confirm with your own counsel before acting on any license interpretation.

Next step

Start with step one: map the repositories and their history, metadata only. If the company fits, register as a partner to introduce it; the CEO can also start the company application at sourcex.si/apply with your referral link attached.