Tag: tutela del software

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>>.