programmi per elaboratore – Lorenzo Albertini

Il problema della legittimità dell’uso dei training data per lo sviluppo dell’intelligenza artificiale

Il Trib. del Northern District della California 11 maggio 2023, Case 4:22-cv-06823-JST, Doe1 ed alktri c. Github e altri, decide (per ora) la lite promosa da titolari di software caricato sulla piattafoma Github (di MIcrosoft) contro la stessa e contro OpenAI per uso illegittimo dei loro software (in violazione di leggi e di clausole contrattuali).

La fattispecie -non è difficile pronostico- diverrà sempre più frequente.-

I fatti:

<<In June 2021, GitHub and OpenAI released Copilot, an AI-based program that can “assist software coders by providing or filling in blocks of code using AI.” Id. ¶ 8. In August 2021, OpenAI released Codex, an AI-based program “which converts natural language into code and is integrated into Copilot.” Id. ¶ 9. Codex is integrated into Copilot: “GitHub Copilot uses the OpenAI Codex to suggest code and entire functions in real-time, right from your editor.” Id. ¶ 47 (quoting GitHub website). GitHub users pay $10 per month or $100 per year for access to Copilot. Id. ¶ 8.
Codex and Copilot employ machine learning, “a subset of AI in which the behavior of the program is derived from studying a corpus of material called training data.” Id. ¶ 2. Using this data, “through a complex probabilistic process, [these programs] predict what the most likely solution to a given prompt a user would input is.” Id. ¶ 79. Codex and Copilot were trained on “billions of lines” of publicly available code, including code from public GitHub repositories. Id. ¶¶ 82-83.
Despite the fact that much of the code in public GitHub repositories is subject to open-source licenses which restrict its use, id. ¶ 20, Codex and Copilot “were not programmed to treat attribution, copyright notices, and license terms as legally essential,” id. ¶ 80. Copilot reproduces licensed code used in training data as output with missing or incorrect attribution, copyright notices, and license terms. Id. ¶¶ 56, 71, 74, 87-89. This violates the open-source licenses of “tens of thousands—possibly millions—of software developers.” Id. ¶ 140. Plaintiffs additionally allege that Defendants improperly used Plaintiffs’ “sensitive personal data” by incorporating the data into Copilot and therefore selling and exposing it to third parties. Id. ¶¶ 225-39>>.

MOlte sono le vioalazioni dedotte e per cio il caso è interessante. Alcune domande sono però al momento rigettate per insufficiente precisazione dell’allegaizone , ma con diritto di modifica.

La causa prosegue: vedremo

(notizia e link alla sentenza da Kieran McCarthy nel blog di Eric Goldman)

I passi di un protocollo tecnologico di comunicazione, necessitati in relazione all’obiettivo, non sono proteggibili col diritto di autore

la corte di appello del 3 cirCuito riforma una sentenza di primo grado che aveva accolto nua domanda per presunta illecita riproduizione di un codice di trasmissione tecnologica..

Si tratta di PYROTECHNICS MANAGEMENT, INC. v. *XFX PYROTECHNICS LLC; FIRETEK, 29.06,.2022, No. 21-1695.

Si trattava di tecnologia che regolava l’uso di fuochi di artificio e precisamente:

A Pennsylvania company, Pyrotechnics manufactures
and sells hardware and software that control fireworks displays
under the “FireOne” brand. fireTEK App. 71–72. The FireOne
system includes two main devices: a control panel and a field
module. The control panel accepts user input, creates digital
messages, and converts the digital messages to analog signals
that it sends to a field module over two wires. On receipt of the
analog signal, the field module decodes the message and
performs the assigned task—for example, the message may
instruct the field module to ignite a particular firework.
Sometimes the field module sends a response message to the
control panel. Since around 1995, Pyrotechnics’s control
panels and field modules have used a proprietary protocol to
communicate with each other. Pyrotechnics developed the
protocol to enable the FireOne system to precisely—and
safely—control complex fireworks displays, which can
involve tens or hundreds of field modules.

Il protocollo tecnologico per far comunicare il control panel e il field module (non è chiaro se fosse software in senso tecnico, parrebbe di no) era stato copiato tramite reverse engineering. Ma il protocollo stesso, secondo la corte di appello, era stato scritto solo in relazione al purpose o function (dialogo tra le due componenti della macchina) e cioè senza margini di libertà espressiva.

Passo centrale:

A work’s idea, we said, is its
“purpose or function.” Id. “[E]verything that is not necessary
to that purpose or function [is] part of the expression of the
idea. Where there are various means of achieving the desired
purpose, then the particular means chosen is not necessary to
the purpose; hence there is [protectable] expression, not idea.”
Id. (emphasis omitted) (citations omitted). We observed in
Whelan that, though perhaps “difficult to understand in the
abstract,” the rule becomes clearer in its application. Id. at 1248
n.28. That is true here.
The District Court identified the “purpose or function”
of the protocol as “to communicate between the FireOne
control panel and . . . field module.” Pyrotechnics Mgmt., 2021
WL 925812, at *9. But the Court also described the protocol’s
“idea” generically as “controlling pyrotechnics displays.” Id.
at *3–4, *10. The District Court’s disparate designations
conflict with Whelan: “the purpose or function of a utilitarian
work [is] the work’s idea.” 797 F.2d at 1236 (emphasis omitted
in part).
The District Court correctly identified the purpose and
function of the protocol. While the purpose of the FireOne
system—including the control panel and the field module,
together—is to control fireworks displays, the protocol enables
Pyrotechnics’s control panel and field module to communicate
with each other. This purpose is underscored by Pyrotechnics’s
repeated references to the “communication protocol” and the
“communication code.” See, e.g., fireTEK App. 64–65
(statements of Pyrotechnics’s counsel), 73–75 (statements of
Pyrotechnics’s President) (emphasis added). Under Whelan,
this communicative purpose is also the protocol’s idea.

E’ allora ovvio che in tale contesto fattuale una protezione non era concedibile, pena il cozzare con il § 102.B del tit. 17 US Code per cui <<In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work>>

Da noi non c’è regola generale così esplicita , ma l’esito sarebbe stato uguale.

Si v. però il cenno nella disciplina del software: << Restano esclusi dalla tutela accordata dalla presente legge le idee e i principi che stanno alla base di qualsiasi elemento di un programma, compresi quelli alla base delle sue interfacce. >>, ART. 2.8 L. AUT.; e l’art. 64 ter.3)

(notizia e link alla sentenza dal blog del prof. Eric Goldman)

Sentenza veneta in tema di tutela del software (sul concetto di diagramma di flusso)

Alcuni medici avevano consegnato a dei programmatori incaricati dalla ULSS delle idee scrtite sulla realizzazione di un software per le gestione e il monitoraggio dei pazienti affetti da dipendenze , per poi crearne una banca dati.

Avevano quindi agito per l’accertamento della titolarità propria, anzichè in capo alla ULSS, della privativa di autore.

In primo grado il Tribunale rigetta la domanda , osservando che <la documentazione dimessa non integrasse il c.d. “materiale preparatorio” del software successivamente sviluppato, oggetto di tutela ai sensi dell’art. 2 c.p.i., dovendo esso intendersi solo come quel materiale che consenta ad un programmatore di passare alla successiva fase di stesura del codice sorgente del programma. Precisava che tale definizione poteva essere attribuita solo a diagrammi di flusso o a blocchi completi, mentre il materiale fornito dagli attori, di cui i convenuti comunque avevano tempestivamente eccepito l’assenza di data e di sottoscrizione, non poteva essere qualificato come tale>.

Va però male pure l’appello, deciso da App. Venezia 07.06.2021, sent. 1665/2021, RG 636/2019, est. Micochero.

La corte veneziana infatti conferma con questo passaggio motivatrio: <<Nel caso di specie gli appellanti, nell’atto introduttivo del presente grado di giudizio, compiono un’opera di confronto grafico tra la documentazione dimessa e le interfacce del programma in questione. Tale documentazione viene corredata da una descrizione avente ad oggetto la paternità del documento, che non era stata compiuta in alcun modo nel corso del primo grado, per cui essa costituisce nuova allegazione, inammissibile nel presente grado di giudizio.

Anche prescindendo da tale descrizione e dalla effettiva paternità dei disegni e degli schemi (oggetto del secondo motivo di gravame), va comunque evidenziato che gli schemi e i disegni riprodotti non possono essere qualificati come materiale preparatorio della fase di progettazione, come asserito dagli appellanti. Va infatti evidenziato che il software “….” è il risultato di un progetto denominato “….” voluto dalla Regione Veneto con delibera n. ….seguendo le linee guida dell’Osservatorio Europeo sulle droghe e tossicodipendenze, e affidato, per il suo sviluppo, alla ULSS ……. per migliorare il trattamento dei pazienti affetti da tossicodipendenze e ottimizzare le attività assistenziali del …. Ai tre medici che lavoravano presso il Dipartimento per le dipendenze della suddetta ULSS fu dato l’incarico di seguire il progetto, ed, in particolare, al …., fu attribuita la qualifica di direttore tecnico scientifico e di coordinamento del progetto. Risulta quindi evidente che i tre medici abbiano posto in evidenza quale dovesse essere lo scopo e l’utilità del programma, indicando ai programmatori (……) quali dovevano essere le informazioni che lo stesso doveva fornire, giungendo anche a suggerire la veste grafica più idonea allo scopo.

Tuttavia detta attività ancora non integra il concetto di lavoro preparatorio di progettazione perché, come correttamente spiegato nei considerando sopra riportati [N.d.s.: cons. 7 e 11 della dir. Ue 24 del 2009] , in quanto esso già presuppone l’utilizzo di un linguaggio tecnico che permetta al programmatore di procedere immediatamente alla realizzazione successiva dei codici sorgente. Rientrano in detto ambito i “flowchart” – diagrammi di flusso – che già presuppongono una dimestichezza con il linguaggio informatico (algoritmi) e che permettono al programmatore di realizzare direttamente le stringhe nel linguaggio informatico, essendo diretti a creare una rappresentazione grafica delle operazioni da eseguire per l’esecuzione di un algoritmo. I documenti dimessi non sono, all’evidenza, diagrammi di flusso, ma costituiscono nient’altro che una spiegazione del risultato che si voleva attenere con il programma, una indicazione specifica ai programmatori su ciò che il programma doveva fornire all’utente. Ne consegue che essi non possono assurgere alla qualità di “lavori preparatori”, anche se riferibili ai tre medici>>.

Software, decompilazione e tutela d’autore in sede europea (dopo le conclusioni dell’A.G., arriva la C.G.)

E’ messa la parola fine alla lite intorno al diritto di intervenire sul software quando sia necessario per rimediare ad errori, <<anche quando la correzione consista nel disattivare una funzione che incide sul corretto funzionamento dell’applicazione di cui fa parte il programma stesso.>>

Dopo le conclusioni 10.03.21 dell’avvocato generale accennate in mio post, interviene la CG con sentenza 06.10.2021, C-13/20, Top System c. Stato belga.

La CG risponde positivamente al quesito del giudice belga: l’acquirente del software può decompilarlo quando necessario per rimediare ad errori e ciò anche si deve disattivarne un afunzione.

Interpretazione non molto difficile, peraltro: il concetto di <<correzione di errori>> (art. 5.1 dir. 1991 n. 250) porta tranquillamente a ciò.

Nè vi osta la disciplina sulla decompilazione ex art. 6 dir. cit., che si limita a regolarne un’ipotesi di liceità: non c’è alcun motivo per ritenerla l’unica (§§ 48-50). L’intepretazione complessiva degli artt. 5 e 6 lo conferma senza esitazione.

Ne segue che non ha alcuna base testuale nè logica pretendere per il caso di correzione degli errori i requisiti pretesi per la diversa ipotesi di decompilabilità ex citato art. 6.1 (§§ 68).

Tutto sommato decisione facile.

La CG accenna poi alla regolabilità contrattuale dell’evenienza di errori, § 66-67: non può portare all’esclusione totale del diritto di decompilazione. In altre parole questo è indisponibile, perchè posto da norma imperativa.

Infine sarà importante capire quando la decompilazione è realmente <necessaria> alla correzione.

Copyright, fair use e Application Programming Interfaces (APIs) alla Corte Suprema (fine della lite Oracle v. Google?)

La Suprema Corte (SC) ha deciso la causa Oracle v .Google reltiva al copiaggio della seconda dilinee di codice della prima proprie di Application Programming Interfaces (APIs) : Supreme Court No. 18–956, April 5, 2021, GOOGLE LLC v. ORACLE AMERICA, INC.

Molti i commenti : ad es. v. la sintesi di Bernardini-Borgogno in www.lavoce.info del 4 agosto 2021 e l’approfondito esame di Lemley-Samuelson, Interfaces and Interoperability After Google v. Oracle, Texas Law review, 2021, vol. 100/1 .

Ricordo poi il più approfondito lavoro di Lemley-Samuelson, Interfaces and Interoperability After Google v. Oracle, luglio 2021, per cui la SC ha errato nel non esaminare la questione della proteggibilità o meno delle Sun Java Application Program Interface (API), limitandosi a dar ragione a Google in base al fair use (per la ragine più liquida in sostanza; ). Meglio, più che <non esaminando>, si dovrebe dire <ipotizzandone la proteggibilità: “assume[d], but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted”. Metodo decisionale incomprensibile, dovendosi decidere via via le questioni secondo l’ordine logico, che prevede l’anteriorità di quella sulla proteggibilità rispetto a quella sulla difesa da fair use.

Per gli aa. invece la proteggibilità via copyright va negata.

Software e tutela d’autore in sede europea (le conclusioni dell’A.G.)

Nella causa C-13/20 si discute sulla tutelabilità del software tramite diritto di autore.

Un ente pubblico belga procede a decompilazione di un software creato per lui da una software house, pure belga. Quesrta contesta la legittimità della decompilaizone.

La lite è portata in sede europea sulla base della dir. 91/250 del 14.05.1991.

Sono state depositate il 10.03.2021 le conclusioni del bravo A.G. Szpunar in causa Top System SA c. Stato Belga .

Questioni sollevate dal giudice belga:

«1) Se l’articolo 5, paragrafo 1, della [direttiva 91/250] debba essere interpretato nel senso di consentire al legittimo acquirente di un programma per elaboratore di decompilarlo, in tutto o in parte, qualora tale decompilazione sia necessaria per consentirgli di correggere errori che incidono sul funzionamento di detto programma, anche quando la correzione consista nel disattivare una funzione che incide sul corretto funzionamento dell’applicazione di cui fa parte il programma stesso.

2) In caso di risposta affermativa, se egli debba soddisfare anche i requisiti di cui all’articolo 6 della [direttiva 91/250] o altri requisiti».

Sulla prima, così conclude l’AG: <<Propongo dunque di rispondere alla prima questione pregiudiziale dichiarando che l’articolo 5, paragrafo 1, della direttiva 91/250 dev’essere interpretato nel senso che consente al legittimo acquirente di un programma per elaboratore di procedere alla decompilazione di tale programma qualora sia necessaria per correggere errori che incidono sul suo funzionamento.>>, § 64.

Sulla seconda, così conclude: <<Propongo dunque di rispondere alla seconda questione pregiudiziale dichiarando che l’articolo 5, paragrafo 1, della direttiva 91/250 dev’essere interpretato nel senso che la decompilazione di un programma per elaboratore, in forza di tale disposizione, da parte del legittimo acquirente, per correggerne gli errori, non è subordinata ai requisiti di cui all’articolo 6 di tale direttiva. Una siffatta decompilazione può invece essere effettuata soltanto nella misura necessaria per tale correzione ed entro i limiti degli obblighi contrattuali dell’acquirente>>, § 89.

Esame analitico ed equilbirato: sono sempre interessanti le opinioni dell’AG Szpunar.