Robot software licensing checklist

Published 14 November 2026 · inventory version 0.1 · published and edited by Randy Levine for Synthari AI LLC. No lawyer has reviewed this page, and it has not been reviewed by a qualified robotics professional. It states no legal conclusions. Corrections and disagreements are welcome at support@embodiedsoftwarelabs.com.

Why the badge is not the answer

An SPDX short-form identifier — the SPDX-License-Identifier: MIT line at the top of a source file — is described by SPDX itself as a simple way to state the licence that applies to that file, with the SPDX License List giving each entry a short identifier, a full name, the licence text and a permanent URL. It is a precise, useful, machine-readable label.

It is a label. It names a licence; it does not interpret one. A scanner that walks your dependency tree and emits four hundred identifiers has told you what the labels are. Whether that combination is acceptable for what you are shipping, to whom, under which obligations, is a legal question about documents, facts and jurisdiction — and it is the question this page exists to help you ask properly rather than answer badly.

The second thing a badge will not tell you is that a stack does not have a licence. Three packages that routinely run in the same robot, with the licence each one's own ROS Index package summary stated on 14 November 2026:

None of these is a problem. The point is only that a sentence beginning "we're Apache 2" is already inaccurate before anyone has looked at the hundreds of transitive dependencies underneath. Read these at the version you actually ship; the values above came from a summary page on one day, and summaries can lag a repository.

1. What is being licensed: code, weights, assets and configurations

The first failure is treating a delivery as one thing. A robot capability arriving on site is typically at least nine, and they behave differently:

Background that existed before the work. Contributed code written for this engagement. Third-party code you did not write and may or may not ship. Weights, which are not source code and frequently not under a software licence at all. Training data behind those weights, including anything recorded on your site. Configuration — tuning, calibration, task definitions, parameter sets. Assets — meshes, CAD, scenes. Operational data the system produces while running. And documentation.

The inventory asks for one row per asset with its type, who created it, where it came from, the licence identifier, the URL of the actual text, and — the field that does the work — the date somebody read that text and who they were. Rows where nobody has are marked NOT READ and left visible.

The other field worth the trouble is origin, and the answer to watch for is unknown. An asset whose origin nobody can name is the most expensive row in the document, because resolving it means establishing who wrote something and under what terms, long after the fact.

2. Dependencies and redistribution obligations

Everything in this section turns on a question your own engineers answer before any lawyer is involved: does this dependency ship to the customer, or does it only ever run on machines you control? Get that wrong and every answer below it is wrong too.

For each dependency that does ship, the inventory records the exact version, the identifier the project itself states, the URL of the licence text at that version, whether anyone has read it, whether the package bundles further licences of its own, and what the text says about modified versions and about patents. None of those are judgements. They are facts you can write down in an afternoon and that counsel cannot work without.

Then the question most projects cannot answer: has anything ever produced a complete dependency list with licences? Which tool, run against which lockfile, when, stored where, reviewed by whom — and does anything fail the build when a new licence appears in the tree. Most teams can account for the five dependencies they chose and not the four hundred underneath them, and the ones underneath are where surprises live.

3. Robot, site and deployment rights

Scope is where a licence and an operation quietly disagree. Each of these is a dimension somebody can later say was never included:

How many robots, and is it a count or specific serial numbers — and what happens when one is replaced. Which sites, named or any you operate. Which legal entities, and whether subsidiaries are inside. What happens if you acquire someone, or someone acquires you. Contractors and integrators working on your behalf. Simulation and test installs. Development copies on engineers' machines. Geography. Field of use. Whether you may demonstrate it publicly, film it, or publish benchmark numbers. And the term.

Weights get their own block, because they are routinely licensed on different terms from the code that runs them and the difference is invisible from a source-file header. Some model licences — the OpenRAIL family is the clearest published example — pair open access with use-based restrictions, and require that downstream recipients take on the same restrictions. That is a different shape from a permissive software licence, and an SPDX identifier on your own source says nothing about it. The inventory asks whether the weights licence restricts uses, whether those restrictions pass downstream, whether you may fine-tune and who owns the result, and whether you may distil, quantise or convert the format. Those are questions for counsel reading the actual document, not conclusions to be drawn here.

4. Ownership of outputs, improvements and operational data

Five questions that are habitually answered as one. The inventory makes them eight rows, because they genuinely have different answers: the implementation as delivered; improvements the supplier makes for you; improvements you make yourself; tuning and calibration produced on your site; weights fine-tuned on your data; raw operational logs; aggregated statistics derived from those logs; and failure recordings.

Raw data and the statistics derived from it are not the same asset, and a deployment can plausibly produce data you own, statistics somebody else owns, and a model improvement nobody has assigned to anyone. Write all three rows.

Then the feedback-loop question, asked plainly rather than inferred: does anything leave your site automatically, what exactly, how often, to where, can it be turned off, does the system still work with it off, may the supplier use it to improve a product sold to others, may it be used to train a model, and is any of it personal data — who decided that, and on what basis.

The useful way to fill this section in is two columns: what the draft agreement says next to what we assumed. The gap between them is the finding, and it usually appears where the agreement is silent rather than where it disagrees.

5. Updates, termination and continuity

Are updates included or priced separately, are you obliged to take them, may you decline one and stay supported, and may the terms change at an update — who has to agree, and with how much notice.

Then termination: how, by whom, what cure period, and the question that matters operationally — on termination must you stop running it, or only stop updating it? Those are very different outcomes when the thing in question is moving a line. Plus any wind-down period, what must be deleted and who verifies that, and whether any part of it stops working on a date, a count or a check-in.

Continuity covers the supplier disappearing: acquisition, insolvency, discontinuation, or simply leaving the market. Is there escrow, with whom, what exactly is in it, when was it last deposited, what triggers release and who decides the trigger has occurred — do the weights go in or only the code — and the field that turns escrow from a comfort into a control: has anyone ever restored it and tried to build it? An escrow deposit nobody has restored is an untested backup.

6. Questions to take to qualified counsel

This section is the output. Everything above is fact-gathering; this is what you hand over, and the point of handing it over is that a lawyer given a filled-in register can answer questions, and a lawyer given "we're using some open source robotics stuff" cannot.

What goes in the brief: the completed asset register, the dependency list with the date it was generated, the licence texts themselves at the versions you ship, the weights licence in full as a separate document, any draft agreement — and the inventory with every NOT READ left visible. Those gaps are information, and tidying them away before the meeting removes the most useful thing in the document.

The inventory carries fourteen starter questions, each tagged with the section it came from — what obligations attach when we ship, what changes if we modify a dependency, whether the combination in this register is acceptable for what we are doing, what the weights licence permits for our customers, what we have created if we fine-tune on our own data, whether our definition of "site" matches the structure we actually have, what happens on an acquisition in either direction, who owns the operational data and whether that matches what the system actually sends, what we may publish, whether we may keep running it after termination, and whether the escrow does what we think it does.

They are prompts, not a complete list, and your counsel will have their own. The last one is the one teams forget: which of these answers belongs in the agreement rather than in an email?

The decision table

Per asset class: the question that usually decides it, who can actually answer it, and what a wrong assumption costs. This is a thinking aid, not a recommendation and not a contract — the right-hand column is the practical consequence teams report, not a legal outcome.

The worked package, and what it is not

The inventory ships with a filled-in example. It is entirely fictional. The supplier does not exist, the package does not exist, nothing in it has been delivered to anyone, and none of it is a legal conclusion or a model to copy into an agreement. It is a picture of a document part-way through being filled in.

What it shows is a realistic first pass: nine assets, four of them marked NOT READ, one with an unknown origin, and three the draft agreement does not mention at all. The two that matter most — the model weights and the data behind them — are the two nobody had opened, which is the usual pattern rather than an invented one.

The most instructive part is section 4, set out as two columns: what the draft says, next to what the customer assumed. Implementation licensed, assumed owned. Tuning silent, assumed theirs. Aggregated statistics explicitly available to the supplier for product improvement, and nobody had noticed. Nobody acted in bad faith in that example — the draft is simply silent exactly where the assumption was strongest, which is what makes writing the assumptions down worth the hour.

References

Every licence named on this page is reported as that project's own published summary states it, on the date it was read. These are the documents, with what was actually checked in each:

• SPDX — handling licence information
  Checked 14 November 2026. Describes a short-form identifier as a way to state the licence applying to a source or documentation file, and the SPDX License List as a list of commonly found licences in which each entry carries a short identifier, a full name, the licence text and a permanent URL. Also gives the one-line in-file form and the OR, AND and WITH expression operators. The list itself is where identifiers resolve.
• rclcpp — ROS Index repository summary
  Checked 14 November 2026. States that contributions to the repository are made under the Apache 2 License. Reported here as what the page says, not as a conclusion about the licence.
• moveit — ROS Index package summary
  Checked 14 November 2026. States BSD-3-Clause at version 2.15.2, repeated across the Humble, Jazzy, Kilted, Lyrical and Rolling sections.
• hardware_interface — ROS Index package summary
  Checked 14 November 2026. States Apache License 2.0; version 4.50.0 under Jazzy, 2.54.4 under Humble, 5.20.0 under Kilted. Three ROS packages, two different licences — which is the only claim this page makes from these three sources.
• OpenRAIL — open and responsible AI licensing frameworks
  Checked 14 November 2026. Describes a use-based restrictions clause setting out a limited number of restricted uses, and states that OpenRAIL licences require downstream adoption of those restrictions. Cited for the shape of that licence family only; what any specific weights licence permits is a question for counsel reading it in full.
• CC BY 4.0
  The licence this inventory is published under.