Google and Oracle are headed to the Supreme Court. The future of software hangs in the balance.
Google and Oracle are headed to the Supreme Court. The future of software hangs in the balance. A generation of software built around shared assumptions for interoperability faces an uncertain future depending on the outcome of a yearslong legal fight between Google and Oracle. Tom Krazit https://www.protocol.com/google-oracle-supreme-court-software-api (Sent from my wireless device; please excuse brevity and typos (if any))
On Wed, Oct 07, 2020 at 10:12:40PM +0200, J.C. DE MARTIN wrote:
Tom Krazit https://www.protocol.com/google-oracle-supreme-court-software-api
Ieri sono stato completamente ipnotizzato dall'ascolto dell'hearing della corte suprema americana con gli avvocati dei contendenti e del governo federale. Consiglio l'ascolto a tutti i legal/license geek che ci leggono: https://www.c-span.org/video/?469263-1/google-v-oracle-america-oral-argument -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
On Thu, 8 Oct 2020 08:24:40 +0200 Stefano Zacchiroli <zack@upsilon.cc> wrote:
Ieri sono stato completamente ipnotizzato dall'ascolto dell'hearing della corte suprema americana con gli avvocati dei contendenti e del governo federale. Consiglio l'ascolto a tutti i legal/license geek che ci leggono:
https://www.c-span.org/video/?469263-1/google-v-oracle-america-oral-argument
Interessante in effetti, grazie davvero della segnalazione. Francamente, le argomentazioni di Google non ti sembrano piuttosto fragili? Parliamo di 600 pagine di API copiate di sana pianta. Secondo Google è fair use perché, in 10 anni, ha permesso a milioni di sviluppatori di arricchire un suo Walled Garden. Quanto al fatto che non si potessero scrivere in un'altro modo, sappiamo tutti che non è vero: potevano riprogettare le interfacce da zero ANCHE continuando ad usare lo stesso linguaggio ma, ovviamente, si sarebbero trovati a competere per gli sviluppatori sullo stesso piano di Apple e Microsoft, mentre loro VOLEVANO batterli attraendo orde di programmatori Java già belli che formati. E poi... il FUD nell'appello finale non ha prezzo. Chissà se i giudici saranno così autoreferenziali da credere di poter distruggere l'informatica tutta con una sentenza... Sia chiaro: il Copyright è incompatibile con la democrazia. Ma un'API è codice QUANTO le sue implementazioni. E' come se Google avesse scritto un sequel di Harry Potter sostenendo che si tratta di fair use perché in 10 anni è stato letto gratuitamente da miliardi di lettori (sulla sua piattaforma di sorveglianza, fra un Ad "etico" e l'altro). Giacomo
Buongiorno Stefano, Stefano Zacchiroli <zack@upsilon.cc> writes:
On Wed, Oct 07, 2020 at 10:12:40PM +0200, J.C. DE MARTIN wrote:
Tom Krazit https://www.protocol.com/google-oracle-supreme-court-software-api
Ieri sono stato completamente ipnotizzato dall'ascolto dell'hearing della corte suprema americana con gli avvocati dei contendenti e del governo federale. Consiglio l'ascolto a tutti i legal/license geek che ci leggono:
https://www.c-span.org/video/?469263-1/google-v-oracle-america-oral-argument
Grazie della segnalazione ma siccome molti di noi non hanno tempo (o voglia) di "sbobinare" 1h e 37min di video, potresti sintetizzare la tua posizione in merito alla querelle? In molti, me compreso, si fidano del tuo giudizio in merito :-D Ovviamente questo invito è allargato ad altri giuristi in lista. Per come la sto capendo io grazie al lavoro dei wikipediani https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc., il caso è molto pompato visto il peso degli attori MA è talmente legato alla storia del DELIRIO legale di Java Standard Edition [1] (la versione PROPRIETARIA) che cercare di spaventare l'universo mondo di tutti i programmatori con la storia del «dopo di noi l'APIcalisse» mi sembra veramente capzioso. Che le API siano protette da copyright (ma non brevettabili, e ci mancherebbe) non ci sono più dubbi, tutto sta ora vedere se nel copiare (Google ha copiato, no?) pezzi di codice delle API Java nel software development kit (SDK) ha agito nel suo diritto di "fair use" o no. MA dire che in caso la corte stabilisse che la copia di quel codice non fosse fair use allora: --8<---------------cut here---------------start------------->8--- "In the short term, it will be a huge windfall to a small number of companies that have interfaces that a lot of people use," he said. "These interfaces will suddenly be new control points that people will be able to use to extract revenue from other companies for the right to use what was previously understood to be free." [...] But an Oracle victory could drag software development back into a world of silos, in which only the software built by a single vendor or across a consortium of powerful vendors would be able to enjoy the benefits of interoperability that have made the modern internet so compelling. Such a victory could create a new tax on software development, just as software becomes indispensable to the modern economy. --8<---------------cut here---------------end--------------->8--- (tratto da https://www.protocol.com/google-oracle-supreme-court-software-api) mi pare sparare grosso. Mi sbaglio io e ha ragione Tom Krazit? Non possiamo tranquillizzare i programmatori grandi o piccoli che seguono questa lista che possono dormire sonni tranquilli se non copiano codice proprietario (et. al, il mio non vuole essere un bigino di come rispettare le licenze software)? :-D Grazie! Giovanni. [...] [1] con tutta la BUROCRAZIA annessa e connessa per ottenere la "bolla papale" per validare una implementazione di Java -- Giovanni Biscuolo
On Fri, Oct 09, 2020 at 07:39:00PM +0200, Giovanni Biscuolo wrote:
Grazie della segnalazione ma siccome molti di noi non hanno tempo (o voglia) di "sbobinare" 1h e 37min di video, potresti sintetizzare la tua posizione in merito alla querelle?
Ritengo vera la parte della posizione di Google secondo la quale il mondo del software considera normale potere reimplementare in parte o in toto API esistenti senza correre rischi di violazione del copyright. A livello di risultato di policy (l'aspetto più rilevante per questa lista), un mondo nel quale ciò si può fare è il meglio possibile, perché massimizza sia l'interoperabilità che la re-implementabilità di sistemi esistenti dominanti (penso ad esempio ad rms che reimplementa le API degli UNIX proprietari negli anni '80). Quindi da questo punto di vista, si, una vittoria di Oracle sarebbe parecchio preoccupante per me. (Nota che non è proprio vero che lo stato giuridico della copyrightability delle API sia al momento assodato da giudizi precedenti. Da quel che mi dicono legulei americani il giudizio del 9th circuit su questa diatriba ha poco valore in quanto precedente legale, per motivi tecnico-legali che non saprei riportare fedelmente.) Detto questo, il fatto che le API non siano copyrightable o che siano copyrightable ma con fair use che permette di invocarle/reimplementarle, mi sembra tutto sommato un dettaglio. È certamente interessante esplorarlo da un punto di vista tecnico-legale per scavare sempre più nei confini del copyright. Ma dal punto di vista dei programmatori il risultato finale sarebbe equivalente. Confido quindi in almeno una delle due risposte positive.
Ovviamente questo invito è allargato ad altri giuristi in lista.
Hear, hear ! In particolare può essere interessante per questa lista discutere il potenziale impatto geopolitico di un giudizio di copyrightability forte delle API, senza fair use. (Quello che io considero il caso pessimo.) Perché a differenza degli USA, nel diritto EU il concetto di interoperabilità è importantissimo, quindi una tale decisione USA creerebbe una differenza legale molto significativa tra i due lati dell'oceano. Con potenziali ricadute su dove è più interessante impiantare specifiche divisioni IT. Ciao -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
On October 10, 2020 6:39:01 AM UTC, Stefano Zacchiroli <zack@upsilon.cc> wrote:
Ritengo vera la parte della posizione di Google secondo la quale il mondo del software considera normale potere reimplementare in parte o in toto API esistenti senza correre rischi di violazione del copyright.
Su questo il dibattito è stato interessante. Per esempio, come osservava il consulente dello stato (caspita se era preparato!), è piuttosto comune trovare Copyright statements su header e documentazione delle API, sia nel software libero che non. Francamente non ricordo UN caso in cui gli header di una libreria C (o di qualsiasi altro linguaggio) i cui header non contenessero un copyright statement. Il che mostra abbastanza chiaramente come l'affermazione di Google sia discutibile.
A livello di risultato di policy (l'aspetto più rilevante per questa lista), un mondo nel quale ciò si può fare è il meglio possibile, perché massimizza sia l'interoperabilità che la re-implementabilità di sistemi esistenti dominanti
Solo per player dominanti!
(penso ad esempio ad rms che reimplementa le API degli UNIX proprietari negli anni '80).
Splendido esempio! All'epoca il kernel Unix consisteva di meno di 20.000 righe di codice (v7, del 1979, se vuoi ti cerco il link ai sorgenti) e tutto il resto del sistema user space consisteva di meno di 200.000 righe, incluso compilatore C, shell, awk, diversi altri programmi e persino alcuni giochi. Il solo kernel Linux OGGI consiste di oltre 27 MILIONI di righe di codice. Un browser Web come Chrome è molto più grande. E tu paragoni RMS che reimplementa Unix negli anni 80 con Google che reimplementa Java 10 anni fa? Un mondo in cui ciò si può fare è un mondo dominato da pochi colossi che possono rubare idee di successo a piccoli gruppi di sviluppatori o ad aziende più piccole di loro.
Quindi da questo punto di vista, si, una vittoria di Oracle sarebbe parecchio preoccupante per me.
Posso rassicurarti su questo: nel mondo disegnato da una vittoria di Google, Microsoft non è in grado di reimplementare un browser Web ed è costretta ad adottare l'engine di Google!
In particolare può essere interessante per questa lista discutere il potenziale impatto geopolitico di un giudizio di copyrightability forte delle API, senza fair use.
Ragionevolmente, possiamo aspettarci un mondo con maggiore competizione sulle API. Ovvero un mondo con meno posizioni dominanti e più standard di interoperabilità aperti. Rimane il problema della complessità, spesso artificiale più che accidentale, che andrebbe tenuta sotto controllo per impedire che diventi una barriera (anche per la regolamentazione)
(Quello che io considero il caso pessimo.)
Per il momento, a me sembra ancora invece il caso ottimo. Sia per il software libero che per le nazioni che non controllano i GAFAM. Ovviamente uno di noi sbaglia. Detto questo credo che i giudici daranno ragione a Google per ovvie ragioni geopolitiche: Google usa Java (su Android) per controllare la telefonia mondiale. Gli Stati Uniti non rischierebbero mai di incrinare il suo potere.
Perché a differenza degli USA, nel diritto EU il concetto di interoperabilità è importantissimo, quindi una tale decisione USA creerebbe una differenza legale molto significativa tra i due lati dell'oceano. Con potenziali ricadute su dove è più interessante impiantare specifiche divisioni IT.
Difficilmente uno stato europeo potrebbe permettere ad un azienda USA di violare le leggi USA. Ma rimarrà UNA soluzione semplice per garantire interoperabilità e fingere di permettere la concorrenza: rilasciare esplicitamente le API con una licenza libera. Magari un copyleft molto forte. ;-) Dunque dormi sonni tranquilli. Se vince Oracle il software libero ne trarrà enorme vantaggio (e anche il marketing open source). Giacomo
Ciao Stefano, grazie per i tuoi commenti Stefano Zacchiroli <zack@upsilon.cc> writes: [...]
un mondo nel quale ciò si può fare è il meglio possibile, perché massimizza sia l'interoperabilità che la re-implementabilità di sistemi esistenti dominanti (penso ad esempio ad rms che reimplementa le API degli UNIX proprietari negli anni '80).
... o a Torvalds che scrive Linux negli anni '90 con tutto quello che ne è conseguito [...]
(Nota che non è proprio vero che lo stato giuridico della copyrightability delle API sia al momento assodato da giudizi precedenti. Da quel che mi dicono legulei americani il giudizio del 9th circuit su questa diatriba ha poco valore in quanto precedente legale, per motivi tecnico-legali che non saprei riportare fedelmente.)
Ok chiaro, questo non è secondario per me :-D
Detto questo, il fatto che le API non siano copyrightable o che siano copyrightable ma con fair use che permette di invocarle/reimplementarle, mi sembra tutto sommato un dettaglio.
Non a me, che la cosa rimanga nel limbo aumenta enormemente la possibilità di FUD; magari mi sbaglio.
È certamente interessante esplorarlo da un punto di vista tecnico-legale per scavare sempre più nei confini del copyright. Ma dal punto di vista dei programmatori il risultato finale sarebbe equivalente. Confido quindi in almeno una delle due risposte positive.
C'è una terza via... la famigerrima terza via :-)
Ovviamente questo invito è allargato ad altri giuristi in lista.
Hear, hear !
In particolare può essere interessante per questa lista discutere il potenziale impatto geopolitico di un giudizio di copyrightability forte delle API, senza fair use. (Quello che io considero il caso pessimo.) Perché a differenza degli USA, nel diritto EU il concetto di interoperabilità è importantissimo,
Ecco appunto: la terza via, ovvero saper dimostrare che si è fatta una reimplementazione delle API allo scopo di rendere il software interoperabile, usando se necessario anche il reverse engieering e AGGIRANDO i DRM - e *per questo fatto* poter stare al riparo da ogni sorta di minaccia; oggi non mi pare siamo in questa situazione, forse questo caso potrebbe persino peggiorare le cose ma non riesco a valutare di quanto... "a naso" di poco (in caso vincesse Oracle) [...] Saluti, Giovanni -- Giovanni Biscuolo
participants (4)
-
Giacomo Tesio -
Giovanni Biscuolo -
J.C. DE MARTIN -
Stefano Zacchiroli