di Andrea Monti – PC Professionale n. 102
Ottenere una tutela giuridica del software sempre più efficace è un’esigenza da qualche tempo in cima alle priorità degli operatori del settore che rivendicano una (giusta) protezione dalle varie forme di abuso che possono essere commesse a loro danno.
Attualmente l’utilizzo del software (inteso in senso ampio, a ricomprendere anche basi dati, siti web e via discorrendo) è regolamentato da due leggi fondamentali: quella sul diritto d’autore e quella recentemente introdotta in Italia con il recepimento di una direttiva dell’Unione Europea che estende la protezione per mezzo del diritto d’autore anche alle banche dati.
Tutto questo è il risultato di una scelta di politica legislativa che – a livello internazionale prima ancora che italiano – individuava nel diritto d’autore lo strumento migliore per proteggere i diritti degli sviluppatori.
Il risultato di questa scelta si è concretizzato nello stabilire per legge che l’oggetto della protezione dovesse essere la cosiddetta “forma espressiva” e non l’idea in quanto tale, escludendo poi addirittura la tutelabilità dell’interfaccia. In pratica, non posso impedire che il mio concorrente realizzi un sistema operativo a finestre e point and click, ma sono tutelato se il programma altrui utilizza del mio codice o se, tramite il reverse engineering, è stata riprodotta la mia creazione.
I limiti della legge sul diritto d’autore
E’ abbastanza chiaro – anche facendo riferimento alle applicazioni concrete della legge sul software – che il legislatore avesse in mente di proteggere più che altro gli applicativi di largo consumo (videogiochi, suite per l’ufficio, CAD), quelli cioè che meglio di altri si prestano ad essere oggetto di duplicazione abusiva a scopo di lucro.
Non bisogna tuttavia dimenticare che a fianco, anzi, al di sopra, di questo mercato ce n’è un altro che ruota attorno ad applicazioni non di uso comune, ma non per questo meno importante: quello del software per i grandi sistemi che gestiscono servizi (bancari o aereoportuali, per esempio) o attività produttive o di ricerca.
Si tratta, come è facile immaginare, di programmi altamente specializzati e frutto di costose fasi di ricerca e sviluppo che sicuramente non saranno oggetto di duplicazione “di massa” e che comunque afferiscono più alla sfera delle vere e proprie invenzioni che a quella delle opere letterarie.
In questi casi la tutela offerta dal diritto d’autore si rivela alquanto carente perchè il problema non è tanto la circolazione di copie abusivamente duplicate, quanto il reimpiego da parte di concorrenti o comunque di terze parti, di soluzioni tecniche inventate da una certo produttore.
Come funzionano i brevetti
Se si trattasse di invenzioni o di modelli di utilità “tangibili” il problema non si porrebbe, visto che per questo tipo di cose la legge prevede la possibilità di brevettare il “trovato” (così si chiamano nel linguaggio legale).
Quando si brevetta un’invenzione, chi lo fa ne è fino a prova contraria il “proprietario” (a differenza di quanto accade con il diritto d’autore, dove persino la registrazione presso la SIAE non ha alcun valore in questo senso).
Mentre chi è “autore” di un software può legalmente vietare il reverse engineering o mantenere segreti i sorgenti, con il brevetto accade il contrario: la condizione per ottenerlo è che tutte le specifiche tecniche siano assolutamente trasparenti e note, ma ogni utilizzo da parte di soggetti diversi dall’inventore è soggetto al pagamento di royalty.
Trattandosi di software invece, questo non è possibile visto che la legge sui brevetti esclude espressamente la brevettabilità dei programmi “in quanto tali.
Tutto questo però il linea di principio, perchè – come sempre – la realtà è molto più articolata e complessa.
Alcuni aspetti concreti
Innanzi tutto ci sono paesi, come gli Stati Uniti, che – avendo il copyright e non il diritto d’autore – consentono di brevettare il software oltre a sanzionarne contemporaneamente la duplicazione abusiva.
Poi ci sono “prassi” applicate da uffici pubblici di paesi che non consentono la brevettabilità del software i quanto tale, ma ammettono quella del software in quanto “componente” di un’invenzione industriale. E’ il caso dell’Ufficio Europeo dei brevetti, che ha cominciato ad aggirare in questo senso il divieto di brevettabililità dei programmi imposto dalla legge.
Stando così le cose non è affatto semplice sapere esattamente come sia possibile proteggere un software, visto che le variabili in gioco cominciano ad essere molte e – come vedremo – contraddittorie.
La posizione dell’Unione Europea
Per cercare di mettere ordine in tutto questo l’Unione Europea ha cominciato delle manovre esplorative che si sono concretata in un libro verde (http://www.andreamonti.net/patit.pdf) alla cui pagina 18 sono contenute le domande alle quali si dovrà dare una risposta:
· In materia di brevettabilità dei programmi per elaboratore e di invenzioni connesse al
software :
– le differenze esistenti attualmente nella giurisprudenza degli Stati membri sono tali da
creare ostacoli agli scambi o falsare le condizioni di concorrenza?
– le differenze esistenti tra l’Europa e i suoi principali partner economici sono tali da
creare difficoltà per le imprese europee?
– queste differenze sono tali da richiedere un’armonizzazione complementare a livello
comunitario in questo settore?
· In materia di brevettabilità dei programmi per elaboratore e di invenzioni connesse al
software, ritiene che si debba proporre, a lunga scadenza, l’abrogazione dell’articolo
52, paragrafo 2 della Convenzione di Monaco?
– In caso di risposta affermativa, come concepisce l’applicazione simultanea del diritto
d’autore e del diritto dei brevetti per la stessa creazione/invenzione?
– In caso di risposta negativa, ritiene tuttavia che sia necessario procedere ad una
modifica degli orientamenti per gli esaminatori dell’UEB su questo punto?
L’impatto dell’applicazione della normativa sui brevetti al software
Se da un lato la lettura del libro verde evidenzia chiaramente che l’Unione Europea si rende conto di maneggiare una materia estremamente volatile ed esplosiva – vedi, in questo senso, la consapevolezza di dover verificare le “compatibilità” di condivisione fra legge brevetti e legge sul diritto d’autore – dall’altro sembra che siano state trascurate alcune implicazioni molto delicate, specie per quanto riguarda i sistemi Opensource.
Quanto al primo problema (compatibilità fra brevetto e diritto d’autore), va detto che tale coesistenza non è certo indolore, perchè come abbiamo visto ci sono alcune previsioni normative in contrasto frontale. Ne consegue – ad esempio – che per un’azienda potrebbe non risultare vantaggioso brevettare un programma con funzioni innovative perchè nei (lunghi) tempi necessari ad ottenere la registrazione, qualcuno potrebbe “liberamente ispirarsi” all’idea e realizzare un oggetto che fa la stessa cosa ma con processi, linguaggi e soluzioni diverse “bruciando” il mercato di chi attende i tempi della burocrazia.
Se infatti in campo industriale la “libera ispirazione” non è così semplice da concretizzare (essendo necessari impianti produttivi, materie prime, laboratori per i test e quant’altro) parlando di software le cose sono molto differenti: bastano computer, tool di sviluppo e cervello… tutte risorse ampiamente disponibile nel mondo dell’IT.
Brevetti e OpenSource
Credo tuttavia che il problema fondamentale del brevettare il software stia nel rischio di paralizzare qualsiasi forma di innovazione e sviluppo indipendente, che inceve sono la linfa vitale di tutto il movimento Opensource. I modi per raggiungere questo poco desiderabile risultato sono veramente parecchi, dalla “brevettazione selvaggia” di qualsiasi funzionalità o standard tecnologico, alla creazione di veri e propri cartelli di produttori, al divieto esplicito di rilasciare “oggetti” software brevettati con licenza opensource.
Tanto per fare qualche esempio, ecco alcune funzionalità già brevettetate negli Stati Uniti (maggiori informazioni su http://www.base.com/software-patents/examples.html)
Il brevetto #5,121,492 protegge la tecnica di emulare la velocità di acesso ad un CD-Rom rallentando la velocità del disco rigido. Il brevetto #4,965,765 protegge l’uso di colori diversi nella scrittura dei programmi. Il brevetto #4,558,302 protegge il formato di compressione LZW (impiegato, se non ricordo male, nel formato grafico TIFF). Il brevetto #4,947,346 protegge la funzione del word-processor che rileva la pressione dei tasti e in base a questa segnala all’utente le nuove funzionalità presenti nel programma.
Come è facile immaginare l’elenco potrebbe continuare molto a lungo, ma questi pochi esempi sono già abbastanza indicativi su quali siano i temi in discussione, molto ben schematizzati nell’articolo di Bruce Perens pubblicato su Linux World (http://www.linuxworld.com/linuxworld/lw-1998-11/lw-11-thesource.html).
Questa situazione mi ricorda un quesito molto in voga nel settore della logica ricreativa: se un muro indistruttibile non può essere distrutto e un proiettile inarrestabile non può essere fermato, cosa succede quando un proiettile inarrestabile colpisce un muro indistruttibile?
Gli interessi contrapposti sembrano veramente essere inconciliabili. Da un lato non credo sia ragionevole nè giusto espropriare le aziende del software dei risultati spesso faticosamente raggiunti, ponendole in una condizione di minore tutela rispetto a chi produce tecnologia fisicamente tangibile. Dall’altro lato però è innegabile che il movimento Opensource (non solo nella componente Linux) ha dimostrato una vitalità e una abilità creativa in grado di rivaleggiare da pari a pari (quando non addirittura di superare) i colossi dell’IT e che non sarebbe giusto nè intelligente deprimere questo importante fenomeno. Specie – mettendosi nella logica delle aziende – per il notevole potenziale economico che sempre di più comincia ad essere associato al mondo del libero codice.
Per concludere, dunque, credo che da un punto di vista giuridica una soluzione compromissoria – come rileva lo stesso Parens – sia inevitabile e necessaria, ma sono fiducioso (e spero di non sbagliarmi) sul fatto che proprio le aziende capiscano l’importanza dell’Opensource e si adoperino per non farlo morire. Magari usando gli stessi strumenti che lo mettono a rischio, ad esempio concedendo licenze particolari per lo sviluppo di programmi freeware (nel senso di software liberi, non necessariamente gratuiti) e prendendo coscienza del ruolo di interesse pubblico che – più di altri – gli operatori dell’IT stanno assumendo.
In tutto questo c’è solo da sperare che nel frattempo non intervenga la solita legge guastafeste.
Possibly Related Posts:
- Chi ci protegge dal dossieraggio tecnologico?
- Webscraping e Dataset AI: se il fine è di interesse pubblico non c’è violazione di copyright
- Perché Apple ha ritirato la causa contro la società israeliana dietro lo spyware Pegasus?
- Le sanzioni UE ad Apple e Google aprono un altro fronte nella guerra contro Big Tech (e incrinano quello interno)
- Le accuse mosse a Pavel Durov mettono in discussione la permanenza in Europa di Big Tech