Maritime technology: A primer on software agreements

Published 23 May 2023

As maritime technology gains greater adoption, purchasers of maritime software will need to become familiar with the special contractual provisions that appear in software agreements.  This article provides an introduction to the key issues which should be checked and considered when negotiating a maritime software agreement.

Introduction

Maritime technology is developing at a faster pace than ever before. Digitalisation of the industry has firmly taken hold and while the traditional paper and manual processes remain, increasingly these processes are being replaced or complemented by digital ones.  Those processes go beyond the familiar use of IT for onboard or onshore administrative tasks and offer new ways of operating, such as remote monitoring of cargo and equipment and new platforms for connecting with customers.

The breadth and scope of available maritime technology software for both Information Technology (IT) and Operational Technology (OT) applications is beyond the scope of this briefing, but the below diagram gives some idea of the variety of the newer software solutions available:

Whereas several of the very largest shipping companies have invested in their own in-house technology platforms, many smaller entities simply do not have the funds or in-house IT expertise necessary to develop their own bespoke products and must therefore rely on external suppliers. In this briefing, we look at the key risks and liabilities that arise in the context of contracts for the supply of software particular to the shipping industry, and the key issues to be addressed when entering into such contracts.  Naturally, there are more general issues to consider in all software contracts which we have considered in other articles such as this one, here.

The special maritime context

There are certain key structural elements of the maritime industry which we consider provide important context to the discussion that follows.  These include:

• The widespread use of single ship owning companies within a larger, group fleet
• The large number of third parties and intermediaries that a ship and its owners interact with, on a global basis, and who may require access rights to software
• The relatively long lifespan of ships and their equipment
• The unpredictability of a ship's trading patterns and ports of call to allow for routine physical inspections and upgrades to software, coupled with the more predictable scheduling of dry dockings and surveys
• The still limited availability of cost-effective, reliable, high bandwidth internet connectivity at sea for ‘over the air’ or remote software updates and support
• The shipping industry as a relative late comer to cyber security and resilience
• The lack of IT expertise within the industry
  
  

The different methods of procuring software

Traditionally, software was sold under a licensing agreement, granting the buyer the right to install the software on its own systems and to use the software within the terms of the license.  This is often known as “on prem” implementation. More recently, we have seen the development of ‘software as a service’ or ‘SaaS’ in which the supplier grants the buyer access to the software, via an app or web-based platform, with the software itself remaining installed on the supplier's servers and systems.  The latter is often done on a subscription model basis, thereby providing more flexibility for the buyer.  Additionally, it is possible to buy software and the related intellectual property rights outright, or to purchase software design services for the development of wholly new, bespoke software.  Broader issues around SaaS deals are noted here.

Determining the method of procurement is an important first step as it will impact the degree to which the terms and conditions for the supply of the software are open to negotiation.  For the purchase of access to existing software, either via a licensing agreement or a SaaS agreement, it is likely that you will be a rule-taker, in the sense that there will be very little scope to negotiate changes to the software supplier's standard terms and conditions, much like buying access to an app on your phone or buying access to Microsoft Office for working from home. Nevertheless, it is still important to consider the terms and conditions carefully and to evaluate what risks and liabilities may arise which may need to be countered via a change in internal policies and / or insurance cover. In addition, nothing is “non-negotiable” when it comes to the most significant points, from experience, but obviously commercial leverage is key.

For the purchase of bespoke software design services, there will likely be much more scope for negotiating the terms with the supplier and it is also highly likely that the selection of the supplier will have taken place following some kind of tender process, such that they should already be aware of your key contractual requirements.  We are also starting to see a hybrid of standard software being offered with bespoke add-on modules, which may also give you more room to negotiate.

A fundamental issue which must be considered at the procurement stage and throughout the life cycle of any system contract is cyber-security. The management of cyber risk within a shipping company is now an integral part of the company's Safety Management System following the introduction of IMO Resolution MSC.428(98).  It is therefore essential that due diligence is carried out in relation to the supplier's own cyber-risk management processes as part of the procurement process, and that this is reviewed as new products or versions of products are supplied. Owners should develop their own minimum cyber security standard for suppliers and assess compliance against this.

Key risks and liabilities

The key risks and liabilities to look out for when entering into an agreement for the supply of software will differ dependent on the procurement method chosen.  We summarise the key issues arising under each method below:

For all types of software agreement, particular attention should be paid to the following key issues:

1. The description of the software:

• Is the description of the software, and the warranties provided by the supplier as to performance by reference to that description, sufficiently detailed and clear (and broad in the case of warranties)? Is indemnity protection required for key areas such as IP infringement and data protection?

2. Price and payment

• What exactly is included in the price and in what circumstances, if any, is this partly or wholly refundable?

3. Duration of the agreement, termination rights and any provisions dealing with post-termination issues such as retention of data and software where this is installed on your systems

4. Non-performance:

• Agreed damages / penalties for e.g., non-compliance with warranties, late payment of fees etc.
• Limitations of liability
• Exclusions of liability

5. Permitted Use and Users:

• Where software is being purchased for use across a fleet, and that fleet is organised across several one ship owning SPVs or other segregated ownership model, care needs to be taken to ensure the identity of the licensee / buyer is drafted sufficiently widely to allow all of those individual companies to benefit from the agreement, and not just the group holding company who may be the named entity entering into the agreement.

• Similar issues arise if it is envisaged that the software will need to be accessed and used by third parties such as fleet managers, surveyors, etc.

6. Warranties for cyber-security vulnerabilities[1] and compliance, including data compliance. These need to be carefully drafted to ensure Owners obtain the maximum protection that is commercially possible.

7. Governing law and jurisdiction: As with any contract, an express and clear clause covering the choice of governing law and applicable jurisdiction must be inserted.  This provides necessary clarity as to the law which will apply to the interpretation of the contract and avoids satellite arguments over jurisdiction.

Special considerations for operational technology

For software which is intended to be used with or integrated into OT, the following further issues must also be considered, in addition to any Class, insurance or Flag mandated requirements:

• How is risk and liability for failures in software, particularly safety critical software, apportioned?

• The need for safety critical software to have a built in ‘ability of system to fall back to minimal risk condition’ to ensure cyber resilience[2].

• The need for the supplier's ongoing assistance and cooperation to allow the Owner to comply with ongoing obligations as to safety and maintenance of onboard systems. See for example, the requirement for ongoing performance evaluations and testing as required by IACS Unified Requirement E26[3].  This should also extend to assistance required in relation to cyber-security, including collaboration in the development of the buyer's own cyber emergency response plan, performance of emergency drills, and consideration of the type of assistance that may be required from the supplier in the event of a cyber-incident.

• Comprehensive testing prior to integration into onboard systems.

• Whether, for safety critical systems, it is necessary and / or prudent to put in a place a software escrow agreement to provide continuing access to the software and related data, in the event of unforeseen circumstances such as the insolvency of the software provider or unexpected downtime. Further information on the apportionment of risk via escrow arrangements in software transactions can be found here.

Operational issues

Alongside consideration of the contractual clauses, where new software is adopted a review of operational processes is highly recommended.  Key questions to be asked include:

1. Is the process for selecting the software provider in line with industry best practice? For example, the IACS Unified Requirement E22 imposes an obligation to carry out a quality assessment and to ensure the supplier / software is properly certified[4].

2. How does the new software integrate and interoperate with current systems?

3. Will the software provider also provide sufficient and on-going training for crew members (and where necessary, shore-side staff including IT and other operational colleagues) to ensure they are fully conversant with the software? Will you amend your policies and processes to make it clear who has responsibility for maintaining or operating the software and how this is divided between crew and shore side staff?

4. What are your operational continuity plans in the event the software fails? Are the crew undertaking regular drills so they are prepared in the event of such a failure?

5. Are there any new cyber vulnerability issues from the new software and / or upgrades which need to be addressed in your cyber security systems and policies? Cyber-security response plans need to be continually reviewed and updated as new software is introduced.

6. Does the model for delivery and maintenance of the new software comply with best practice recommendations in the industry?[5]

7. Does the use of the software have any material impact on your insurance policies / the risks covered such that your policies need to be updated or revised?
   
   
   

Future developments

The law surrounding digital products and digitalisation in England & Wales generally remains largely undeveloped, as the legislative process is far slower than the speed of technological developments.  However, there are several draft bills in the pipeline alongside ongoing consultations on matters such as electronic trading documents, smart contracts, and digital assets, which suggest that it will be necessary to keep a close eye on statutory and regulatory developments in the near future.

DACB are well-versed in all matters relating to maritime regulations, contractual risk management and the risks and opportunities that accompany the adoption of new technologies, from software to autonomous ships, to cyber-risk, to data governance, to intellectual property and digital asset management.  If you are embarking on a digitalisation journey and wish to discuss how you can best protect your business while continuing to pursue innovation, please do not hesitate to contact the authors or your usual DACB contact.

[1] See the Bimco Guidelines on Cyber Security Onboard Ships for general guidance on cyber-security issues when selecting vendors

[2] IACS Unified Requirement E26, April 2022, on "Cyber Resilience of Ships"

[3] Ibid.

[4] IACS Unified Requirement E22, Rev. 2 June 2016, on "On Board Use and Application of Computer Based Systems"

[5] For example, IACS UR e 26 provides in relation to remote maintenance: "When remote access is used for maintenance, the following requirements shall be complied with in addition to those in 4.2.6.3.1:

- Documentation shall be provided to show how they connect and integrate with the shore side.

- Patches and updates shall be tested and evaluated before they are installed to ensure they are effective and do not result in side effects or cyber events that cannot be tolerated. A confirmation report from the software supplier towards above shall be obtained, prior to undertaking remote update…"