Proprietary algorithms in your code: exclude or include?

What counts as a proprietary algorithm in a code license?#

A proprietary algorithm, for licensing purposes, is code whose competitive value depends on competitors not knowing how it works. Typical examples are scoring and ranking models, scheduling or routing solvers, pricing and quoting rules, fraud or anomaly thresholds, proprietary data transformations, and the tuned parameters and weights that make any of these perform.

Most of a codebase is not in that category. Application screens, CRUD services, standard integrations, infrastructure code, migrations and test harnesses are necessary but rarely secret, and they hold much of the engineering history that AI developers license. Drawing the line narrowly keeps the package valuable while protecting what matters.

A separate category needs checking before any tiering: logic built under custom development agreements. Some customer contracts assign the resulting IP to the customer or restrict reuse of deliverables, so a module can be off limits for contract reasons even when it is not competitively sensitive. Search statements of work and master agreements for assignment and work-product clauses.

Why is a training license different from showing code in diligence?#

In diligence, an acquirer's reviewers read code under an NDA, for a limited purpose, and the access ends. In a training license, the code becomes material a model learns from, and models can absorb patterns and sometimes reproduce passages they were trained on, even when the contract restricts how the buyer uses the data.

Trade secret protection generally depends on taking reasonable measures to keep the information secret. US Department of Justice guidance describes those measures as reasonable rather than absolute, citing steps such as limiting access on a need-to-know basis and requiring confidentiality agreements. Licensing core logic for training, even under confidentiality terms, may make that position harder to argue later, which is a question for counsel before any core code is offered. Excluding it avoids the question entirely.

The decision rule and three-tier scope#

The decision rule asks one question of each component: would a competitor who read it learn how your product wins? If yes, it is core IP. Applying that rule across a codebase produces three tiers, each with a default treatment.

• 1Is the component described internally as confidential, restricted or trade secret?
• 2Would a competitor gain a measurable shortcut by reading it?
• 3Is it still in production, or is it a retired approach the product has moved past?
• 4Was it funded by, built for or assigned to a specific customer?
• 5Does it implement security controls whose details would help an attacker?
• 6Is the idea already public through a patent or published paper, leaving only the implementation private?

How do you carve out core IP without breaking the rest?#

Core IP is carved out by path, then chased into every place that describes it. Start by removing the core directories from a separate delivery mirror, across all history, so that no earlier commit still contains them. Where calling code would become unreadable, replace the core module with an interface stub: function signatures and short descriptions with no implementation.

Then follow the algorithm outward. Pull request diffs that touch core paths, review comments that explain why a weight was changed, commit messages that describe the approach, and design documents in Confluence or Notion can each reveal what the code removal hid. Exclude those pull requests whole, or redact the specific passages, and record which rule was applied.

Finally, check configuration and data files. Thresholds, coefficients and lookup tables often sit in YAML, JSON or database seeds rather than in the algorithm's own folder, and they can carry most of the secret on their own.

Illustrative: a field service routing vendor draws the line#

Illustrative: a fictional field service software company sells dispatch and scheduling software to HVAC and plumbing contractors. Its edge is a route optimization solver and a travel-time model with weights tuned over years of customer feedback.

The CTO classifies the solver and the weights as tier 1, the dispatch module and the pull requests that debated weighting changes as tier 2, and the scheduling interface, mobile app, accounting integrations and bug-fix history as tier 3. The delivery mirror drops the solver paths from history and replaces them with stubs, excludes every pull request whose diff touched those paths, and redacts the related design pages in Confluence. Counsel reviews the scope, and the licensed package keeps years of dispatch application engineering history without the solver.

Which contract terms protect what you include?#

Contract terms protect the tier 2 and tier 3 code you include; they are not a substitute for excluding tier 1. Read the draft license for the clauses below, and ask counsel how each interacts with your confidentiality and trade secret position.

Watch for terms that pull in the opposite direction. A request for exclusivity, perpetual rights or a broad grant covering future code changes the risk of everything included, and may also trigger investor or lender approvals. Each of those is negotiable, and none is needed for a typical non-exclusive training license.

• 1Permitted use limited to training and evaluating models, with no redistribution of the raw code.
• 2Confidentiality obligations covering the delivered package and any samples shared before signing.
• 3A prohibition on attempts to reconstruct excluded components or identify the supplier's customers.
• 4Questions about how the buyer tests models for reproducing licensed text and what happens when it does.
• 5A non-exclusive grant for a fixed term unless there is a deliberate reason to agree otherwise.
• 6Deletion or return of the delivered data at the end of the term, with written confirmation.

How SourceX handles core IP#

SourceX identifies candidate core IP in the Rights step of the SourceX five-step transaction, and the supplier decides the scope; SourceX does not need core code to assess fit, and its own rights in any deidentified dataset are set out in the signed agreement. Exclusions are applied during Preparation in the supplier's environment.

The SourceX Evidence Packet records the permitted use and the categories excluded, such as optimization logic or tuned parameters, without describing their contents, so the buyer understands what is missing and why.