Contractual agreements on intellectual property and source code are the starting point

Software – more specifically, the source code – is usually protected by copyright. The source code is readable text written by the programmer in a programming language. The copyright holder has an exclusive right (copyright) with regard to the source code. The copyright holder is basically the ‘author/creator’ (the programmer) of the software. Copyright can only be transferred in writing under Dutch law. This means that if it is related to software specifically developed for an organisation (custom software), the client must agree in writing to the transfer of intellectual property rights in respect of the software (more specifically, the source code) with the developer.

Yet, this is not the only focus area in software-development agreements. For example, in 9 out of 10 cases, also custom software consists of existing source code written by third parties (third-party software). This is often open-source software. It is a misconception that ‘open source’ means that you can do whatever you want with that code. Licensing conditions may also apply to open-source software code. The violation of the underlying license terms constitute an infringement of intellectual property rights. Consequently, it is important to include in the agreement regarding the development of software whether or not the use of (open-source) software from third parties is permitted. If that is the case, the software developer, and subsequently the client as user of the software, must act under the terms of the (open-source) license.

Tip 1: Make sure to include the understandings relating to the transfer or license (the right of use) with regard to the intellectual property rights concerning the to be developed software in writing beforehand.

Tip 2: During the development of the software, also make sure to lay down whether or not (open-source) third-party software may be used in the development, and if so, on what conditions.

The relevance of documentation

A great deal of software development is currently based on the so-called ‘agile’ principle. Agile means that the software will be developed in successive, short periods of time (also called ‘iterations’ or ‘sprints’). At the end of each iteration, which starts with planning, analysis and design, the software will be tested and verified.

In agile development, the emphasis is on direct communication and personal contact instead of written reporting. Since the process of describing how the software is built and processing changes afterwards is very time-consuming, documentation is sometimes overlooked or incomplete. This is not necessarily a problem, because the knowledge is also ‘in the mind of the programmer’. But what if you want to change to another software developer? In that case it will be useful to be able to rely on something, such as solid documentation.

Tip 3: Make sure to agree in advance on the acceptance criteria for the documentation and/or make sure to actively monitor the software development during the development process, possibly allowing several persons to gain knowledge of how the software works.

The risk of a ‘vendor lock-in’

Usually, the software development process starts expeditiously. The completion of the development process, does not necessarily imply the end of the collaboration with the developer. After all, the computer programme needs to be maintained which means that logical errors (‘bugs’) must be removed and improvements (‘updates’ and ‘releases’) need to be implemented.

Without maintenance, software becomes rapidly unusable. If the client does not have access to the source code (and the complete documentation), he will not be able to maintain the software by itself or through a third party. This would make the client dependent on the original software developer. This is not a desirable situation, especially if, for example, the software developer becomes bankrupt, or if the relationship with the developer terminates for another reason.

This example draws our attention to the relevance of whether the copyright owner (i.e. the client) should be able to dispose and claim the source code from the software developer (or the trustee)?

The Dutch court examined this question in the past and ruled that the distinction between standard and custom software determines the right to issue the source code. Where it concerns custom software that cannot be used elsewhere, the supplier of the software (or the trustee in the event of bankruptcy) will have to provide the client access to the source code.

Custom software is therefore a relevant factor. But it also follows from this court decision that the deployability of the software by the developer must be considered. The follow-up question was whether a reasonable compensation had be paid to the software developer for the issuance of the source code. As far as standard software is concerned, the developer often has a commercial interest in withholding the source code. After all, he has invested time and money to develop the software and wants to avoid the software from being copied. With custom software, the client usually fully financed the development of the software and it has been programmed in accordance with the client’s specific requirements and specifications. In that case, basically, no additional compensation needs to be paid to the software developer.

Tip 4: be aware of the presence of a potential vendor lock-in risk and to be on the safe side, make sure to include in your agreement a provision that the development and transfer of the custom software includes the transfer and delivery of the source code.

Does maintenance work on standard software constitute copyright infringement?

In conclusion, another interesting question is whether the maintenance for standard software can be taken over by a third party in the event of the software supplier’s bankruptcy.

Modification of the software is not permitted without the permission of the copyright owner (i.e. the software developer of the standard software). That would constitute an infringement of copyright with respect to the software. However, Section 45j of the Dutch Copyright Act provides for an exception for the ‘lawful acquirer’ of the software. The licensee may be considered a lawful acquirer and could therefore have the maintenance of the software performed by himself or a third party.

However, the section further states that the modification of the software is “necessary for the intended use of such copyright work” (ed. The software). This introduces a difficulty, as also established by a Dutch District Court in an interlocutory judgement of April 2019. In a case initiated by a software supplier against a licensee who had outsourced the maintenance of the software to a third party, the software supplier held that this qualified as copyright infringement. The licensee invoked Section 45j of the Dutch Copyright Act. The District Court ordered the licensee to specify the ‘necessity requirement’ and the ‘intended use’ since this was not laid down in writing.

About one year later, on 5 March 2020, this was followed by a new interlocutory judgement in which the District Court found that the maintenance activities carried out by the third party were not required in view of the intended use of the software. In the District Court’s opinion, the licensee worded the intended use too broadly and insufficiently described the maintenance work. In addition, the claim that those actions were technically ‘absolutely necessary’ in order to be able to use the software in accordance with its intended purpose was insufficiently substantiated. Conclusion: infringement of the software supplier’s copyright.

Tip 5: Make sure to clearly define the purpose of the license and its intended use in the software-license agreement. As a software supplier, if you consider it undesirable to outsource maintenance to a third party, it is advisable to include an explicit provision to this end. In the example mentioned, this could have saved the software supplier from going to court.

If you have any questions about software development, please contact Chantal Bakermans via mail (c.bakermans@penrose.law) or call +31 (0)20-2400710.

Lawfirm Penrose, Amsterdam.

Others also searched for: