Identify what is actually yours to license
A repository is a container for many kinds of material: original code, dependency snapshots, generated files, sample assets, documentation, test fixtures, and copied snippets. Start with a source inventory and separate these categories. A company may have a clear claim to some components and only a limited use license for others.
Check employee and contractor agreements, acquisition documents, and contribution history. U.S. copyright law distinguishes ownership of a copy from ownership of the underlying copyright. Use a qualified reviewer for uncertain contribution chains rather than asking an engineer to certify broad ownership from memory.
Define the learning task and required context
Function-level examples, issue-to-patch pairs, repository navigation tasks, and build-repair exercises need different packaging. A patch without its base revision cannot reliably show what changed. A code fragment without imports or a schema may be unusable even if it looks technically impressive.
Provide language versions, dependency manifests, build instructions, license information, and known environment limitations when authorized. Mark generated code and synthetic examples. If tests pass only inside unavailable internal infrastructure, explain that constraint instead of describing the collection as independently executable.
Treat history as a separate exposure surface
Deleting a secret from the current branch does not remove it from old commits or archived artifacts. Review history, branches, issues, continuous-integration logs, example configuration, and test data before creating the proposed delivery. Do not use production credentials or private customer records to make a buyer’s environment work.
Where possible, prepare a minimal reproducible package with safe fixtures. Keep a manifest tying each example to an approved revision and the transformations performed. Excluding proprietary infrastructure may reduce realism; explain that tradeoff so the buyer can judge whether the task remains useful.
- Scan code, history, and bundled assets.
- Separate vendored dependencies from original contributions.
- Verify licenses for documentation and test fixtures too.
Scope training rights and retention explicitly
Ask whether the buyer wants evaluation access, internal model training, commercial model training, or redistribution. These are distinct commercial discussions. Define permitted affiliates and contractors, access logging, security expectations, and what happens to raw code after evaluation or termination.
For acceptance, use objective properties such as revision availability, buildability under the agreed environment, test execution, and completeness of issue-patch links. Do not guarantee that the buyer’s model will improve. A pilot should establish whether the package supports the intended task before either side commits to a much larger repository transfer.
Common questions
Does an open-source repository need no review?
No. Review its actual license, included dependencies, notices, and the proposed use. Public access is not a substitute for understanding the applicable rights.
Is a secrets scan enough?
No. It addresses one category of exposure. Ownership, dependency rights, customer fixtures, confidential logic, and historical content need separate review.