Can you license a codebase containing open-source components for AI training?

What can you license from a codebase with open source inside?#

From a codebase with open source inside, you can license the code your company and its employees or contractors wrote, along with the engineering records around it, but not open-source or other third-party code as if you owned it. The open-source parts stay under their own licenses, and a data license from you cannot grant rights you never held.

That still leaves a great deal. First-party code usually carries the product's business logic, integrations and fixes, and the commit messages, pull request discussions and linked issues explain why each change was made. Those records of real engineering work are what developers building coding assistants look for.

Where open-source code hides in a private repository#

Open-source code hides in more places than a dependency file shows. Package manifests list what the build pulls in, but many repositories also carry third-party code directly in the tree, often added years ago by engineers who have since left.

Build the list by searching the repository, not by asking the team to remember. License files, copyright lines naming other organizations and directory names are the fastest leads.

• 1Vendored folders: libraries copied into the repo, often under vendor, third-party or lib directories.
• 2Committed dependencies: node_modules or similar folders checked in at some point and never removed.
• 3Copied snippets: functions pasted from public answers, blog posts or other projects, sometimes with license headers stripped.
• 4Forks: internal forks of open-source projects with company patches layered on top.
• 5Generated code: output from open-source generators that can carry template text from the tool.
• 6SDKs and samples: vendor SDKs, sample apps and test fixtures copied from documentation.
• 7Assets and data: fonts, icons, test datasets and schemas under their own licenses.
• 8Customer-owned code: customizations or integrations built under statements of work that assign ownership to the customer. It is not open source, but it is not yours to license either.

Exclude, mark or include: deciding component by component#

Each third-party component gets one of three treatments, decided by its license, how entangled it is with your code and what the buyer needs. Counsel and engineering decide together, and every decision is recorded in the package manifest.

Excluding a component removes its files, not its traces. Imports, configuration and calls into the library remain in first-party code, which is normal and expected; what matters is that the library's own source does not ship.

How buyers check for open-source contamination#

Buyers check for open-source contamination by scanning delivered code for license headers and notices, matching files and snippets against public repositories, and comparing the results with the supplier's manifest. A mismatch between manifest and scan does more damage than a known component that was disclosed.

Run the same checks before delivery. Software composition analysis tools and license scanners flag known components and headers, and a plain search for license text and outside copyright lines catches many leftovers. If the company already keeps a software bill of materials for security reviews, start from it, but treat it as a list of declared dependencies rather than proof that nothing else was copied in.

Secret scanning belongs in the same pass. Gitleaks scans git repositories and files for passwords, API keys and tokens, though its maintainer has said it is feature complete and will receive security patches only. TruffleHog scans git and other sources and can log in to confirm whether a found secret is live, which calls for care when it is pointed at third-party systems.

Commit history and code reviews carry open source too#

Commit history, pull request reviews and issue threads can carry open-source code even when the current tree is clean. A diff that added a vendored library years ago, a review comment pasting a fix from an upstream project and an issue quoting a stack trace from a third-party package all travel with the history.

Decide early whether the package is a snapshot of current code or a history of engineering work. Histories are usually more valuable to buyers, and they need filtering: drop commits that only touch excluded paths, trim diffs to first-party files and review pasted blocks in comments. Rewrite history only on an export copy, never on the working repository.

What to disclose and what to promise#

A code license should disclose every known third-party component and promise only what the supplier controls, which is the first-party code in its manifest. Describe the package as first-party code and related engineering records, list excluded paths and known embedded components, and state the method used to find them.

Tie the representations to that manifest. For embedded snippets the supplier could not reasonably detect, a knowledge qualifier and a remove-and-replace remedy are common. Avoid blanket promises that the package contains no third-party code, because few repositories of any age can support that sentence.

The manifest is the document both sides rely on, so keep it specific enough that a buyer's engineer can reconcile it with a scan without calling you.

• 1Repository and path for every file or folder in the package.
• 2Status of each path: first-party, excluded or marked third-party.
• 3Component name and license for each marked or excluded third-party item.
• 4The scanning tools and manual checks used, and when they ran.
• 5The date range of commit history included, and the filters applied to it.
• 6The engineer and counsel who reviewed and approved the final list.

Illustrative: a property management software company scopes its repos#

Illustrative: a fictional property management software company with a long-running GitHub organization wants to license its main application repository, pull request reviews and linked Jira issues. A first scan finds a committed node_modules folder from an early version, a vendored PDF library, an internal fork of an open-source scheduling component and scattered snippets carrying other organizations' copyright lines.

The CTO's team excludes the committed dependencies and the vendored library, includes only the company's own patches on the fork with clear markers, and removes or rewrites the snippets. History on the export copy is filtered to first-party paths. The final manifest lists every excluded path and marked file, and the company's representation covers the manifest, with a knowledge qualifier for anything the scans missed.

How SourceX scopes code packages#

SourceX scopes code in the Supply and Rights steps of the SourceX five-step transaction, starting from metadata: repositories, languages, years of history and known third-party components. No code is shared during the initial assessment.

For packages that proceed, the SourceX Evidence Packet notes which paths were excluded and why, next to the provenance, licensing rights, permitted use, privacy record and release authorization it always carries. Buyer and supplier then work from the same manifest.