Robotics and Autonomous Systems IP Toolkit: Stacks, Sensor Data, Safety Files, and Integration

By Casey Scott McKay · 2024-05-19

A robot is four assets pretending to be one: hardware, a software stack, a corpus of sensor and field data, and a safety file that is the actual barrier to entry. This toolkit assembles the working material for practitioners advising robotics developers, integrators, and operators. It explains why the safety case is the most valuable and least discussed asset in the sector, how field data rights determine whether a deployed fleet improves the vendor's product or the customer's, what a model trained on customer data means at the end of a contract, and why the integrator layer is where most ownership disputes are created. It covers the open source position that most robotics stacks inherit without auditing, the outputs question for machine-generated work, and the liability allocation that shapes every commercial term.

IP and Technology > Information Technology | Toolkit | Published 19 May 2024 - Updated 15 November 2024 | Casey Scott McKay - marksy.us

Summary. A robot is four assets pretending to be one: hardware, a software stack, a corpus of sensor and field data, and a safety file that is the real barrier to entry. This toolkit assembles working material for advising developers, integrators, and operators: why the safety case is the sector's most valuable and least discussed asset, how field data rights determine whether a deployed fleet improves the vendor's product or the customer's, what a model trained on customer data means at contract end, and why the integrator layer creates most ownership disputes. It covers the inherited open source position, the machine-outputs question, and the liability allocation shaping every commercial term.

Keywords: robotics IP · autonomy stack · sensor data rights · training data provenance · safety case documentation · functional safety file · integrator agreements · field data · model weights · simulation environments · teleoperation · open source robotics · machine outputs · liability allocation · fleet learning

Start Here

Ask a robotics company what it owns and it will describe a robot. Ask a lawyer to schedule the assets and four separate things appear, each governed differently, each held by a potentially different party.

The hardware. Mechanical design, actuators, sensors, and the integration of bought-in components. Protected by patents on the genuinely novel mechanisms, by design rights on appearance, and — mostly — by manufacturing know-how that is a trade secret if it is treated as one.

The stack. Perception, localisation, planning, and control software, plus the middleware that connects them. This is copyrighted code with an open source inheritance that almost nobody has audited, sitting on top of models whose legal status is unsettled.

The data. Sensor recordings, annotated training sets, simulation environments, and — the category that matters commercially — field data generated by deployed units in customer environments.

The safety file. Hazard analyses, risk assessments, requirement traces, verification evidence, and the documented argument that the system is acceptably safe for its intended use. It costs more than everything else, cannot be shortcut, and is the reason a competitor with an identical robot cannot sell one.

The characteristic failure in this sector is treating the first as the asset and the other three as by-products. In practice the hardware is increasingly commoditised, the stack is partly borrowed, the data is contested, and the safety file is the moat.

Four questions organise the practice.

Who owns the field data, and can the vendor learn from it? The single most consequential term in a robotics deployment agreement, and the one most often left to a general confidentiality clause.

What is in the stack, and under what licence? Robotics middleware and perception libraries carry obligations that propagate, and the audit is rarely done before shipping.

Who holds the safety case, and what happens to it on exit? It is jointly created in most integrations and owned by nobody in particular.

Where does liability sit when the system acts? The allocation determines the commercial structure and, indirectly, the intellectual property terms.

For the doctrinal treatment see The Machine That Decides; for the operational sequence see Building a Robotics or Autonomous Systems Programme.

The stack, and the open source inheritance

Robotics software is built on shared infrastructure to a degree unusual even in software. Middleware frameworks, perception libraries, planning algorithms, simulation environments, and driver layers are overwhelmingly open source, and a working stack typically incorporates hundreds of components under a dozen or more licence families.

The consequences are ordinary open source consequences with a robotics twist.

Permissive licences require attribution and notice preservation, which is a build-system problem rather than a legal one and is failed for that reason.

Reciprocal licences propagate, and the boundary questions — dynamic linking, plugin architectures, separate processes communicating over a message bus — are exactly the architectural patterns robotics middleware uses. A stack that communicates through a publish-subscribe layer may or may not have created a combined work, and reasonable practitioners disagree.

Network-triggered obligations matter for teleoperation and fleet management systems, where software is used over a network rather than distributed.

Hardware distribution triggers distribution. A company that thinks of itself as selling robots rather than software is nonetheless distributing software, with everything that entails including source availability obligations and, under some licences, installation information for the device.

Model weights are not clearly code, and licences drafted for software do not map cleanly onto trained parameters. Terms attached to pre-trained models frequently include use restrictions of a kind traditional open source licences do not have, which makes them contractual rather than open in the conventional sense.

See Copyleft and Consequences, the Software, Data, and Open Source Toolkit, and the Technology Contracts Toolkit.

Data: provenance, annotation, and the field

Data in robotics divides into four categories with different legal positions.

Collected sensor data. Recordings from cameras, lidar, radar, and other sensors. Facts about the world, thinly protected at best under Feist Publications v. Rural Telephone Service, protected in practice by access control and contract, and potentially personal data where people appear in it.

Annotated training sets. The annotation is the value and the labour, and it is a compilation with a stronger position than the raw data. Annotation is frequently outsourced, which raises ownership questions under 17 U.S.C. § 201 that a purchase order does not resolve.

Simulation environments. Synthetic scenes, scenario libraries, and the tooling that generates them. These are authored works with clear protection, are expensive to build, and are the asset most often overlooked in a schedule.

Field data. Everything a deployed unit records in a customer environment. This is where the commercial fight is, because it improves the product, it may reveal the customer's operations, and both parties believe they own it.

The field data question should be decided expressly, in five parts.

Who owns the recordings, which is usually the customer for anything depicting their premises, people, or processes.

What may the vendor do with them: diagnostics only, aggregate performance analysis, or training.

What survives termination: whether the vendor must delete, and whether a model already trained can be unwound — which it cannot, so the input restriction is the only real control.

Whether improvements flow back, and whether the customer gets any benefit from a model improved on its data.

Who bears the privacy obligations where the data contains images of people, which in warehouse, retail, hospital, and public-space deployments it invariably does.

See the Data Licensing and Rights Toolkit, the Data Licensing Checklist, Buying a Model, and the AI Procurement and Governance Toolkit.

The safety file, which is the actual asset

A system that acts in the physical world near people requires a documented safety argument. Depending on the domain that may be a functional safety assessment against a recognised standard, a risk assessment and residual risk statement, a conformity assessment, or a full safety case with an explicit argument structure.

Whatever its form, it comprises: a definition of the intended use and the operational design domain; hazard identification; risk assessment; safety requirements derived from the hazards; the design measures satisfying them; verification and validation evidence; residual risk acceptance; and the traceability tying every element together.

Three properties make it the sector's most important asset.

It is expensive and slow. Years of work and a substantial fraction of programme cost.

It is not replicable from the product. A competitor can buy a robot, disassemble it, and learn the design. It cannot learn the hazard analysis, the test campaign, or the argument.

It is legally awkward. It is a compilation of authored documents, a trade secret if treated as one, frequently jointly created with an integrator and a notified or certifying body, and subject to disclosure obligations to customers and regulators that cut against secrecy.

Practical positions worth taking early.

Schedule it as an asset in every agreement that touches it, rather than leaving it as an unnamed work product.

Allocate ownership on integration projects, since the integrator's application-specific hazard analysis and the developer's platform safety argument combine into something neither party owns cleanly.

Control the disclosure route. Customers need enough to operate safely; competitors need nothing. The line is drawn by defining what is delivered rather than by a confidentiality clause applied after the fact.

Treat it as a trade secret deliberately, with marking, access control, and enumeration, so that 18 U.S.C. § 1839 is available if it walks out with a departing safety engineer.

Version it against the product. A safety argument that no longer matches the software running in the field is not a defence; it is evidence.

Integration, and where ownership disputes are made

Very few robots are sold as finished products. Most are deployed through an integrator who selects the platform, designs the cell or the route, writes application-specific software, configures the safety measures, and commissions the installation.

That produces three-party structures — developer, integrator, end customer — with a predictable set of unresolved questions.

Who owns the application software? The integrator wrote it, the customer paid for it, and the developer's platform is required to run it. Absent a written transfer satisfying 17 U.S.C. § 204, the integrator owns it, which customers consistently find surprising.

May the integrator reuse it? The commercial model depends on reuse across customers, and customers frequently believe they bought exclusivity they did not pay for.

Who owns the configuration and tuning? Parameters developed on site over weeks are valuable and are documented nowhere except the machine.

Who owns the application safety assessment? See above; this is where the joint creation problem bites hardest.

Who supports the system if the integrator disappears? Which is a continuity question answered by escrow, documentation obligations, and a step-in right, or not answered at all.

What data flows to whom? The developer wants field data for the platform; the integrator wants it for the application; the customer wants none of it to leave.

The drafting response is a three-way framework rather than two bilateral agreements, or — where that is impractical — carefully aligned flow-downs. See the Joint Development Agreement Checklist, the Software Continuity and Escrow Toolkit, and Contracting With a Manufacturer.

Outputs, inventorship, and the machine that produces something

Two questions recur once a system operates autonomously.

Does the machine's output attract rights, and whose? A robot that generates a survey, a map, an inspection report, or a design is producing something that looks like a work. The consistent answer in current practice is that human authorship is required, which places purely machine-generated output outside copyright and makes the value contractual — in the selection, arrangement, and presentation contributed by people, and in the terms on which the output is supplied.

Can a machine be an inventor? The settled answer at present is no; an inventor must be a natural person. Where an autonomous system contributes materially to a solution, the practical response is to document the human contributions to conception, since a filing with a defective inventorship statement is a correctable problem only if the facts are recorded.

See Who Owns the Work?, the AI Content and IP Toolkit, Deploying Generative AI Without Losing Your IP, and the Inventorship and Patent Ownership Disputes Toolkit.

Patents in autonomy

Eligibility is the first hurdle. A claim to a planning or perception method risks characterisation as an abstract idea under 35 U.S.C. § 101 and the Alice Corp. v. CLS Bank International framework. Claims tied to specific sensor configurations, physical actuation, and concrete technical improvements fare better than claims to decision logic in the abstract.

Enablement and written description under 35 U.S.C. § 112 are genuinely difficult for learned systems, where the behaviour is a product of training rather than of design, and where Amgen Inc. v. Sanofi has sharpened the requirement that a claimed genus be enabled across its scope.

Divided infringement arises where a claim spans a robot, a cloud service, and an operator's action.

Design patents under 35 U.S.C. § 171 are useful for service and consumer robots, where appearance carries brand value.

The publication problem is acute, since robotics research culture publishes aggressively and the grace period in 35 U.S.C. § 102 is narrow domestically and absent in most foreign jurisdictions.

Freedom to operate should precede commitment to a sensor architecture, since redesigning a perception stack after deployment is close to impossible.

See the Patent Fundamentals Toolkit, Freedom to Operate, and the Freedom to Operate Checklist.

Privacy, because robots have cameras

Any system with perception sensors deployed near people collects personal data, and the sector consistently under-appreciates this.

Images of people are personal data in most regimes, whether or not anyone intends to identify them, and a warehouse robot recording continuously is running a surveillance system.

Biometric statutes reach face and gait analysis, with written consent requirements and per-violation damages, discussed in Your Face as Data and the Biometric and Sensitive Data Toolkit.

Workplace deployments engage employee monitoring rules, since a robot recording a facility is recording the people who work in it. See Everything the Application Knows and the Recruitment and Workforce Data Toolkit.

Public-space deployments raise notice questions that no contract with the customer resolves, because the people recorded are not parties to it.

The training use is the sharp end. Field data containing images of people, used to train a model, is a processing purpose that must be disclosed and that may require a basis the deployment never established.

See the State Privacy Compliance Toolkit and Standing Up a Multi-State Privacy Compliance Program.

Liability, and why it drives the commercial terms

A system that acts physically can injure people and damage property, which changes the negotiating posture on every clause.

Product liability attaches to the hardware and, increasingly, to the software. The developer, the integrator, and the customer each have exposure, and the allocation between them is contractual only as between them.

The safety file is the primary defence, which is another reason to treat it as an asset and to keep it current.

Indemnities and caps are negotiated against physical harm, not against subscription fees, and a cap at fees paid is not a serious position where a machine can injure someone.

Insurance participates structurally, and insurers ask about the safety case, the change management process, and the software update mechanism. See the IP Insurance and Risk Transfer Toolkit.

Over-the-air updates create a continuing duty. A vendor that can change the behaviour of a deployed fleet has assumed something, and the contract should say what.

Teleoperation blurs the allocation further, because a human operator in another country intervening in a system's behaviour introduces a party whose acts are attributable to somebody.

Trade secrets, hiring, and the mobility problem

Most of what distinguishes a robotics company is unpatented: tuning heuristics, failure-mode knowledge, calibration procedures, test methodology, and the accumulated understanding of why the system behaves as it does in the field.

That material lives in a small number of engineers, which makes hiring the sector's principal competitive mechanism and the principal source of disputes.

Reasonable measures must be designed for a small, mobile, technically sophisticated workforce. Access control, marking, enumeration of what is secret, and disciplined onboarding and exit.

Departure forensics should be routine rather than exceptional, because a process applied only when someone is suspected looks like retaliation and produces worse evidence.

Restrictive covenants are increasingly unavailable or narrowed, which pushes the protection back onto secrecy discipline and onto confidentiality terms that survive employment.

Inevitable disclosure is unavailable in many jurisdictions, and a claim built on it in the wrong forum fails at the outset.

Simulation environments and test corpora walk out easily, because they are files, and they are frequently the most valuable single artefact.

See Trade Secrets and the DTSA, Building a Trade Secret Program That Survives Litigation, the Trade Secret Protection and Departure Checklist, Where an Employee Can Go, and the Employee, Founder, and Mobility IP Toolkit.

Fleet learning, and the question the sector has not settled

The commercial promise of deployed robotics is that the fleet improves. Every unit that operates generates experience; the experience trains a better model; the better model is pushed to every unit. The vendor's product improves at the customer's expense, in the sense that the customer's environment supplied the training signal, and the customer's competitor receives the benefit.

Nobody has settled what is fair here, and the contracts reflect that by saying nothing or by saying something opaque.

Four positions are actually available, and a practitioner should know which one is being taken.

No learning from customer data. The vendor uses field data for diagnostics and support only. Clean, easy to police, and it forecloses the business model the vendor is probably funded on. Customers in sensitive environments — defence, healthcare, competitively sensitive manufacturing — often insist on it and should.

Learning from de-identified aggregate data. The vendor may use derived signals rather than recordings. Workable, but the de-identification standard must be specified, and "aggregate" is doing enormous work in most drafting.

Learning with reciprocity. The vendor may train on customer data and the customer receives something: reduced pricing, priority access to improvements, or a share of the benefit. Rare, negotiable, and the position most likely to survive contact with a sophisticated customer.

Learning without limits. The default in most vendor paper, expressed as a licence to use data to improve the services. Customers sign it because it is buried, and discover it when a competitor's units perform better in their own use case.

The unwind question sits under all four. A model trained on a customer's data cannot be untrained when the contract ends. Deletion obligations that speak only to data are therefore incomplete, and the only real control is the input restriction agreed at the start. Say so in the negotiation, because a customer that believes deletion will fix it later is negotiating on a false premise.

The competitive-intelligence problem sits alongside. Field data from a warehouse reveals throughput, layout, staffing, and process. Even where nothing identifiable leaves, a vendor serving three competitors in one industry holds knowledge none of them intended to share. That is a confidentiality question rather than a data-protection one, and it is answered by use restrictions and by internal separation rather than by de-identification.

Advising the three kinds of client

The platform developer. Builds robots and a stack, sells to integrators or directly. Its priorities are the open source audit, the safety file as an asset, field data rights running toward it, and a patent portfolio concentrated on genuinely novel mechanisms and on system claims that a competitor cannot avoid. Its characteristic error is under-documenting the safety argument as an asset — treating it as a compliance cost rather than as the moat — and then finding it jointly created, unmarked, and walking out with an engineer.

The integrator. Selects platforms, designs applications, commissions installations. Its priorities are reuse rights across customers, ownership of application software and configuration, a clear boundary between platform and application safety arguments, and continuity obligations that do not make it the guarantor of a vendor it does not control. Its characteristic error is signing customer paper that assigns everything, which destroys the reuse economics its business depends on, usually discovered two customers later.

The operator. Buys and runs a fleet. Its priorities are data ownership, privacy responsibility, continuity if the vendor or integrator fails, control over updates that change behaviour in its facility, and clarity on liability if something goes wrong. Its characteristic error is assuming that paying for a system means owning the software in it, and that a confidentiality clause protects data it never asserted ownership of.

Each of the three signs agreements drafted by the others. A practitioner who knows which chair the client is sitting in, and which two clauses matter most from that chair, will add more value in an hour than a full review adds in a week.

A short glossary

Autonomy stack. The layered software producing perception, localisation, planning, and control, connected by middleware.

Operational design domain. The conditions under which the system is designed to operate safely. The single most load-bearing definition in any safety argument, and the thing marketing departments quietly widen.

Safety case. The structured argument, supported by evidence, that a system is acceptably safe for a defined use. Not the same as a certificate.

Hazard analysis. The identification of ways the system can cause harm, from which safety requirements are derived.

Traceability. The links from hazard to requirement to design measure to verification evidence. Without it the file is a pile of documents rather than an argument.

Field data. Everything a deployed unit records in a customer environment. The commercial fight.

Fleet learning. Improving a shared model from data generated across deployments.

Model weights. The trained parameters. Not obviously code, not obviously data, and licensed under terms drafted for neither.

Simulation environment. Synthetic scenes and scenario libraries used for development and verification. Highly portable, highly valuable, routinely unscheduled.

Teleoperation. Remote human intervention in an otherwise autonomous system, introducing an actor whose conduct is attributable to somebody.

Software bill of materials. The generated inventory of components and licences. Generated, not compiled by hand.

Application software. The integrator's site-specific code, owned by the integrator absent a signed transfer.

Configuration and tuning. Site-specific parameters developed over weeks and documented nowhere but the machine.

Over-the-air update. The mechanism by which a vendor changes deployed behaviour, and the source of a continuing duty the contract should define.

Practitioners who keep those fourteen straight will avoid the sector's standard category error, which is treating a robot as a product rather than as a bundle of four assets held by three parties under two regulatory regimes.

What good looks like

Eight features distinguish a robotics company whose intellectual property position will survive diligence, an incident, or a departure.

A four-asset schedule exists and is used. Hardware, stack, data, safety file, enumerated and attached to every agreement, so no two parties mean different things by "the system."

The bill of materials is generated by the build, not assembled by hand before a financing, with a standing escalation rule for reciprocal and network-triggered licences.

Field data terms are explicit and priced. Ownership, permitted uses, training, survival, and the honest statement that a trained model cannot be unwound.

Annotation and simulation assets are assigned in writing, because both are contractor-produced, both are portable, and neither transfers by paying an invoice.

The safety file is treated as an asset: scheduled, marked, access-controlled, version-matched to the deployed software, and allocated between platform and application on integration projects.

Publication is cleared before submission, with a route short enough that researchers use it.

Deployment agreements name a continuity mechanism — escrow with build environment and calibration data, documentation obligations, step-in rights — rather than assuming the counterparty persists.

An incident runbook exists and preserves the software version, the safety file version, the logs, and the telemetry within hours rather than weeks.

Companies with those eight negotiate from strength and defend from evidence. Companies without them find that the two documents everyone wants after an incident — the safety argument and the field data — are respectively out of date and owned by someone else.

Marketing claims, and the regulator nobody expects

Robotics companies describe their systems ambitiously, and the gap between the marketing and the operational design domain is a legal exposure in three directions at once.

Advertising law. Capability claims must be substantiated. "Fully autonomous," "requires no supervision," and accuracy percentages are all claims, and unsubstantiated performance claims engage 15 U.S.C. § 45 and, as between competitors, 15 U.S.C. § 1125. See the Advertising and Marketing Law Toolkit.

The safety argument. A marketing claim that the system operates in conditions the safety file excludes is evidence that the operational design domain was not respected, and it will be produced. This is the most damaging document in a post-incident case and it was written by someone who never read the hazard analysis.

Investor materials. Capability descriptions in a deck become representations, and the divergence between what the deck says and what the file supports is a diligence finding and occasionally a securities problem.

The remedy is procedural and cheap: route capability claims through the same person who owns the safety file, and give marketing a written list of the phrases that cannot be used. It takes an hour, it is the highest-yield hour available in this sector, and no company does it until after the first near-miss.

Two related points. Demonstrations are claims — a video showing behaviour outside the operational design domain is a representation about capability, and it circulates permanently. And comparative benchmarks are claims about a competitor, with everything that implies about substantiation and about the competitor's willingness to respond in kind.

The first meeting

Six questions asked of a new robotics client will surface almost everything that matters, and none requires engineering knowledge.

Show me your bill of materials. If it does not exist, or was compiled by hand for the last financing, the open source position is unknown and the audit is the first workstream.

Who owns what the robot records in a customer's building? If the answer is a general confidentiality clause, the most valuable commercial term in the business has not been negotiated.

Where is the safety file, and who can open it? If it is on a shared drive everyone can read, it is not a trade secret and the moat is unprotected.

Does the safety file match the software currently deployed? If nobody knows, that is the answer, and it is the worst possible answer after an incident.

Who wrote the application code at your three largest customers? If it was an integrator, the customer probably does not own it and probably believes it does.

What was published, demonstrated, or put in a deck before it was filed? Research culture, conference demos, and investor materials are the three standard sources of both prior art and unsupportable capability claims.

Six questions, half an hour, and a work plan ordered by exposure rather than by tidiness. Everything else in this toolkit is detail hung on those answers.

A seventh question is worth adding wherever people are near the machines: whose faces are in your training data, and on what basis? The answer determines whether a biometric statute is engaged, whether the deployment notice was adequate, and whether the training use had any lawful footing at all — and it is the exposure most likely to arrive as a class action rather than as a commercial dispute.

An eighth, for companies with fleets in the field: what happens if you push an update that makes something worse? The mechanism exists, the duty follows the mechanism, and almost no contract says what either party may do about it.

A ninth, for anyone contemplating an exit inside two years: which of your customer agreements would a buyer refuse to inherit? In this sector the answer is usually the ones with unlimited liability for physical harm, the ones granting exclusivity nobody priced, and the ones where field data rights run the wrong way. All three are renegotiable while the relationship is good and immovable once a process starts.

A tenth, for the integrator client specifically: how much of your last five projects could you reuse tomorrow? If the honest answer is none, the assignment clauses have been quietly dismantling the business model one signature at a time, and nobody has noticed because each individual deal looked fine.

Ten questions, one hour, and a client who now understands that the robot was never the asset — the file, the data, and the code were, and three of them belong to somebody else.

That reframing is the whole value of the meeting, and it is worth more than any document produced afterwards.

Write the reframing down in a one-page note and send it the same day, because it is also the document that gets the budget approved.

A Suggested Reading Path

Starting a robotics venture: The Machine That Decides, then Building a Robotics or Autonomous Systems Programme, then the Robotics and Autonomy IP Checklist.

Before shipping any software: the Software, Data, and Open Source Toolkit and Copyleft and Consequences.

Negotiating a deployment: the AI Procurement Checklist, Negotiating an AI Vendor Agreement, and the Technology Contracts Toolkit.

Data programme: the Data Licensing Checklist and the Data Licensing and Rights Toolkit.

Privacy overlay: the Biometric Data Checklist, Building a Biometric Compliance Program, and the State Privacy Law Applicability and Readiness Checklist.

Patents: the Patent Prosecution Toolkit, the Design Patent Checklist, and the Freedom to Operate and Patent Clearance Toolkit.

Adjacent sectors: the Automotive, Mobility, and Connected Vehicle IP Toolkit, the Aviation, Aerospace, and Drone IP Toolkit, and the Medical Device and Diagnostics IP Toolkit for surgical and clinical robotics.

Transactions: the IP Due Diligence Toolkit, with attention to the open source audit and the field data terms, which are the two findings that most often change a price.

Primary Authorities

| Authority | Use | |---|---| | 35 U.S.C. § 101 | Eligibility for perception and planning claims | | Alice Corp. v. CLS Bank International | The abstract idea framework | | 35 U.S.C. § 102 | Research publication as prior art | | 35 U.S.C. § 103 | Obviousness over a fast-moving literature | | 35 U.S.C. § 112 | Enablement for learned behaviour | | Amgen Inc. v. Sanofi | Enabling the full scope of a claimed genus | | 35 U.S.C. § 171 | Design patents on service and consumer robots | | 35 U.S.C. § 271 | Divided infringement across robot, cloud, and operator | | KSR International Co. v. Teleflex Inc. | Combination obviousness | | 17 U.S.C. § 102 | Code, simulation assets, and documentation as works | | 17 U.S.C. § 103 | Annotated datasets as compilations | | 17 U.S.C. § 106 | Reproduction and derivative rights in the stack | | 17 U.S.C. § 201 | Ownership of contractor annotation and integrator code | | 17 U.S.C. § 204 | The signed writing customers assume they have | | 17 U.S.C. § 412 | Timely registration of code and documentation | | Feist v. Rural Telephone | Thin protection in raw sensor data | | Google LLC v. Oracle America | Interfaces and reimplementation | | 18 U.S.C. § 1836 | Federal misappropriation claim | | 18 U.S.C. § 1839 | Reasonable measures over safety files and test corpora | | 15 U.S.C. § 45 | Autonomy and safety claims in marketing | | 15 U.S.C. § 1125 | False advertising about capability | | FRCP 26 | Protective orders over source and safety evidence | | FRCP 34 | Production of logs and telemetry | | FRCP 37 | Preservation of field data after an incident |

Search the underlying materials directly for robotics field data ownership, safety case documentation trade secret, autonomous system product liability allocation, open source robotics middleware compliance, and machine generated output authorship.

Forms and Templates

A four-asset schedule — hardware, stack, data, safety file — used as the opening annex of every agreement, so that all parties are describing the same objects. Most robotics disputes begin as a disagreement about what was being transacted.

A software bill of materials process, generated by the build rather than compiled by hand, with licence identification and an escalation rule for reciprocal and network-triggered licences.

A field data clause covering ownership of recordings, permitted vendor uses stated positively, the training question answered explicitly, survival on termination, the unwind position stated honestly, and privacy responsibility allocated.

An annotation vendor agreement with an express assignment, because annotation is the labour and a purchase order does not transfer the compilation.

A simulation asset schedule, since scenario libraries are frequently the most portable valuable thing a company owns.

A safety file ownership and access clause for integration projects, allocating the platform argument and the application argument and defining what is delivered to the customer.

A three-party integration framework or aligned flow-downs covering application software ownership, reuse rights, configuration and tuning, safety allocation, support continuity, and data flows.

An escrow instrument covering source, build environment, calibration data, and the safety file, with release conditions including vendor insolvency and sustained support failure.

An update and change-management clause, since a vendor able to alter deployed behaviour has assumed a duty that should be defined.

A teleoperation protocol addressing who the operator is, whose acts they are, what is recorded, and where the recordings go.

A publication clearance form routed before submission, because robotics research culture publishes and the grace period will not save a foreign filing.

An incident preservation runbook, since the first hours after a physical incident determine what evidence exists, and FRCP 37 obligations attach earlier than most engineering teams assume.

For general drafting starting points, see the Draft License Agreement and the License Agreement Template.

Five recurring matters

A customer demands ownership of everything the robot records. Reasonable as to recordings of its premises and people; unworkable as a blanket position, because diagnostic telemetry is how the vendor keeps the fleet safe. Split the categories: customer owns environment recordings, vendor may use de-identified diagnostics, training use is separately negotiated and separately priced.

An open source audit before a financing finds a reciprocal licence in the perception layer. Establish first whether the boundary is genuinely crossed — process separation and message-bus communication are arguable — and then decide between replacing the component, re-architecting, or complying. Compliance is often cheaper than the engineering team expects and always cheaper than a disclosure in a purchase agreement.

An integrator dissolves mid-project. The customer discovers it owns neither the application software nor the configuration and has no copy of either. Escrow with a build environment and the calibration data is the answer, and it must be in place before the risk materialises.

A safety engineer leaves for a competitor. The claim, if there is one, rests on whether the safety file was treated as a secret: marked, enumerated, access-controlled. Companies that did that have a case; companies that stored it on an open share do not.

An incident occurs in the field. Preserve immediately — logs, telemetry, the software version, the safety file version in force — and expect the safety argument and the field data to be the two things everyone wants. A safety file that no longer matches the deployed software is the worst document in the case.