Skip to content

Can a software company license its code and tickets?

Short answer

Usually, for code and engineering records the company owns. Buyers want private code with its full history, the pull requests and reviews behind it, and the tickets that explain each change. Customer data you hold for your customers, third-party and open-source code, and secrets in git history come out first. General information, not legal advice.

Get your data pricedBook a call

Updated

Why buyers want private engineering records

Epoch AI's January 2026 report on AI training environments found coding is still a major source of demand. Public code is easy for anyone to collect, so private repositories offer something buyers can't get elsewhere.

The shape of the data matters too. A widely used public evaluation, SWE-bench, builds each task from a real GitHub issue, the pull request that resolved it and the tests that check the fix. A 2025 benchmark built the same way, SWE-Bench Pro, includes a commercial set of 18 proprietary repositories obtained under partnership agreements with early-stage startups.

MIT Technology Review reported in October 2026 that buyers of startup code and workspace data include foundation AI labs, companies that build simulated workplaces for training, and tech companies building their own models. The sales it describes came from companies that had shut down or were in bankruptcy. Business Insider reported the same month that companies still operating can sell too, if they have enough data.

What's valuable

  • Code with its full history: commits, branches and messages, including refactors, migrations and reverted mistakes.
  • Pull requests and reviews: the diff, the reviewer's comments, the revision and whether it merged.
  • Tickets linked to fixes: a bug report, the change that closed it and the tests that fail before and pass after. Repos that build and run their tests from a clean checkout are more useful, because each pair can become a task with a checkable answer.
  • Incidents and postmortems: the alert, the timeline, the root cause and the commit that fixed it.
  • Design docs and specs: the reasoning behind a decision, linked to the code that carried it out.
  • Support tickets with resolutions, with customer details removed.

The links matter as much as the records. A ticket that points to the commit that closed it tells a buyer more than either one alone.

Customer data in tickets and logs

If your product stores your customers' data, you usually process it on their behalf. Under the GDPR, a processor acts only on the controller's documented instructions, and one that decides its own purposes is treated as a controller for that processing. California's privacy law limits a service provider to the business purposes in its contract, and the state's regulations allow only narrow exceptions. Your data processing agreements and customer terms may go further, and some bar AI training outright.

So production databases, application logs, error-tracker payloads and attachments stay out. In tickets and chat, customer names and identifying business details come out, and customers whose terms forbid this use are left out entirely. Don't rewrite your terms to cover data you already hold: FTC staff warned in February 2024 that quiet, retroactive changes can be unfair or deceptive.

Open-source code, contractors and secrets

  • Third-party and open-source code. You can license only code you own. Vendored dependencies, copied snippets and files under other licenses come out. GPLv3 also bars adding restrictions on code passed along under it, which a confidential license would do. A license scan of the full tree, with a per-file manifest, sets the scope.
  • Contractor code. Software written by an independent contractor usually isn't a "work made for hire", so the company owns it only through a signed written assignment. Gaps with freelancers or founders' pre-company work come out, or get a confirming assignment.
  • AI-generated code. Copyright needs a human author. The D.C. Circuit held in 2025 that the Copyright Act requires one, and the Copyright Office's January 2025 report says prompts alone don't give a user enough control to be the author. Code a person wrote, or creatively selected, arranged or changed, can still be protected. If much of your code came from AI tools with little human editing, say so, because a license can't grant copyright that may not exist.
  • Client work. Code a dev shop or agency wrote for clients usually belongs to the client under the contract, so it needs the client's written consent.
  • Secrets. Keys, tokens and passwords committed at any point stay in history. GitHub's guidance is to revoke or rotate a leaked secret first, because rewriting history doesn't remove it from other clones or forks. Scan the whole history, not just the latest commit, and rotate what you find before anything moves.
  • Chat exports. Some workplace-chat platforms' API terms limit bulk export and AI training with data pulled through the API, so how the data comes out matters.

How scoping works

  1. At intake you list systems and counts: repositories, tickets, years of history. Nothing leaves your systems, and the intake asks whether customer data you process sits in them, whether the repos hold third-party code and whether they've been scanned for secrets.
  2. You choose what stays out. You might leave out core algorithms, pricing logic, security code, HR and private channels. Employee names come out of commits, reviews and chat the way the license specifies.
  3. You set limits before bidding: no named competitors, a field of use, or evaluation-only use. Trade-secret protection depends on reasonable measures to keep information secret, so confidentiality, deletion at the end of the term and competitor blocks belong in the license.
  4. Nothing moves until you sign, and your counsel reviews the license first.

Software and SaaS lists the systems we cover.

Follow-up questions

It can, which is why scope matters. You can leave out core algorithms and security code, block named competitors, limit the license to a field of use, and keep it non-exclusive and time-limited. Deleting data at the end of a term doesn't undo training already done, so decide those limits before you sign.

Often, with customer names and identifying details removed, and customers whose terms forbid it left out. Production data, logs and attachments stay out because you hold them for your customers.

It can be. Buyers look at history, links between tickets and code, and whether the repo builds and its tests run, more than headcount. We can't promise a bid or a price. After intake we can say what looks strong and what looks thin.

Sources

This is general information about how data licensing works. It is not legal advice, and we are not your lawyer. Have your own counsel review any license before you sign.

Keep reading on licensing your data.