Inventory code, dependencies, parameters, documentation and outputs separately. Request explicit scope for inspection, execution, modification, hosting and sharing. Source access is neither an ownership transfer nor proof of reproducibility; output access does not establish permission to reconstruct or redistribute the model. Review the actual agreement under the relevant jurisdiction.
Identify the object being supplied
Begin with a delivery inventory rather than the phrase model licence. A provider might supply daily scores, an executable container, a spreadsheet with visible formulas, or a repository containing research code. Those packages create different dependencies. A score feed may be sufficient for an analyst's comparison exercise, while an independent implementation review may require calculation details that the feed alone cannot reveal.
List trained parameters, configuration files, third-party libraries, example inputs, build instructions and explanatory documents beside the main deliverable. Ask which components are included, which are accessible only during evaluation, and which remain hosted by the provider. This prevents a demonstration of source code from being mistaken for a commitment to deliver a maintained, buildable implementation throughout the proposed commercial relationship and any agreed transition period.
Separate intellectual property from practical access
WIPO's copyright FAQ distinguishes protected expression from ideas and mathematical concepts as such. That distinction does not settle the legal treatment of a particular model, its documentation, or an attempted reproduction. Software, confidential methods, contractual promises and other rights can raise different questions. The buyer should obtain jurisdiction-specific advice on the actual materials and proposed activities, rather than infer permission from a general description of copyright.
WIPO also describes confidential algorithms as potentially relevant to trade-secret protection. Treat a source review as a controlled disclosure exercise: identify reviewers, storage locations and permitted notes before access begins. A confidentiality agreement can address disclosure without answering every question about execution or modification. Record those questions separately so a signed nondisclosure document does not become the team's informal substitute for the intended model licence.
Translate intentions into requested permissions
Describe activities with concrete verbs: inspect the implementation, execute it on approved infrastructure, change a parameter, correct a defect, compare results, or show a chart to another party. Ask the agreement reviewer to map each activity to a provision or an unresolved question. A delivery description such as downloadable package does not by itself resolve how many copies, environments or recipients are contemplated by the parties.
Modification deserves particular attention. Distinguish a buyer's configuration changes from edits to supplied code and from independent surrounding software. Request a clear account of support responsibilities after each kind of change, plus the treatment of contributed fixes. Do not assume that paying for customization determines ownership. Identify the background components and proposed new deliverables before counsel evaluates the negotiated allocation of rights and responsibilities between the parties.
Work through a hypothetical review budget
Suppose a hypothetical investment team wants to compare daily model scores and inspect the calculation for six sample instruments. It budgets two analysts for twelve hours each and one engineer for sixteen hours: 2 x 12 + 16 = 40 staff hours. These are invented planning assumptions, not a provider's price or delivery promise. The team first decides which questions genuinely require implementation access rather than documented sample calculations.
Its proposed scope gives the analysts output access and asks for a supervised code review by the engineer, without requesting production hosting or redistribution. If a reproducibility test later needs a runnable package, procurement records that as a separate requested permission and deliverable. The forty-hour estimate measures buyer effort only; it excludes legal review, provider fees and any additional data acquisition. A cheaper-looking output package is not scored as equivalent to source delivery.
| Hypothetical buyer role | People | Hours each | Total hours |
|---|---|---|---|
| Analyst | 2 | 12 | 24 |
| Engineer | 1 | 16 | 16 |
| Total | 3 | Not applicable | 40 |
Test whether delivery is reproducible
For a runnable package, ask for one frozen input fixture, the expected result, dependency versions and numerical tolerances. Rebuilding the package and matching that result establishes a narrow technical fact: this implementation can reproduce this fixture under the tested conditions. It does not establish that all research is reproducible, that the model is economically useful, or that the buyer possesses every permission needed for a different deployment arrangement.
For output-only delivery, substitute tests that match the offered service. Check identifiers, units, coverage, missing-value flags and correction handling against an agreed sample. Ask what evidence is available when a result is disputed. A source escrow arrangement, if proposed, needs separate review of deposit contents, verification, release conditions and usable dependencies; the existence of an escrow label is not evidence that operations could continue after a supplier failure.
Record the decision and the exit boundary
The procurement decision should name the chosen delivery form, the unresolved permissions and the operational consequence of each exclusion. An output subscription may be a sensible choice when the buyer can validate the relevant claims without maintaining code. A source package may be justified when independent operation or inspection is central. Neither form deserves an automatic quality premium merely because it sounds more transparent or technologically sophisticated.
Before signature, ask what happens to supplied code, generated results, review notes and copies in backups when access ends. Preserve only what the agreed terms and applicable obligations permit, with restricted access where appropriate. Have qualified reviewers reconcile the actual documents and governing law. The practical objective is a deliverable the team can evaluate and use within documented boundaries, not a universal legal conclusion about who owns every possible output.
- Name every deliverable and requested activity.
- Test reproducibility separately from permission and investment merit.
Evaluation checkpoints
- Code access, output access and ownership are separate questions.
- Specify inspection, execution, modification and sharing individually.
- Public IP guidance cannot replace review of the actual agreement.
Source notes
Related questions
Internal Use and Redistribution of Model Results
Map recipients, channels and transformations before sharing licensed investment model material outside an evaluation team.
Data Rights Versus Model Rights
Trace input licences, model permissions and output distribution without assuming one agreement covers the entire workflow.
Reading Model Documentation for Procurement
Connect methodology, data definitions, version identity and limitations to the exact model being evaluated.
Choosing Model Delivery Formats
Compare files, APIs, reports and executable packages using a shared semantic contract and realistic integration tests.
First edition, 16 October 2026. Illustrative procurement situations are not actual client engagements or legal advice.