Fairlode guide · 12 October 2026
Could you license a codebase for AI?
Start with what the software does and what history comes with it. Do not send a repository or grant Git access just to find out whether there is interest.
Describe the whole development record
A codebase is more than a line count. For an initial review, distinguish the current source from its development history. Does it include commits, issue discussions, pull requests, tests, documentation and release notes? Can a problem be followed through to a change and an outcome?
These are useful questions for describing the collection, not a promise that every element attracts payment. A buyer must confirm which parts matter for their use. The public Grepped site lists software repositories and development records among the material it considers; that does not mean it has accepted your repository or made an offer.
Current product or older version?
An older platform is not automatically low-risk. It may still contain code used in your current product, active customer customisations or confidential architectural decisions. A retired internal tool can also contain third-party material. Record the status accurately: active, maintained for existing customers, archived or never put into production.
An outline could say: “A business software platform covering purchasing, stock and service workflows, with several years of development history and automated tests.” This is an illustrative description, not a customer case study.
Check what your company can authorise
Make an internal list of employee work, contractor work, customer-specific work and open-source dependencies. Ask the appropriate adviser to check assignments, customer agreements and dependency licences. Having access to a repository is not the same as having permission to license everything inside it.
Keep an explicit list of exclusions. That might include customer data, production credentials, infrastructure configuration and material belonging to another organisation. Do not assume a licence to the main application covers every attached issue, document or comment.
Prepare a short initial description
- What the software does and the kind of organisation it serves.
- Approximate number of repositories, years covered and commit range.
- Whether it is used in production and whether development continues.
- Which supporting records exist: issues, reviews, tests and documentation.
- Any known ownership restrictions, without disclosing confidential clauses.
- Who would need to approve an agreement.
Approximate answers are fine for an initial enquiry. Do not export a repository to obtain a precise count if a broad band is sufficient.
Before a technical review
Ask who will access the material, what they will receive and why. Agree the confidentiality process and the permitted evaluation before sharing. Review the proposed licence with an adviser who understands software IP. Keep commercial interest separate from permission to train a model.
Read the training and evaluation guide before choosing which uses you would consider.