Data type guide

Prepare source code for AI licensing

Repositories with history, tests, and context.

Sources and guidance · Reviewed October 2026

What makes this collection useful

A repository becomes more informative when its changes can be connected to issues, code reviews, test results and documentation. An archive that cannot build may have less utility for execution-based evaluations.

Prepare before approaching buyers

Separate first-party files from dependencies, forks, generated files and contractor contributions. Scan history as well as the current branch for secrets. Preserve a reproducible environment only where you can license its components.

Possible evaluation contexts

Code understanding; debugging tasks; repository-level agent evaluation. These are possible uses, not statements of current buyer demand.

Where preparation breaks down

Embedded credentials, incompatible licences, absent contractor assignments and non-reproducible tests.

What to put in the datasheet

Language mix; commit dates; test coverage; dependency inventory; build instructions. State how each measure was calculated and which records were excluded. Keep the sample aligned with the collection described.

A practical next step

Create a one-page inventory, separate rights-cleared material from unresolved records and use the readiness checklist. Only then prepare a sample for a verified counterparty under appropriate evaluation terms.

Common questions

Does owning the files mean I can license them?

No. Ownership of the storage or account does not settle copyright, privacy, confidentiality or third-party restrictions. Review the rights in the content and the intended use separately.

Can I get a price without sending the full collection?

A high-level datasheet can support an initial discussion. A buyer may later request a reviewed sample and diligence; avoid sending raw archives at the first contact.

Use this as a preparation framework. It is not legal advice, a valuation or a promise that a buyer will accept your data.