Overview blog: copyright in software

Your company has spent months working on a software project. Thousands of lines of code are perfectly in place, the functionalities, APIs and UI all work as intended, and the delivery is a great success. But then a dispute arises: do the copyrights to the software belong to the developer, to your company, or to the client who footed the bills?

These kinds of disputes are a regular source of conflict, and the answers are not always what the parties had hoped or expected; parties often incorrectly assume that everything will sort itself out. In this blog, we set out when software is protected by copyright, who the rightsholder is, and what you can arrange contractually to avoid any surprises.

When is software actually protected by copyright?

Before you can discuss who holds the rights, it is important to know whether there is any copyright protection in the first place. The good news: copyright arises automatically, without registration or any other formalities. In practice, this is often referred to as an act of creation, upon which the copyright comes into existence.

Copyright only applies to something referred to in copyright law as a 'work'. At the time of the Copyright Act 1817 (the first national statutory copyright regulation in the Kingdom of the Netherlands) this concept referred primarily to literary works, works of art and the related 'regt van kopij' (right of copy). With the introduction of the Copyright Act 1912, which has since been amended on numerous occasions to keep pace with modern times, the scope of the concept of a work was gradually broadened. It was ultimately the European Software Directive of 1991 that explicitly brought software within the protection of copyright law, and that has since harmonised that protection across the EU. However, the software must meet three requirements:

• Original character: the software must not be derived from someone else's work. Absolute novelty is not required and coincidental similarities are permitted, but deliberate copying is not.
• Personal stamp of the author: the software must be the result of creative human effort, involving creative choices. Banal or purely technically determined works fall outside the scope of protection.
• Perceptible to the senses: the software must be perceptible in some way. This requirement is almost always met in the case of software.

In practice, the creativity threshold for software is remarkably low, and that is good news. Although software is by nature technical and functional, established case law of the Court of Justice of the EU shows that protection arises quickly, provided the developer had some creative freedom when writing the code and made personal choices in doing so. Think of the structure of the code, the chosen architecture or the way in which a problem was solved. Purely mechanical or technically predetermined code, where the programmer effectively had no choice, falls outside the protection. But in most cases, the rule is: if there is a human behind the code who made choices, the threshold for protection is quickly met.

What is not covered by protection?

Copyright protects the concrete elaboration, not the underlying idea. An idea for a handy app or a clever algorithm is not protected in itself; only the actual code that works out that idea enjoys copyright protection. Moreover, not every aspect of a piece of software falls within the scope of protection. Examples include:

• The programming language in which the software is written
• The functionality of the software as such
• File formats associated with the software
• Functionally determined UI elements: parts of the user interface that are determined solely by technical or functional requirements

What is protected are the source code and object code as such, to the extent that they meet the previously mentioned requirements.

The general rule: the author is the rightholder

Once it is established that the software is protected by copyright, the question arises: who holds the rights? The general rule is straightforward: copyright belongs to the author, the person who made the creative choices and thereby placed their personal stamp on the work.

In practice, software is rarely the work of a single person; software developers often work in teams, meaning there are regularly multiple authors involved. The law then distinguishes between two situations:

• Composite work: the work consists of multiple separate, distinguishable contributions. Each author holds copyright in their own contribution and can also enforce it independently.
• Joint copyright: the contributions are so intertwined that they can no longer be distinguished. In that case, all authors hold the copyright jointly: they must each give separate consent for exploitation and each have a claim to a proportionate share of the renumeration involved.

The law would not be the law without exceptions to the general rule, and there are plenty. Fortunately, they can be reduced to roughly three recognisable situations.

Exception 1: employer's copyright

The most common exception is employer's copyright (Article 7 of the Dutch Copyright Act). This provides that where an employee creates software in the course of their employment, the employer is deemed to be the author and thus acquires the copyright.

For this rule to apply, two requirements must be met:

1. There must be an employment contract (which also implies a relationship of authority, remuneration, a continuing relationship and productivity).
2. The creation of the software must fall within the employee's job description.

Although this framework seems clear on paper, it regularly gives rise to borderline cases in practice:

• Software written outside working hours: employer's copyright can still apply, provided that writing the software falls within the employee's job description.
• Interns: interns fall outside the scope of employer's copyright in principle, because an internship is primarily aimed at acquiring knowledge and experience, not at performing work.
• Freelancers and self-employed individuals: the starting point is that they fall outside the scope of employer's copyright. But what if an external programmer has been carrying out work for the same company for a long time? Whether an employment contract exists depends not only on what is set out on paper, but also on how the collaboration works in practice (as confirmed by the Dutch Supreme Court in the Deliveroo judgment (HR 24 March 2023, ECLI:NL:HR:2023:443)).
• Broad job description: the more detailed the job description, the easier it is to establish whether the software falls within it. Note that an explicit instruction from the employer can, in cases of doubt, still lead to employer's copyright applying.

Recent development: the ONB judgment (CJEU, 6 March 2025, ECLI:EU:2025:141)

It is worth noting that the Court of Justice of the European Union recently issued a judgment that calls into question statutory arrangements that transfer copyright without consent. In the ONB case (a dispute between the Orchestre National de Belgique and its musicians), the Court ruled that a Belgian Royal Decree requiring the mandatory transfer of musicians' neighbouring rights was not permissible.

Although the case concerned the neighbouring rights of musicians, the judgment may have broader implications. The relevant provisions are derived from European directives that also apply to copyright. Dutch lawyers are therefore asking whether Article 7 of the Dutch Copyright Act, which automatically vests copyright created by employees in the employer, remains tenable in light of this judgment. For the time being, the Dutch system appears to hold, thanks to the unless-clause in Article 7: parties can contractually deviate from the general rule, meaning there is no question of an entirely involuntary transfer as in Belgium. Nonetheless, the developments are certainly worth following closely.

Want to know more? Read this blog.

Exception 2: fictitious authorship

A lesser-known exception is fictitious authorship: it is not the person who writes the code, but the person who supervises and directs who is deemed to be the author, provided that person also actually makes the creative choices.

For software, this is an exceptionally high bar. The supervisor or manager must make substantive, creative decisions, while the programmer merely carries out executive work. This rarely occurs in practice. An exception is conceivable where there is a very detailed design in which the programmer is essentially only technically translating what has already been fully conceived by someone else.

Exception 3: the commissioned work situation

A common misconception: clients who hire a software company or freelance developer often assume they own the copyright in the delivered work. After all, they paid for it, right?

The general rule applies here too: the creator holds the rights. The software developer or supplier retains the copyright, regardless of how high the invoice was. So remember: paying doesn’t give you control. From a copyright standpoint, payment is completely irrelevant.

So what does the client receive? In principle, a licence (also known as a right of use) to the software. The exact scope of that right of use depends on:

• What was discussed and agreed during the proposal stage
• The purpose of the assignment
• What is stated in the development agreement and/or the general terms and conditions

Does the client want more than just a right of use? Then the transfer of copyright must be explicitly set out in the contract. Without such a provision, the rights remain with the software developer or supplier; that is often exactly as intended.

From the developer's perspective, too, the licence is no coincidental construction. Software developers typically work with reusable building blocks: libraries, standard modules and architectural patterns that they deploy across a wide range of projects. These components often form the core of their expertise and business operations. When a developer transfers the full copyright to their software, they risk restricting themselves in the use of their own code. Even if they built it from the ground up themselves. The licence offers a solution: the client gets what they need to exploit the software, while the developer remains free to use their building blocks for other projects.

The scope of the right of use also has practical consequences: it is often not permitted to simply engage a third party for maintenance or further development. Permission from the original developer is required for this, and that permission is by no means guaranteed.

This does not alter the fact that there is often room for partial transfer. Elements that have been developed specifically and exclusively for the client, such as a bespoke module or a client-specific design, are well suited to being transferred separately. In this way, the developer retains the rights to their generic building blocks, while the client becomes the full rightholder of what was made specifically for them. This does, however, require that the split be expressly set out in the contract and that it be clearly separable from the rest of the code.

Finally, there is a special situation worth noting: when a legal entity publishes software for the first time (for example via a post on GitHub or the launch of an app) without a natural person being named as the author, the legal entity itself is deemed to be the author. If the actual developer subsequently wishes to claim copyright, they will need to prove that the publication under those circumstances was unlawful.

Practical recommendations: arrange it contractually

The law covers a great deal, but by no means everything. Good contractual structuring is therefore essential. The following advice per category:

• Employers: explicitly set out in the employment contract that all intellectual property rights in works created in the course of employment belong to the employer. Not sure whether something falls within the job description? Arrange a transfer after the fact via a separate agreement regardless.
• Clients: ensure that the contract states that copyright is transferred to you. If a full transfer is not achievable, at least arrange the right to have maintenance and further development carried out by a third party of your choosing. Always check the supplier's general terms and conditions, these often contain deviating provisions on ownership.
• Employees and developers: have you written software outside working hours and want to keep it for yourself? Then make sure to record this in your contract, preferably before taking up employment. Once you have started the job, it becomes more difficult to make such arrangements.
• For everyone: a transfer of copyright is only valid if it is set out in writing in a deed. That is, a signed document in which the transfer is explicitly and unambiguously recorded. A verbal agreement or an email does not suffice. The same applies to an exclusive licence: this must also be set out in writing in a deed to be legally valid. If you do not wish to fully transfer the rights and do not want to agree to exclusivity, a non-exclusive licence is a good alternative, no deed is required for this. The author retains the copyright but grants the other party the right to use, adapt or further develop the software, on the terms you agree together. Even so, it is advisable to record the arrangements in writing, if only to avoid disputes further down the line.

Conclusion

Who holds the copyright in software depends strongly on the situation: employment, commission or supervision. The law provides an answer, but in practice that answer often disappoints the parties involved. Sound contractual structuring is therefore of great importance. Arrange it as early and as concretely as possible.

Do you have questions about your own IP strategy, your employment or procurement contracts, or an ongoing dispute about software ownership? We advise various organisations on intellectual property and the legal aspects of digital infrastructure. With IP Proof, we help organisations map their digital IP portfolio and identify where adjustments are needed.