1 – Il rapporto tra il programmatore del software e il committente
Compreso che il software è a tutti gli effetti un bene giuridico tutelato dalla legge, risulta interessante analizzare l’interazione esistente tra l’autore e i potenziali soggetti interessati alle prestazioni del software, quali ad esempio gli utenti che navigano o lavorano sul web, le imprese intenzionate ad usufruire dei vantaggi dell’automazione o ancora i privati che desiderino godere delle funzioni di un software nella propria quotidianità.
Pertanto, esistono fattispecie in cui l’utilizzatore dell’opera dell’ingegno è persona diversa dal suo titolare (sviluppatore) ed avviene così una scissione tra i due soggetti.
In primo luogo bisogna considerare la differenza tra programmatore e utente/committente.
Il primo è colui che genera il software grazie alle proprie competenze e conoscenze ed è colui che gode sempre dei diritti d’autore, distinti – come visto in precedenza – in morali e patrimoniali.
Il secondo è un soggetto che usufruisce del software in base al proprio interesse e ne ricava un potenziale beneficio. Si è usato il termine committente poiché spesso accade che questi fornisca un incarico ad un esperto-sviluppatore affinché crei per lui un software, studiato esattamente sulle richieste ed esigenze manifestategli.
A tal proposito, si consideri che l’avvento dell’informatizzazione e dell’automazione negli anni ha suscitato molto interesse nei privati e nelle imprese, le quali, intenzionate a rimanere al passo con il progresso tecnologico nella gestione delle proprie attività, richiedono a personale esperto delle consulenze circa la realizzazione di software, che si evolvono poi frequentemente in richieste di sviluppo/realizzazione degli stessi.
È da qui che nasce il rapporto tra i due soggetti: da un lato il programmatore esperto, il quale, concordando le modalità di svolgimento dell’incarico, creerà un software appositamente studiato per le richieste del caso, e dall’altro colui che abbisogna delle prestazioni di un software-programma per
l’espletamento di proprie attività.
Tale circostanza deriva dal fatto che il committente in questione decide di non prendere in considerazione un software già esistente sul mercato e generato per il pubblico genericamente inteso, preferendo piuttosto rivolgersi ad esperti del settore per la realizzazione di un software “personalizzato”.
Il presupposto giuridico di tale fattispecie è la stipulazione di un contratto consensuale tra le parti, nel rispetto della legge e delle norme previste dal nostro ordinamento.
2 – Il contratto di sviluppo del software.
Il contratto di sviluppo software è un contratto atipico, il quale prevede che il committente incarichi una software house o un singolo sviluppatore-programmatore (lavoratore autonomo) per la realizzazione di un software che meglio si adatti alle proprie necessità. Si ricorda, pertanto, che ad oggi esistono diversi tipi di software, con annesse diverse funzionalità e potenzialità.
Il software – riconosciuto ad oggi come opera dell’ingegno – è disciplinato normativamente dalla Legge sul diritto d’autore (n. 633/41), la quale garantisce sempre diritti morali e patrimoniali al proprio autore, che, se non specificamente regolamentati nel contratto tra le parti, rischiano di essere trascurati e di non coprire il programmatore del software nella misura prevista dalla legge.
Il contratto di sviluppo dovrà perciò essere redatto in modo analitico e preciso, tenendo conto delle precise esigenze di entrambe le parti.
A tal proposito, il programmatore, successivamente alla stipula di un contratto di sviluppo, può rimanere il titolare dei diritti d’autore sul software da lui creato – come è anche possibile che ceda alcuni di questi diritti al committente.
È necessario quindi che nel contratto sia indicato chiaramente, anche sotto il profilo della proprietà intellettuale, cosa spetta all’uno e cosa all’altro.
Come in precedenza analizzato, i diritti morali discendenti dalla tutela autorale fanno sempre capo all’autore del bene poiché inalienabili, e dunque nel momento in cui un programmatore genera un software è indubbio che egli rimanga il “padre” dell’opera.
Diverso discorso vale per i diritti patrimoniali, i quali possono essere alienati insieme alla stessa. Ad esempio, può accadere che il committente sia intenzionato ad acquistare i diritti patrimoniali sul software a lui ceduto, così da riuscire a sfruttarlo economicamente successivamente alla ricezione.
Diversamente, può accadere che egli sia intenzionato esclusivamente a godere del software e delle sue funzionalità, permettendo così al programmatore di mantenere i diritti d’autore sul software, potendo lo stesso modificarlo e distribuirlo a soggetti terzi.
In questo ultimo caso, allora, più che di contratto di sviluppo software si parlerà di una licenza d’uso, tramite la quale il committente ottiene semplicemente il beneficio del godimento dell’opera poiché non interessato ad acquistarne i diritti patrimoniali d’autore.
3 – Le fasi della contrattazione
Le fasi della contrattazione per lo sviluppo-realizzazione di un software sono diverse, e precisamente vi sono:
- l’analisi delle esigenze del committente, la quale ha un ruolo preponderante poiché essa incide sulle conseguenze giuridiche nonché sui diritti riconosciuti alle parti. Infatti, il committente in tale fase dovrà manifestare la volontà – da inserire nel contratto – circa la natura e le prestazioni del programma da realizzare, nonché quella di ricevere o meno i diritti patrimoniali al momento della cessione del software.
Ad esempio, un’impresa che richieda ad un esperto la realizzazione di un software per l’espletamento di alcune attività interne e attinenti alla gestione tecnica, nella maggior parte dei casi non avrà interesse ad acquistare anche i diritti sul software poiché interessata esclusivamente al risultato e non anche alla possibilità di riprodurre le funzionalità e le prestazioni del software per eventuali e futuri affari; - la progettazione, in cui il programmatore svilupperà il software in base alle tempistiche e modalità pattuite;
- il collaudo, al fine di verificare il funzionamento e le prestazioni del software prima che questo venga consegnato per l’utilizzo;
- l’accettazione del risultato, la quale può manifestarsi a seguito di più collaudi nel caso in cui si tratti di un software particolarmente complesso o siano sorte nuove esigenze del committente durante la progettazione.
4 – L’esigenza di una forma contrattuale rigorosa.
Godere dei diritti patrimoniali sul software significa avere la possibilità di continuare ad utilizzare i codici attuati per la creazione dello specifico software successivamente all’espletamento dell’incarico postogli dalla committenza, quindi di riprodurlo e cederlo ad altri committenti per trarne ulteriori benefici.
Dunque, non è difficile ritenere che l’autore del software generalmente mantenga l’interesse – salvo diversa ed esplicita pattuizione – a rimanere titolare di tali diritti sul bene.
Per certi versi il contratto di sviluppo sembra rispecchiare le caratteristiche del contratto di prestazione d’opera (se il programmatore è un privato) ovvero d’appalto d’opera (se il programmatore è una società).
Tuttavia – anche se la disciplina di questi contratti risulti pressoché sovrapponibile – vi sono delle differenze da tenere in considerazione poiché il software – quale opera dell’ingegno e proprietà intellettuale – è un bene giuridico immateriale e in virtù di ciò presenta delle caratteristiche evidentemente diverse rispetto ad altri beni/opere realizzabili.
Dunque, un contratto di sviluppo software redatto nella forma di un comune contratto di appalto rischierebbe di provocare gli effetti di quest’ultimo favorendo il committente, trasferendogli ogni diritto di sfruttamento commerciale del software nonché dei codici tramite i quali è stato generato, con la conseguenza che il soggetto che li ha creati non potrà utilizzarli per altri incarichi.
Nessun problema sorgerà nel caso in cui la volontà del programmatore sia ab origine la stessa del committente. Diverso, invece, sarà il caso in cui le due volontà siano differenti e non espresse esplicitamente nel contratto.
Da tenere in considerazione è quindi la natura e la forma che il contratto di sviluppo necessita. Esso dovrà essere redatto in forma scritta nell’interesse delle parti, in quanto, considerata la atipicità dello stesso poiché non ancora disciplinato nel nostro ordinamento, ciò che rileva in caso di contenzioso giudiziale è quanto le parti hanno pattuito ed esplicitato nel contratto.
Quindi, in assenza di una contrattazione precisa ovvero in assenza della prova di una contrattazione scritta, l’autorità potrà semplicemente riferirsi alla disciplina applicabile in quanto assimilabile a quella trattata, potendo talvolta comportare conseguenze non desiderate dalle parti ovvero da una di queste.
In altre parole, una scarsa informazione reciproca al momento delle trattative è quasi sempre motivo di futuro contenzioso tra lo sviluppatore e il committente.
Difatti, quando si parla di diritti d’autore sulle opere dell’ingegno il cui utilizzo è destinato a terzi – e ancor di più nel caso del software – risulta essenziale la redazione di un contratto preciso e rigoroso in ogni sua parte – tramite il supporto legale di professionisti esperti – affinché si elimini a monte il rischio di incomprensioni o fraintendimenti tra i soggetti coinvolti.
The software development contract
1 – The relationship between the software programmer and the client
Understanding that the software is in all respects a legal asset protected by law, it is interesting to analyze the interaction existing between the author and the potential subjects interested in the performance of the software, such as users who browse or work on the web, companies intending to take advantage of the benefits of automation or even private individuals who wish to enjoy the functions of a software in their daily lives.
Therefore, there are cases in which the user of the work of the mind is a person other than its owner (developer) and thus a split occurs between the two subjects.
First of all, we must consider the difference between programmer and user/client.
The first is the one who generates the software thanks to his own skills and knowledge and is the one who always enjoys the copyright, divided – as seen previously – into moral and patrimonial.
The second is a subject who uses the software based on his own interest and derives a potential benefit from it. The term client has been used because it often happens that the client provides a task to an expert-developer to create for him a software, studied exactly on the requests and needs expressed to him.
In this regard, it should be considered that the advent of computerization and automation over the years has aroused much interest in private individuals and businesses, which, intending to keep up with technological progress in the management of their activities, ask expert personnel for advice on the creation of software, which then frequently evolve into requests for development/creation of the same.
This is where the relationship between the two subjects arises: on the one hand the expert programmer, who, by agreeing on the methods of carrying out the task, will create a software specifically designed for the requests of the case, and on the other the person who needs the performance of a software-program to carry out his own activities.
This circumstance arises from the fact that the client in question decides not to take into consideration a software already existing on the market and generated for the general public, preferring instead to turn to experts in the sector for the creation of a “customized” software.
The legal basis for this situation is the stipulation of a consensual contract between the parties, in compliance with the law and the rules established by our legal system.
2 – The software development contract.
The software development contract is an atypical contract, which provides that the client appoints a software house or a single developer-programmer (self-employed worker) to create a software that best suits their needs. It should therefore be remembered that today there are different types of software, with different functionalities and potential attached.
Software – recognized today as a work of the mind – is regulated by law by the Copyright Law (no. 633/41), which always guarantees moral and patrimonial rights to its author, which, if not specifically regulated in the contract between the parties, risk being overlooked and not covering the software programmer to the extent required by law.
The development contract must therefore be drawn up in an analytical and precise manner, taking into account the specific needs of both parties.
In this regard, the programmer, after signing a development contract, may remain the owner of the copyright on the software created by him – as it is also possible that he transfers some of these rights to the client.
It is therefore necessary that the contract clearly indicates, also from the point of view of intellectual property, what belongs to one and what to the other.
As previously analyzed, the moral rights deriving from the copyright protection always belong to the author of the asset since they are inalienable, and therefore when a programmer generates a software there is no doubt that he remains the “father” of the work.
A different argument applies to the patrimonial rights, which can be alienated together with the same. For example, it may happen that the client is intent on purchasing the patrimonial rights on the software transferred to him, so as to be able to exploit it economically after receiving it.
Otherwise, it may happen that he intends exclusively to enjoy the software and its functions, thus allowing the programmer to maintain the copyright on the software, being able to modify it and distribute it to third parties.
In this last case, then, rather than a software development contract, we will speak of a license of use, through which the client simply obtains the benefit of the enjoyment of the work since he is not interested in purchasing the copyright.
3 – The phases of the negotiation
The phases of the negotiation for the development-realization of a software are different, and precisely there are:
- the analysis of the client’s needs, which has a preponderant role since it affects the legal consequences as well as the rights recognized to the parties. In fact, the client in this phase will have to express the will – to be included in the contract – regarding the nature and the performances of the program to be created, as well as that of receiving or not the patrimonial rights at the time of the transfer of the software.
- For example, a company that requires an expert to create software for the performance of some internal activities and those related to technical management, in most cases will not be interested in also purchasing the rights to the software because it is only interested in the result and not in the possibility of reproducing the functionality and performance of the software for any future business;
- the design, in which the programmer will develop the software according to the agreed timing and methods;
- the testing, in order to verify the functioning and performance of the software before it is delivered for use;
- the acceptance of the result, which may occur following multiple tests in the case of particularly complex software or new needs of the client have arisen during the design.
4 – The need for a rigorous contractual form.
Enjoying the property rights on the software means having the possibility of continuing to use the codes implemented for the creation of the specific software after the completion of the task assigned by the client, therefore reproducing it and transferring it to other clients to obtain further benefits.
Therefore, it is not difficult to believe that the author of the software generally maintains the interest – unless otherwise and explicitly agreed – in remaining the owner of such rights on the asset.
In some ways the development contract seems to reflect the characteristics of the contract for the provision of services (if the programmer is a private individual) or of the contract for the provision of services (if the programmer is a company).
However – even if the discipline of these contracts is almost superimposable – there are differences to take into consideration since the software – as a work of the mind and intellectual property – is an intangible legal asset and by virtue of this has evidently different characteristics compared to other realizable goods/works.
Therefore, a software development contract drawn up in the form of a common procurement contract would risk causing the effects of the latter by favoring the client, transferring to him all rights to commercially exploit the software as well as the codes through which it was generated, with the consequence that the person who created them will not be able to use them for other tasks.
No problem will arise if the programmer’s will is originally the same as the client’s. However, the case will be different if the two wills are different and not explicitly expressed in the contract.
The nature and form that the development contract requires must therefore be taken into consideration. It must be drawn up in written form in the interest of the parties, since, given the atypical nature of the same since it is not yet regulated in our legal system, what is relevant in the event of a legal dispute is what the parties have agreed and made explicit in the contract.
Therefore, in the absence of a precise negotiation or in the absence of proof of a written negotiation, the authority may simply refer to the applicable discipline as it is similar to that discussed, which may sometimes lead to consequences that are not desired by the parties or by one of them.
In other words, poor mutual information at the time of negotiations is almost always a reason for future litigation between the developer and the client.
In fact, when it comes to copyright on intellectual works whose use is intended for third parties – and even more so in the case of software – it is essential to draft a precise and rigorous contract in every part – with the legal support of expert professionals – so that the risk of misunderstandings or misinterpretations between the parties involved is eliminated at the outset.
