Who owns the software development if you paid for it?

'In software development, ownership does not follow payment – it follows authorship, unless otherwise contractually agreed to by the parties.'

Software development sits on the frontier of the Fourth Industrial Revolution. Everything from cloud computing to blockchain and Artificial Intelligence, exists on software platforms. Increasingly, the most successful enterprises operating on this frontier (particularly those adopting SaaS models) derive their core value not from physical assets such as machinery or inventory but from the intellectual property embedded within their software.

However, software development remains a legally and commercially complex terrain in engagements between commissioning parties and software developers, often giving rise to disputes concerning the ownership, control and exploitation of that intellectual property. Consequently, a detailed Software Development Agreement (‘’SDA’’) with clear provisions that navigate the parties through the minefield of proprietary ownership and commercial terms is an invaluable tool for enterprises looking to excavate on this frontier, unmarred by unnecessary and costly legal disputes relating to proprietary ownership. As such, this article highlights important contractual provisions that should be incorporated into your SDA.

It is [unfortunately] quite a common practice for software developers and commissioning parties to commence the full-scale development of their projects, purely based on mutual goodwill and the initial perceptions of a positive working relationship, all without any agreed contract in place. Some of the most high-profile disputes in the industry (e.g., the litigation between the Winklevoss brothers and Mark Zuckerberg) have arisen not from technical failure of the software but rather from a foundational misalignment on matters relating to ownership and control of the underlying software.

Indeed, some parties have a warped perception of SDAs as something to be feared, something that might remove the enterprising and innovative spirit required to develop the software. However, this could not be further from the truth. SDAs can be viewed in a similar vein to prenuptial agreements; they are not designed in anticipation of conflict but rather to preserve respective rights and expectations of the parties by delineating the matters of ownership, control and risk at the outset. In doing so, both parties may participate more freely and confidently in the development process, secured in the knowledge that their respective interests are clearly defined and safeguarded.

Under the Copyright Act 98 of 1978, the ownership in the software automatically vests in the software developer (author), as the author is the first owner of copyright. ’In software development, ownership does not follow payment – it follows authorship, unless otherwise contractually agreed to by the parties.'As such, the most important provision of an SDA is a clear and comprehensive clause dealing with Intellectual Property and Ownership of the software, lest the commissioning party wants to find itself in a situation where it has funded the development of the software without having acquired any proprietary rights in it. The Intellectual Property and Ownership clause must address the matters of assignment of rights and the treatment of pre-existing materials used in the development that occurs during and after the lifecycle of the software.

SDA’s must also have a clearly defined Scope of Work/Services that articulates the functionality and the commissioning partner’s desired outcomes and/or deliverables. Although agile delivery may be the preferred mode for the development of software, it often opens room for scope creep and disputes that may arise where there has been no mutual understanding of the exact functional capabilities of the deliverables. To that end, it is often recommended that the Scope of Work/Services must include detailed acceptance criteria for deliverables that is tied to functionality and performance, which must be formally accepted by the commissioning party. Additionally, the SDA must make provision for formal Change of Control Procedures that will prevent the informal expansion of scope that has not been mutually agreed to and accepted in writing by the parties.

Ideally, with the development lifecycles and/or phased delivery milestone-based delivery framework outlined in the Scope of Work/Services, a milestone-based billing schedule is the preferred payment structure that aligns payment with demonstrable delivery outputs. In this way, the commercial value is exchanged with demonstrable development and delivery, thereby reducing the occurrence of disputes relating to unsatisfactory work produced.

It is increasingly rare to find systems and software built from first principles. As such, Software Developers rely on external libraries and tools to aid in development. In particular, the use of some open-source licences may conflict with the commissioning party’s proprietary interests. Therefore, the SDA must be fortified with provisions that regulate the use of open source and third-party components that may dilute the commissioning party’s intellectual property rights in the developed software. Additionally, the SDA must contain several undertakings and indemnities from the Software Developer which warrant that the utilisation of any open-source or third-party components will not adversely affect the commissioning party’s ownership or commercialisation of the software.

By incorporating these robust contractual clauses, together with the appropriate compliance provisions for data protection of security incidents, commissioning parties can avoid uncertainty and disputes and empower themselves to actualise the full value of the software developed.

Contact Zinta Strydom, Managing Director: Home | ZS Attorneys