Licensing code vs open-sourcing it: which is better for a retired product?

What are the realistic options for a retired codebase?#

A retired codebase has three realistic futures: archive it and do nothing, publish it under an open source license, or license it privately to an AI developer for training and evaluation. The choice usually arrives once customers have migrated to a newer platform and the old product stops earning.

Doing nothing is a decision too, and it has a cost. Build servers get switched off, the engineers who understood the architecture leave, and the subscriptions behind the issue tracker and code review tool lapse. Even if the repository survives, the history around it, which is often the most useful part, can quietly disappear.

The real comparison is therefore between two kinds of release. One is public, permanent and free to everyone. The other is private, bounded by contract and chosen deliberately, with the company keeping ownership.

How do licensing and open-sourcing compare?#

Licensing and open-sourcing differ most on control and reversibility. An open source license invites anyone to use, modify and redistribute the code, while an AI training license lets one named developer use copies for a defined purpose under confidentiality.

If the decision is close, weight the irreversibility row most heavily. Every other row can be revisited later; that one cannot.

When does open-sourcing make more sense?#

Open-sourcing makes more sense when the code's main value is to the people still using it rather than to anyone who would pay to study it. A retired on-premise product with loyal customers, a developer tool with a plugin ecosystem, or a library other products depend on can all justify a public release.

Plan the security side before publishing. Releasing source exposes unpatched vulnerabilities to anyone, including attackers targeting customers who still run old versions, so tell those customers first and fix or document known issues.

• 1Customers still run self-hosted installs and need a way to patch them after support ends.
• 2The product grew from community contributions, and a public release honors that history.
• 3The code is mostly standard plumbing with little distinctive domain logic.
• 4The company's hiring or developer-relations strategy benefits from visible engineering work.
• 5There is no issue tracker, review history or design record worth preserving alongside the code.

When does a private license make more sense?#

A private license makes more sense when the code carries years of real engineering decisions that a coding-agent developer cannot find in public repositories. Vertical products are often strongest here: scheduling rules for a trade, billing edge cases for an industry, or integrations with niche hardware and back-office systems.

What makes the package useful is usually the trail around the code. A license can include material that would rarely be published at all, such as internal review threads and the issues that explain why a change was made.

A license also suits owners who want the choice to stay open. Non-exclusive terms leave room to license again, to publish later or to reuse parts in a successor product.

• 1Commit history with meaningful messages, not a single squashed snapshot.
• 2Pull requests and review comments showing what reviewers caught and how authors responded.
• 3Issues and bug reports linked to the commits that fixed them.
• 4Test suites and CI results showing whether each change worked.
• 5Design notes or decision records that explain architecture choices.

What rights cleanup does each route require?#

Rights cleanup is required for both routes, and it is largely the same work. Before code is published or licensed, the company has to show it owns what it is granting and that nothing inside belongs to someone else.

Commit history is where the two routes differ most. A public release exposes every commit ever made, so many teams publish a fresh repository that starts from a cleaned snapshot rather than the original history. A private license can include the full history, which is usually where its value sits, but only after the whole history, not just the latest branch, has been scanned for secrets and every credential found has been rotated.

Treat this as general information rather than legal advice. Ownership gaps and inbound license terms differ by company, so have counsel review them before either route proceeds.

Can you license the code first and open-source it later?#

Licensing first and open-sourcing later is possible when the license is non-exclusive and does not restrict your own later publication. Check for confidentiality clauses that cover the licensed material itself, because some licensees want assurance that what they paid for will not become free.

The reverse order rarely works for the code itself. Once a repository is public, anyone can copy it, so a developer has little reason to license the same snapshot privately. Material that never went public, such as an internal issue tracker, review discussions or incident postmortems, may still be licensable later.

A staged plan is common: license the full history privately, then publish a cleaned snapshot without the internal discussion. Write that intention into the license so both sides agree on it from the start.

Illustrative: a scheduling product reaches end of life#

Illustrative: a fictional field inspection software company retires its desktop scheduling product after moving most customers to its cloud platform. The repository holds many years of commits, a Jira project with linked bugs, code reviews in Bitbucket and a Confluence space of design notes. A few customers still run self-hosted installs, and one of them holds a source code escrow agreement.

The founder and CTO start with customer contracts, not code. The escrow agreement lists end of maintenance as a release condition, so that customer receives the deposit its contract requires. The rights review then finds a reporting module built under a development agreement that gives one customer ownership, and Jira tickets that quote inspection site addresses.

They choose a non-exclusive AI training license for the full history, excluding the customer-owned module and pseudonymizing site addresses and author emails. The remaining self-hosted customers are covered by maintenance terms under their existing agreements. The license expressly allows a later public release of a stripped-down snapshot, which the company keeps as an option rather than a commitment.

How SourceX approaches a retired codebase#

SourceX treats a retired codebase as one package moving through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The first fit check uses metadata only, such as languages, years of history and which trackers link to the code, and nothing is shared at that stage.

Ownership, third-party code and customer material are reviewed in the Rights step before any file moves. Large repositories stay in the company's own storage or ship on encrypted drives, and the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, which also helps if the company publishes code later.