# Robot software rights inventory
**Version 0.1 — 14 November 2026**
Published by Embodied Software Labs (Synthari AI LLC).
Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Use it, change it,
publish your filled-in copy. No attribution is required in the filled-in document itself.
---
## Read this first
**This is not legal advice, and it is not a contract.**
No lawyer wrote this document and no lawyer has reviewed it. It contains no legal
conclusions and it is not capable of telling you whether any licence permits anything.
It is an inventory: a way of writing down what exists, who made it, which licence text
governs it, and which of those you have actually read.
Its only purpose is to make the conversation with your own counsel short and specific.
A lawyer handed a filled-in copy of this can answer questions. A lawyer handed
*"we're using some open source robotics stuff"* cannot.
**Three rules while filling it in:**
1. **Record the licence text, not the badge.** A short identifier such as
`Apache-2.0` or `BSD-3-Clause` names a licence. It does not tell you whether two
licences can be combined in your situation, and it does not tell you what the
obligations cost you. Write down the identifier *and* the URL of the actual text
*and* the date you read it.
2. **Write `NOT READ` where nobody has read it.** That is the most useful answer in
this document, and it is more common than anyone admits.
3. **Answer per asset, not per project.** One stack routinely contains several
different licences. Treating "the stack" as having "a licence" is how the trouble
starts.
**Do not** paste contract text, counsel's advice, or anything under NDA into this file
if you intend to share it outside your organisation.
---
## 0. The package being licensed
| Field | Answer |
| --- | --- |
| 0.1 What is this package called | |
| 0.2 Who is supplying it | |
| 0.3 Who is receiving it | |
| 0.4 Is a licence already drafted, or is this pre-negotiation? | |
| 0.5 Who inside your organisation decides? | |
| 0.6 Who is your counsel on this, and have they seen anything yet? | |
| 0.7 Date of this inventory | |
---
## 1. Asset register
One row per asset. Split anything that has more than one origin.
| # | Asset | Type | Who created it | Origin | Licence identifier | Licence text URL | Date read | Read by |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | | | | | | | | |
| 2 | | | | | | | | |
| 3 | | | | | | | | |
| 4 | | | | | | | | |
| 5 | | | | | | | | |
**Type** — use one of these, because they behave differently and are regularly
collapsed into one word:
| Type | What it covers |
| --- | --- |
| `background` | Existed before this work and is not being created for it. |
| `contributed-code` | Source written for this engagement. |
| `third-party-code` | Dependencies, drivers, libraries you did not write. |
| `weights` | Trained model parameters. Not source code, and often not under a software licence at all. |
| `training-data` | What the weights were trained on, including anything recorded on your site. |
| `config` | Tuning, calibration, task definitions, behaviour trees, parameter sets. |
| `assets` | Meshes, CAD, textures, scene files, recorded scenarios. |
| `operational-data` | Produced while the system runs: logs, trajectories, images, timings. |
| `docs` | Manuals, specifications, training material. |
**Origin** — `written for this work`, `supplier background`, `your background`,
`upstream open source`, `vendor proprietary`, `generated by a model`, `unknown`.
> `unknown` origin on any row is the single highest-value finding in this document.
> It is also the row that is most expensive to resolve later, because resolving it
> means finding out who wrote something and under what terms, years after the fact.
---
## 2. Dependencies and redistribution obligations
Fill one block per dependency that ships, or that you link against. Not per project.
| Field | Answer |
| --- | --- |
| 2.1 Package name and exact version | |
| 2.2 Licence identifier as the project states it | |
| 2.3 URL of the licence text in that repository, at that version | |
| 2.4 Has somebody read that text? Who, when? | |
| 2.5 Does the package itself bundle other licences? | |
| 2.6 Does it ship to the customer, or stay on your machines? | |
| 2.7 If it ships: what does the licence text say must ship with it? | |
| 2.8 If it is modified: what does the text say about modified versions? | |
| 2.9 Any patent clause? Does it terminate on anything? | |
| 2.10 Questions this raises for counsel | |
**2.11 — The whole-dependency-tree question.** Most projects can answer 2.1–2.10 for
the five dependencies they thought of and not for the four hundred underneath them.
| Field | Answer |
| --- | --- |
| Has anything produced a full dependency list with licences? | |
| What tool, run when, against which lockfile or manifest? | |
| Where is that output stored? | |
| Who reviews it when it changes? | |
| Does anything fail the build when a new licence appears? | |
> A tool that emits identifiers has told you what the labels are. It has not told you
> whether the combination is acceptable for what you are doing, and that is the part
> that needs a lawyer rather than a scanner.
**2.12 — Worked illustration: one stack, three licences.**
These are three packages that routinely appear in the same robot, with the licence each
one's own ROS Index package summary stated on 14 November 2026:
| Package | Version / distro | Licence as the package summary states it |
| --- | --- | --- |
| `rclcpp` | ROS 2 client library | Apache 2 License |
| `hardware_interface` | 4.50.0, Jazzy | Apache License 2.0 |
| `moveit` | 2.15.2 | BSD-3-Clause |
The point is not that any of these is a problem. The point is that **a single robot
stack does not have "a licence"**, so a sentence beginning "we're Apache 2" is already
inaccurate before anybody has looked at the four hundred transitive dependencies.
Verify these yourself at the version you actually ship. The values above were read on
one day, from a summary page, and summaries can lag a repository.
---
## 3. Robot, site and deployment rights
The scope questions. Each one is a dimension somebody can later say was not included.
| Field | Answer |
| --- | --- |
| 3.1 How many robots may run it? | |
| 3.2 Is it tied to serial numbers, or to a count? | |
| 3.3 What happens when a robot is replaced? | |
| 3.4 Which sites? Named, or any site you operate? | |
| 3.5 Which legal entities? Does it cover subsidiaries? | |
| 3.6 Does it cover an entity you acquire? One that acquires you? | |
| 3.7 Contractors and integrators working on your behalf? | |
| 3.8 Other robot models, now or later? | |
| 3.9 Simulation and test installations — counted, or free? | |
| 3.10 Development copies on engineer machines? | |
| 3.11 Geographic restrictions? | |
| 3.12 Field of use restrictions — industry, application, task? | |
| 3.13 May you demonstrate it publicly? Film it? Publish results? | |
| 3.14 May you benchmark it and publish the numbers? | |
| 3.15 Term — perpetual, fixed, or renewing? | |
**3.16 — Weights, separately.** Weights are frequently licensed on different terms from
the code that runs them, and the differences are not visible from a source-file header.
| Field | Answer |
| --- | --- |
| Are the weights covered by the same document as the code? | |
| What is the exact name of the weights licence? | |
| Does it restrict *uses* rather than only copying? | |
| Must those restrictions be passed to anyone you give the model to? | |
| May you fine-tune? Who owns the result? | |
| May you distil, quantise or convert the format? | |
| May you run it on hardware you do not own? | |
| Does anything require attribution in your product? | |
> Some model licences — the OpenRAIL family is the clearest published example — combine
> 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 files says nothing about it.
> Ask counsel what it means for your specific deployment; do not infer it from a label.
---
## 4. Ownership of outputs, improvements and operational data
Five separate questions that are routinely answered as one.
| # | The thing | Who owns it | Who may use it | May it be published? | Does it transfer on exit? | Written down where? |
| --- | --- | --- | --- | --- | --- | --- |
| 4.1 | The implementation as delivered | | | | | |
| 4.2 | Improvements the supplier makes for you | | | | | |
| 4.3 | Improvements you make yourself | | | | | |
| 4.4 | Tuning, calibration and configuration you produce | | | | | |
| 4.5 | Model weights fine-tuned on your site | | | | | |
| 4.6 | Raw operational data — logs, images, trajectories | | | | | |
| 4.7 | Aggregated statistics derived from 4.6 | | | | | |
| 4.8 | Failure cases and incident recordings | | | | | |
**4.9 — The feedback-loop question, asked plainly.**
| Field | Answer |
| --- | --- |
| Does anything leave your site automatically? | |
| If so, what exactly, how often, and 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? | |
| Is any of it personal data? Who decided that, and on what basis? | |
| Who is told when the answer to any of the above changes? | |
> 4.6 and 4.7 are different assets and are often treated as one. 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.
---
## 5. Updates, termination and continuity
| Field | Answer |
| --- | --- |
| 5.1 Are updates included, or priced separately? | |
| 5.2 Are you obliged to take them? | |
| 5.3 May you decline one and stay supported? | |
| 5.4 May terms change at an update? Who has to agree? | |
| 5.5 What is the notice period for a change? | |
| 5.6 How is the licence terminated, and by whom? | |
| 5.7 What is the cure period for a claimed breach? | |
| 5.8 On termination, must you stop running it, or stop updating it? | |
| 5.9 Is there a wind-down period? How long? | |
| 5.10 What must be deleted, and who verifies it? | |
| 5.11 Does any part of it stop working on a date, a count, or a check-in? | |
**5.12 — Continuity if the supplier disappears.** Acquisition, insolvency,
discontinuation, or simply a decision to leave the market.
| Field | Answer |
| --- | --- |
| Is source escrow in place? With whom? | |
| What exactly is in escrow, and when was it last deposited? | |
| What triggers release, and who decides the trigger has happened? | |
| Would the released material actually build? Has anyone tried? | |
| Do the weights go into escrow, or only the code? | |
| Does the licence survive an acquisition of the supplier? | |
| Does it survive an acquisition of *you*? | |
| What is your plan if the answer to all of the above is no? | |
> "Has anyone tried to build it" is the field that turns escrow from a comfort into a
> control. An escrow deposit that nobody has ever restored is an untested backup.
---
## 6. Questions to take to counsel
This section is the output of the document. Everything above is fact-gathering; this is
what you hand over.
**6.1 — Attach to the brief for counsel:**
- [ ] The completed asset register from section 1
- [ ] The dependency list with licence identifiers and 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 from the supplier
- [ ] This document, with every `NOT READ` left visible
**6.2 — The questions. These are prompts, not a complete list, and your counsel will
have their own.**
| # | Question | Which section it comes from |
| --- | --- | --- |
| 1 | Given this dependency list, what obligations attach to us when we ship? | 2.7, 2.11 |
| 2 | Which of these obligations change if we modify a dependency? | 2.8 |
| 3 | Do any of the patent provisions here interact with our own patent position? | 2.9 |
| 4 | Is the combination of licences in this register acceptable for what we are doing? | 1, 2 |
| 5 | What does the weights licence permit for our specific deployment and customers? | 3.16 |
| 6 | If we fine-tune on our own data, what have we created and who owns it? | 3.16, 4.5 |
| 7 | Does our definition of "site" and "entity" cover the structure we actually have? | 3.4–3.7 |
| 8 | What happens to our rights if we are acquired? If they are? | 3.5, 5.12 |
| 9 | Who owns the operational data, and does that match what the system actually sends? | 4.6, 4.9 |
| 10 | Is any of the data flowing off site personal data, and what follows if it is? | 4.9 |
| 11 | What are we permitted to publish — benchmarks, failures, video? | 3.13, 3.14 |
| 12 | On termination, may we keep running what we have? | 5.8, 5.9 |
| 13 | Is the escrow arrangement capable of doing what we think it does? | 5.12 |
| 14 | Which of these answers should be in the agreement rather than in an email? | all |
**6.3 — What you are asking counsel to decide.** Note it explicitly, so the brief is a
question and not a request for reassurance:
| Field | Answer |
| --- | --- |
| The decision this is informing | |
| The date by which it is needed | |
| What we will do if the answer is unfavourable | |
| Who signs | |
---
## Appendix A — Decision table
Not a contract and not a recommendation. A way of seeing, per asset class, which
question is the one that matters and who can answer it.
| Asset class | The question that usually decides it | Who can answer it | What a wrong assumption costs |
| --- | --- | --- | --- |
| Third-party code that ships | What must travel with it when we distribute? | Counsel, reading the actual text | Rework late, or a shipped obligation you did not meet |
| Third-party code that stays internal | Does it ship at all, or only run on our machines? | Your own engineers, honestly | A wrong answer here makes every row below it wrong |
| Contributed code | Who owns it when the engagement ends? | Counsel, from the agreement | Paying twice, or losing the ability to maintain it |
| Supplier background IP | What are we permitted to keep using afterwards? | Counsel | A delivered system you cannot legally continue to run |
| Model weights | Does the licence restrict *uses*, and do those restrictions pass downstream? | Counsel, reading the weights licence in full | A product you cannot sell into a customer's application |
| Training data | Where did it come from, and was its use permitted? | The supplier, in writing | The weights become unusable and so does everything built on them |
| Tuning and configuration | Is this a deliverable or the supplier's method? | Counsel, from the agreement | You can run the system but not change it |
| Operational data | What leaves the site, and what may be done with it? | Your engineers first, then counsel | Data you assumed was yours training somebody else's product |
| Escrow | Has anyone restored it and built it? | Your engineers | Discovering the answer during the incident |
---
## Appendix B — A hypothetical worked package (HYPOTHETICAL)
**This example is entirely fictional and HYPOTHETICAL.** The supplier does not exist, the package does not
exist, nothing described here has been delivered to anyone, and every entry was invented
to show what a filled-in register looks like. **None of it is a legal conclusion, a
recommendation, or a model to copy into an agreement.** It is a picture of a document
part-way through being filled in — including the gaps, which is the realistic state.
### The package
*(fictional)* Northfield Packing Co. is scoping a supervised tote-transfer capability
from *(fictional)* Harrowgate Robotics. Nothing has been signed.
### 1. Asset register
| # | Asset | Type | Who created it | Origin | Licence identifier | Date read | Read by |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | Capability source | `contributed-code` | Harrowgate | written for this work | Not stated in the draft | — | **NOT READ** |
| 2 | ROS 2 client library | `third-party-code` | upstream | upstream open source | Apache 2 License, per the package summary | 14 Nov 2026 | Eng lead |
| 3 | Motion planning | `third-party-code` | upstream | upstream open source | BSD-3-Clause, per the package summary | 14 Nov 2026 | Eng lead |
| 4 | Controller framework | `third-party-code` | upstream | upstream open source | Apache License 2.0, per the package summary | 14 Nov 2026 | Eng lead |
| 5 | Grasp model weights | `weights` | Harrowgate | supplier background | A named model licence with use restrictions | — | **NOT READ** |
| 6 | Training data behind row 5 | `training-data` | unknown | **unknown** | — | — | **NOT READ** |
| 7 | Cell CAD | `assets` | the original cell installer | third party, not the supplier | None — no document exists | — | — |
| 8 | Tuning and calibration | `config` | jointly, on site | written for this work | Not addressed in the draft | — | — |
| 9 | Operational logs | `operational-data` | produced by the system | generated in operation | Not addressed in the draft | — | — |
> Four `NOT READ`s, one `unknown` origin, and three assets the draft does not mention at
> all. That is a normal result for a first pass, and it is exactly the list counsel
> needs. Rows 5 and 6 are the ones that matter most and the ones nobody had opened.
### 2. Dependencies
Full tree not yet generated. No tool has been run, no output is stored, nothing fails
the build when a new licence appears. **Question 1 for counsel cannot be asked until
this exists**, so generating it is the first action, before the meeting.
### 3. Scope, as the draft currently reads
| Field | Answer |
| --- | --- |
| Robots | "the robot" — singular, not tied to a serial number. Unclear what happens on replacement. |
| Sites | One named site. Northfield operates three. |
| Entities | Northfield Packing Co. only. Two subsidiaries not mentioned. |
| Contractors | Not mentioned. The line is maintained by a contractor. |
| Simulation | Not mentioned. |
| Publishing results | Not mentioned. |
| Term | Three years, renewing. |
**3.16 Weights** — the draft refers to a model licence by name but does not attach it.
Nobody at Northfield has read it. Whether it restricts uses, and whether those
restrictions would reach Northfield's own customers, is **unknown and material**.
### 4. Outputs and data
| The thing | Draft says | Northfield assumed |
| --- | --- | --- |
| Implementation as delivered | Licensed, not owned | Owned |
| Improvements Harrowgate makes | Harrowgate owns | Not considered |
| Tuning produced on site | Silent | Northfield owns |
| Weights fine-tuned on site | Silent | Not considered |
| Raw logs | Silent | Northfield owns |
| Aggregated statistics | Harrowgate "may use for product improvement" | Not noticed |
> The gap between the two columns is the finding. Nobody acted in bad faith; the draft
> is simply silent where the assumption was strongest.
### 5. Continuity
No escrow. No wind-down period in the draft. Termination clause requires the system to
stop being used, not merely stop being updated — which, if correct, would stop the line.
**Flagged as the first question in the brief.**
### 6. What went to counsel
The register above with every `NOT READ` left visible, the two unattached licences once
obtained, the draft agreement, and questions 1, 5, 6, 9, 12 and 13 marked urgent.
---
## Change log
| Version | Date | Change |
| --- | --- | --- |
| 0.1 | 14 November 2026 | First publication. |
## Review status
**No lawyer has reviewed this document**, and it contains no legal conclusions by
design. It has also not been reviewed by a qualified robotics professional.
Corrections and disagreements are welcome at `support@embodiedsoftwarelabs.com`.
## References
- SPDX — handling license info, short-form identifiers and the SPDX License List —
- The SPDX License List itself —
- `rclcpp` package summary —
- `moveit` package summary —
- `hardware_interface` package summary —
- OpenRAIL — open and responsible AI licensing frameworks —
- CC BY 4.0 —