Is Open-Source Robotics Software Safe to Ship Commercially?

Yes, open-source robotics software is safe to ship commercially — permissive licences like the Apache-2.0 one HORUS uses were written for that, as was ROS 2's. Safety here is inventory and support, not licence fear: know every component on the machine, know who patches a fault at a customer site, and keep each part replaceable. The verdict flips when a copyleft component lands deep inside a binary you cannot open. The rest of this post is for a team with a working robot, a customer waiting, and a legal or safety review that nobody has prepared for.

Somebody asks the question that stops the meeting: are we actually allowed to sell this? The prototype works. It came together out of packages found on the internet over eighteen months, and nobody wrote down where half of them came from. There is a driver an intern patched one afternoon, and a solver that arrived as a dependency of a dependency, whose only advocate has left the company.

Now legal wants a list. The safety consultant wants to know who is responsible for the code that decides when the arm stops. An investor asked, politely, whether anybody could take the software away from you. Meanwhile the customer with the second machine had a crash on Tuesday, and the honest fix involves waiting on a maintainer you have never spoken to. None of this felt like a risk while it was one laptop and one robot on a bench. It feels different once there is an invoice attached and a company name on the delivery note.

Is open-source robotics software safe to ship commercially?

Yes, and the evidence is in the machines already on sale. The robot moving totes around a warehouse, the one scrubbing a supermarket floor overnight, the arm packing punnets on a farm — open-source software sits inside almost all of them, starting with the operating system. So the question is never whether it is allowed. It is three narrower questions wearing one coat. Can anybody force us to publish our own code? Almost never, once you check what you genuinely ship. Who fixes this at two in the morning when a customer's line is stopped? You do, or a company you pay. And can we show a safety reviewer what is inside? Only if somebody kept a list. The teams that get hurt are not the ones who chose open source. They are the ones who never made the list, met a copyleft component halfway through a pilot, or built a product on a package with one maintainer who quietly stopped answering. Each is avoidable with work that is boring rather than hard.

What does open source actually mean once you are selling a machine?

Open source means you hold the source code and a licence describing what you may do with it, and nothing beyond that. It is not a supplier. Nobody owes you a fix, a release date, a phone number, or a promise that next year's version still does what this year's does today. In exchange you get something vendors rarely sell: the ability to read the thing misbehaving, change it, and put the change on a machine tonight. The licences fall into two families, and commercially the difference is the whole conversation. Permissive terms — Apache-2.0, BSD, MIT — say keep our notice and otherwise do as you like, including selling binaries while your own code stays private. Copyleft terms, the GPL family, say that if you distribute the software you also distribute your changes, and depending on the variant, whatever those changes are joined to. Neither family is dangerous. Not knowing which one governs the codec sitting four dependencies deep in your perception chain is dangerous, because handing a customer a machine counts as distributing software.

What are the real options for the software under a commercial robot?

There are six options that companies genuinely choose between, and most products ship a combination of two. You can take ROS 2 as it comes and own the integration and licence review yourself. You can run the same ecosystem alongside a company selling supported long-term builds, which buys somebody to call during an audit. You can keep ROS 2 above and move the few processes that share a control loop onto a narrow permissive layer such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one computer are never serialised; the licence is Apache-2.0, the project is validated in simulation rather than fielded at scale, and it is not a full ROS replacement, which is exactly why it belongs beside that ecosystem instead of in place of it. You can buy a proprietary framework that arrives with indemnity and certification paperwork, or a complete platform from a robot vendor and write only the application on top. Or you can write everything yourself, which costs more than every team estimates.

How do the options compare when there is a customer waiting?

Compare them by the last column first: find the row whose "when not to" describes your company, and cross it out. Most teams are left holding two, and the honest tiebreaker is which one your own engineers could support on a bad night without phoning anybody.

Notice what the table has no column for: how modern anything is, or how fast. Neither has ever been why a robot company missed a ship date.

Are you a startup, a contract integrator, or an established manufacturer?

These three should worry about completely different things, and copying the wrong one's habits is the common mistake. A startup before product-market fit should optimise for how many ideas it can try, because the product will change far more than the software will; open source is nearly always right here, and the licence inventory can be a spreadsheet finished before the first paid pilot. A contract integrator building machines one customer at a time has a different master: read what you signed about intellectual property, escrow and deliverables before reading any software licence, because a customer's clause is routinely stricter than anything the open-source world asks of you. An established manufacturer arrives with a supplier list, a safety standard, a bill of materials that includes licences, and an engineering culture that expects a name against every layer. For that company the question is procurement-shaped rather than technical, and "open source" translates to "who do we have a support arrangement with", which is a solvable problem with a purchase order attached.

What hardware are you shipping this on, and does that change the licence question?

It changes it more than most teams expect, because obligations attach to distribution, and distribution means the software leaving your building. Software you install on a machine a customer takes away is distributed, so every licence term is live. Software running only on your own servers, with robots calling in over the network, mostly does not trigger copyleft sharing — except the AGPL variant, written to close that gap. Then there is the hardware shape. One Linux computer doing everything means your processes share a machine, and the cost of moving data between them is a real line item. A Linux computer plus a separate motor controller means the tightest timing already lives off Linux, and the middleware question becomes calmer. A fleet reporting to a server is a network problem. And there is always the cost-reduced second board, chosen by someone optimising the bill of materials, with less headroom than the prototype enjoyed. Software that only fitted comfortably on generous hardware becomes a schedule problem precisely when the company starts trying to make money.

What if you have to ship within a year?

Keep the foundation your team already runs, and do the licence inventory this month instead of the month before the audit. A year is shorter than it sounds: a hardware revision, a certification round, one supplier delay and a pilot customer's change requests will consume the slack you were quietly counting on. Listing everything on the machine is a day of work while a component is still replaceable, and a redesign once the machine is at a customer site. Do it now, and check again on every upgrade, because a dependency's terms can change between releases and nobody sends a letter. Beyond that, resist swapping any layer unless you can name the customer-visible symptom the swap removes. "The arm stops a beat late when the vision pipeline is busy, and the operator noticed" is such a symptom. "We are uneasy about our stack" is not, and rewriting on that basis has sunk more schedules than any licence has. The same trap catches teams going from prototype to product.

What does your team need to know to carry open-source software safely?

Somebody on the team must be able to build every shipped dependency from source, and know what to do when that fails. This is the skill people underestimate. Not writing algorithms — rebuilding somebody else's project on your hardware, applying a patch, keeping that patch when the upstream project moves, and knowing which version is on which machine in the field. Add one person who can read a licence without a lawyer present and knows when to escalate. That is the whole team you need. If nobody wants those jobs, you have not chosen wrong, you have chosen expensively: buy the support arrangement, because someone must do the work and it is cheaper as a line item than as an emergency. The failure mode to watch is a company where everybody uses the dependencies and nobody owns them. That survives right up until a fault appears in a layer no one has opened, on a Friday, at the customer with the loudest procurement department.

What do you give up by shipping on open source?

You give up a supplier to point at, and inherit a dependency surface you did not design. In practice that means upgrades arriving on somebody else's calendar, and a decision every couple of years about whether to move to a newer release or freeze and maintain your own. It means that when a fix lands deep in a component, you may carry a private patch forever, and that patch is now yours to re-apply at every upgrade. It means orphaning risk: the package solving your unusual problem may have one maintainer, and maintainers take other jobs. It means a larger image, a longer boot, and more parts to explain to a certifier who wants to know why each one is on a machine near people. And the evidence burden for an audit sits with you, since no vendor documents anything on your behalf. Those costs are real and paid quietly. What arrives in return is a decade of other people's work, a hiring pool that already speaks the vocabulary, and tools you would otherwise be building instead of building your product.

When is ROS 2 the better choice?

ROS 2 is the better choice for most commercial robots, and the cases are easy to name honestly. If your product is perception-heavy — mapping a site, recognising objects, planning a route around people — the packages are the product, and no transport advantage compensates for rewriting years of them. If the machine is one of many reporting to a server, the ecosystem was built for that world and has lived in it for years. If your customers or integrators expect to plug their own tooling into your robot, they will expect standard interfaces and will be annoyed by anything else. If you need to hire quickly, the pool of engineers who already know the ecosystem dwarfs every alternative. And if the sensor your product depends on has exactly one maintained driver, the decision was made for you. HORUS is not the answer in any of those cases, and choosing it there swaps a mature ecosystem for plumbing your own team would have to build and support alone. That trade only pays for the narrow slice of products whose value lives in a loop rather than in a stack.

Does shipping open source mean giving away your own code?

No, and here is why: the obligation to publish attaches only to software carrying copyleft terms, and only when you distribute that software. Your application, your motion tuning, the thing that makes your machine worth buying — none of it becomes public because it runs on the same computer as a permissively licensed framework. Companies ship closed applications on open foundations every day, and the licences were written by people who intended exactly that. Where teams get caught is narrower. Statically linking a copyleft library into your own binary is the classic trap, because the licence then reaches into what it is joined to. Modifying a copyleft component and shipping the modification is another. A third is quieter: a contributor pastes code from a project with different terms into your repository, and nobody notices for two years. The defence is a list, a check at every upgrade, and a rule about where copied code may come from. That is process, not legal jeopardy.

Is it true that nobody is accountable when open-source software fails?

Partly, but not the way you think. It is true that a licence disclaims warranty, that no maintainer owes you a response, and that a project can be abandoned without notice. What is false is the implied comparison, because accountability for a robot's behaviour never sits with a software supplier anyway. When a machine injures somebody, the company whose name is on it answers, whether the code inside was bought or downloaded. A commercial licence changes who pays a defect claim and who staffs the support line, not who is responsible for the machine. So the practical question is not accountability in the abstract but response time: when a component misbehaves at a customer site, how long until somebody who understands it is working on it? With open source you can always be that somebody, which is more than a proprietary vendor offers on a bad day. Buy a support contract when you have machines in the field, and skip it while you have none.

What does it look like when open source actually bites a product?

It looks like four specific Tuesdays, and none of them involve a lawyer. The first is the orphaned driver: the sensor works, the package that talks to it has not been updated in years, and a new operating system release breaks it, so now you maintain a driver. The second is the licence discovered late, usually a codec or a solver, found during a customer's review rather than yours, when replacing it means re-validating a perception chain that took months to tune. The third is version drift: unit forty-one behaves differently from unit twelve, nobody can say which packages differ, and the machine you would compare against was reflashed in March. The fourth is the patch you carry: a one-line fix for a start-up race, never sent upstream, silently dropped during an upgrade, and the race returns on the machines furthest from your office. Every one of these is a records problem wearing a technical costume, and every one is cheaper to prevent than to survive.

How do you decide whether to ship on it?

Decide by asking what would have to be true for the answer to be no, because the list is short. It would have to be true that a copyleft component sits inside a binary you cannot open, that no support is purchasable for the parts you depend on, that nobody in the company can build the stack from source, or that a customer contract forbids code you cannot assign. If none of those hold, ship. If one holds, fix that one rather than reconsidering the approach, because the alternatives carry the same risks with an invoice attached. Then do three pieces of unglamorous work: list what is on the machine, decide who answers when a component fails at a customer site, and write down how a version reaches a robot and how you would later prove which one it received. Teams who do those three ship open source comfortably for years; teams who skip them have exciting quarters. If you are still weighing the platform question, whether the ecosystem scales to a product is the companion decision, and what quietly breaks in generated code catches younger teams.

Decide by situation rather than by principle:

• If you are pre-revenue with a demo to build -> open source as it comes, because trying more ideas beats owning less code.
• If you have machines at customer sites and an audit approaching -> open source plus paid support, because somebody external must be answerable.
• If your differentiator is a control loop on one computer -> keep the ecosystem above and put that loop on a permissive shared-memory layer, because packages cannot supply timing.
• If a certifier reads your file before you ship -> a supplier with indemnity, because the paperwork is part of the product.
• If a customer contract demands escrow -> whatever you can rebuild from source unaided, because you must hand over what you promised.

When two of those lines survive, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, licence — and keep whichever loses on fewer. No scores: they are questions about your company rather than about software. And if your product keeps landing on one machine, with more than one language, and a loop customers notice when it slips, star HORUS on GitHub so it is in your list when you start building.