La struttura delle app: un’analisi dettagliata per sviluppatori

Tempo di lettura stimato:10 Minuti, 14 Secondi

Nel panorama odierno della proprietà intellettuale, la comprensione della struttura dei programmi per elaboratore assume un ruolo certamente non più di secondo piano. I software e le app, infatti, rappresentano beni immateriali (?) di inestimabile valore, la cui corretta tutela giuridica richiede una conoscenza approfondita delle loro componenti essenziali e della loro architettura interna. Abbiamo approfondito tali aspetti nel fascicolo 4-5/2023 della prestigiosa Rivista di Diritto Industriale, con un analisi della qualificazione giuridica e della tutela del materiale preparatorio di un software. Qui invece, senza alcuna pretesa di esaustività, ma con l’obbiettivo invece di essere quanto più chiari possibili nell’esposizione, ci soffermeremo in particolare sulla struttura dei programmi per elaboratore e sui mezzi più idonei di tutela.

Possiamo cominciare con l’affermare che un programma per elaboratore si configura come un insieme strutturato di istruzioni e dati, concepito per essere eseguito da un sistema informatico al fine di svolgere compiti specifici. La sua composizione si articola in differenti livelli, ciascuno dei quali riveste una peculiare rilevanza ai fini della protezione giuridica.

1. Codice sorgente e codice oggetto
Il codice sorgente rappresenta la forma leggibile dall’essere umano, redatta in linguaggi di programmazione di alto livello. Attraverso un processo di compilazione o interpretazione, esso viene tradotto in codice oggetto, leggibile ed eseguibile dalla macchina. La distinzione tra codice sorgente e codice oggetto riveste particolare importanza nella disciplina del diritto d’autore, influenzando direttamente la titolarità dei diritti e le modalità di sfruttamento economico (per approfondire premere qui).

In termini estremamente pratici, il codice sorgente è considerato l’espressione creativa del programmatore ed è generalmente tutelato come opera dell’ingegno. D’altra parte, il codice oggetto, sebbene non direttamente leggibile, è il risultato finale destinato all’esecuzione e alla distribuzione commerciale. Ad esempio, un’azienda che sviluppa un software proprietario può decidere di proteggere il codice sorgente come segreto industriale, rilasciando solo il codice oggetto per impedire la copia non autorizzata. Al contrario, nel caso del software open source, il codice sorgente è reso disponibile al pubblico con specifiche licenze, come la GPL (General Public License), che ne regolano l’utilizzo e la modifica.

2. Architettura modulare
Un aspetto distintivo dei programmi per elaboratore è la loro struttura modulare. Ogni modulo racchiude specifiche funzionalità e può essere riutilizzato in differenti contesti applicativi. Tale organizzazione consente non solo una maggiore efficienza nello sviluppo, ma implica anche la necessità di un’attenta gestione della titolarità e delle licenze, soprattutto in ambito aziendale.

Ad esempio, l’impiego di moduli software open source all’interno di soluzioni proprietarie richiede un’attenta verifica delle condizioni di licenza, al fine di evitare violazioni involontarie delle clausole di distribuzione.

O ancora, in progetti di sviluppo collaborativo tra più aziende, è essenziale definire con chiarezza la proprietà dei singoli componenti, stabilendo contratti adeguati per evitare controversie sulla titolarità intellettuale.

3. Interfacce e API (Application Programming Interface)
Le interfacce costituiscono un elemento essenziale per l’interoperabilità dei software. Le API consentono la comunicazione tra diversi componenti software, favorendo la creazione di ecosistemi digitali interconnessi. Ma la protezione delle API costituisce un tema alquanto controverso, dal momento che si colloca al confine tra il diritto d’autore e la libera concorrenza.

Ma vediamo meglio. Le API rappresentano un’interfaccia standardizzata che permette a software diversi di interagire tra loro, e la loro protezione può limitare la concorrenza impedendo ad altri sviluppatori di creare prodotti compatibili. Ad esempio, celebri casi giudiziari come “Google vs. Oracle” hanno evidenziato come la protezione delle API possa influenzare l’innovazione e la competizione nel settore tecnologico. In questo caso, Oracle ha sostenuto che Google avesse violato il diritto d’autore copiando parti delle sue API Java per sviluppare il sistema operativo Android. La controversia ha sollevato questioni complesse su cosa sia effettivamente proteggibile dal diritto d’autore e su come bilanciare la tutela della proprietà intellettuale con la necessità di promuovere l’innovazione tecnologica.

Il caso Google LLC v. Oracle America, Inc. è probabilmente una delle controversie legali più rilevanti nella storia della proprietà intellettuale nel settore tecnologico, incentrata sulla protezione del diritto d’autore sulle API.

Oracle, dopo aver acquisito i diritti su Java nel 2010 attraverso l’acquisizione di Sun Microsystems, citò in giudizio Google nel 2010, sostenendo che quest’ultima aveva violato il diritto d’autore copiando circa 11.500 righe di codice dalle proprie API Java per utilizzarle nello sviluppo del sistema operativo Android, e che pertanto avrebbe dovuto ottenere una licenza per utilizzare quelle specifiche API.

Google, dal canto suo, sostenne che le API non sono soggette a protezione del diritto d’autore, in quanto rappresentano un metodo di interfacciamento standardizzato necessario per garantire l’interoperabilità tra software diversi, e che comunque anche se fossero protette, il loro utilizzo rientrava nel concetto di fair use (uso leale), dato che Android rappresentava un’opera trasformativa e non un semplice adattamento delle API Java.

La disputa si è protratta per oltre un decennio e ha attraversato diversi gradi di giudizio negli Stati Uniti. Nel 2012 un tribunale distrettuale della California stabilì che le API non potevano essere coperte dal diritto d’autore, poiché costituivano un metodo operativo e non un’opera creativa originale. Ma successivamente, nel 2014, la Corte d’Appello, adita da Oracle, ribaltò la sentenza, sostenendo invece che le API erano idonee alla protezione del diritto d’autore, poiché la loro struttura e organizzazione erano abbastanza originali da meritare tutela, senza pronunciarsi però sulla questione del fair use, rimandando quindi la decisione al Tribunale distrettuale per stabilire se l’uso da parte di Google delle API rientrasse o meno nel fair use, ossia se fosse giustificabile senza violazione di copyright.

Nel 2016, quindi, la causa è stata riesaminata dal Tribunale distrettuale della California, questa volta però con l’intervento di una giuria federale, chiamata a valutare proprio se l’uso delle API da parte di Google fosse da considerarsi lecito secondo il principio del fair use, che consente l’uso limitato di opere protette a determinate condizioni (ad esempio, per innovazione o miglioramento tecnologico). E questa giuria ha dato ragione a Google, affermando che l’uso delle API Java rientrava nel concetto di fair use, poiché Google aveva usato solo le parti essenziali per lo sviluppo di Android, contribuendo all’innovazione tecnologica senza danneggiare il mercato di Oracle.

Oracle, naturalmente non soddisfatta, ha impugnato nuovamente la decisione, portando il caso a un altro appello, nel quale sostanzialmente sosteneva che l’uso delle API da parte di Google non poteva rientrare nel fair use, poiché Android aveva generato ingenti profitti sfruttando le tecnologie Java senza compensare Oracle.

E la Corte d’Appello, nel 2018, ha annullato la decisione della giuria, stabilendo che l’uso delle API Java da parte di Google non rientrava nel fair use, poiché l’utilizzo non era sufficientemente “trasformativo” e aveva creato un danno economico a Oracle, e Google, pertanto, risultava responsabile di violazione del copyright, con un potenziale risarcimento miliardario.

Google ha quindi presentato ricorso alla Corte Suprema degli Stati Uniti.

La Corte Suprema, massima autorità giudiziaria negli Stati Uniti, ha accettato di esaminare il caso e si è pronunciata nell’aprile 2021.

Con una maggioranza di 6 voti a 2, la Corte Suprema ha stabilito che l’uso delle API Java da parte di Google rientrava nel fair use, ribaltando la decisione della Corte d’Appello e ponendo fine alla controversia.

Nello specifico la Corte ha ritenuto che Google aveva copiato solo le parti necessarie per garantire la compatibilità e l’interoperabilità del proprio sistema operativo. L’uso di quelle API era infatti trasformativo, poiché Android era un sistema innovativo e diverso da Java. Sostanzialmente la Corte ha ritenuto che una protezione eccessiva delle API avrebbe potuto ostacolare l’innovazione e danneggiare la concorrenza nel settore tecnologico.

In definitiva, dopo 11 anni di battaglie legali, la decisione della Corte Suprema ha rappresentato una vittoria per Google e ha creato un precedente significativo.

Le API possono essere protette dal diritto d’autore, ma il loro utilizzo può essere giustificato dal fair use, a condizione che promuova l’innovazione e la concorrenza. Le aziende devono essere caute nell’uso delle API altrui, bilanciando la necessità di interoperabilità con i limiti imposti dalla legge sul copyright. Il settore tecnologico ha ora maggiore libertà di costruire nuove soluzioni interoperabili, senza il timore di cause legali per l’uso di API standardizzate.

Le differenze normative tra USA e UE

Negli Stati Uniti, il sistema giuridico prevede, come abbiamo visto, la dottrina del fair use, che consente l’utilizzo di opere protette da copyright in determinate circostanze senza necessità di autorizzazione. E la decisione della Corte Suprema ha ritenuto che l’uso delle API Java da parte di Google rientrasse in questa dottrina, favorendo l’innovazione e la concorrenza.

In Europa, invece, la tutela del software è regolata, come sappiamo, dalla Direttiva 2009/24/CE, che disciplina la protezione giuridica dei programmi per elaboratore nell’ambito del diritto d’autore. E a differenza del concetto di fair use, l’ordinamento dell’Unione Europea ammette eccezioni più ristrette e specifiche, come quelle previste dagli articoli 5 e 6 della Direttiva, che consentono la decompilazione e l’uso del software per finalità di interoperabilità, a determinate condizioni (per approfondire premere qui).

Gli sviluppatori europei che interagiscono con API di terze parti devono tener conto delle diverse impostazioni normative:

  • In Europa, l’utilizzo di API senza autorizzazione può costituire una violazione del diritto d’autore, a meno che non ricada nelle eccezioni previste dalla legge, come l’interoperabilità o l’uso per la creazione di software compatibili.
  • Negli USA, grazie alla decisione su Google vs Oracle, potrebbero beneficiare di una maggiore libertà d’uso, ma questa protezione non si estende automaticamente al mercato europeo.

Un’azienda europea che sviluppa software destinato a un mercato globale dovrà pertanto adottare un approccio conforme alle normative UE, valutando attentamente la possibilità di ottenere licenze per l’utilizzo di API e garantendo che il proprio operato non violi i diritti esclusivi del titolare.

La Corte di Giustizia dell’Unione Europea (CGUE) ha affrontato questioni simili, ad esempio nel caso C-406/10, SAS Institute Inc. v. World Programming Ltd., stabilendo che le funzionalità di un programma per elaboratore non sono soggette a protezione mediante diritto d’autore, bensì solo la loro espressione specifica, come il codice sorgente o oggetto. Questo principio potrebbe fornire una base giuridica per un utilizzo lecito delle API in Europa, a patto che si rispetti la normativa vigente.

Per approfondire:

- G. SARTOR, L’informatica giuridica e le tecnologie dell’informazione, Torino, 2016; 

- G. CAPO, La tutela giuridica del software in AA.VV. Manuale di diritto dell’informatica, Napoli, 2004;

- MARCHETTI-UBERTAZZI, Commentario breve alle leggi su proprietà intellettuale e concorrenza, Padova, 2012;

- GUGLIELMETTI, L’invenzione di software, Milano, 1999;

- GIANNANTONIO, Manuale di diritto dell’informatica, 2^ ed., Padova, 1997;

- L. J. SMITH, Whether Copyright Protects the Graphic User Interface of a Computer Program: Bezpečnostní softwarová asociace - Svaz softwarové ochrany contre Ministerstvo kultury (C-393/09), in Computer and Telecommunications Law Review, 2011, 17, 3 p. 70-72;

- H. BITAN, L’interface graphique d’un logiciel constitue une oeuvre autonome distincte du logiciel, in Droit de l’immatériel: informatique, médias, communication, 2011, 70, p. 13-19;

- L. COSTES, Protection des interfaces graphiques des logiciels: la position de la CJUE, in Droit de l’immatériel: informatique, médias, communication,
2011, 68, p. 30-31;

- M. HOLÝ, On the possibility of copyright protection of a graphic user interface of a computer program, Brussels, 2014;

- J-P TRIAILLE, L’arrêt“BSA” en matière de protection des logiciels, deux réponses fort étonnantes de la Cour de justice, 2012;

- L. IDOT, Programmes d’ordinateur et interfaces, Europe 2011 Février Comm. nº 2, p. 44;

- M. BASSINI, Diritto d’autore e tutelabilità dell’interfaccia grafica utente del software: alcuni importanti rilievi della Corte di giustizia, in Diritto pubblico comparato ed europeo, 2011 p. 508-514;

- S. DÜRAGER, Die Schutzfähigkeit der Benutzeroberfläche im Immaterialgüterrecht, in Österreichische Blätter für gewerblichen Rechtsschutz und Urheberrecht, 2011 p. 100-106;

- J-P TRIAILLE, Enfin des arrêts de la Cour de justice en matière de protection des logiciels, in Journal des tribunaux, 2012 p. 833-835;

- C. LE STANC, Droit du numérique. Logiciels: objet de la protection, in Recueil Le Dalloz, 2012 p. 2343-2344;

- BERTANI, Open Source ed elaborazione di software proprietario, in AIDA, 2004, p. 114;

- DRAGOTTI, Software, brevetti e copyright: le recenti esperienze statunitensi, in Riv. Dir. Ind., 1994, p. 539 ss.;

- N. NAPPI, La tutela del software nell’Unione Europea e il caso Oracle: una forte scossa al Diritto d’Autore, in Diritto.it, Roma, 2015.
The following two tabs change content below.

Nicola Nappi

⚖️ Diritto commerciale, assicurativo, bancario, delle esecuzioni, di famiglia. Diritti reali, di proprietà, delle locazioni e del condominio. IT Law. a Studio Legale Nappi
*Giurista, Master Universitario di II° livello in Informatica Giuridica, nuove tecnologie e diritto dell'informatica, Master Universitario di I° livello in Diritto delle Nuove Tecnologie ed Informatica Giuridica, Corso di Specializzazione Universitario in Regulatory Compliance, Corso di Specializzazione Universitario in European Business Law, Corso di Perfezionamento Universitario in Criminalità Informatica e Investigazioni digitali - Le procedure di investigazione e di rimozione dei contenuti digitali, Corso di Perfezionamento Universitario in Criminalità Informatica e Investigazioni digitali - Intelligenza Artificiale, attacchi, crimini informatici, investigazioni e aspetti etico-sociali, Master Data Protection Officer, Consulente esperto qualificato nell’ambito del trattamento dei dati.
error: Misure tecnologiche di protezione attive ex art. 11 WIPO Copyright Treaty, §1201 del DMCA, art. 6, dir. 29/2001/CE, art. 102-quater, l. 22 aprile 1941, n. 633, art. 171-ter, l. 22 aprile 1941, n. 633.