Come se la stupidità delle aziende e del sistema brevettuale americano non fosse sufficiente, ci si mette di mezzo anche la giustizia. Durante l’appello del processo conclusosi nel 2012 a favore di Google, il giudice Kethleen O’Malley ha sentenziato che le API dovrebbero poter essere coperte da copyright. Di fatto, contro ogni aspettativa, al processo di appello sta vicendo Oracle.

Secondo la nuova sentenza, Oracle può far causa a Google per aver impiegato delle API di Java nel creare Android. Il problema è che Google non ha, di fatto, copiato il codice sorgente, ma soltanto la segnatura dei metodi. Cosa significa questo? Facciamo un passo indietro e cerchiamo di capire come funziona Java nei suoi punti fondamentali.

In Java, quando si crea un metodo – ovvero una funzione – lo si fa utilizzando la seguente forma:

public void sum (int a, int b)

Questa riga ci dice che:

  • il metodo è pubblico ed è, quindi, accessibile da qualunque classe (ovvero da qualunque programma o pezzo di programma che svolge una specifica funzione);
  • restituisce un valore void, ovvero una volta terminata l’esecuzione del metodo non c’è un output;
  • il metodo si chiama “sum”;
  • i valori in input sono due numeri interi chiamati “a” e “b”.

Il nostro metodo sum potrebbe essere parte di una classe chiamata MathOps. Quest’ultima potrebbe essere, a sua volta, parte di un programma più complesso: per identificare univocamente il metodo sum, quindi, bisogna indicare il percorso completo che bisogna fare per raggiungerlo – un po’ come con i file. Ad esempio, il percorso potrebbe essere com.tuttoandroid.app.MathOps.sum(int a, int b).

Il nostro metodo sum potrebbe poi essere il duplicato di una funzione già esistente: ad esempio, potrebbe aggiungere alcune funzioni che nella versione integrata in Java o in un certo programma non sono presenti. Il nostro sum va quindi a sostituire il metodo già esistente. Questo fatto si chiama overloading ed è stato appositamente inserito all’interno di Java per dare la possibilità al programmatore di ricreare a suo piacimento pezzi di codice senza dover sottostare ad una implementazione fallata o non rispondente ai suoi requisiti.

Una sentenza contro le funzioni di Java?

Va da sé, anche leggendo queste poche righe di spiegazione che sono largamente insufficienti a capire come funziona un linguaggio complesso come Java, che pensare di rendere proteggibili da copyright elementi come la segnatura dei metodi è pura follia.

È evidente che il giudice O’Malley non ha mai scritto una riga di codice in vita sua e non ha seguito il parere di tutto il mondo del software. Pensare di proteggere tramite copyright un elemento che fa parte del funzionamento stesso di un linguaggio signifca non solo impedire a chiunque di scriversi una propria versione di un metodo, ma – in una prospettiva più ampia – impedire di scrivere nuovo codice senza preoccuparsi della possibilità che qualcuno abbia protetto la segnatura. Di fatto, tutto il mondo del software si troverebbe impantanato in una palude di burocrazia e cose del tutto non necessarie messe in piedi per far dispetto a Google.

Questo il commento del giudice O’Malley sulla faccenda:

“Troviamo che la corte distrettuale non sia riuscita a distinguere la soglia tra ciò che è proteggibile da copyright – che rappresenta un limite inferiore – e lo scopo di una condotta che costituisce un’attività di violazione. La corte ha anche sbagliato a utilizzare principi di fair use, che comprendono preoccupazioni sull’interoperabilità, nella sua analisi sulla possibilità di registrare il copyright. Per le ragioni che seguono, dichiariamo che il codice di dichiarazione e la struttura, sequenza e organizzazione dei package delle 37 API di Java possono essere protetti da copyright.”

Il problema è che il giudice O’Malley, a quanto è possibile capire, esclude il problema prettamente informatico e non si preoccupa delle ripercussioni. Il problema sembra essere considerato dal mero punto di vista giuridico. Non sembra esserci alcun tentativo di comprendere il problema realmente.

Oracle: Google compete contro di noi

Sarebbe interessante capire come un sistema operativo mobile come Android potrebbe mai danneggiare Oracle. Voi avete mai sentito parlare di un sistema operativo sviluppato da Oracle al di fuori di Oracle Linux e (dopo l’acquisizione di Sun) di Solaris? Io no. Né ho mai sentito parlare di sistemi operativi mobili sviluppati da Oracle.

Così come non ho mai sentito parlare di DBMS di Google. O di server mission-critical di Google. O di qualunque altro prodotto di Oracle con cui Google potrebbe essere in competizione.

Eppure gli avvocati della compagnia di Larry Ellison hanno affermato che “il software Java ha richiesto anni e molti milioni di dollari per essere sviluppato, e il Circuito Federale ha capito che nessuno con la testa a posto farebbe un simile investimento se chiunque potrebbe semplicemente rubare questo lavoro ed usarlo per competere contro lo sviluppatore originale”.

Ecco. Questo dà un ottimo quadro della situazione. Davvero, Oracle, dov’è la competizione? Dove la vedi? L’unica competizione tra Google e Oracle è nella lista delle aziende con più soldi in banca. Stop. Finisce lì. Punto.

Oracle, se davvero credi di avere ragione e che la storia non sarà con te più che dura, ricordandoti come una massa di gente avida e senza scrupoli, ti sbagli. È un peccato che tanto talento debba essere sprecato così. Al posto che perdere tempo e far perdere tempo agli altri con inutili cause legali volte solo a ingrossare il tuo portafoglio (già, peraltro, abbastanza gonfio), forse se ti fossi applicata e avessi creato un tuo sistema operativo mobile le cose starebbero diversamente.

Ma hai preferito stare zitta e guardare mentre Android cresceva, per poi colpire appena hai pensato che la taglia sarebbe stata grande a sufficienza. La storia non ti perdonerà, Oracle. Sei avvertita.

Via