Abstract
Many software projects begin in the same way: someone who understands the problem to be solved defines the functions, workflows, information to be processed, and even the appearance of the screens; a programmer then translates those instructions into code. But can the person who devised how the program should work also be regarded as the author of the software? In Order No. 23473 of 1 August 2023, the Italian Supreme Court addressed precisely this boundary, clarifying when a contribution to software design may be protected by copyright and when, instead, it remains at the level of an idea or functional instructions.
If I design the functions of a software program, can I be considered its author?
This is a very common situation. A professional may have an in-depth understanding of a particular business process, identify the functions the software should have, determine what information should be collected, and tell developers what the interface should look like. The program itself is then created by programmers.
Who owns the software in this situation?
The case examined by the Italian Supreme Court, First Civil Division, in Order No. 23473 of 1 August 2023, arose from a very similar scenario.
Three doctors working at a healthcare facility had participated for many years in a project aimed at the digital management of care and treatment pathways for people affected by addiction. They claimed to have devised the program – called MFP – and therefore asserted both authorship and the economic exploitation rights in the software.
In support of their position, they produced handwritten notes, diagrams, and drawings used during development. According to their account, those instructions had enabled the IT specialists to create and subsequently expand the program.
The courts, however, found that this was not sufficient.
The central issue was not who had first come up with the idea for the program, but whether the doctors’ contribution had already taken on a sufficiently defined form of expression to fall within the copyright protection afforded to software.
What is the “preparatory design material” of a software program?
The law does not protect only code that has already been written.
Article 2(8) of Italian Law No. 633/1941 includes among protected works original computer programs as well as their preparatory design material.
The same approach derives from Article 1 of Directive 2009/24/EC, under which the term computer program also includes preparatory design material. The Directive, however, sets an essential limit: protection applies to the forms of expression of a program, whereas the ideas and principles on which it is based are excluded.
This is a distinction we had already examined when discussing the legal tools available to protect software: copyright may protect not only the code itself, but also the design work that precedes programming, provided that it has reached a sufficient level of concretization.
For example, stating that a management system must allow certain information to be entered, monitor particular activities, and produce specific results essentially describes what the program must do.
It is different to prepare a design structure capable of concretely representing how the program is to achieve that result.
It is precisely this distinction that lies at the heart of the Supreme Court’s order.
When do instructions given to a programmer become “preparatory design material”?
In the case examined, the documents produced by the claimants did not contain, according to the findings made in the proceedings, elements that would have allowed the program to be implemented directly.
In particular, the Supreme Court referred to the absence of technical representations comparable to flowcharts or other elements capable of describing, in operational terms, the algorithm to be translated into software.
The doctors’ instructions still required the intervention of IT specialists, who had to develop, structure, and transform them concretely into the program.
The test therefore cannot be reduced to the quantity or level of detail of the instructions provided.
A professional may have a perfect understanding of the sector, identify the problem to be solved, determine what information must be processed, and provide very precise guidance on the user experience. Their contribution may even be indispensable to the creation of the product.
But the economic or causal importance of a contribution does not automatically mean that it is protectable by copyright.
In other words, describing the desired function in detail does not necessarily amount to creating the design of the program in a copyright sense.
The same principle also helps explain why it is so important to be able to reconstruct the human contribution in more recent development processes, including those involving artificial intelligence tools: as we discussed in relation to AI-created software and proof of rights, documenting the creative and design process may become crucial when reconstructing ownership of the resulting work.
Can a highly detailed idea still fall outside copyright protection?
This is probably the most counterintuitive aspect of the decision.
Copyright protection is not intended to monopolize a problem to be solved or a result to be achieved.
The idea of creating a program that automates a particular activity, the functions it should have, the economic result being pursued, or the general logic of the system may all have considerable value. However, for copyright protection to apply, it is necessary to determine whether those ideas have taken on a concrete form of expression capable of being protected.
On this point, the Supreme Court also refers to the case law of the Court of Justice of the European Union (C-393/09, Bezpečnostní softwarová asociace) concerning graphical user interfaces: the fact that something enables the user to make use of a program’s functions does not, for that reason alone, make it a form of expression of the program itself. A graphical user interface may potentially qualify for protection in its own right if the relevant requirements are met, but that is a separate issue.
For anyone developing a project, therefore, the question should not simply be “who had the idea?”, but above all: what did each person actually create before the code was written?
How can someone who designs software without writing the code protect their contribution?
Above all, the order provides a practical indication: when several people contribute to the creation of software, relying on a later reconstruction of who supplied the decisive ideas in order to determine ownership of the rights can be risky.
A person who contributes to the design does not need to write the source code personally. What matters, however, is to make their contribution identifiable and capable of being documented.
Technical specifications, system architectures, diagrams, prototypes, design documents in their various versions, repositories, and change tracking can all help reconstruct who made particular choices and the level of development those choices had reached before the programmer became involved.
From a contractual perspective, it is equally important to establish in advance who will own the code, the preparatory material, the technical documentation, the interfaces, and the other assets developed as part of the project.
Clients, software houses, programmers, and consultants may in fact make very different contributions. Ownership of the final result cannot be reconstructed solely on the basis of who first proposed a particular function or identified the problem the software was intended to solve: it is necessary to assess, on a case-by-case basis, what contribution was actually made, the form in which it was expressed, and how the corresponding rights were regulated.
Reviewed by: Arlo Canella
Publication date: 29 September 2026
© Canella Camaiora S.t.A. S.r.l. - All rights reserved.
Textual reproduction of the article is permitted, even for commercial purposes, within the limit of 15% of its entirety, provided that the source is clearly indicated. In the case of online reproduction, a link to the original article must be included. Unauthorised reproduction or paraphrasing without indication of source will be prosecuted.
Margherita Manca
Avvocato presso lo Studio Legale Canella Camaiora, iscritta all’Ordine degli Avvocati di Milano, si occupa di diritto industriale.