ARTICLE
28 April 2026

Digital Drafting - Software Provisions In Engineering And Construction Contracts

WB
Womble Bond Dickinson

Contributor

Being different is our normal way of working. It's not just what we do, it's how we do it.

You'll benefit from more than just the skills and know-how you'd expect from a pioneering law firm; our technology specialists, process and project management leaders, accountants and tax advisers work alongside lawyers with specialist sector expertise – from business to government.

Working side by side, we'll find clever solutions to your age-old problems.

With 1,300 professionals across 39 offices in the US and UK, we're equipped to tackle mission-critical challenges, wherever you do business.

Want the proof? It's in our track record. With our straight-talking, entrepreneurial approach, we’ve set new industry precedents, achieved market firsts and delivered trailblazing work for our clients.

So, whatever your future holds, we're here for you with A Point of View Like No Other.

As in many other sectors, software has become increasingly important in engineering and construction projects in recent years.
United Kingdom Media, Telecoms, IT, Entertainment
Sheilah Mackie’s articles from Womble Bond Dickinson are most popular:
  • in United States
Womble Bond Dickinson are most popular:
  • within Law Department Performance, Real Estate and Construction and Employment and HR topic(s)
  • with Senior Company Executives and HR
  • with readers working within the Property and Law Firm industries

As in many other sectors, software has become increasingly important in engineering and construction projects in recent years.

Software is often now a key deliverable, as plant increasingly relies on sophisticated automation or control systems. The integration of robotics into engineering and construction projects has also moved from a futuristic concept to a reality for many operational aspects, particularly in the automation of warehouse operations.

So how well do standard forms of construction contract such as MF/1 deal with the provision of software?

Considering software terms and the MF/1

MF/1 rev 7 (and the previous rev 6) contains an optional special condition governing the incidental supply of hardware and software, but whether or not to include this software licencing option is often given limited consideration by the parties. Working with a specialist IT lawyer or advisor can assist immeasurably. But where you don’t have that luxury or where you'd like to have a clearer sense about what should be considered when including this special condition, so that you can have effective discussions with other parties, here are some of the key points to consider (with capitalised terms being those defined in the MF/1):

  • Is the special condition the right starting point? It may be that a contractor (or the licensor of the software) has a standard form of wording or licence agreement already developed for the software deliverables and that could be a better starting point. From the purchaser's perspective, the terms may be weighted in favour of the contractor and may need to be negotiated. However, if it's been well prepared it should reflect the specific requirements of the software being provided. It's also likely to link well with any maintenance and support agreement being offered by the contractor. On the flip side, working with a contractor's standard form of wording or licence agreement generally requires some effort to rationalise those terms and definitions with those already included in MF/1 to avoid inconsistencies and conflicting provisions.
  • Standard Software and Bespoke Software? The special condition anticipates that the deliverables will include the contractor's standard computer programs and potentially also bespoke software to be developed by the contractor under the contract. It must be established if these categories actually reflect what will be delivered and, if not, appropriate amendments agreed to the definitions and substantive terms. Often third party software will also be part of the overall system being delivered. If so, appropriate provisions need to be included to govern the licences being granted this to software, including ensuring that the Statement of Requirements is clear as to whose responsibility it is to acquire and pay for this software, as well ensuring that all necessary rights are included in the relevant licences to enable both the purchaser and the contractor to use the software as needed during the build process and after handover.
  • Acceptance testing and sign-off. The special condition contains provisions dealing with how the software deliverables will be tested and signed off - with these being treated as Tests on Completion and a Trial Period taking place. However, this may not always be appropriate for your deliverables, in which case suitable alternative arrangements will need to be agreed instead. This is especially important to consider where some of the deliverables are provided by a third party, as those third parties may have quite different approaches to how (if at all) acceptance of their software will be effected.
  • Licence rights. The special condition contains a very simple non-exclusive right for the purchaser to use the Standard Software in the System for the purposes of the purchaser's business. This may be all that a purchaser needs but you should consider if the licence rights need to be wider and more explicit. For example, does the licence need to cover the purchaser's wider group? Does it need to be sub-licensable to third parties working with the purchaser or transferable if the purchaser decides to sell the plant or sells its business and assets in the future? Such rights may be implied but it's always better to set out explicitly what the licence does and does not include.
  • Ownership of Bespoke Software. The special condition provides that title to any bespoke software vests in the purchaser and that the contractor will be granted a non-exclusive worldwide licence to market the bespoke software and sub-licence it to third parties on terms to be agreed. This is commonly amended, with the contractor typically wanting to own the bespoke software even if the purchaser has paid for it. Purchasers sometimes want to own bespoke software as a matter of principle, but you should consider how useful bespoke software would be on its own without access to the contractor's standard software and whether it has any intrinsic value of its own. Instead, it may be more beneficial to seek an amendment, for example to the effect that the contractor can own any bespoke software and the purchaser gains a reduction in price along with a restriction on the contractor licensing the bespoke software to agreed competitors of the purchaser.
  • Source code and escrow. For some purchasers, having a copy of the source code to any bespoke software or having it deposited with a third party escrow agent is not of particular concern. For others, it's a key issue to be addressed with the purchaser wanting a copy of both the source code and related user and technical manuals and documentation for all software deliverables being held with a reputable third party escrow service. Where source code and related materials are to be held in escrow, the triggers for release of that source code to the purchaser should also be considered to ensure that they align with all circumstances where access would be required. The special condition provides only that where source code is held by a third party, the triggers for release are liquidation of the contractor, the contractor having a receiver appointed, or the contractor ceasing to provide services in respect of the source code. These are narrow circumstances, particularly given the plethora of insolvency proceedings available to organisations nowadays, so purchasers may want to secure a wider range of triggers.
  • Defect liability. A defects liability regime is included that runs for 12 months after Acceptance of the System, with the contractor being responsible for making good any defect in or damage to any portion of the software which results in the failure of the System to fulfil the Statement of Requirements and Functional Specification and which arises from defective materials, including software, workmanship or design. This can often be sufficient for software deliverables but consider whether any amendments made to the wider defects liability regime cut across the software provisions or result in conflicting provisions. Consideration should also be given to any maintenance and support arrangements offered by the contractor to ensure that a purchaser is not actually paying for remedial work under that follow-on contract, where that remedial work should already be covered under the MF/1 regime.
  • Clause 42 Patent rights etc. The wording in this clause may be suitable for many purchasers when sitting alongside the special condition. However, it's always worth reading clause 42, the special condition and any related amendments together to ensure that appropriate indemnity coverage is included for all of the software deliverables being provided. For example, database rights may need to be added in or express coverage for use by the purchaser's group and any outsourced IT services providers.

For certain projects where software is pivotal, there may be additional considerations or protections that are required especially if any form of AI is being used.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

[View Source]

Mondaq uses cookies on this website. By using our website you agree to our use of cookies as set out in our Privacy Policy.

Learn More