L’Articolo 52 della Convenzione sul Brevetto Europeo (EPC, European Patent Convention) esclude dalla brevettabilità i “programmi per elaboratori”, ma solo “in quanto tali” (as such). Tre parole su cui ruota l’intera disputa intorno alla direttiva europea sulla brevettabilità delle invenzioni implementate al computer, proposta dalla Commissione come COM(2002) 92 il 20 febbraio 2002.

Contesto

L’EPC, firmata a Monaco nel 1973 ed entrata in vigore nel 1977, elenca all’Articolo 52(2) una serie di oggetti che non sono considerati invenzioni: scoperte, teorie scientifiche, metodi matematici, presentazioni di informazioni e, appunto, i programmi per elaboratori. L’Articolo 52(3) aggiunge la qualifica che cambia tutto: l’esclusione vale per quegli oggetti “in quanto tali”.

L’Ufficio Europeo dei Brevetti (EPO, European Patent Office) ha svuotato quella qualifica un caso dopo l’altro. La decisione T 1173/97 (caso IBM/Computer program product, 1998) stabilisce che un programma può avere “carattere tecnico” quando produce un “effetto tecnico ulteriore” rispetto alle normali interazioni fisiche fra software e hardware. Su questa base l’EPO ha concesso decine di migliaia di brevetti su metodi implementati via software, anche se il testo dell’Articolo 52 sembra escluderli.

La COM(2002) 92 nasce dichiaratamente per “armonizzare” la situazione fra gli Stati membri. Resta da capire che cosa si armonizza: la prassi dell’EPO, oppure il testo restrittivo della convenzione.

Il testo e gli emendamenti

La proposta originale della Commissione mette nero su bianco quasi tutta la prassi dell’EPO. Definisce “invenzione implementata al computer” un’invenzione la cui esecuzione coinvolge un computer e che presenta, nella sua attuazione, una o più caratteristiche realizzate in tutto o in parte da un programma. Per la brevettabilità chiede un “contributo tecnico” (technical contribution), ma lascia la nozione di “tecnico” quasi del tutto indefinita, e finisce per rimetterla all’interpretazione dell’ufficio che i brevetti li concede.

Il 24 settembre 2003 il Parlamento Europeo vota in prima lettura e approva il testo con emendamenti pesanti: 364 voti a favore, 153 contrari, 33 astensioni. Gli emendamenti intervengono esattamente sui punti rimasti aperti:

  • Definiscono il “campo della tecnologia” in modo da escludere l’elaborazione di dati in quanto tale: il trattamento, la manipolazione e la presentazione di informazioni non sono di per sé un campo tecnico.
  • Introducono una clausola di interoperabilità: un brevetto non può impedire l’uso di tecniche brevettate quando serve a convertire le convenzioni adottate fra due sistemi o reti informatiche, perché la comunicazione e lo scambio di dati restino possibili.
  • Restringono il “contributo tecnico” pretendendo che appartenga a un campo tecnico in senso tradizionale: forze della natura controllate, non semplice logica eseguita su hardware generico.

Fra le due versioni la differenza pratica è enorme. Con la formulazione della Commissione un metodo di compressione dati o un protocollo di rete è brevettabile perché “produce un effetto tecnico”. Con quella del Parlamento lo stesso metodo ricade nell’esclusione dell’Articolo 52, perché l’elaborazione di dati non è un campo tecnico.

Il punto critico

Il software non si comporta come un’invenzione meccanica o chimica. Un algoritmo è una sequenza finita di passi logici; la sua “implementazione al computer” non aggiunge niente di fisicamente nuovo, perché qualunque computer general-purpose esegue qualunque algoritmo per costruzione. Dire che eseguire un algoritmo su un processore produce un “effetto tecnico ulteriore” fa dipendere la brevettabilità dal modo in cui la si descrive, più che da quello che si rivendica davvero.

Da qui nascono due problemi concreti per chi scrive codice.

Il primo è la sovrapposizione fra brevetti e diritto d’autore. Il software è già protetto dal copyright, che copre l’espressione, cioè il codice sorgente scritto. Un brevetto copre l’idea: il metodo, a prescindere dall’implementazione. Due programmi sviluppati in modo del tutto indipendente, senza che nessuno dei due autori abbia mai visto il codice dell’altro, possono violare lo stesso brevetto. Il copyright non fa mai questo, perché difende dalla copia, non dalla coincidenza.

Il secondo è l’impossibilità di verificare in anticipo. Per un brevetto industriale classico un’azienda può commissionare una ricerca di anteriorità (prior art) prima di mettere un prodotto sul mercato. Per il software i brevetti già concessi dall’EPO su metodi elementari — barre di avanzamento, doppio clic, ordinamento di liste, formati di compressione — sono così tanti che una ricerca esaustiva costa più di quanto possa permettersi chiunque non abbia un ufficio legale dedicato. Chi scrive software non può sapere prima quali brevetti sta violando.

Implicazioni per il software libero

Lo sviluppo open source poggia sulla composizione incrementale di codice riutilizzabile e sulla pubblicazione delle sorgenti. Entrambe lo espongono al rischio brevettuale, e lo espongono più di altri.

L’esposizione è strutturale, non accidentale. Un progetto con i sorgenti pubblici offre a chiunque il modo di controllare quali tecniche usa; un software proprietario, distribuito solo come binario, rende quell’analisi molto più costosa. E un’azienda commerciale che incorpora una libreria libera in un prodotto chiuso può difendersi con un proprio portafoglio brevettuale e con accordi di licenza incrociata (cross-licensing); un progetto di volontariato non ha brevetti da scambiare né i mezzi per negoziare licenze o reggere un contenzioso.

La Foundation for a Free Information Infrastructure (FFII), attiva sul tema dalla fine degli anni Novanta, raccoglie questi argomenti intorno alla petizione EuroLinux contro i brevetti software, che a oggi conta diverse centinaia di migliaia di firme fra sviluppatori, piccole e medie imprese, amministratori di sistema e ricercatori. Nei prossimi giorni a Bruxelles è in programma una conferenza pubblica sul tema. Anche noze aderisce alla campagna FFII, pubblicando sul proprio sito l’appello, la lettera aperta e la lista dei firmatari: https://www.noze.it/insights/campagna-brevetti-software/.

Limiti

Conviene dire con precisione che cosa la direttiva, in tutte e due le versioni, non fa. Non introduce da zero i brevetti software in Europa: l’EPO li concede già da anni in base alla propria prassi. La direttiva interviene su un sistema che esiste, e la posta è se quella prassi venga messa nero su bianco e resa vincolante per i tribunali nazionali, oppure ristretta.

Vale anche per la versione del Parlamento, che non è priva di ambiguità. Il “campo della tecnologia” è definito più per esclusione che per inclusione, e come si applichi davvero dipenderà comunque dall’interpretazione dei giudici. Una formulazione legislativa, per quanto attenta, non toglie lo spazio di discrezionalità di un esaminatore o di un giudice; lo sposta.

Infine il testo è ancora in lavorazione. Dopo la prima lettura del Parlamento il dossier è passato al Consiglio, che deve fissare la propria posizione comune prima del ritorno in seconda lettura. Quale delle due impostazioni prevarrà — quella che mette nero su bianco la prassi dell’EPO o quella che la circoscrive — oggi non è ancora deciso.

Immagine di copertina: Due attivisti seduti a un tavolo durante un incontro con la Commissione Europea, dicembre 2004 — foto di Björn Laczay, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Opponents_of_software_patents_meet_with_the_European_Commission.jpg