Can you sell source code from a company that shut down?

Who can sell code after the company has closed?#

The legal entity that employed the engineers owns the source code, so only someone authorized to act for that entity can sell or license it. Founders who wrote much of the code do not own it personally if they signed invention assignment agreements, which venture-backed startups commonly require.

Closing the business does not end the entity at once. A company that has stopped operating can usually still sign contracts to wind up its affairs, including disposing of assets, until dissolution is complete and in some states for a period after. The board, a wind-down officer, an assignee for the benefit of creditors or a bankruptcy trustee may hold that authority.

Check one more party early: the lender. Venture debt and bank facilities often take a security interest in all assets, including intellectual property. A sale or license of code may need the lender's consent or a lien release, and a buyer's counsel will usually ask to see it.

The rights checklist before any code sale or license#

A source code rights checklist covers the four rights checks plus a secrets scan, and each item can shrink or block what you are able to transfer. Most can be answered from contracts and repository metadata, without anyone opening the code itself.

Contractor gaps are a frequent surprise. An early freelancer who built the first version on a handshake may still own that code unless a written assignment exists. A confirmatory assignment signed now is often simple, but it needs a contractor you can still reach.

How open source licenses affect a code sale#

Open source licenses travel with the code they cover, so a buyer receives open-source components on the same terms the company had, not as owned property. A sale transfers the company's own code and whatever rights it held in third-party code, nothing more.

Permissive licenses such as MIT and Apache 2.0 mainly require keeping notices. Copyleft licenses such as the GPL family can require that derivative works be shared under the same license when they are distributed, and the AGPL extends similar obligations to modified versions that users reach over a network. A buyer folding your code into its product will ask which services contain copyleft code and how it was linked.

For an AI training license the question shifts. Developers want to know which files the company wrote and which it imported, so a software composition report or a dependency manifest per repository helps. Vendored third-party folders are often excluded outright to keep the package clean.

Selling the codebase vs licensing the engineering history#

Selling the codebase transfers ownership of the product to one buyer, while licensing the engineering history grants AI developers limited use of the record of how the software was built. The two paths attract different counterparties and can sometimes be combined.

Order matters. Once the code is sold outright, the company has no rights left to license unless the sale agreement reserves them, so decide before the asset purchase agreement is signed, not after.

AI developers usually care less about whether the product had customers and more about the trail of work: commit messages, pull request reviews with comments and revisions, issues linked to fixes, test results and incident write-ups. A product that failed in the market can still leave a well-documented engineering record.

A simple decision rule helps. If a product buyer exists and needs exclusive control of the code, sell the product and reserve a license right to the historical records. If no product buyer emerges, keep ownership and license the engineering history non-exclusively. If neither path clears the rights checks, preserve the paper trail and records for retention only.

What to preserve before GitHub and Jira are cancelled#

Preserving source code for a sale or license means more than cloning repositories, because much of the useful context lives in the hosting platform and the issue tracker. Run the exports while admin accounts and paid plans are still active.

Run a secret scan before any copy leaves your control. Open-source scanners such as Gitleaks and TruffleHog search git history for passwords, API keys and tokens, and TruffleHog says it can also check whether a found secret is still live. The Gitleaks maintainer announced in May 2026 that the tool is feature complete and will receive security patches only, so confirm which scanner your team relies on and revoke every live credential it finds.

• 1Full mirrors of every repository, including all branches, tags and archived repositories.
• 2Pull request and merge request data with review comments, approvals and linked commits, pulled through the platform's export tools or API.
• 3Issue tracker exports from Jira, Linear or GitHub Issues, with comments, status history and links to commits.
• 4CI and test history where it can be exported, plus release notes and changelogs.
• 5Architecture docs, runbooks and postmortems from Confluence, Notion or a docs repository.
• 6The paper trail: invention assignments, contractor contracts, customer statements of work, escrow agreements and any open-source scan reports.

Illustrative: a closed freight software company sorts its repositories#

Illustrative: a fictional freight-quoting software company that grew past fifty employees closes after a failed funding round. It holds a GitHub organization with several years of history, a Jira instance linked to most pull requests, and Sentry incident records. The former CTO, now the wind-down officer, wants to know whether anything can be sold.

The rights review finds three issues. One enterprise customer's integration was built under a statement of work that assigned the code to that customer, so its repository is excluded. An early contractor never signed an assignment and signs a confirmatory one. One internal service bundles AGPL code, which is documented and left out of any license package.

No buyer wants the product itself. The board instead approves a non-exclusive license of the engineering history: commits, reviewed pull requests and linked Jira issues, with customer names and employee identities replaced and secrets scrubbed. The company keeps ownership, and escrow beneficiaries receive the notices their agreements require.

How SourceX approaches code from closed companies#

SourceX treats a closed company's code and engineering history as one possible package within the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The first step is a metadata-only fit check covering the hosting platform, the tracker, years of history and repositories with known restrictions. No code is shared at that stage.

If the package proceeds, the rights findings go into a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization, so a buyer can see who approved the license and on what authority. Large repositories stay in the seller's own storage until delivery is approved, and the code is licensed, not sold.