È legale clonare le funzionalità di un software?

Agli inizi di novembre 2021 gli sviluppatori di una defunta app fotografica, Phhhoto, hanno promosso una causa civile contro Meta (allora, Facebook) davanti all’Us District Court for the Eastern District of New York che potrebbe decretare la fine dell’industria del software. Benché l’azione giudiziaria riguardi un’accusa di concorrenza sleale, il giudice americano dovrà anche decidere se l’imitazione di una funzionalità sia legale o meno. di Andrea Monti – Originariamente pubblicato su Strategikon – un blog di Italian Tech.

Per capire l’impatto di una decisione del genere, basta pensare che se passasse questo principio, sarebbe stato impossibile per Microsoft creare Word, per Google sviluppare Chrome, o per Apple creare Final Cut dal momento che le funzionalità erano già disponibili in prodotti preesistenti.

Cosa sono le funzionalità software
Dal punto di vista tecnico, la funzionalità di un programma è il cosa fa a prescindere dal come lo fa. Dunque, per esempio, ogni client di posta ha la funzionalità per l’attach di file (liberamente replicabile), ma ciascuno la realizza scrivendo un codice differente (tutelato dalla legge).

È intuitivo che non è pensabile rivendicare, per esempio, l’esclusiva sulla funzionalità di salvataggio file o sostenere che nessuno programma dovrebbe contenere le funzionalità per l’applicazione di filtri di sfocatura alle immagini. Tanto è vero che sinora le questioni in materia di software hanno riguardato essenzialmente l’abuso di codice sorgente e non quello delle funzionalità che, in quanto tali, sono a un livello di astrattezza tale da non essere proteggibili legalmente.

Cosa è protetto dal copyright
In Italia l’articolo 2 comma I numero 8 della legge sul diritto d’autore esclude dalla tutela “le idee e i princìpi che stanno alla base di qualsiasi elemento di un programma” e l’articolo 45 del codice della Proprietà industriale (emanato su indicazione europea) esclude la proteggibilità dei metodi matematici (cioè degli algoritmi).

Perché è importante mantenere libere le funzionalità
Questi princìpi sono componenti essenziali dello sviluppo di software e hanno consentito la creazione di un ecosistema scientifico, industriale e commerciale nel quale anime diverse, come quelle proprietaria, libera oppure open source, hanno alimentato (a vario titolo) i grandi processi di innovazione tecnologica del nostro tempo. Rimetterli in discussione affermando che è illegale replicare funzionalità software significa paralizzare un intero comparto industriale e, soprattutto, pregiudicare irrimediabilmente i diritti dei cittadini che non potranno più avere libertà di scelta.

Precedenti storici
In realtà, il tentativo di imporre un limite alla replica delle funzionalità di un programma ha origini lontane. La vicenda di Phhhoto e quella di Business Competence (di cui si dirà fra qualche riga) ricordano da vicino la causa persa nel 1995 da Apple, che aveva accusato Microsoft di avere violato il copyright sulla funzionaltà Cestino, utilizzata per prima da Cupertino e replicata dalla casa di Redmond nel proprio sistema operativo.

La sentenza affermò chiaramente che “Apple non può invocare una tutela simile a quella brevettuale per l’idea di un’interfaccia grafica o per l’idea della metafora di un desktop”. Dunque, almeno fino a oggi, su entrambe le sponde dell’Atlantico la regola è (abbastanza) chiara. Ma la nuova causa civile azionata contro Meta potrebbe cambiare drasticamente lo scenario.

Il merito della causa Meta vs Phhhoto
Il merito della vicenda è semplice: gli sviluppatori di Phhhoto sostengono di essere stati costretti a chiudere l’azienda a causa di un atto di concorrenza sleale di Meta. Nello specifico, accusano Meta di avere copiato la funzionalità principale del loro software (una raffica di 4 foto per creare un effetto animazione) nell’ambito di una più estesa strategia anticompetitiva diretta a mettere fuori mercato soggetti che traevano vantaggio dall’interazione di Phhhoto con Instagram. Come scrivono a pagina 4 del complaint: prima Facebook avrebbe cercato di includere l’app all’interno di Messenger e poi, di fronte al rifiuto, avrebbe rilanciato proponendo di incorporare il software nel News Feed degli utenti e alla fine avrebbe interrotto le trattative. Dopodiché “Facebook and Instagram embarked on a scheme to crush Phhhoto and drive it out of business. Among other anticompetitive acts directed against Phhhoto, Instagram withdrew interoperability previously provided to Phhhoto, changed Instagram’s longstanding third party content attribution rules to Phhhoto’s detriment, and introduced—with the anticompetitive intent and effect of harming Phhhoto rather than otherwise benefiting Facebook or Instagram—a market clone that copied feature-by-feature the Phhhoto product.”

In altri termini, secondo la ricostruzione dei ricorrenti, quando Facebook ha realizzato di non poter ottenere il controllo su questa app avrebbe fatto in modo di bloccare l’interazione con Instagram, lanciando inoltre, contemporaneamente, un clone di Phhhoto, chiamato Boomerang. La conseguenza sarebbe stata che gli utenti di Instagram, migrando verso Boomerang, avrebbero smesso di usare Phhhoto causandone l’uscita dal mercato.

Business Competence vs Facebook: il precedente italiano
Se la storia di Phhhoto sembra familiare al lettore italiano è perché, nel 2018, il tribunale di Milano decise una causa per certi versi analoga che contrapponeva a Facebook una software house milanese, Business Competence. Analogamente alla vicenda di Phhhoto, Facebook aveva sviluppato un software che replicava le funzionalità e le logiche di funzionamento di quello creato in Italia e del quale il social network aveva avuto la disponibilità per una verifica tecnica preventiva. In questo modo, sostengono i suoi autori, il software italiano avrebbe perso la possibilità di fare utili appoggiandosi agli utenti del social network, oramai indirizzati verso il programma concorrente.

Similarità e differenze fra i due casi
Le similarità fra i due casi sono, come detto, evidenti. Tuttavia, la causa americana discute la clonazione delle funzionalità di un software in termini di concorrenza sleale, mentre quella italiana ha affrontato la controversia anche in termini di diritto d’autore, il che amplifica le potenziali conseguenze economiche e politiche di un determinato modo di applicare la legge.

Dal punto di vista generale le due vicende pongono due questioni: fino a che punto il proprietario di un software ha il diritto di bloccare l’interoperabilità con altri programmi, e se sia lecito creare un app che clona le funzionalità di un altro software preesistente allo scopo di assicurarsi un vantaggio competitivo. Non sappiamo ancora, ovviamente, come deciderà la corte americana, però possiamo trarre alcuni spunti analizzando la decisione di quella milanese che diede ragione alla software house italiana per quanto riguarda la tutela giuridica delle funzionalità software.

Le criticità della decisione milanese e i rischi della sentenza Usa
Secondo i giudici italiani è irrilevante l’accesso ai sorgenti per verificare il funzionamento di un software e il modo in cui interagisce con i dati, perché basta analizzarlo dall’esterno.

In termini di duplicazione abusiva di software o di creazione di opere derivate, questa affermazione non è molto sensata. Per capire se è stato copiato o imitato un programma è certamente necessario analizzarne i codici sorgenti. Se, tuttavia, l’obiettivo è verificare la replica di funzionalità, è evidente che non c’è bisogno di accedere ai codici sorgenti perché in un mondo popolato da interfacce grafiche ciò che conta è il design dell’interazione e non la serie di istruzioni che la rendono possibile. Ma le interfacce, il design dell’interazione e le funzionalità di un software non sono protette dalla legge sul diritto d’autore. Sembra dunque che la corte di Milano abbia confuso due ambiti molto diversi fra loro.

La differenza fra copiare (o rielaborare) un software e duplicarne le funzionalità
In termini generali si può certamente discutere del fatto che accedere ai sorgenti di un software altrui potrebbe costituire sia duplicazione abusiva sia un vantaggio concorrenziale, ma solo se i codici venissero pedissequamente copiati e riutilizzati a danno del titolare dei diritti (situazione molto diffusa, specie in relazione alle library). Al contrario, la semplice analisi delle funzionalità e la loro replicazione non può essere considerata una violazione del diritto d’autore e nemmeno, in realtà, un atto di concorrenza sleale, a meno che questo non accada copiando brutalmente pezzi di codice. Per capire la differenza, basta ricordare che la nascita di Unix BSD Net/1 e BSD Net/2 fu resa possibile dalla riscrittura da parte del Computer System Research Group dell’università di Berkely delle parti sulle quali AT&T deteneva i diritti. Le funzionalità erano le stesse, non il modo in cui erano scritte.

I rischi per l’ecosistema del software
Il caso Business Competence vs Facebook ha aperto un varco per far entrare nel terreno del copyright anche gli elementi essenziali dell’innovazione software che invece dovrebbero rimanere liberi e quello Phhhoto vs Meta rischia di allargarlo. È vero che si tratta di vicende giudiziarie decise da ordinamenti giuridici diversi e su questioni non integralmente sovrapponibili, ma da tempo le decisioni sulle cause high-tech vengono prese ispirandosi anche a quanto fanno i giudici di altri Paesi. Esiste dunque la concreta possibilità che si formi un’interpretazione trasversale sull’estensione della tutela del software fino a includere ambiti che, invece, non sono regolati e dovrebbero rimanere liberi.

Se confermato, l’effetto paradossale causato da questo orientamento è creare il presupposto per paralizzare qualsiasi progetto, magari open source, invocando una sorta di clonazione di funzionalità.

È un modo rapido ed efficiente per liberarsi della concorrenza, a condizione di potersi permettere di sostenere i costi legali, cosa che non è alla portata di tutti. Ma di qualcuno sì…

Possibly Related Posts: