Overview
We produced a software development agreement for a process following an AGILE methodology. The agreement included software support and maintenance provisions with service levels and covered the supply of open-source software. The agreement needed to work for multiple parties across a supply chain.
Context and Challenge
Our client was a subcontractor to a large consultancy on a project funded by USAID. Our client was tasked to procure a document management information system for a multi-donor organisation.
Our client was unaccustomed to being responsible for the delivery of technology projects and so was not alive to many of the inherent risks. They had lined up a developer and were ready to pull the trigger with them but many important points had not been nailed down such as IP ownership and support and maintenance with service levels for the system once built.
The developer was based in Africa and within a jurisdiction where it would have been difficult for our client to enforce its rights under the contract.
Our client’s subcontract with placed a lot of risk on our client without having been tailored for the delivery of software and therefore without the unusual disclaimers of liability for projects of this nature. Obligations placed on IP ownership for deliverables did not match what our client had agreed with the software developer (open-source software was to be included in the developed product) and were unrealistic in this context but they could not be ignored because our client had signed up to these.
The consultancy on the other side of our client’s contract was not the end customer. We had to understand the contents of the head contract and what the end customer wanted to achieve with the software and what constraints they were under.
It was unclear how personal data to be stored on the system would be protected – data protection compliance hadn’t really been thought through.
Process and Insight
We spent time reviewing where the client was up to with the developer. The developer had already answered a Q&A but there were still important elements that had not been addressed that needed to be nailed down. The position on IP ownership was unclear.
We reviewed the subcontract and the head contract and flagged issues and suggested solutions.
We spent time with the client explaining the risks and how to mitigate them.
We liaised with all parties to discuss data protection issues, provide options and suggest solutions.
We checked each component of the open-source software to be used to understand the applicable licences. We needed to ensure that the licences were permissive.
We produced a first draft of the contract and to an extent followed an AGILE process ourselves as the contract was further amended as challenges and risks were identified and addressed.
Solution
Having established where the gaps lay in issues such as IP ownership we addressed these with both the developer, our client’s counterpart and the end customer, the latter two signing off on the use of open source software in the product and other IP ownership arrangements. The developer agreed that IP ownership in the development work that they would be doing would be owned by the end customer. IP ownership in pre-existing software would be owned by the developer but licensed royalty-free and perpetually to the end customer.
We recommended an AGILE process for the software development as it was clear to us that the technical specification for how the system should be developed was insufficient.
The developer agreed to attach their rates for the maintenance and support of the software to the development contract along with SLAs so that future costs and commitments to support the system would be certain from the outset.
We attached an IP schedule to the development contract setting out each component of the software to be delivered and, in the case of open-source software, what open-source licence applied.
We came up with a payment structure and sign-off mechanics for the developer to mitigate against the risk of non-performance where enforcement of rights would be difficult.
We included third party rights and step in rights for the client’s counterpart and the end customer as neither were parties to the software development agreement.
Results
We delivered a contract that was clear and protective for our client and the other parties up the supply chain. It covered many important issues that had not been initially considered or dealt with properly which, if left unaddressed, could have had serious consequences for our client and the end customer.
The development work went well with no issues on performance or timing of delivery of the system.
