What Robotics Licences Actually Allow You to Sell

Permissive licences like the Apache-2.0 behind HORUS and ROS 2 let you sell robots with your own code closed; copyleft attaches conditions instead. A licence never asks whether you charge money — it asks what leaves your building, and handing a customer a machine counts as handing over the software inside. The verdict flips when a copyleft component is linked into the binary carrying your own work. The rest of this post is for a team with a working robot, a first paying customer, and a licence question somebody raised late.

The question rarely comes from engineering. It arrives as a forwarded email from a customer's procurement team with a spreadsheet attached, asking for every third-party component on the machine and the licence covering each one. Or it comes from an investor's diligence list, four days before the call, phrased as a single line item nobody on your side owns.

So somebody opens the build directory and starts counting, and the number keeps growing. There is the framework, its dependencies, a camera library that came with the camera, a solver an engineer added because it worked, and a compression library nobody chose at all. Some have licence files. Some have a line in a readme. One has a comment at the top of a header that says free for research use.

Nobody in the room can say whether that matters. The lawyer asks what you ship, and the honest answer is a machine, which is not an answer she recognises. Meanwhile the customer wants a delivery date, and nobody wants to be the person who says stop.

What do robotics licences actually allow you to sell?

Almost anything you can build, because licences constrain what travels with the machine, not what you charge for it. Three narrower questions hide inside the big one, and they have different answers. May you keep your own source private? Under permissive terms, yes, and companies do it every day. Under copyleft it depends on what your code is joined to, not on how much of it you wrote. May the customer demand something from you? Under permissive terms, only the notices. Under copyleft, the source for the covered part — a chore unless your own work is tangled into it. And can somebody sue you over a patent later? Some licences say something about that and some say nothing at all. Price never appears in any of these, because selling is not the regulated act. Distributing is, and a robot leaving your building on a truck is a distribution event as surely as a download. Teams get hurt when they discover what came along for the ride only from a customer's scanner.

What is a software licence actually doing on a robot?

A licence is permission with conditions attached, and without one the legal default is that nobody may copy your code at all. That is the part people invert. Open-source licences are not restrictions layered onto free software; they are the grant that makes the software usable, and the conditions are what the author asked for in return. On a robot, three things make this stranger than on a web service. First, the software physically leaves — it rides out of the door inside a machine, so obligations that sleep during development wake up on delivery day. Second, the stack is deep and uninvited: your robot runs an operating system, drivers, a framework, maths libraries, codecs, and a model or two, each with its own terms. Third, some of the most important components did not come from the open-source world at all. A camera SDK, an arm vendor's motion library, a GPU toolkit — these arrive under contracts somebody accepted by clicking, and those terms are usually stricter than anything on a public repository.

Which licences are you actually choosing between?

You are choosing between five families, and most robots carry components from four of them at once. Permissive terms — MIT, BSD, Apache-2.0 — say keep the notice and otherwise sell what you like, with Apache-2.0 adding a written patent promise the others lack. Weak copyleft — LGPL, MPL — asks that changes to that component stay open and that a customer can swap in their own build of it, while leaving your application alone. Strong copyleft, the GPL family, reaches into whatever the covered code is joined into, and AGPL extends the same idea to software users reach over a network. Proprietary vendor terms cover the SDKs bundled with your hardware and can restrict fields of use, redistribution, or unit counts. Dual-licensed projects simply offer a choice: accept copyleft, or pay for terms you can live with. Framework choice is a licence choice too. ROS 2 sits mostly under Apache-2.0 and BSD, which is why it appears in commercial machines constantly. HORUS is Apache-2.0 as well: an open-source real-time robotics middleware for Rust, Python and C++ whose three languages share the same shared-memory ring buffers, so messages between processes on one computer are never serialised.

How do the licence families compare when there is a machine to sell?

Read the last column first, because the fastest way to shorten the list is to find the row describing your situation and rule that component out early. Nothing here substitutes for your own counsel reading your own facts.

Are you a hobbyist, a startup, or a company with a procurement department?

The same components carry different weight depending on who is asking. A hobbyist can ignore almost all of this: nothing is being distributed, so the obligations never activate, and a GPL solver on your own bench is nobody's business but yours. A startup with a pilot machine at a customer site has crossed the line without noticing, because a paid pilot is a delivery, and the terms activated the day the van arrived. That team needs a component list and one afternoon of triage, not a compliance programme. A company with a procurement department faces a different problem entirely: the terms are probably fine, but somebody must produce evidence that they are, in a format a stranger can check. That is a records exercise. The distinction that matters is not company size but whether machines have left the building yet, because everything before that moment is reversible for the cost of an afternoon.

Does the hardware you picked change what you are allowed to sell?

Yes, and more often than the open-source components do. The sensor, arm and compute module you chose arrived with software, and that software came under terms somebody accepted during setup, usually without reading. Camera SDKs sometimes forbid redistribution, meaning you may use the library but not ship it inside your machine, which is a problem discovered late and solved slowly. Vendor motion libraries sometimes charge per machine, turning a build-of-materials line item into a licence line item once you scale past a handful of units. Accelerator toolchains carry field-of-use restrictions that matter in medical or defence contexts. None of this is hostile — it is written in documents engineers rarely open, because the hardware already works. The practical rule is that anything installed by a vendor installer, downloaded behind a login, or delivered on a memory card with the hardware, needs its terms read before your first commercial delivery — not before your first demonstration.

What if you have to ship in three months?

Then triage in a fixed order, because the deadline does not change what is true, only how you spend the time. First, generate the component list mechanically rather than from memory, since the parts that cause problems are exactly the ones nobody remembers adding. Second, separate what physically ships on the machine from what merely lives on developer laptops, because build tools and test frameworks are usually not distributed and usually not your problem. Third, sort the shipped list by family and look only at copyleft and vendor terms, ignoring the long permissive tail, which needs a notice file rather than a decision. Fourth, for each copyleft item, ask whether the component is separable — a process you talk to, a library you can swap — or whether it is welded into your own binary. Separable is a packaging task. Welded is a replacement task, and replacement is what eats a schedule. Fifth, ask the customer for their own software terms now rather than at signature, because large buyers often have stricter clauses. Teams that follow that order finish. Teams that start by reading licence texts stall.

How much of this does your team need to understand themselves?

Enough to recognise the families and to answer one technical question that lawyers cannot answer for them: what is joined to what. Nobody on an engineering team needs to interpret licence text, and it is a bad use of their time to try. What they must be able to state precisely is which components are separate processes, which are dynamically loaded libraries, which are compiled into the same binary as proprietary code, and which are reachable by somebody outside the company over a network. Those four facts decide most of the outcome, and only the people who built the system know them. The reverse mistake is just as common: asking a lawyer to discover the components. Lawyers cannot see inside a build. Generate the list with tooling, have engineering annotate how each item is linked and whether it ships, then hand that to counsel. A team that learns to name the five families and describe their own linkage honestly has covered most of what the situation demands, and the specialist handles the rest.

What do you give up by building on permissively licensed software?

You give up somebody to blame, and it is worth naming that plainly rather than pretending the trade does not exist. A permissive licence disclaims warranty, promises no fixes, offers no release schedule, and grants nobody a duty to answer your email at two in the morning when a customer's line has stopped. There is no indemnity clause, so if a patent dispute lands, it lands on you rather than on a supplier who priced that risk into a contract. There is no commitment that next year's version behaves like this year's. In exchange you get the source, the right to fix things yourself tonight, and freedom from per-machine fees that grow with your success. Commercial suppliers sell the opposite trade, and for some products it is the right one — a certified programme with a regulator reading the file often wants a supplier who signs things. Most robotics companies end up mixing both, buying support for the parts that would stop a customer line and carrying the rest themselves.

When is ROS 2 the better choice?

ROS 2 is the better choice for most commercial robots, and the licence picture makes that easier rather than harder. The core sits under permissive terms, so it was never the barrier teams imagine, and the surrounding ecosystem is where products are actually won. If your machine's value is perception — mapping a site, recognising objects, planning a path around people — the packages are the product, and no messaging advantage repays rewriting years of them. If your customers or integrators expect standard interfaces so they can attach their own tooling, they will be annoyed by anything unfamiliar. If the sensor your product depends on has exactly one maintained driver, the decision was made for you before you arrived. HORUS is not the answer in any of those cases, and choosing it there trades a mature ecosystem for plumbing your own team would have to build and support alone. That trade repays only the narrow class of products whose difference lives in a control loop rather than in a stack of capabilities.

Does selling a robot mean you have to publish your own source code?

No, and here is why: publication obligations attach to specific components under specific terms, and only when those components are distributed. Your application, your motion tuning, your customer-facing behaviour — none of it becomes public because it runs on the same computer as licensed open-source software, or under the same operating system. That family was written by people who intended companies to sell closed products built on their work. Where teams do get caught is narrow and identifiable. Statically linking a GPL library into your own binary is the classic case, because the obligation follows what the covered code is joined into. Shipping a modified copy of a copyleft component without offering the modification is another. A quieter one is a contributor pasting code from a differently licensed project into your repository, where it sits unnoticed for years. Each has a boring defence — a component list, a check at every upgrade, and a written rule about where copied code may come from. That is process, not jeopardy. Whether open source is safe to ship at all covers the wider version of this worry.

Is a permissive licence all the legal cover a robot company needs?

Partly, but not the way you think. A permissive licence settles the copying question and, with Apache-2.0, says something useful about patents. It settles nothing else, and several of the other things are larger. Trademark is separate: permission to use code is not permission to use a project's name or logo on your packaging. Third-party patents held by people who never contributed are untouched by any licence anywhere. Export rules apply to encryption and to certain classes of autonomy regardless of what your dependencies say. Machine-learning models are the current sharp edge, because weights and datasets frequently arrive under bespoke terms restricting commercial use or particular applications, and those terms look nothing like the familiar families. And the largest one: safety liability for what the machine does is unaffected by every licence in your file. When an arm injures somebody, the company whose name is on the machine answers, whether the code inside was downloaded or purchased. Licence review is one workstream among several, and the cheapest to finish early.

What does a licence problem actually look like when it reaches a product?

It looks like four specific weeks, none of which involve a courtroom. The first is the procurement scan: a customer runs a tool over your delivered image, and a report lands naming a component you have never heard of, with a purchase order held behind it. The second is the evaluation SDK, where the camera library that has worked all year turns out to be licensed for development, and the vendor's production terms come with a per-machine fee that changes your unit economics. The third is the model licence: the perception network somebody downloaded during a hackathon carries a non-commercial clause, and retraining an alternative is a quarter of work nobody scheduled. The fourth is the welded solver — a GPL component compiled directly into the binary that also holds your motion tuning, discovered during a pilot, where the only honest options are to replace it, to separate it, or to publish more than you meant to. Every one of these is far cheaper when found before delivery, and every one is found by generating a list.

How do you decide what you can sell?

Decide by asking what would have to be true for the answer to be no, because the list is short and each item is checkable. It would have to be true that a copyleft component is welded into a binary you cannot open, that a vendor's terms forbid shipping something the machine needs, that a model or dataset carries a use restriction covering your customers, or that a customer contract demands rights you cannot grant. If none of those hold, you can sell. If one holds, fix that item rather than reconsidering the whole approach, because the alternatives carry the same questions with an invoice attached. Then do the three unglamorous things: generate the component list mechanically, record for each item whether it ships and how it is linked, and put a check into your release process so the answer stays current. That work takes days once and hours per release afterwards. If the framework choice underneath is still open, whether the ecosystem carries a commercial product is the companion decision, and how much of a robot you can build without writing much code matters if your team is small.

Decide by situation rather than by principle:

• If nothing has been delivered yet -> use anything, because obligations start at delivery.
• If a paid pilot sits at a customer site -> generate the list this week, because the terms activated on delivery day.
• If your differentiator sits in one binary -> keep copyleft components out of that binary, because that is the only place the question gets expensive.
• If a customer's scanner is coming -> produce the evidence before they do, because arguing with a report you have not seen is the worst position available.
• If your product depends on a bought SDK -> read the production terms before pricing, because per-machine fees change the business, not the code.

When two of those lines apply at once, weigh the underlying platform on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, licence — and keep whichever option loses on fewer. They are questions about your company rather than scores about software. And if the licence column keeps pointing you toward permissive terms with a patent grant, star HORUS on GitHub so it is in your list when you start building.