Most products sold today contain code. Sometimes a few kilobytes on a microcontroller, sometimes a full application and a mobile companion. Buyers negotiate the physical object carefully and inherit the code by accident, because it arrives already written, inside a sample that works. The moment it stops being a detail is the moment you want something changed — and by then the negotiating position is gone.
Three situations, and they are not variants of each other
Before asking who owns what, establish which of these you are in. Buyers routinely believe they are in the third when they are in the first, because the product carries their brand and their menu texts.
| Situation | Who wrote the code | What you can realistically ask for |
|---|---|---|
| The factory supplies its own firmware | The factory or its chip supplier, long before you arrived | A compiled binary, a version number, a changelog, and the right to keep using it. Sources are rarely obtainable, and the honest plan assumes you will not get them |
| The factory writes it for you | The factory's engineers, on your specification, paid by you in one form or another | Ownership or a broad licence, the sources, the build environment and the right to have it modified elsewhere — all of it named in the contract, before the work starts |
| You bring the code | You, or a developer you pay directly | A clean handover procedure: what you deliver, how it is flashed, who holds the signing keys, and what the factory may not do with what it receives |
What to get in writing, whichever situation you are in
The list below is not a legal document; it is the set of questions whose answers decide what you can do in two years. Ask them in the quotation phase, when the factory wants the order. Asking them after the first production run turns a routine clarification into a renegotiation.
- The sources, and in what state: a repository you can compile, not a folder of files sent once.
- The build chain: compiler and version, configuration, and the exact steps that turn sources into the binary actually loaded on the product.
- The keys: who holds the signing and flashing keys, and whether a second party can produce a binary the product will accept.
- The right to modify, and to have someone else modify it — the second half of that sentence is the one that gets dropped.
- The third-party components: which libraries and stacks are included, under which licences, and what those licences require of you when you sell the product.
- The documentation: memory map, protocols, the meaning of the error codes, and how to rebuild a unit from nothing.
- Where the back end lives, if there is one: whose servers, whose account, whose domain, and what happens to the data.
When sources genuinely cannot be handed over — which happens, and is sometimes legitimate — the fallback is an escrow arrangement: the code is deposited with a third party and released to you on defined events, such as the supplier ceasing to trade or failing to maintain the product. It is a weaker protection than ownership and it needs to be set up while relations are good, but it is far better than the usual alternative, which is nothing.
What happens when you want to change factory
Changing a hardware supplier is a known exercise: you recover the tooling, hand over the drawings, requalify the parts and accept a difficult first run. Changing a supplier whose firmware you do not own is a different exercise, because the new factory can copy the object and cannot copy the behaviour. What you are really moving is not the product but the half of it you can document.
The symptoms are recognisable. Units that work but fail a test the old ones passed. An option in the menu nobody can explain. A calibration step that existed only in a script on one engineer's machine. And, at the worst moment, a fleet of products already sold that can no longer receive a correction, because the only party able to produce a valid binary is the supplier you have just left.
Updates after the sale, which is a commitment and not a feature
A product that can be updated is a product that must be. Once you can correct a defect remotely, customers, distributors and in some cases regulators will expect you to. That expectation outlives the relationship with the factory that wrote the code, which is why the update path is a contractual subject rather than a technical one.
- Who can produce an update the installed products will accept, and for how long that remains true.
- What it costs per version, and whether corrections of the supplier's own defects are billed.
- How an update reaches a product already at a customer's site, and what happens if it fails halfway.
- Who is told what: a version history you can show a customer, a distributor or an authority.
One question separates a product you own from one you rent: if this supplier disappeared tomorrow, could someone else produce a valid update for the units already sold? If the answer is no, the code is not yours, whatever the invoice says — and that is worth knowing before the answer is tested.
None of this requires a hostile conversation. A factory that writes good firmware is usually willing to say who owns it, what is included and what a modification costs, provided the question is asked plainly and early. What breaks relationships is discovering, two years in, that each side had assumed a different answer and both were sincere.