Can you license a private GitHub repository with third-party code?

The presence of third-party code does not provide a simple yes or no answer. Identify which material you control, which permissions apply to included components and what the proposed license would allow the recipient to do. A repository-level label is not a complete rights review of every file, dependency, fixture, comment and historical revision.

The practical decision is whether you can describe a contribution whose contents and permitted uses are supportable. That may involve a narrower scope, exclusions, additional permission or a different proposed use. Do not assume that making a repository private, buying a software product or removing a dependency file settles the question.

Which repository material and AI uses does the recipient request?

Ask what the recipient wants: a current snapshot, history of changes, review conversations, tests, execution material or some combination. Then identify the proposed uses, recipients and onward permissions. The same archive can raise different questions under different grants.

For example, permission to inspect code for a controlled evaluation is different from permission to redistribute it. A proposal involving model training can raise questions not answered by a general statement that the recipient may view the repository. The actual agreement and relevant licenses need review for the intended activity.

For US copyright-protected material, 17 USC 101 includes an exclusive license in its definition of a transfer of copyright ownership, while excluding a nonexclusive license. Section 204 generally requires a signed writing for a copyright ownership transfer other than one occurring by operation of law. Calling an arrangement a license does not settle its effect; these provisions do not establish rights in every repository component or apply the same formality to every nonexclusive permission.

Who contributed the code, fixtures and surrounding records?

A useful inventory includes company-authored code, employee and contractor contributions, client-specific work, third-party components, copied examples and test material. It should also identify documentation, images or data fixtures that may have different origins from the code around them.

The US Copyright Office’s work-made-for-hire guidance distinguishes employee work within employment from qualifying specially ordered or commissioned work under an express written agreement. Do not assume that paying a contractor makes every contribution company-owned. Locate the relevant contribution and transfer documents for the actual work and proposed use.

Use the inventory to locate the agreements and reviewers needed. A commit author's name is a clue about provenance, not proof that the author personally owns the work or can license it. A company account holding the repository is not a complete authority record either.

Understand what the repository license does and does not show

GitHub's licensing documentation explains the role of a repository license in communicating permissions. A license file is an important evidence item. Check which material it actually covers and whether other notices or agreements apply.

The Open Source Initiative's license list identifies OSI-approved licenses. It does not determine whether a particular repository is wholly covered by one license, whether its dependencies are compatible or whether the person offering it controls all included material.

Do not treat open source as a single permission category. Identify the applicable license and the activity being considered. Equally, do not describe third-party material as cleared merely because a tool found a familiar license name.

A fictional fixture that changes the scope

Imagine a company's current code is largely its own work, but integration tests include a client-provided configuration and an example document used to reproduce a fault. The owner is considering offering repository history for evaluation.

Removing the client fixture from the current branch may leave copies in earlier revisions or discussions. Excluding it from the proposed contribution may also affect whether the test can be reproduced. The company needs to understand both the rights boundary and the technical consequence.

A narrower contribution could omit the restricted component and explain which checks are no longer reproducible. Another possibility might be an appropriately authorized substitute. The recipient must understand the changed evidence; a prepared contribution should not imply that it reproduces the original case when it does not.

This is an invented example. It does not establish that replacing material resolves a particular license or confidentiality obligation.

Does removing a restricted file from the current branch solve the problem?

A historical contribution can contain material absent from the current branch. Identify the selected revisions, branches, discussions and attachments. Apply the review to that scope rather than assume that a current-file inspection covers every earlier state.

Security-sensitive information deserves separate attention. Credentials, private endpoints, unreleased vulnerability details or customer environments can appear in code or comments. A rights inventory is not a substitute for checking whether the proposed scope contains information the company should not disclose.

Keep the original source and prepared contribution distinguishable. Record exclusions and transformations so a reviewer can see what was offered and what it cannot demonstrate. Technical completeness and permission are related questions, but neither establishes the other.

Give reviewers a bounded question

Instead of asking whether the whole repository is safe to sell, describe the exact proposed contribution and use. Attach the relevant component inventory and agreements through appropriate controlled channels. Identify unresolved items and ask what they mean for that scope.

The answer may be that a particular subset can progress, a permission is needed, a recipient's requested grant should be narrowed or the opportunity should stop. A useful review should support one of those decisions without promising a general clearance for every future use.

For technical record semantics, the engineering-history opportunity page distinguishes the code and surrounding history. The provenance guide explains how source and preparation records connect to a delivered version.

Start without sharing the repository

An initial company data profile can state the product domain, retained development period, available issue/review/test history and known third-party categories. It does not need a private repository link, access token, source sample or client fixture.

Avelence can help assess positioning, buyer-market fit and licensing strategy for the material the company may be able to authorize. Appropriate rights, privacy and technical reviewers still need to establish the actual contribution and its limits. A commercial match does not create missing permission, and a private repository is not automatically a licensable dataset.

Frequently asked questions

Does deleting a third-party fixture from the latest branch clear repository history?

No. Earlier revisions, pull-request discussions or attachments can still contain it. Define the historical contribution being considered and review that scope. If the fixture is excluded, record the effect on reproducibility so a recipient does not assume that an altered test reproduces the original case.

Can a private repository’s license file cover all its contents?

It is an evidence item, not a complete component inventory. Check the license’s scope alongside notices, dependencies, contractor and client agreements, fixtures and historical contributions. The proposed activity also matters: permission to inspect a file is not automatically the same as permission to redistribute it or use it for every AI-related purpose.