La sentenza era nell’aria già da qualche tempo: fiumi di parole sono stati scritti a favore dell’una e dell’altra parte durante questo processo, ma per quanto riguarda la sezione dedicata al copyright i pareri sono stati molto sbilanciati a favore di Google. Questo anche a causa del fatto che Oracle, nonostante abbia assunto uno dei migliori avvocati degli Stati Uniti, non è riuscita ad essere convincente abbastanza e a dimostrare la bontà delle sue posizioni. Dopo la sonora sconfitta subita nella sezione relativa ai brevetti, Oracle puntava tutto sul verdetto sul copyright e, in particolare, sulla possibilità di poter registrare sotto copyright le API di un linguaggio di programmazione (nel caso specifico Java). Ciò non è però avvenuto.

Il giudice William Alsup ha infatti usato parole molto ben precise. Riportiamo sia le parole originali della sentenza che la traduzione.

So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.

It is true that the very same functionality could have been offered in Android without duplicating the exact command structure used in Java. This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.

But the names are more than just names — they are symbols in a command structure wherein the commands take the form

java.package.Class.method()

Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability.

[…] In closing, it is important to step back and take in the breadth of Oracle’s claim. Of the 166 Java packages, 129 were not violated in any way. Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines. Oracle must resort, therefore, to claiming that it owns, by copyright, the exclusive right to any and all possible implementations of the taxonomy-like command structure for the 166 packages and/or any subpart thereof – even though it copyrighted only one implementation. To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition.

Fin quando il codice utilizzato per implementare un metodo è differente [rispetto a quello standard], chiunque è libero sotto protezione del Copyright Act di scrivere il proprio codice per ottenere la stessa funzione o specifica di qualunque metodo nelle API di Java. Non importa che la dichiarazione o che il prototipo del metodo siano uguali. Stando alle regole di Java, devono essere identici per dichiarare un metodo che specifichi la stessa funzionalità – anche quando l’implementazione è differente. Quando c’è solo un modo per esprimere un’idea o una funziona, allora chiunque è libero di farlo e nessuno può monopolizzare quell’espressione. E, mentre i nomi delle classi e dei metodi in Android avrebbe potuto essere differente dai nomi delle loro controparti in Java e avrebbero funzionato ugualmente, la protezione del copright non si estende mai ai nomi o alle frasi brevi.

È vero che si sarebbe potuto offrire la stessa identica funzionalità in Android senza duplicare l’esatta struttura di comandi di Java. Si sarebbe potuto fare questo riordinando i vari metodi in diversi raggruppamenti tra i vari package e classi (anche se fossero stati usati gli stessi nomi). In questo senso, c’erano molti modi per raggruppare i metodi pur duplicando lo stesso insieme di funzionalità. 

Ma i nomi sono più che solamente nomi – sono i simboli in una struttura di comandi dove i comandi prendono la forma

java.package.Class.method()

Ogni comando chiama in azione una funzione preassegnata. L’albero dei nomi nella sua interezza, ovviamente, ha elementi creativi ma è anche una struttura di comandi precisa – un insieme di simboli utilitari e funzionali, ognuno dei quali deve portare avanti una funzione preassegnata. Questa struttura di comandi è un sistema o metodo di operazione secondo la Sezione 102(b) del Copyright Act e, quindi, non può essere protetto da copyright. La duplicazione della struttura dei comandi è necessaria per l’interoperabilità.

[…] Concludendo, è importante fare un passo indietro e guardare all’ampiezza delle accuse di Oracle. Di 166 package in Java, 129 non sono stati violati in alcun modo. dei 37 accusati, il 97 percento delle linee di Android erano scritte da Google e il rimanente 3 percento era liberamente replicabile grazie alla merger doctrine e alla name doctrine. Oracle deve fare ricorso, quindi, all’affermazione che possiede, grazie al copyright, il diritto esclusivo su tutte e tutte le possibili implementazioni della struttura di comandi tassonomica dei 166 package e/o una porzione di essi – anche se ha registrato una sola implementazione. Accettare le dichiarazioni di Oracle vorrebbe dire permettere a chiunque di registrare una versione di codice per costruire un sistema di comandi e da lì impedire a tutti gli altri di scrivere la propria versione differente per ricostruire tutti o parte di quegli stessi comandi. Nessuna sentenza ha mai appoggiato una posizione così radicale.

Una posizione piuttosto dura nei confronti di Oracle che fa ben capire, però, che il giudice Alsup sa bene di cosa parla e ha una conoscenza approfondita – ben oltre quello che ci si aspetterebbe da un giudice – di Java e delle sue meccaniche interne. Visto che non tutti ne sono a conoscenza, provo a spiegare un pochino ciò che il giudice ha affermato.

Java prevede che si possano effettuare operazioni tramite metodi, ovvero funzioni di codice che svolgono una funzione ben precisa. Ad esempio, il metodo

system.out.println(string a)

si occupa di stampare a schermo una linea. Il nome del metodo è preceduto da “system.out” poichè indica il percorso in cui si trova il metodo stesso all’interno dei package di Java. Posso quindi scrivere le seguenti linee di codice per scrivere un programma che serve a stampare un messaggio:

public class Messaggio {

public static void main (String [] args){

system.out.println(“Questo è un messaggio”)

}

}

Ciò cui il giudice fa riferimento quando afferma “Non importa che la dichiarazione o che il prototipo del metodo siano uguali. Stando alle regole di Java, devono essere identici per dichiarare un metodo che specifichi la stessa funzionalità – anche quando l’implementazione è differente.” fa riferimento al fatto che in Java è possibile scrivere una propria versione di qualunque metodo tramite il cosiddetto overload. L’overload consiste nell’assegnazione ad un nuovo metodo di un nome già assegnato ad un metodo precedentemente creato: in questo modo posso creare un metodo che faccia le stesse cose ma in maniera diversa. Gli esempi si potrebbero sprecare, ma per ricorrere ad un esempio estremamente semplice posso scrivere più metodi, tutti diversi l’uno dall’altro, per selezionare elementi in un array (una sorta di “scaffale” in cui sono inseriti gli elementi).

Proteggere con il copyright le API significherebbe che un programmatore non potrebbe più scrivere la propria versione di un metodo impedendogli di portare a termine il proprio lavoro e complicandogli incredibilmente la vita. La decisione del giudice Alsup è perfettamente logica sia da un punto di vista giuridico che da un punto di vista prettamente informatico e rispecchia la volontà dei creatori di Java quando lasciarono la possibilità di fare overload dei metodi.

Con questa sentenza, inoltre, il giudice ha dato anche un netto vantaggio a Google nel processo d’appello che sicuramente si terrà. La sua decisione rimarrà con ogni probabilità immutata anche nel secondo grado, visto che il giudice ha dimostrato una competenza ed una precisione nella sua relazione veramente incredibili.

Tutto ciò che Oracle potrà ottenere saranno 300’000 dollari per la copia di 2 metodi. Una miseria, per una compagnia che fattura miliardi di dollari ogni anno e che ha speso milioni di dollari in questa causa. Per fare un paragone storico un po’ azzardato ma – a mio parere – calzante, Oracle è nella stessa condizione della Germania nelle prime due guerre mondiali: convinta di poter portare avanti una blitzkrieg contro il resto dell’Europa e di vincere in brevissimo tempo, in realtà si è poi trovata con enormi difficoltà e grandi disfatte. Alla fine arriva la distruzione e la sconfitta schiacciante, così come è accaduto ad Oracle in questo processo.

Per il momento si tratta di una vittoria memorabile per Google ed Android. Facciamo i nostri migliori complimenti a Mountain View per il risultato!