Preparing a codebase for licensing

Define exactly what you might license

Name the repositories, branches, snapshot or history period, and supporting material you are considering. Decide whether tests, documentation, issue threads and review comments are included. Those items can have different owners and privacy risks.

Keep a written exclusion list for customer code, unrelated products, credentials and other restricted content. The useful package does not need to be every file in the organisation. A clear boundary supports both preparation and licence negotiation.

Build the rights inventory

Locate employee and contractor IP assignments, acquisition documents where relevant, and agreements covering external contributions. Inventory dependencies and bundled source, including their licences and any notice or redistribution obligations.

Do not interpret “we pay for it” or “it is on our GitHub” as proof of ownership. Where rights are uncertain, document the issue and seek permission or legal advice. A dependency inventory is a starting point, not a certificate that every intended AI use is authorised.

• Map each included repository to its owner and responsible team.
• Separate original company code from third-party components.
• Record missing assignments or unclear contribution permissions.

Scan current files and historical commits

Use appropriate secret-scanning tools on the full intended export, not just the latest branch. Review configuration files, test fixtures, logs, build artefacts and attachments. If a credential was exposed, rotate it; deleting a file is not sufficient remediation.

Search for personal data, customer identifiers and confidential endpoints. Manual review can still be needed after automated scanning. If history is cleaned, verify that earlier commits and tags no longer expose excluded content in the package you will deliver.

Document usability without promising perfection

Include a concise readme, language and dependency information, architecture context and test instructions where available. Record known missing services or build prerequisites. Explain what can and cannot be reproduced outside your environment.

A buyer may care about linked development examples rather than a runnable product. Preserve authorised issue-to-fix context when possible and describe gaps honestly. Do not add synthetic history or claim tests pass unless someone has run them in the stated environment.

Keep evaluation separate from delivery

The initial AssetGate assessment needs only a description. A later sample or inspection should have an agreed purpose, authorised access and limits on retention and reuse. Do not provide production access, account passwords or live secrets.

Before final delivery, agree the licence scope, permitted AI uses, redistribution, derivatives, confidentiality, security and termination arrangements. Confirm what files and rights the buyer receives and keep a record of the delivered version.

• Review a scoped package rather than sharing an entire organisation account.
• Re-run secret and privacy checks on the final export.
• Keep a manifest or version identifier for the authorised delivery.
• Arrange legal review before commercial use.

Avoid premature preparation costs

Start with the inventory and questions you can answer now. A speculative opportunity may not justify a major engineering cleanup. Use a personal follow-up to establish whether a further review makes sense.

AssetGate cannot guarantee a buyer or price. Uncertain rights and sensitive content are flagged for review, and you decide whether to proceed. Preparation should support an evidence-based discussion, not a fabricated valuation.