Buying a Machine With Software In It
The mechanical parts of a capital purchase are covered by decades of contract practice. The software inside is usually covered by a licence nobody in the room has read.
A machine tool has a twenty-year life. The industrial PC driving it has a seven-year life, the operating system on that PC has a support horizon of five years, and the application licence renews annually on terms the vendor can change. Nobody signs a purchase order for those three different lifespans; they sign one for a machine.
That mismatch is where most of the unpleasant surprises in industrial capital equipment now live, and almost none of it is covered by the commercial terms that handle the mechanical side perfectly well.
Start with what is actually being bought. Software is licensed rather than sold, so it is worth asking plainly: is the licence perpetual or subscription, is it tied to the machine or to a named user or to a network dongle, what happens if the machine is moved to another site, what happens if the company is restructured and the legal entity changes, and what happens if the licence server cannot be reached. That last one has stopped production lines. A machine that phones home to validate a licence and cannot is a machine that may or may not keep running, and the answer belongs in the contract rather than in an anecdote.
Then the support horizon, asked as a date and not as a sentiment. For how long will the vendor supply security patches for the software in this machine? For how long will they support it on a current operating system? When the OS goes out of support — and it will, inside the machine's life — who pays for the migration, and is it technically possible at all, or does the application only run on the version that shipped? A great deal of industrial equipment is running unsupported operating systems today for exactly this reason, and the decision that put it there was made at purchase by not asking.
Source escrow is worth raising for anything critical, and it is worth understanding what it actually delivers. A properly drafted escrow places the source and build environment with a third party, released on defined events such as the vendor ceasing to trade. It is not a substitute for support and it is close to useless if the deposit is never verified, because source that does not build is not source. If escrow matters enough to pay for, it matters enough to require periodic verification.
Data and interfaces deserve a clause of their own. Who owns the data the machine produces? Can it be exported in a documented format without buying anything further? Is there an API, is it documented, and is it covered by the same support terms as the rest? A machine that produces excellent data that can only be seen through the vendor's portal is a machine that will not participate in the site's own systems, and discovering that after installation converts an integration task into a negotiation.
Cybersecurity has quietly become a procurement question too. Under the EU Cyber Resilience Act and similar regimes elsewhere, a connected product carries obligations, and for equipment placed on the European market the obligation sits with the manufacturer. Asking for a software bill of materials, a vulnerability disclosure contact, and a commitment on patch timelines is now a reasonable and increasingly common request, and a vendor who cannot answer is telling you something useful.
None of this requires a redrafted contract template. It requires the software questions to be asked during evaluation, by someone who will still be there in year six, and the answers written into the order rather than remembered from a meeting.