How a robot gets licensed¶
Software that runs on a robot is licensed in one of two ways. The publisher chooses which, per offer, and the choice changes what you manage day to day. Applets and firmware are robot-held by default; web applications are account-held.
Account-held: a pool of seats¶
Your account holds the license and it carries a quantity. You assign a seat to a robot, the robot may run the software, and you can take the seat back later and give it to a different robot. This is the familiar model, and it is described in Subscriptions and licenses.
Robot-held: the license belongs to the robot¶
There is no pool and there are no seats. The license names one robot, and that robot carries it.
Approval is per robot. Each robot needs its own request and its own decision.
There is nothing to assign. Trying to assign a robot-held license to a terminal is refused — it is already on the only terminal it can ever be on.
It stays with the robot. Because the license names the robot’s own identity rather than a seat in your pool, it does not follow the person who asked for it and it cannot be moved to a different machine.
Where the license lands¶
A license for a robot is always registered in the account that owns that robot — resolved from the platform’s own device inventory at the moment the request is made, not taken from whoever filed it.
That matters when the request comes from somewhere else. A head office, a partner, or a service organization that has been granted authority over your site can file the request, but the resulting license, and the bill, land with the site that owns the robot. If the robot is not known, or has no owner, the request is refused rather than guessed at.
The owning account must already hold the software before a robot-held license can be issued for it. Acquire the product for that account first; then request the license for the robot.
The certificate the robot carries¶
When a robot-held license is issued, the platform mints an X.509 certificate for that one robot and delivers it over the same secure channel the robot already uses for its software. The applet checks the certificate when it starts: a robot with no valid certificate does not run the software, whatever the console shows.
The certificate’s validity follows the commercial terms. On a paid offer it runs to the end of the current billing period plus a short grace period, and it is extended when the next invoice is paid. On a free offer it runs for a year.
Issuing a license and delivering its certificate happen together — if the certificate cannot be delivered, the license is not quietly issued without it. If a request stops at that point, check that the owning account still holds the product and that the listing has a current published version.
A robot that asks for its own license¶
Some robots request their own license. The robot names itself, the platform works out who owns it, and files the request in that owner’s account — nobody has to notice a new machine and file paperwork for it.
Two things are the same as any other request:
It still needs a decision. A self-request is never auto-approved. It appears in the approval queue exactly like one a person filed, and whoever holds the authority for that offer approves or refuses it. See When a license needs an approval.
It arrives already submitted. There is no draft step, because no person is going to press submit. You see it in the pending queue straight away.
The robot cannot claim to be a different robot: its identity is resolved by the platform from the device, never taken from the request.