ORACLE v. GOOGLE, DE MINIMIS NON CURAT LEX

Con due provvedimenti, dell’11 e del 23 maggio 2012, la giuria della Northern District of California, istruita dal giudice William Alsup, si è pronunciata sulla nota causa tra Oracle America Corp. e Google Inc.
La causa, suddivisa in due parti, una relativa alla violazione di copyright e l’altra di brevetti, ha destato interesse soprattutto per la prima, in particolare per la ipotesi di violazione delle API (Application Programmer Interface) che mai prima d’ora sono state considerate oggetto di tutela da parte del diritto d’autore.
Nel provvedimento dell’11 maggio, la giuria si è limita ad affermare che c’è stata una violazione di diritti d’autore detenuti da Oracle relativamente a poche righe di codice (segnatamente 9 righe in decompilazione di 8 file) e che tale violazione, pur non essendo “de minimis” come sostenuto da Google, non ha coinvolto parti essenziali di Java. Tale decisone è comunque stata presa attraverso un JMOL (Judgement as a Matter Of Law) con cui il giudice Alsup ha in parte avocato a sé il giudizio (overrule) sostituendosi alla giuria, ritenendo lo stesso maturo per la decisione. La questione più importante, ovvero l’accertamento della violazione delle API, è invece ancora in sospeso e, secondo alcune indiscrezioni, dovrebbe giungere entro due settimane.
Nel provvedimento più recente è stato invece accertato che nessuno dei capi di Oracle relativi ai brevetti è stato violato.
La difesa di Google si è basata essenzialmente sul principio del “de minimis” ma non è riuscita a convicere la giuria. Nell’ambito del diritto d’autore, ha infatti ammesso che il codice di Java decompilato fosse stato utilizzato ma solo per effettuare dei test, senza poi essere ripreso nel sistema operativo pubblicato. Il consulente tecnico di Oracle ha dimostrato come l’uso del codice fosse stato invece significativo, anche per la produzione, e che il plagio fosse evidente data la esatta corrispondenza tra il codice dei file di Java e quelli di Android. Tra l’altro, nel provvedimento il giudice fa riferimento ad un principio della Corte d’Appello del suo distretto secondo il quale, per accertare se un plagio è da considerare o meno “de minimis”, non conta la quantità né come la parte di opera copiata viene poi utilizzata.
Il processo non è quindi affatto concluso, anzi, procede ora sulla questione più importante del “copyright infringement”, quello relativo alle API. Il tema infatti si colloca e identifica in un contesto generale annoso e complesso, relativo alla tutela giuridica dei programmi per elaboratore, che con le API non ha tuttavia mai avuto una diretta relazione. Nel complaint Oracle chiede di accertare violazioni su un terzo di tutte le API del sistema operativo Android, per cui, rispetto a quanto richiesto, il provvedimento emesso lo scorso 11 maggio si è occupato di una parte davvero esigua, quasi insignificante.
Non è inopportuno qui ricordare che il software è uno dei beni più controversi di cui il diritto si sia mai occupato, strattonato dal diritto d’autore e dal diritto industriale in quel simulacro di ambito giuridico chiamato proprietà intellettuale. Quando apparvero i primi programmi per elaboratore, la maggior parte dei giuristi li ritenne opere dell’ingegno, e non invenzioni, secondo un indirizzo di pensiero formatosi proprio negli Stati Uniti già negli anni 50 denominato “copyright approach” (modello poi adottato anche in Europa nel 1991 con la Direttiva 91/250/CEE, che non riuscì tuttavia a conciliare il modello del “copyright” con quello del “diritto d’autore”). In ambito brevettuale, invece, c’è sempre stata un’evidente differenza tra Europa e Stati Uniti. In Europa il software non è brevettabile “di per sé”, ovvero, “as such”. La Convenzione di Monaco sul brevetto europeo del 1973 lo prevede espressamente e nel 2005 il Parlamento dell’UE ha bocciato senza riserve una proposta di direttiva sulla brevettabilità dei programmi. Negli USA le domande di brevetto che hanno ad oggetto il software vengono invece accettate molto facilmente perché è sufficiente che la parte richiedente sia in grado di dimostrare il cosiddetto “effetto tecnico” che, molto semplicemente, può essere ricondotto alla elaborazione di file da parte del computer.
Una delle poche certezze sinora emerse nel giudizio è che la copia pedissequa del programma o di una determinata sequenza di linee di codice è vietata dalla legge sul diritto d’autore, anche se ciò non preclude che una stessa idea venga realizzata attraverso il ricorso ad altre istruzioni, per ottenere lo stesso risultato. Rispetto ai brevetti, gli accertamenti si sono basati invece su principi totalmente differenti. Attraverso il brevetto, la realizzazione indipendente delle idee e dei principi che sono alla base del programma viene privata a soggetti terzi e la protezione è offerta solo relativamente ad una specifica funzione del programma.
Per quanto attiene alle interfacce di programmazione (le API), così come i linguaggi, occorre una ricognizione differente che non può essere collocata sic et simpliciter nel diritto d’autore o nel diritto brevettuale. Le API, in generale, possono essere considerate fuori dalla portata del copyright e, ad oggi, nessun giudice ha affermato il contrario.
Le API sono interfacce, non sono programmi, stabiliscono essenzialmente come deve essere eseguita una “chiamata” da e verso il programma, ma non come deve essere il programma che le effettua. Per esempio, è come dire che occorre determinare in un programma come devono essere i toni DTMF e quale debba essere la loro durata minima per poi sviluppare un’applicazione su Android che li genera premendo un’area dello schermo del programma di composizione del numero. Le API sono quindi un dato fattuale, per cui, non si possono considerare espressione di creatività protetta dal copyright. In Europa, questo principio è fatto salvo dal diritto a conseguire l’interoperabilità, contenuto nella Direttiva 91/250/CEE (in sostanza, se non usi le API non puoi interoperare). In USA la questione è controversa perché tale principio non è stato codificato, anche se vi sono precedenti giurispriudenziali illustri che hanno trattato il tema (cfr. Lotus Development Corporation v. Borland International, Inc., 516 U.S. 233, 1996 ed Apple Computer, Inc. v. Microsoft Corporation, 35 F.3d 1435, 9th Cir., 1994).
In tutto questo contesto ora delineato, occorre anche considerare che Java ha una sua caratteristica peculiare, ovvero, la programmazione ad “oggetti” capace di generare le cosiddette “classi” (nello specifico le Java API Packages che secondo Oracle sono state copiate). Quando un programmatore scrive e sviluppa un programma, raramente parte da una pagina vuota perché utilizza le cosiddette “routine” e “librerie” o, se si tratta di Java, gli “oggetti” e le “classi”. In sostanza, utilizzerà codice già scritto da altri contenente istruzioni ormai consolidate e collezionate negli anni, il più delle volte banali e prive di originalità. Se così non fosse, le possibilità dei programmatori sarebbero molto limitate e lo sviluppo di ogni singola funzione del programma necessiterebbe di una propria licenza e relativi problemi di compatibilità con le licenze di altre componenti del programma, oltre che il pagamento delle royalty al titolare dei diritti.
L’ambito giuridico europeo può comunque considerarsi estraneo a qualunque decisione della corte statunitense e, anche nel caso in cui quest’ultima dovesse giungere ad ammettere la protezione delle API, è altamente improbabile che un giudice europeo possa essere influenzato da tale teoria perché palesemente in contrasto con il principio dell’interoperabilità dei sistemi ivi richiamato, recentemente affermato anche dalla Corte di Giustizia dell’UE nel caso C-406/10 (Sas Institute Inc. v. World Programming Ltd.).
Il caso Oracle contro Google resta comunque di grande interesse per tutti, Europa compresa. Senz’altro lo è per l’industria tecnologica direttamente coinvolta e per gli sviluppatori indipendenti di Java e Android in tutto il mondo che sentono l’esigenza di lasciare libere le idee di circolare e di essere espresse in ogni forma possibile. Un grande incentivo all’innovazione è, da sempre, la libertà.