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 Thu, 8 Oct 2020 08:53:58 +0200 "J.C. DE MARTIN" <demartin@polito.it> wrote:
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.
L'allarmismo che circonda questa sentenza mi è sempre sembrato sciocco. Se vince Google, tutto resta com'è. Verrà preservata la compatibilità con le API di chi ha maggiore potere commerciale: chi sovvenziona la diffusione delle API che controlla, chi influenza gli sviluppatori open source finanziando i loro eventi etc... Continueremo ad avere il cloud in mano a poche aziende statunitensi, protocolli complicati e centralizzanti, API legacy che fossilizzano design spesso affrettati dal rush to market etc... Insomma, la distopia che siete già abituati a razionalizzare. Se vince Oracle, qualcosa cambierà. Ma come?
If Oracle's argument is upheld, software developers fear chilling effects will descend upon their industry. A ruling in its favor could embolden older tech companies looking for growth to assert copyright over a wide swath of modern software, arguing that many of today's applications would not exist without their work.
Leaving the appeals court rulings in place would definitely rattle the open-source software community, which built the blueprint for a generation of collaborative enterprise software development. [...] "We're going to see a lot of software we would have seen written, not be written as a result of this," said Nell Shamrell-Harrington, a former senior staff research engineer at Mozilla who is active in open-source software communities. "[APIs] are the building blocks of the web."
Ci sono almeno cinque assunzioni false in questo FUD: 1) Che la compatibilità con standard (API, formati, protocolli) controllati da grandi aziende abbia giovato al software libero, invece di farne un surrogato a basso costo che spesso è funzionale alle strategie dei concorrenti (vedi Office vs OpenOffice, Firefox vs Chrome etc) La compatibilità piena è sempre una chimera, ma il controllo è reale. 2) Che le API esistenti, spesso prodotte da aziende in "rush to market" siano migliori di quelle che potrebbero essere create decenni dopo, alla luce delle esperienze pregresse 3) Che nuove API libere, definite da software sotto copyleft molto "virali", non possano costituire il punto di equilibrio fra gli interessi di aziende in competizione, a BENEFICIO del software libero e della società 4) Che tutti gli Stati continuino a lasciare il controllo della dimensione cibernetica in cui viviamo a pochi monopolisti globali (ma ben localizzati) e non decidano di creare essi stessi NUOVE API sotto copyleft molto "virali", imponendone il supporto attraverso la legge ed avviando una vera democratizzazione della realtà cibernetica 5) Che lo scombussolamento economico derivato dalla sentenza non permetta di rivedere la normativa sul copyright, progettata per garantile il controllo delle idee ad un monarca e dunque incompatibile con democrazie ove il popolo detenga la sovranità. Magari sbaglio eh... ma veder descrivere Google come campione della concorrenza... mi lascia un po' basito. E non dovrebbe! Dopo tutto, si chiama egemonia culturale. Giacomo PS
Kyle Mitchell, an attorney who advises companies on software licensing issues, compared methods for building APIs to the tips and tricks that craftspeople acquire as they gain experience in a certain trade, like carpentry. Those so-called "secrets" are open knowledge among veterans of that trade, but they require some skill or a patient mentor to acquire; yet, no one "owns" the knowledge required to frame a wall, for example.
Si tratta di una sciocchezza immane: Mitchell mente sapendo di mentire. Se così fosse, la creazione di un API sarebbe automatizzabile. Progettare un API, un protocollo o un formato è un lavoro profondamente creativo. Le possibilità sono pressocché infinite, ciascuna con tradeoff che sono spesso più culturali, economici e politici che tecnici. Si tratta di un lavoro persino più creativo che scrivere un programma, non solo per l'enorme varietà di possibilità (e dunque di decisioni), ma perché l'API può determinare, in modo più o meno preciso, non solo quali implementazioni sono possibili, ma quali usi saranno possibili e quali saranno più efficienti. Ed il grado di precisione è esso stesso una scelta arbitraria. Possiamo discutere se l'interoperabilità con chi ha maggiori mezzi economici per imporre la propria API sia più importante della protezione del profitto garantito da un monopolio artificiale progettato in epoca feudale per limitare il potenziale rivoluzionario della stampa. Ma sostenere che la progettazione di un API non sia un lavoro ESTREMAMENTE creativo è ridicolo.
participants (2)
-
Giacomo Tesio -
J.C. DE MARTIN