ABUL

Software patents in Europe : what can happen next ?

François PELLEGRINI — 2006-05-24T17:05:50Z

Présentation réalisée le 15 septembre 2005 au Parlement Danois (Folketinget) dans le cadre
de la conférence intitulée Software patents in Europe
organisée par les associations Prosa et IT Politisk.

Analisi degli articoli della direttiva « brevetti software » vottata dal Consiglio

Antonella BECCARIA, François PELLEGRINI — 2005-05-12T14:10:24Z

Questo documento analizza, articolo per articolo, la versione della direttiva sulle « invenzioni ottenute attraverso elaboratori » proposta dai membri degli uffici dei brevetti che siedono presso il Coreper e votata dal Consiglio del 18 maggio 2004 [01]. Il documento illustra sotto quali aspetti questa direttiva differisce sostanzialmente da quella emendata e votata in prima lettura dal Parlamento europeo il 24 settembre 2003 [02].

Analisi degli articoli

Di seguito non si procederà che all'analisi degli articoli propriamente detti, avendo i considerati un'importanza minore. Si farà tuttavia riferimento ad essi in caso di incoerenze palesi con il contenuto degli articoli.

Per facilitare la comprensione delle differenze tra le due versioni, i punti cruciali sono stati evidenziati in grassetto.

Articolo 1

Versione del Consiglio

La presente direttiva stabilisce regole concernenti la brevettabilità delle invenzioni messe in opera attraverso elaboratore.

Analisi delal versione del Consiglio

Il termine « messe in opera attraverso elaboratore » è inappropriata e ingannevole. Nello spirito della maggioranza dei lettori, fa riferimento al fatto che una invenzione materiale possa essere pilotata da un elaboratore. Tuttavia, in questo caso, la presenza di un elaboratore non apporta nulla di significativo all'invenzione e l'invenzione stessa può essere a tutti gli effetti rivendicata in virtù dei testi esistenti, sia che si tratti di prodotto o di processo. È del resto il senso stesso dell'articolo 52.2 della Convenzione Europea del Brevetto secondo la quale, nel caso di un'invenzione che fa intervenire sia un elemento materiale che software, come un sistema di frenata ABS o una lavatrice avviata da un processo di lavaggio, l'invenzione nel suo insieme può essere rivendicata, ma il software che utilizza, in quanto tale, non può divenire l'oggetto di rivendicazioni perché il software non è brevettabile, ma sottoposto al regime del diritto d'autore.

Il senso nascosto di questo termine, avanzato dai rappresentanti degli uffici dei brevetti, è dunque che un'invenzione può essere integralmente « messa in funzione » da un elaboratore e dunque che questa « invenzione » è un programma. In questo ambito, l'oggetto della direttiva è di instaurare la brevettabilità del software.

Per un'analisi più approfondita del legame tra materiale e software e sul fatto che il software non può essere considerato come « tecnico » nel senso previsto dai brevetti, si veda [03] e [04].

Versione del Parlamento

Idem.

Analisi della versione del Parlamento

La versione del Parlamento è sfortunatamente identica a quella del Consiglio. Se la volontà di sottofondo era realmente di vietare la brevettabilità del software, sarebbe stato piuttosto necessario riformulare questo articolo parlando di invenzioni « controllate
dagli elaboratori » per illustrate efficacemente che l'invenzione, nel senso dei brevetti, non può risiedere nel software. Un emendamento parlamentare in questa direzione era stato depositato, ma non adottato. Infatti, se il testo avesse dovuto essere riscritto in modo coerente, sarebbe stato necessario ogni volta sostituire il termine « invenzione messa in opera da un eleboratore » con « invenzione controllata da un elaboratore ».

Articolo 2

Versione del Consiglio

a) "invenzione messa in opera da un elaboratore" indica ogni invenzione la cui esecuzione implica l'utilizzo di un elaboratore, di una rete informatica di o un altro apparecchio programmabile, presentando l'invenzione una o molteplici caratteristiche che sono realizzate totalmente o in parte da uno o molteplici programmi per elaboratore.

b) "contributo tecnico" indica un contributo allo stato dell'arte nell'ambito tecnico, che è nuovo e non evidente per una persona del mestiere. Il contributo tecnico è valutato prendendo in considerazione la differenza fra lo stato dell'arte e l'oggetto della rivendicazione del brevetti considerato nel suo insieme che deve comprendere caratteristiche tecniche, accompagnate o meno da caratteristiche non tecniche.

Analisi della versione del Consiglio

Questo articolo costituisce la prima breccia che permette effettivamente la brevettabilità assoluta dei brevetti e dei metodi commerciali.

L'Articolo 2.a stabilisce a tutta prima che la totalità delle caratteristiche di una invenzione possono essere realizzate da un programma per elaboratore, che legittima la brevettabilità software al di fuori di ogni contributo materiale innovativo.

Di seguito, l'Articolo 2.b dispone che, nel momento della valutazione del contributo tecnico, non si considerano solo le caratteristiche tecniche dell'invenzione, ma anche le caratteristiche non tecniche. Grazie a ciò, un nuovo programma eseguito su un banale elaboratore può realizzare un contributo tecnico perché la novità proviene dal software (non tecnico) e la tecnicità dall'uso di un elaboratore (non nuovo) mentre l'insieme è al tempo stesso nuovo e tecnico.

Versione del Parlamento

Ai fini della presente direttiva, le definizioni che seguono si applicano a :

a) "invenzione messa in funzione da un elaboratore" indica ogni invenzione ai sensi della Convenzione sui brevetti europei in cui l'esecuzione implica l'utilizzo di un elaboratore, di una rete informatica o di un altro apparecchio programmabile e che presenta, nella sua messa in opera, una o più caratteristiche non tecniche che sono realizzate totalmente o in parte da uno o più programmi per elaboratore, oltre a caratteristiche tecniche che ciascuna invenzione deve apportare ;

b) "contributo tecnico", chiamato anche "invenzione", indica un contributo allo stato della tecnica in un ambito tecnico. Il carattere tecnico del contributo è una delle quattro condizioni della brevettabilità. Inoltre, per meritare un brevetto, il contributo tecnico deve essere nuovo, non evidente e suscettibile di applicazione industriale. L'utilizzo delle forze della natura al fine di controllare gli effetti fisici al di là della rappresentazione numerica delle informazioni appartiene a un ambito tecnico. Il trattamento, la manipolazione e la rappresentazione di informazioni non appartengono a un ambito tecnico, anche se dispositivi tecnici sono utilizzati per effettuarli ;

c) "ambito tecnico" indica un ambito industriale di applicazione che richiede l'utilizzo di forze controllabili della natura per ottenere risultati prevedibili. "Tecnico" significa "appartenente a un ambito tecnico" ;

d) "industria", nel senso del diritto dei brevetti, significa "produzione automatizzata di beni materiali".

Analisi della versione del Parlamento

L'Articolo 2 del Parlamento Europeo, da parte sua, definisce precisamente i limiti della tecnicità per evitare che il software, i metodi commerciali e altri processi intellettuali possano essere resi brevettabili.

L'Articolo 2.a specifica che il software non può apparire che sotto forma di contributi non tecnici nelle rivendicazioni di brevetti e che, per essere promuovibile, un brevetto deve possedere almeno una caratteristica tecnica innovativa. Così, un nuovo sistema ABS che utilizza un elebaoratore è brevettabile perché questo sistema fornisce un contributo tecnico nuovo situato nell'ambito materiale. In questo caso, il fatto che un programma sia utilizzato da un sistema ABS fa parte delle rivendicazioni non tecniche e il programma, in quanto tale, non è dunque coperto dal brevetto, ma dal regime del diritto d'autore.

L'Articolo 2.b precisa che l'uso di ordinatori per mettere in opera processi di trattamento dei dati non può rendere questi ultimi brevettabili.

L'Articolo 2.c dà una definizione precisa della tecnicità nel senso dei brevetti, già presente nel diritto nordico e basata sul fatto che un'invenzione nel senso dei brevetti deve fornire una soluzione innovativa a un problema appartenente al mondo fisico. Ciò esclude di fatto i metodi commerciali, educativi e non solo dal campo della brevettabilità.

L'Articolo 2.d definisce l'ambito industriale nel quale si applica il brevetto al fine di evitare l'apparizione di brevetti nelle industrie come quella cinematrografica o musicale.

Articolo 3

Versione del Consiglio

Soppresso.

Analisi della versione del Consiglio

Questo articolo, il quale stabiliva inizialmente, nella versione della Commissione, che le « invenzioni messe in opera da un elaboratore » appartenevano a un ambito tecnico per natura ed erano dunque intrinsecamente brevettabili al di fuori di ogni altra considerazione, è stato soppresso sia dal Parlamento Europeo che dal Consiglio. Era in effetti tautologico poiché, facendo riferimento alla nozione di invenzione, ci si trova nell'ambito in cui la brevettabilità si applica.

Va tuttavia notato che il contenuto di questo articolo costituisce sempre l'apertura del Considerando 12, che è dunque inconsistente.

Versione del Parlamento

Ggli Stati membri vigilano affinché il trattamento dei dati non sia considerato ambito tecnico ai sensi del diritti dei brevetti e che le innovazioni in materia di trattamento dei dati non costituisca invenzione ai sensi dei diritto dei brevetti.

Analisi della versione del Parlamento

Il Parlamento ha votato un nuovo articolo 3 in cui specifica esplicitamente che i processi di trattamento dei dati non fanno parte del campo della brevettabilità. Questo articolo fa qualche dubbio impiego dell'Articolo 2.b del Parlamento: numerosi emendamenti equivalenti sono stati presentati da parlamentari differenti. Ciò si produce ad altri ambiti del testo parlamentare, ma non arreca disturbo.

Articolo 4

Versione del Consiglio

Per essere brevettabile, un'invenzione messa in opera da un elaboratore deve essere suscettibile di applicazione industriale, essere innovativa e implicare un'attività inventiva. Per implicare un'attività inventiva, un'invenzione messa in opera da un elaboratore deve apportare un contributo tecnico.

Analisi della versione del Consiglio

Non ci sarebbe niente da ridire su questo articolo se la nozione del contributo tecnico fosse definita in modo da escludere il software e i metodi commerciali. Si è visto nell'analisi dell'Articolo 2 che non era il caso.

Versione del Parlamento

1. Per essere brevettabile, un'invenzione messa in opera da un elaboratore deve essere suscettibile di applicazione industriale, essere innovativa e implicare un'attività inventiva. Per implicare un'attività inventiva, un'invensione messa in funzione da un ordinatore deve apportare un contributo tecnico.

Analisi della versione del Parlamento

La versione del Parlamento è identica a quella del Consiglio. Solo la numerazione cambia.

Articolo 4bis

Versione del Consiglio

1. (nuovo) Un programma per elaboratore in quanto tale non può costituire un'invenzione brevettabile.

2. Una invenzione messa in opera da un elaboratore non è considerata come apportatrice di un contributo tecnico semplicemente perché implica l'utilizzo di un elaboratore, di una rete o di un altro dispositivo programmabile. Di conseguenza, non sono brevettabili le invenzioni che consistono in programmi per elaboratore, siano essi espressi in codice sorgente, in binario o in altra forma, mettano in opera metodi per l'esercizio di attività economiche, metodi matematici e altri metodi, se quste invenzioni non producono effetti tecnici al di là delle interazioni fisiche normali fra un programma e un elaboratore, la rete o un altro dispositivo programmabile sul quale si esegue.

Analisi della versione del Consiglio

Questo articolo costituisce la seconda branca che permette la brevettabilità totale del software così come dei metodi commerciali.

L'Articolo 4bis.1 stabilisce che il software « in quanto tale » non è brevettabile. Tuttavia, nessuna definizione di « software in quanto tale » viene fornita e l'Articolo 4bis.2 torna a dire che tale software non esiste.

L'Articolo 4bis.2 costituisce un magnifico tentativo di creare confusione. Se ci sbarazza delle sue dubbie negazioni, si torna a dire che si possono effettivamente brevettare programmi che mettono in opera metodi commerciali, metodi matematici e altri metodi, a condizione che questi programmi producano un effetto « tecnico ». Ora, come detto nel testo della direttiva della Commissione [05, pagina 16], l'EPO considera il software fornitore di un effetto « tecnico » se si considerano motivazioni « tecniche » prima di scriverlo o se utilizza mezzi « tecnici » per la messa in opera.

Così, se il software serve a qualcosa e può esprimersi sotto forma di linguaggio tecnicistico, è consideranto come « tecnico » e dunque brevettabile, il software « in quanto tale » era, al contrario, software che non serve a niente e che non è economicamente utile brevettare.

Buoni esempi di brevetti su metodi commerciali effettivamente concessi dall'EPO si trova qui [06]. Il primo di questi brevetti, che porta alla nozione di commercio elettronico, è stato accettato senza problemi dall'EPO per via della definizione in termini tecnici [07] e tutti gli uffici brevetti sanno bene come fare andare a buon fine brevetti sui metodi commerciali [08].

Questo mostra chiaramente che, dal momento in cui si accetta l'idea che certi programmi possano essere brevettabili, allora non c'è alcun mezzo per impedire la brevettazione effettiva dei metodi commerciali, perché tutti questi metodi sono infatti algoritmi che possono essere descritti dalle risorse che mobilitano e il modo in cui li utilizzano. È impossibile effettuare una qualunque distinzione fra software « tecnico » e « non tecnico » [04] e il modo modo di impedire la brevettabilità dei metodi commerciali consiste nell'interdire totalmente la brevettabilità del software.

Versione del Parlamento (seguito dell'Articolo 4)

Articolo 4

[...]

2. Gli Stati membri vegliano affinché il fatto che una invenzione messa in opera da un elaboratore che apporta un contributo tecnico costituisce una condizione necessaria all'esistenza di un'attività inventiva.

3. Il carattere preminenti del contributo tecnico è valutabile prendendo in considerazione la differenza fra l'insieme delle caratteristiche tecniche della rivendicazione di brevetto e lo stato della tecnica, indipendentemente dal fatto che queste caratteristiche siano accompagnate o meno da caratteristiche non tecniche.

4. Per determinare se una invenzione messa in opera da un elaboratore apporta un contributo tecnico, si deve stabilire se apporta una conoscenza innovativa sulle relazioni di causalità per quanto riguarda l'utilizzo delle forze controllabili della natura e se ha un'applicazione industriale in senso stretto sia dal punto di vista del metodo che del risultato.

Analisi della versione del Parlamento

La versione del Parlamento riafferma la necessità di un contributo tecnico nell'ambito fisico che abbia un'applicazione industriale manifesta, per poter brevettare un'invenzione controllata da un elaboratore.

In particolare, a differenza della versione del Consiglio, l'Articolo 4.3 stabilisce che l'evoluzione della novità dell'invenzione non deve aversi che in rapporto alle sole caratteristiche tecniche dell'invenzione, che da sole legittimano il rilascio del brevetto.

Va rimarcato che i termini dell'Articolo 4bis.2 del Consiglio sono ripresi nell'Articolo 5 della versione del Parlamento. Ciò va considerato come retaggio del testo della Commissione, che non ha infatti importanza poiché il testo del Parlamento definisce in modo preciso la nozione di tecnicità.

Articolo 5

Versione del Consiglio

1. Gli Stati membri vigilano a che un'invenzione messa in opera da un ordinatore possa essere rivendicata in quanto prodotto. In altre parole, ci si riferisce a un elaboratore programmato, una rete informatica programmata o un altro dispositivo programmato o un procedimento realizzato da un determinato elaboratore, rete informatica o altro dispositivo attraverso l'esecuzione di un software.

2. Una rivendiazione per un programma informatico, solo o su supporto, non è autorizzata se questo programma, al momento in cui viene caricato e eseguito dall'elaboratore, una rete informatica o un altro dispositivo programmabile, mette in opera un prodotto o un procedimento rivendicato nella domanda stessa di brevetto, conformemente al paragrafo 1.

Analisi della versione del Consiglio

L'Articolo 5.1 reitera la possibilità di brevettare il software permettendo la brevettazione di processi realizzati da un elaboratore. Non si tratta qui di un processo fisico controllato da un elaboratore, ma del fatto che il programma informatico propriamente detto (in inglese, questa confusione è rinforzata dall'utilizzo del vocabolo « process » per riferirsi contemporaneamente a un processo industriale brevettabile, ma anche all'esecuzione di un processo informatico).

L'Articolo 5.2 constituisce la terza breccia. Qui ancora, se ci si sbarazza di negazioni dubbie, sembra che si possa rivendicare un programma su ogni supporto dal momento in cui questo programma è stato rivendicato in quanto processo, cosa giustamente permessa dall'Articolo 4bis. Questo articolo garantisce la brevettabilità assoluta del software e nega l'esistenza di cosiddetto software « in quanto tale » censito come non brevettabile.

Sottolineiamo come questo articolo costituisce una minaccia estremamente grave alla diffusione della conoscenza. Dal momento in cui esiste un brevetto sul commercio elettronico, per esempio, ogni pubblicazione in un libro o su un periodo del programma che consenta questo tipo di attività è legalmente attaccabile. Va certamente compreso anche il codice sorgente, che può essere eseguito direttamente su un elaboratore attraverso un compilatore. Altro esempio eloquente : ogni persona che possieda a casa propria un programma che avvia una « barra di progressione » (EP 394160) [09] (barra che serve a far attendere l'utente) è soggetto a un attacco dal detentore del brevetto.

Versione del Parlamento (Articolo 7)

Articolo 7

1. Gli Stati membri vegliano affinché un'invenzione messa in opera da un elaboratore non possa essere rivendicata che in quanto prodotto, cioè in quanto dispositivo programmato o procedimento tecnico di produzione.

2. Gli Stati membri vegliano affinché le rivendicazioni di brevetto riconosciute sulle invenzioni messe in opera da un elaboratore coprano unicamente il contributo tecnico su cui si fonda una rivendicazione. Una rivendicazione di brevetto di un programma informatico, che sia sul solo programma o su un programma registrato su un supporto di dati, non è accoglibile.

3. Gli Stati membri vegliano affinché la produzione, la manipolazione, il trattamento, la distribuzione e la pubblicazione dell'informazione, sotto qualunque forma, non possa mai costituire una contraffazione di brevetto, diretta o indiretta, anche quando è utilizzato un dispositivo tecnico.

4. Gli Stati membri vegliano affinché l'utilizzo di un programma informatico a fini che non rivelano l'oggetto del brevetto non possono costituire una contraffazione di brevetto, diretta o indiretta.

5. Gli Stati membri vegliano affinché, quando una rivendicazione di brevetto menziona caratteristiche che implicano l'utilizzo di un programma informatico, una messa in opera di riferimento, operativo e ben documentato, di questo programma sia pubblicata in quanto parte della descrizione, senza condizioni di licenza restrittive.

Analisi della versione del Parlamento

Gli Articoli 7.1 e 7.2 della versione del Parlamento stabiliscono esplicitamente che un programma non può costituire l'oggetto di una rivendicazione di brevetto, non potendo comprendere prodotti materiali o processi industriali (e non processi informatici).

L'Articolo 7.3 della versione del Parlamento dispone che i metodi di trattamento dell'informazione (che sono infatti descrizioni algoritmiche di metodi matematici, analoghe per natura alla descrizione di metodi commerciali) non possono essere brevettabili.

L'Articolo 7.4 della versione del Parlamento dice che mai un brevetto su un'invenzione controllata da un ordinatore può permettere di monopolizzare l'uso di algoritmi che il programma di controllo mette in opera.

L'Articolo 7.5 della versione del Parlamento ricorda l'obbligo di persistenza e di diffusione del sapere inerente al sistema dei brevetti.

Articolo 6

Versione del Consiglio

I diritti conferiti da un brevetto deliberato per un'invenzione rilevante del campo di applicazione della presente direttiva non comprendono gli atti autorizzati in virtù degli articoli 5 e 6 della direttiva 91/250/CEE sulla protezione giuridica dei programmi informatici attraverso il diritto d'autore e particolarmente le disposizioni relative alla decompilazione e all'interoperabilità.

Analisi della versione del Consiglio

Questo articolo non è adatto a garantire l'interoperabilità. La possibilità di retro-ingegneria funziona nel caso del diritto d'autore, perché un programma in fieri che interagisca con un programma esistente, per esempio creando file di un formato riconosciuto da questo programma, ha il diritto di esaminare il suo funzionamento e può servirsi dell'informazione ottenuta per scrivere proprie routine di creazione dei file, che sono un'opera originale ai sensi del diritto d'autore e non costituiscono una copia servile del programma iniziale.

D'altro canto, se un formato è brevettato, come per esempio un formato di testo [10], ogni programmatore che desidera realizzare un programma che scrive tali file, se ha il diritto di analizzare il procedimento di creazione dei file, non può commercializzare il suo programma, perché ciò costituirebbe una contraffazione di brevetto che contiene algoritmi per la creazione di istanze di un formato brevettato.

Questo articolo dunque non impedisce affatto la costituzione di utenti prigionieri, obbligati a continuare a usare sistemi informatici dello stesso fornitore perché non si permette a programmi concorrenti di importare legalmente i formati di dati detenuti dal monopolio.

Versione del Parlamento (Articoli 8 e 9)

Articolo 8

I diritti conferiti dai brevetti innovativi deliberati nel quadro della presente direttiva non attaccano gli atti permessi in virtù degli articoli 5 e 6 della direttiva 91/250/CEE, con particolare riferimento alla decompilazione e all'interoperabilità.

Articolo 9

Gli Stati membri vigiliano affinché, quando il ricorso a una tecnica brevettata è necessaria a un fine signiticativo, per esempio assicurare la conversione di convenzioni utilizzate in due sistemi informatici o da reti differenti, in modo da permettere la comunicazione e lo scambio di dati, questo ricorso non sia considerato come una contraffazione di brevetto.

Analisi della versione del Parlamento

La versione proposta dal Parlamento, più della versione proposta al Consiglio dal Lussemburgo, permetterebbe effettivamente di garantire l'interoperabilità definendo una eccezione limitata ai diritti dei brevetti, come autorizzato dall'Articolo 30 dell'ADPIC [11, pagina 5].

Se la direttiva impedisse realmente la brevettabilità del software, questo tipo di articolo non sarebbe necessario per i brevetti europei, ma sarebbe comunque necessario per assicurare in Europa la possibilità di interoperabilità con i brevetti statunitensi.

Articolo 7

Versione del Consiglio

La Commissione sorveglia l'incidenza delle invenzioni messe in opera da un elaboratore sull'innovazione e la concorrenza in Europa e nel mondo intero, così come le imprese europee, in particolare le piccole e medie imprese e la comunità del software libero, e fa altrettanto con il commercio elettronico.

Analisi della versione del Consiglio

Di fronte ai trucchi pro-brevetti già espressi dal Consiglio, ritardi indotti dalla mole di informazione necessaria a un tale seguito, a ai tempi di reazione supplementare necessaria a ogni aggiustamento, questo articolo non ha effetto. Sarebbe meglio prevenire che tentare di curare anni dopo che il male si è manifestato.

Articolo 8

Versione del Consiglio

La Commissione presenta al Parlamento europeo e al Consiglio, per i [tre anni a contare dalla data indicata all'articolo 9, paragrafo 1] al più tardi, un rapporto che indica :

a) l'incidenza dei brevetti deliberati per invenzioni messe in opera da un elaboratore sugli elementi menzionati all'articolo 7;

b) se le regole che impostano la durata della validità e la determinazione dei criteri di brevettabilità per ciò che concerne più precisamente l'innovazione, l'attività inventiva e la portata delle rivendicazione sono adeguate e se sarà opportuno e giuridicamente possibile, tenuto conto degli obblighi internazionali della Comunità, di portare modifiche a queste regole;

c) se sono comparse difficoltà negli Stati membri in cui gli aspetti di innovazione e di attività inventiva delle invenzione non sono esaminate prima del rilascio di un brevetto e se possono essere prese misure, dato il caso, per rimediare;

c bis) se sono comparse difficoltà nella relazione tra la protezione attraverso il brevetto delle invenzioni messe in opera da un elaboratore e la protezione di programmi informatici attraverso il diritto d'autore, prevista dalla direttiva 91/250/CEE e se si sono verificati abusi del sistema dei brevetti in rapporto con le invenzioni messe in opera da un elaboratore;

c ter) il modo in cui le esigenze dalla presente direttiva sono state prese in considerazione nella pratica dell'Ufficio europeo dei brevetti e nelle sue linee direttive in materia di esame;

c quater) a quale riguardo potrebbe essere necessario preparare una conferenza diplomatica per rivedere la Convenzione sul brevetto europeo;

c quinquies) l'incidenza dei brevetti conferiti per le invenzioni messe in opera da un elaboratore sullo sviluppo e la commercializzazione di programmi e di sistemi informatici interoperanti;

c) se sono comparse difficoltà negli Stati membri in cui gli aspetti di novità e di attività inventiva delle invenzioni non sono stati esaminati prima della concessione di un brevetto e se devono essere prese misure, dato il caso, per rimediare;

[...]

Analisi della versione del Consiglio

Tutto ciò costituisce una lista di pii desideri che non potranno da soli correggere una situazione che provocherà uno svantaggio all'Europa. Per esempio, se, a causa di falle aperte nella direttiva, le società statunitensi avessero la possibilità di « fare affari » in Europa e di riacquistare o provocare perdite alle imprese europee concorrenti [12] a forte potenziale innovante, è difficile credere che un riesame della direttiva potrebbe restaurare ciò che è andato perduto. Il caso di Gemplus mostra che la guerra economica per il controllo dei mezzi di accesso all'informazione esiste e che non è utile a fornire agli avversari mezzi supplementari di dominio.

Qualcosa di più lo si trova in paragrafi che, potenzialmente, sono cavalli di Troia, come il b) e il c). Il Paragrafo b) potrebbe autorizzare la Commissione, sulla base delle pratiche degli Stati Uniti e di un'interpretazione estremista degli accordi ADPIC, a togliere ogni restrizione sulla tecnicità aprendo così la strada alla brevettabilità assoluta. Analogamente, il Parafrago c) potrebbe autorizzare la Commissione a chiedere una revisione della Convenzione Europea sul Brevetto per sopprimere l'Articolo 52.2 secondo cui il software non è brevettabile, vecchio sogno dei sostenitori dei brevetti e che sembra sempre nella loro agenda.

Sintesi

Versione del Consiglio contro versione del Parlamento

Contrariamente a ciò che si è sempre preteso, il testo sottoposto al Consiglio [01] dai rappresentanti degli uffici brevetti che siedono al Coreper non è assolutamente un testo di compromesso, come ha dovuto riconoscere davanti al Parlamento olandese il Segretario di Stato van Gennip [13]. La signora van Gennip, al termine del dibattito parlamentare, ha dovuto riconoscere anche che la direttiva mirerebbe a legalizzare la pratica attuale dell'EPO, il quale concede già brevetti puramente software e ad autorizzare la brevettazione degli algoritmi utilizzati nell'ambito dei metodi commerciali (come il "shopping cart" che cita a titolo di esempio).

Indipendentemente dal numero di emendamenti parlamentari ripresi o meno, che non ha alcun significato, è importante vedere in che cosa la versione del Consiglio differisce da quella del Parlamento. Gli emendamenti parlamentari soppressi nella versione del Consiglio comprendono :

la definizione positiva della tecnicità che fa riferimento, per esempio, a un insegnamento innovativo sull'utilizzo di forze controllabili della natura, è la sola capace di limitare la brevettabilità al mondo fisico e di impedire la brevettazione del software così come dei metodi commerciali, educativi e matematici applicati ;
l'esame dei soli contributi tecnici (cioè fisici, nel senso della defizione qui riportata) delle rivendicazioni dei brevetti per l'analisi dell'attività inventiva ;
l'impedimento a rivendicazioni di programmi sui loro supporti, che altrimenti costituirebbe un grave pericolo per la trasmissione della conoscenza ;
una vera garanzia per l'interoperabilità poiché i testi della Commissione e del Consiglio non autorizzano la diffusione del software interoperante che implementa protocolli brevettati e non possono dunque impedire il monopolio dei protocolli di comunicazione dei formati di file.

Così, nella forma votata dal Consiglio, la direttiva permetterebbe effettivamente la brevettabilità del software e non offrirebbe alcun limite. Per convincersene, è sufficiente vedere che la "barra di progressione" [09] resta sempre brevettabile. Ecco come procedere per quello :

in mancanza di una definizione non tautologica della tecnica e considerando la pratica attuale dell'EPO, la barra di progressione ha un effetto « tecnico ». Infatti, grazie ad essa, un utente può sapere quando il suo programma avrà finito di elaborare e può dunque decidere di fare qualcos'altro nell'intervallo invece di attendere, guadagnandi così in produttività e diminuendo il suo stress di attesa. Questo è un effetto differente dalle semplici interazioni normali tra il programma e l'elaboratore, nell'ambito industriale, e può dunque essere considerato come un effetto tecnico. Si vedano per convincersene alcune edificanti citazioni collezionate qui [14] ;
è dunque possibile scrivere una rivendicazione di brevetto facendo intervenire l'esecuzione di una barra di progressione sul computer. Non si tratta di un programma « in quanto tale » poiché si è dimostrato un effetto tecnico ;
si può allora brevettare un programma che metta in opera una barra di progressione, poiché questo programma, una volta caricato su un elaboratore, esegue il processo brevettato.

Se i « programmi in quanto tali » sembrano campo esclusivo della brevettabilità, di tali programmi non ne esistono semplicemente. Ciò che dice giustamente la direttiva è che è brevettabile un programma dal momento in cui lo si esegue per produrre un effetto utile, la ragione per la quale si scrivono programmi.

Il tentativo di voler stabilire un discrimine tra software « tecnico » e software « non-tecnico » non può dunque che essere volto al fallimento [04]. Quindi, se i brevetti sul software fosse legalizzati, tutti gli algoritmi, ivi compresa l'implementazione di metodi commerciali, sarebbero brevettabili. È sufficiente per convincersene constatare il funzionamento attuale dell'EPO dove, a dispetto del criterio di tecnicità, sono stati effettivamente concessi brevetti come quello sul sistema informatico di distribuzione di ricette di cucina nei supermercati destinati a far aumentare le vendite di ingredienti (EP 756731) [15] o sulla valutazione degli studenti (EP 664041) [16].

Definizione della tecnicità e controllo parlamentare dell'EPO

La definizione della tecnicità costituisce l'interesse principale del testo così come il mezzo per la politica di controllare l'Ufficio europei dei brevetti. È per questo che l'EPO rifiuta con grande asprezza ogni definizione esplicita di tecnicità in un testo legislativo che obbligherebbe l'EPO a chiedere una modifica del suo testo e dunque sollecitare un dibattito pubblico sul bene su cui si fonda il suo approccio, ogni volta che desiderasse allargare il suo perimetro di azione.

Brevetti sul software e Diritto Francese

L'irruzione dei brevetti sul software pone anche una questione relativa al Diritto Francese. L'articolo 4 della LCEN (legge n. 2004-575 per la fiducia nell'economia digitale) [17] dispone : « si intende, attraverso standard aperti, ogni protocollo di comunicazione, di interconnessione o di scambio e ogni formato di dati interoperante e le cui specifiche tecniche sono pubbliche e senza restrizioni d'accesso né di messa in opera ». La possibilità di brevettare i mezzi di accesso ai dati della collettività attraverso la brevettazione dei formati di file e dei protocolli di comunicazione [18] è dunque in contraddizione con gli obiettivi dello Stato di fornire un servizio basato sui protocolli e sugli standard aperti, alla base del software libero, come ha annunciato M. Dutreil, Ministro della Funzione Pubblica [19].

Riferimenti

[01]: http://register.consilium.eu.int/pdf/fr/04/st09/st09713.fr04.pdf
[02]: http://www2.europarl.eu.int/omk/sipade2?PUBREF=-//EP//TEXT+TA+P5-TA-2003-0402+0+DOC+XML+V0//FR&LEVEL=3&NAV=X#BKMD-
[03]: http://www.abul.org/brevets/articles/parlement_20030924.php3
[04]: http://www.abul.org/article190.html
[05]: http://europa.eu.int/comm/internal_market/en/indprop/comp/com02-92fr.pdf
[06]: http://webshop.ffii.org/
[07]: http://l2.espacenet.com/espacenet/viewer?PN=EP0803105&CY=gb&LG=en&DB=EPD
[08]: http://www.iusmentis.com/patents/businessmethods/epc/
[09]: http://l2.espacenet.com/dips/viewer?PN=EP394160&CY=fr&LG=fr&DB=EPD
[10]: http://www.microsoft.com/mscorp/ip/format/xmlpatentlicense.asp
[11]: http://gibuskro.lautre.net/informatology/ffii/trips.html
[12]: http://swpat.ffii.org/brevets/effets/openmint/swxai-openmint.fr.pdf
[13]: http://kwiki.ffii.org/?NlparlDetal040603En
[14]: http://swpat.ffii.org/papers/eubsa-swpat0202/tech/
[15]: http://l2.espacenet.com/dips/viewer?PN=EP756731&CY=fr&LG=fr&DB=EPD
[16]: http://l2.espacenet.com/dips/viewer?PN=EP664041&CY=fr&LG=fr&DB=EPD
[17]: http://www.legifrance.gouv.fr/WAspad/RechercheSimpleLegi.jsp
[18]: http://swpat.ffii.org/patents/effects/cifs/index.en.html
[19]: http://www.reuters.fr/locales/c_newsArticle.jsp?type=topNews&localeKey=fr_FR&storyID=5456227

La riproduzione completa e la distribuzione integrale di questo articolo sono permesse con qualsiasi mezzo a condizione che questa nota e le menzioni di copyright siano preservate.

Giochi strategici per il controllo dell'innovazione immateriale e software

Antonella BECCARIA, François PELLEGRINI — 2004-07-23T16:03:04Z

Introduzione

La recente battaglia al Parlamento Europeo sulla brevettabilità del software è un fenomeno che si inquadra al di sopra un conflitto più ampio in cui i giochi economici e strategici sono considerevoli. Essi infatti si situano al livello della perpetuazione delle culture e dell'accesso al sapere andando dunque al di là anche delle rivalità industriali.

Per limitare ragionevolmente la lunghezza di questa nota, si discuterà di alcuni degli aspetti strategici per l'Europa derivanti dalla privatizzazione dei beni informativi. Scopo del documento è di illustrare come sia importante seguire le raccomandazioni del Parlamento Europeo in materia di (non)brevettabilità del software e soprattutto come sia vitale questo orientamento nel quadro di una riflessione strategica coerente e portata avanti nel tempo.

Il lettore interessato a una descrizione generale della brevettabilità del software è invitato a riferirsi a [1] e, per gli argomenti puramente economici che giustificano il rifiuto della brevettabilità, a [2].

I brevetti sul software, un'aberrazione economica

Innanzitutto, come hanno dimostrato numerosi studi economici condotti sul campo [3, 4], un sistema di stimolo all'innovazione non può essere efficace che se non incoraggia effettivamente la produzione di prodotti finiti che vadano a beneficio dei cittadini e dunque della società nel suo insieme. In compenso, il monopolio di concetti di base scoraggia la produzione di tali beni: risulta infatti più redditizio per un attore economico detentore di brevetti ottenere royalty da entità che si assumono il rischio commerciale di realizzare i prodotti finiti piuttosto di concepire lui stesso quei prodotti e di rischiare di trovarsi in balia di attacchi della parte dei suoi simili. Così, più la portata del brevetto è ampia e si estende nel tempo, più vengono incoraggiati comportamenti predatori e l'assenza di assunzione di rischio, a danno dell'innovazione. Nel caso del software, la durata minima di vent'anni, che sarebbe imposta dagli accordi TRIPS se si considerasse il software brevettabile, supera di oltre dieci volte la vita commerciale media di un software: ciò non ha alcun senso economico perché blocca gli sviluppi ulteriori di altri innovatori che devono, per penetrare il mercato, acquisire royalty sulle idee di base il cui costo di sviluppo, se mai c'è stato, è già stato ampiamente rimborsato.

Tra i grandi attori, c'è chi intesse accordi per lo scambio di portafogli di brevetti, scambio che permette loro di credersi in un mondo senza brevetti, ma che genera molteplici effetti perversi. Innanzitutto quale interesse economico c'è per queste imprese, e dunque per i loro clienti e per estensione per la società nel suo insieme, a finanziare il deposito di brevetti che serve a opporsi all'esistenza di altri brevetti mentre la loro assenza tornerebbe direttamente a loro vantaggio? Poi, alla fine di questi scambi, le sole entità che devono supportare il costo delle licenze sono le piccole e le medie imprese innovative, che non possono così accedere ai mercati che sarebbero redditizi per i loro investimenti. Il sistema funziona quindi esattamente all'opposto di come dovrebbe, penalizzando le PMI, che rappresentano più del 70% degli addetti e della ricchezza prodotta nel settore in Europa.

Risulta dunque poco sorprendente che i sostenitori dei brevetti siano maggiormente i gruppi a favore della «proprietà intellettuale» e degli uffici brevetti, i quali prosperano con l'aumento del numero dei protocolli depositati e dei contenziosi che ne discendono così come i servizi sui brevetti di alcune grandi imprese, che acquisiscono un potere crescente malgrado trovino l'opposizione anche delle direzioni tecniche interne (ma non hanno voce in capitolo, come nel caso di Alcatel, per esempio).

I brevetti sul software, una minaccia strategica per l'Europa

L'argomentazione di alcune grandi imprese che fanno pressione per la brevettabilità del software non tiene ed è dannosa a lungo termine per le nazioni europee.

Innanzitutto ribadiamo che la maggioranza di queste imprese produce marginalmente software, anche se esso comprende una fetta importante delle funzioni logiche messe in azione dai dispositivi rilasciati. Tuttavia, come visto più sopra, è la capacità realizzativa dei prodotti che occorre proteggere e non le funzioni logiche astratte di per sé. Non parliamo nemmeno della pressione esercitata dalle imprese dei media (tipo Vivendi), che sono solo utenti di software e che cercano di monopolizzare gli strumenti per la visualizzazione dei loro contenuti.

Inoltre, queste imprese giustificano il bisogno di brevettare il software con la necessità di controllare l'innovazione a monte, delocalizzando la produzione effettiva dei beni materiali nei paesi in via di sviluppo come la Cina o l'India. Ricordiamo a questo proposito la dichiarazione di Serge Tchuruk di Alcatel, il quale si augura che la sua sia un'«impresa senza fabbriche». Questo comportamento non è realista ed è suicida perché:

porta a ridurre in modo significativo il numero di dipendenti europei trasformando queste «grandi» imprese sedicenti europee in società finanziarie che impiegano lavoratori nei paesi in via di sviluppo per fornire ai consumatori europei prodotti i cui benefici di vendita andranno maggiormente ad azionisti non europei. Il saldo dei movimenti di capitali creati è così negativo per il continente europeo;
è irrealistico immaginare che paesi come la Cina e l'India restino esecutori docili al servizio di centri di studio e di ricerca europei con il pretesto che questi ultimi deterranno i brevetti sulle tecnologie messe in opera. Visti gli sforzi di educazione dell'India e della Cina e il contenutissimo costo della loro manodopera operaia ma anche scientifica, è più economico per questi paesi risviluppare la propria tecnologia piuttosto di pagare a caro prezzo le licenze dei brevetti. Approfittando del sapere accumulato di fatto dalle localizzazioni di siti di produzione, attualmente l'interesse di queste nazioni è quello di risviluppare a basso costo proprie tecnologie e brevetti a loro volta. Questi brevetti garantiranno loro il monopolio sui mercati nazionali, di numerosi miliardi di consumatori in totale e non ancora saturi, a differenza dei quelli europei e nord americani. Questi mercati non potranno essere penetrati dalle imprese occidentali perché queste, per inserirvisi e per accedere ai brevetti «locali» a protezione delle tecnologie locali, dovranno consentire lo scambio dei loro portafogli di brevetti: essi non saranno dunque più di alcuna utilità e non ammortizzeranno il costo di una ricerca e di uno sviluppo più costoso. L'esempio dello sviluppo della tecnologia EDV è chiaramente orientato in questa direzione [5, 6]. La tappa successiva sarà dunque che queste grandi imprese che di europeo non avranno altro che le loro sedi sociali, sarà la delocalizzazione dei loro laboratori di ricerca e sviluppo contribuendo all'impoverimento scientifico dell'Europa. è dunque pericoloso da parte loro fare affidamento e dare corso, a nome dell'Europa, alla loro domanda di rafforzamento della «proprietà intellettuale», che non serve nei fatti che agli interessi privati immediati dei loro azionisti a danno degli interesse di lungo termine dell'Europa.

I meccanismi monopolistici come i brevetti non favoriscono altri che gli attori dominanti [7]. D'altro canto, all'inizio del ventesimo secolo, gli Stati Uniti non hanno potuto emergere rapidamente di fronte all'Europa se non violando allegramente numerosi brevetti europei, come attesta la stampa dell'epoca. A fronte del declino finanziario per la ricerca in Francia e anche in Europa, non è ragionevole pensare che l'Europa possa prosperare in questo contesto, presa nella morsa della potenza industriale ancora superiore ma declinante degli Stati Uniti e della potenza crescente dei paesi in via di sviluppo come la Cina e l'India. Ricordiamo che la terza nazione che ha avuto accesso al volo spaziale non è stata una nazione europea, ma la Cina.

Il solo mezzo per l'Europa di continuare a esistere scientificamente consiste nello spronare l'apertura e la collaborazione per mutualizzare gli sviluppi e, per farlo, abbassare il costo globale della sua ricerca, permettendo così di non dover delocalizzare. Il periodo di progresso tecnico che conosciamo è la prosecuzione di quattrocento anni di libera diffusione della conoscenza, successiva all'abitudine ai segreti matematici che prevalevano dall'antichità fino al Rinascimento. è aberrante immaginare che qualcuno possa spronare un ritorno alla parcelizzazione della conoscenza facendo passare questa regressione storica per progresso.

Per concludere, ci si può interrogare sul beneficio per l'Europa dall'adozione di una legislazione che si dice volta a favorire gli Stati Uniti e il Giappone mentre gli stessi Stati Uniti fanno pressione su alcuni eurodeputati (per la maggior parte conservatori inglesi, vecchi riflessi della via dura) affinché la votino [8]. Saranno masochisti a tal punto?

Azioni da portare avanti

è essenziale che il governo francese sostenga senza riserve la posizione adottata dal Parlamento Europeo sulla non brevettabilità dell'immateriale [9] (idee, metodi educativi e commerciali, software), che costituisce una posizione equilibrata e positiva per l'Europa sul piano economico e strategico.

Questa posizione ricorda che il software non può essere in alcun caso brevettabile e che, nel caso di dispositivi ibridi che vedano la combinazione di una parte materiale e di software, questi dispositivi sono brevettabili alla sola condizione che la parte materiale costituisca un'invenzione così come previsto dalla legge sui brevetti. Questa dottrina è semplice ed efficace in quanto:

traccia una delimitazione chiara fra ciò che è brevettabile e ciò che non lo è, al contrario di tutte le contorsioni intellettuali avanzate dagli uffici brevetti per creare una distinzione fra software «tecnico» e «non tecnico»: essa comporta nella pratica ad autorizzare la brevettazione di tutto il software così come dei metodi intellettuali, commerciali o anche ludici
si allinea agli accordi TRIPS in cui il software, non essendo considerato un ambito tecnico, non rientra all'interno dell'articolo 27. D'altro canto, considerare che alcuni programmi sarebbero «tecnici» e dunque brevettabili obbligherebbe, secondo gli accordi TRIPS, a brevettare tutto il software

Riferimenti

[01]: http://www.abul.org/brevets/articles/tsuba_note.php3
[02]: http://www.abul.org/brevets/articles/parlement_20030924.php3
[03]: http://www.ftc.gov/os/2003/10/innovationrpt.pdf
[04]: http://www.researchoninnovation.org/swpat.pdf
[05]: http://www.china.org.cn/english/scitech/78549.htm
[06]: http://www.china.org.cn/english/scitech/80346.htm
[07]: http://www.theworld.com/obi/Bill.Gates/Challenges.and.Strategy, si veda il paragrafo intitolato Brevetti
[08]: http://swpat.ffii.org/papers/eubsa-swpat0202/ustr0309/
[09]: http://swpat.ffii.org/papers/europarl0309/index.en.html

La riproduzione letterale e la distribuzione integrale di questo articolo sono permesse su qualsiasi supporto a condizione che questa nota e le menzioni di copyright siano preservate.

Analisi del voto del Parlamento Europeo del 24/09/1003

Antonella BECCARIA, François PELLEGRINI — 2004-07-23T15:47:29Z

Introduzione

Questo testo analizza il voto del Parlamento Europeo consecutivo all'adozione, in prima lettura, del rapporto emendato della relatrice Arlene MacCarthy sulla proposta di Direttiva Directive COM2002(92) [1] relativa alla « brevettabilità delle invenzioni implementate dagli ordinatori ».

Questo rapporto è stato adottato, certamente, ma la proposta di direttiva non assomiglia affatto a quella che abbiamo combattuto, perché i numerosi emendamenti che sono stati votati [2] hanno trasformato una direttiva per la legalizzazione dei brevetti sul software [3] in una direttiva che vieta i brevetti sul software [ href="#r04">4].

Si può dunque considerare questo voto come una vittoria, anche se il testo così emendato deve ripassare davanti alla Commissione Europea e al Consiglio dove le lobby pro-brevetti, riunite in « gruppo di lavoro sulla proprietà intellettuale », è molto potente e farà di tutto per ribaltare quello che è stato realizzato.

Alcuni termini importanti

è impossibile comprendere la portata della direttiva senza una piccola spiegazione dei termini principali del testo utilizzati per la sua redazione.

« Effetto tecnico »: Ai sensi della legge sui brevetti, come nello spirito della maggioranza delle persone, una invenzione è un dispositivo o un procedimento materiale che apporta una soluzione a un problema concreto: macchina a vapore, regolatore di velocità per la macchina a vapore, filo per tagliare il burro, eccetera. Per evitare che il brevetto sia applicato a discipline industriali, la maggior parte degli uffici brevetti hanno dunque definito che, per essere brevettabile, un'invenzione, oltre alla novità e all'inventiva, deve avere un « carattere tecnico ». Questo termine non è stato sfortunatamente definito con precisione all'epoca, ma lo si è inteso sostenendo che l'invenzione debba avere un effetto fisico determinato nel suo ambiente.
Analogamente, in origine, tutte le funzioni logiche per pilotare queste invenzioni erano realizzate da strumenti materiali (meccanici, idraulici, poi elettronici), ma con l'irruzione dell'informatica, via via queste funzioni logiche sono stata realizzate via software, « dematerializzando » un po' alla volta la realizzazione di queste invenzioni. Non di meno, e questo è il punto critico della battaglia in corso, queste funzioni logiche, che siano realizzate da strumenti materiali o via software, sono astratte e dunque non brevettabili. Così, si può brevettare un regolatore di velocità a ruota, puramente materiale, sulla base della messa in opera della forza centrifuga per regolare l'emissione di vapore nei cilindri, se è innovativo (e lo era nel 1770). E ancora, si può brevettare un regolatore di velocità basato su un rilevatore ottico che misura la velocità di rotazione dell'asse della massa e mosso da un servo-motore sull'immissione di vapore, se non è già stato fatto, ma il fatto che la funzione logica di controllo sia realizzata via software non lo rende brevettabile perché questo processo di controllo è immateriale proprio come il principio della forza centrifuga che si usa per il regolatore a ruota. Esattamente come non si può brevettare la forza centrifuga, ma la messa in opera all'interno di un dispositivo dato, è possibile brevettare il dispositivo di regolazione informatizzato, ma non il software che contiene.
è giustamente quello che la CEB del 1973 ha ripreso negli articoli 52.2c e 53: un dispositivo ibrido in cui intervengono elementi materiali e software è brevettabile se la parte materiale costituisce un'invenzione, ma il software, in quanto tale (« as such »), non è brevettabile e deve dunque essere escluso dalle rivendicazioni di brevetto.
Ciononostante, allettati dagli introiti che potrebbero raccogliere, sia gli uffici brevetti che le grandi imprese del software hanno cercato di renderlo brevettabile. Per quello hanno stravolto il senso di « as such » argomentando che, se il software in quando tale non è brevettabile, un software utilizzato in un contesto tecnico preciso lo era perché era la causa dell'effetto tecnico prodotto dall'invenzione. Questo ragionamento è certamente assurdo perché tutto il software non fa altro che manipolare i dati astratti e un determinato software, messo in funzione in un emulatore logico, esegue senza produrre effetti tecnici dimostrando quindi che l'effetto tecnico non è assolutamente legato al software ma ai dispositivi materiali che il software comanda.
è per quello che, per limitare la brevettabilità ai soli componenti materiali delle invenzioni, escludendo il software, è sufficiente dire che non sono considerati come tecniche di cui le invenzioni necessitano per « l'utilizzo delle forze controllabili della natura ».
« Invenzione implementata da un elaboratore »: Questo termine, creato dalle lobby pro-brevetti, è volontariamente confuso e destinato a ingannare i politici con poteri decisionali sulla portata del brevetto; serve infatti ad aggirare l'Articolo 52.2c della Convenzione Europea sui Brevetti (CEB) del 1973 che esclude con ragione il software dal sistema dei brevetti.
L'obiettivo perseguito dalla direttiva era di precisare le condizioni della brevettabilità per i dispositivi ibridi, materiali e logici, ed erano queste invenzioni ibride che si rientravano sotto il termine di « invenzione implementata da un elaboratore ». Infatti, come appariva sia da una lettura piÃº approfondita del rapporto della signora MacCarthy che da un'operazione di interpretazione degli articoli della direttiva, ciò non permetteva solamente di brevettare le invenzioni che facevano uso di software, ma anche le invenzioni interamente realizzate con software: in altre parole, si concedeva la brevettabilità del software.
è per rimuovere questa ambiguità deliberata che alcuni emendamenti proposti miravano a sopprimere questo termine dal testo della direttiva.

Spiegazione degli articoli

Ecco una rapida spiegazione della direttiva emendata, articolo per articolo. Le considerazioni sono state parzialmente emendate il che significa che qualcuno può ancora affermare che gli algoritmi sono brevettabili. Non di meno, solo gli articoli avranno forza di legge.

Articolo 1

Questo articolo è il solo che non è stato emendato. Avremmo voluto che il termine « invenzione implementata da un elaboratore » sparisse e che l'Articolo 1 sottoscrivesse piuttosto che: « La presente direttiva stabilisce le regole concernenti i limiti della brevettabilità e delle possibile messe in opera dai brevetti per quanto riguarda i programmi per elaboratore ».
Ciononostante, non è molto grave attualmente e sarà con ogni probabilità oggetto di emendamenti in seconda lettura.

Articolo 2a

Specifica precisamente la nozione di « invenzione implementata da un elaboratore », dimostrando che questa deve possedere caratteristiche tecniche e che i programmi per elaboratore fanno parte di un ambito non tecnico.

Articolo 2b

Ricorda le quattro condizioni di brevettabilità.

Articolo 2

Articolo molto importante, che sottoscrive che la condizione di tecnica fa parte di altri riferimenti al mondo fisico e che il fatto di utilizzare dispositivi tecnici per trattare i dati non rende le procedure per il trattamento dell'informazione (cioè il software) tecniche e dunque brevettabili.

Articolo 2d

Limita la brevettabilità al mondo industriale. Le implicazioni di questo articolo sono grandi.

Articolo 3

Il trattamento dei dati non è campo brevettabile, vietando così i brevetti sul software, i metodi commerciali ed educativi, eccetera.

Articolo 4.1

Necessità di una condizione tecnica.

Articolo 4.3

Solo le innovazioni legate alle caratteristiche brevettabili rendono l'invenzione innovativa e dunque brevettabile. Così, un software nuovo eseguito all'interno di un dispositivo materiale precedente non potrà rendere il dispositivo brevettabile. In caso contrario si riconoscerà di fatto l'ingresso del software negli ambiti della brevettabilità.

Articolo 4.3a

Afferma la necessità che il contributo tecnico sia legato a nuovi usi di forze della natura. Completa l'articolo 2c rendendo necessario - e non solo sufficiente - la necessità di un contributo tecnico.

Articolo 5

Rifiuta i brevetti sui metodi intellettuali (software, metodi educativi, commerciali, eccetera).

Articolo 6

L'articolo 6 è decaduto poiché il rifiuto sui brevetti software rimuove qualsiasi problema di interoperabilità. L'articolo 6a ha tuttavia una portata considerevole perché di fatto comprende i sistemi ibridi e permette una interoperabilità su questi sistemi, almeno a livello dei formati di dati.

E adesso?

Il testo votato in plenaria dal Parlamento Europeo sarà trasmesso al Consiglio e alla Commissione che, se non lo accoglieranno, lo riscriveranno e sottometteranno al Parlamento Europeo una « versione di compromesso », a sua volta sottoposta al voto in plenaria (ma senza ripassare davanti alla varie commissioni del Parlamento, come nel caso in prima lettura).

Da un punto di vista strategico, qualcuno si è domandato se non sarebbe stato preferibile che la proposta di direttiva fosse stata respinta dal voto in prima lettura perché inutile dal momento che un emendamento alla CEB riaffermerebbe esplicitamente la non brevettabilità del software. Per di più, l'adozione in prima lettura apre la possibilità che una versione rivista dalla Commissione, che autorizza la brevettabilità del software, sia votata dal Parlamento Europeo per disattenzione o stanchezza e/o pressione delle lobby dei brevetti e dei loro alleati extra-europei [5].

Internamente, dato che le modifiche della CEB sono di competenza degli Stati membri dell'UBE, i cui rappresentati sono per la maggior parte membri degli uffici brevetti nazionali, una domanda di modifica della CEB non potrebbe sottrarsi dallo stretto controllo delle autorità politica, che non sono ancora informate della posta in gioco. La presa di posizione del Parlamento Europeo sulla direttiva, dopo un dibattito intenso che ha permesso di esporre piÃº chiaramente l'insieme degli argomenti, è dunque un punto molto positivo perché contribuisce a questa presa di coscienza. Inoltre, è la prima volta che un testo legislativo definisce esplicitamente la nozione di tecnicità, il che dà a questa direttiva una portata considerevole le cui ricadute vanno ben oltre il mondo del software così come delle frontiere europee. Oltre a ciò, mette i sostenitore dei brevetti software sulla difensiva perché sono ora in dovere di provare in cosa gli emendamenti che vorrebbero reintrodurre potrebbero essere benefici per l'Europa.

Sarà tuttavia necessario sorvegliare attentamente l'evoluzione del dossier in seno al Parlamento Europeo affinché gli emendamenti che saranno introdotti un seconda lettura confermino bene l'orientamento preso, come nel caso della brevettabilità sui viventi. Il voto finale di una parte dei deputati europei (in particolare i gruppi dei Verdi, GUE, EDD, EUN, eccetera) contro il testo traduce giustamente l'intenzione di una parte del Parlamento Europeo a non firmare un assegno in bianco alla Commissione e che saranno attenti nel farsi respingere il testo in seconda lettura, se la Commissione calpestasse la volontà dei rappresentanti dei cittadini.

Si tratta dunque, nei mesi a venire, di fare pressione sui governi nazionali perché possano comprendere la portata degli emendamenti votati sostenendoli al Consiglio e facendo pressione sulla Commissione. Resta quindi ancora molto lavoro da fare.

Riferimenti

[1]: http://europa.eu.int/comm/internal_market/en/indprop/comp/com02-92fr.pdf
[2]: http://www3.europarl.eu.int/omk/omnsapir.so/pv2?PRG=DOCPV&APP=PV2&LANGUE=EN&SDOCTA=2&
TXTLST=1&POS=1&Type_Doc=RESOL&TPV=PROV&DATE=240903&
PrgPrev=PRG@TITRE|APP@PV2|TYPEF@TITRE|YEAR@03|
Find@%2a%69%6e%76%65%6e%74%69%6f%6e%73|FILE@BIBLIO03|PLAGE@1&TYPEF=TITRE&NUMB=1&DATEF=030924
[3]: http://www2.europarl.eu.int/omk/sipade2?PUBREF=-//EP//TEXT+REPORT+A5-2003-0238+0+DOC+XML+V0//FR&
L=FR&LEVEL=3&NAV=S&LSTDOC=Y
[4]: http://swpat.ffii.org/papers/eubsa-swpat0202/plen0309/resu/index.fr.html
[5]: http://swpat.ffii.org/papers/eubsa-swpat0202/ustr0309/

La riproduzione letterale e la distribuzione integrale di questo articolo sono permesse su qualsiasi supporto a condizione che questa nota e le menzioni di copyright siano preservate.

Analyse des articles de la directive votée par le Conseil de l'Union Européenne

François PELLEGRINI — 2004-07-22T11:30:37Z

Ce document analyse, article par article, la version de la directive
sur les « inventions mises en oeuvre par
ordinateur » proposée par les membres des offices de
brevets siégeant au Coreper et votée au Conseil du 18 mai
2004 [01], et montre en quoi cette
directive diffère substantiellement de celle amendée et votée en
première lecture par le Parlement Européen le 24 septembre
2003 [02].

Analyse des articles

On ne fera ici l'analyse que des articles proprements dits, les
considérants ayant une importance moindre. Il y sera cependant
fait référence en cas d'incohérences manifestes avec le contenu
des articles.

Afin de faciliter la compréhension des différences entre les deux
versions, les points cruciaux ont été mis en gras.

Article 1

Version du Conseil

La présente directive établit des règles concernant la brevetabilité
des inventions mises en oeuvre par ordinateur.

Analyse de la version du Conseil

Le terme « inventions mises en oeuvre par
ordinateur » est inapproprié et trompeur. Dans
l'esprit de la majorité des lecteurs, il fait référence au fait qu'une
invention matérielle puisse être pilotée par un ordinateur. Cependant,
dans ce cas, la présence de l'ordinateur n'apporte rien de
significatif à l'invention, et l'invention elle-même peut tout à fait
être revendiquée en vertu des textes existants, en tant que produit ou
procédé. C'est d'ailleurs le sens même de l'article 52.2 de la
Convention Européenne du Brevet qui dit que, dans le cas d'une
invention faisant intervenir à la fois du matériel et du logiciel, tel
qu'un système de freinage ABS ou une machine à laver mettant en oeuvre
un nouveau procédé de lavage, l'invention dans son ensemble peut être
revendiquée, mais que les logiciel qu'elle utilise, en tant que tels,
ne peuvent faire l'objet de revendications car le logiciel n'est pas
brevetable, mais soumis au régime du droit d'auteur.

Le sens caché de ce terme, avancé par les représentants des offices de
brevets, est donc qu'une invention puisse être intégralement
« mise en oeuvre » au moyen d'un ordinateur, et
donc que cette « invention » soit en fait un
logiciel. Dans ce cadre, l'objet de la directive est bien d'instaurer
la brevetabilité logicielle.

Pour une analyse plus approfondie du lien entre matériel et logiciel,
et sur le fait que le logiciel ne peut pas être considéré comme
« technique » au sens des brevets,
voir [03] et [ href="#r04">04].

Version du Parlement

Idem.

Analyse de la version du Parlement

La version du Parlement est malheureusement identique à
celle du Conseil.
Si la volonté sous-jacente était réellement d'interdire la
brevetabilité logicielle, il faudrait plutôt reformuler cet
article en parlant d'inventions « contrôlées
par ordinateur », pour bien montrer que l'invention,
au sens des brevets, ne peut résider dans le logiciel. Un
amendement parlementaire en ce sens avait été déposé, mais n'a
pas été adopté. En fait, si le texte devait être ré-écrit de
façon cohérente, il faudrait à chaque fois remplacer le terme
« invention mise en oeuvre par ordinateur »
par le terme « invention contrôlée par
ordinateur ».

Article 2

Version du Conseil

a) "invention mise en oeuvre par ordinateur" désigne toute invention
dont l'exécution implique l'utilisation d'un ordinateur, d'un réseau
informatique ou d'un autre appareil programmable, l'invention
présentant une ou plusieurs caractéristiques qui sont réalisées
totalement ou en partie par un ou plusieurs programmes
d'ordinateur ;

b) "contribution technique" désigne une contribution à l'état de l'art
dans un domaine technique, qui est nouvelle et non évidente pour une
personne du métier. La contribution technique est évaluée en prenant
en considération la différence entre l'état de l'art et l'objet de la
revendication de brevet considéré dans son ensemble qui doit
comprendre des caractéristiques techniques, qu'elles soient ou non
accompagnées de caractéristiques non techniques.

Analyse de la version du Conseil

Cet article constitue la première brèche permettant effectivement
la brevetabilité absolue des logiciels et méthodes commerciales.

L'Article 2.a stipule tout d'abord que la totalité des
caractéristiques d'une invention peuvent être réalisées par un
programme d'ordinateur, ce qui légitime la brevetabilité logicielle en
dehors de toute contribution matérielle innovante.

Ensuite, l'Article 2.b dispose que, lors de l'évaluation de la
contribution technique, on considère non pas uniquement les
caractéristiques techniques de l'invention, mais également ses
caractéristiques non techniques. Grâce à cela, un nouveau logiciel
s'exécutant sur un banal ordinateur peut réaliser une contribution
technique, car la nouveauté provient du logiciel (non technique) et la
technicité de l'usage d'un ordinateur (non nouveau), l'ensemble étant
à la fois nouveau et technique.

Version du Parlement

Aux fins de la présente directive, les définitions suivantes
s'appliquent :

a) "invention mise en oeuvre par ordinateur" désigne toute invention
au sens de la Convention sur le brevet européen dont l'exécution
implique l'utilisation d'un ordinateur, d'un réseau informatique ou
d'un autre appareil programmable et présentant dans sa mise en
oeuvre une ou plusieurs caractéristiques non techniques qui sont
réalisées totalement ou en partie par un ou plusieurs programmes
d'ordinateurs, en plus des caractéristiques techniques que toute
invention doit apporter ;

b) "contribution technique", également appelée "invention", désigne
une contribution à l'état de la technique dans un domaine
technique. Le caractère technique de la contribution est une des
quatre conditions de la brevetabilité. En outre, pour mériter un
brevet, la contribution technique doit être nouvelle, non évidente et
susceptible d'application industrielle. L'utilisation des forces de
la nature afin de contrôler des effets physiques au delà de la
représentation numérique des informations appartient à un domaine
technique. Le traitement, la manipulation et les présentations
d'informations n'appartiennent pas à un domaine technique, même si des
appareils techniques sont utilisés pour les effectuer ;

c) "domaine technique" désigne un domaine industriel d'application
nécessitant l'utilisation de forces contrôlables de la nature pour
obtenir des résultats prévisibles. "Technique" signifie "appartenant à
un domaine technique" ;

d) "industrie", au sens du droit des brevets, signifie "production
automatisée de biens matériels".

Analyse de la version du Parlement

L'Article 2 du Parlement Européen, pour sa part, définit précisément
les limites de la technicité, afin d'éviter que les logiciels,
méthodes commerciales, et autres processus intellectuels puissent être
rendus brevetables.

L'Article 2.a spécifie que les logiciels ne peuvent apparaître que
sous forme de contributions non techniques dans des revendications de
brevets et que, pour être recevable, un brevet doit posséder au moins
une caractéristique technique nouvelle. Ainsi, un nouveau système ABS
utilisant un ordinateur est brevetable, parce que ce système fournit
une contribution technique nouvelle située dans le domaine matériel.
Dans ce cas, le fait qu'un programme soit utilisé par ce système ABS
fait partie des revendications non techniques, et le programme, en
tant que tel, n'est donc pas couvert par le brevet, mais par le régime
du droit d'auteur.

L'Article 2.b précise que l'usage d'ordinateurs pour mettre en oeuvre
des processus de traitement de données ne peut rendre ces derniers
brevetables.

L'Article 2.c donne une définition précise de la technicité au sens
des brevets, déjà présente dans le Droit nordique, et basée sur le
fait qu'une invention au sens des brevets doit fournir une solution
nouvelle à un problème appartenant au monde physique. Ceci exclut de
fait les méthodes commerciales, éducatives, ou autres du champ de la
brevetabilité.

L'Article 2.d définit le domaine industriel dans lequel s'applique le
brevet, afin d'éviter l'apparition de brevets dans des industries
comme celles du cinéma ou du disque.

Article 3

Version du Conseil

Supprimé.

Analyse de la version du Conseil

Cet article, qui stipulait initialement, dans la version de la
Commission, que les « inventions mises en oeuvre par
ordinateur » appartenaient à un domaine technique par
nature et étaient donc intrinsèquement brevetables en dehors de toute
autre considération, a été supprimé tant par le Parlement Européen que
par le Conseil. Il était en effet tautologique, puisque dès qu'on fait
référence à la notion d'invention, on se trouve dans un domaine où la
brevetabilité s'applique.

Il est cependant à noter que le contenu de cet article constitue
toujours le début du Considérant 12, qui est donc inconsistent.

Version du Parlement

Les États membres veillent à ce que le traitement des données ne soit
pas considéré comme un domaine technique au sens du droit des brevets
et à ce que les innovations en matière de traitement des données ne
constituent pas des inventions au sens du droit des brevets.

Analyse de la version du Parlement

Le Parlement a voté un nouvel Article 3 spécifiant explicitement que
les processus de traitement des données ne fait pas partie du champ de
la brevetabilité. Cet Article fait quelque peu double emploi vis-à-vis
de l'Article 2.b du Parlement, du fait que de nombreux amendements
équivalents ont été présentés par des parlementaires différents. Ceci
se produit à d'autres endroit du texte parlementaire, mais n'est pas
gênant.

Article 4

Version du Conseil

Pour être brevetable, une invention mise en oeuvre par ordinateur doit
être susceptible d'application industrielle, être nouvelle et
impliquer une activité inventive. Pour impliquer une activité
inventive, une invention mise en oeuvre par ordinateur doit apporter
une contribution technique.

Analyse de la version du Conseil

Il n'y aurait rien à redire à cet article si la notion de contribution
technique était définie de façon à exclure les logiciels et les
méthodes commerciales. On a vu dans l'analyse de l'Article 2 que ce
n'était pas le cas.

Version du Parlement

1. Pour être brevetable, une invention mise en oeuvre par
ordinateur doit être susceptible d'application industrielle, être
nouvelle et impliquer une activité inventive. Pour impliquer une
activité inventive, une invention mise en oeuvre par ordinateur
doit apporter une contribution technique.

Analyse de la version du Parlement

La version du Parlement est identique à celle du Conseil. Seule
la numérotation change.

Article 4bis

Version du Conseil

1. (nouveau) Un programme d'ordinateur en tant que tel ne peut
constituer une invention brevetable.

2. Une invention mise en oeuvre par ordinateur n'est pas considérée
comme apportant une contribution technique simplement parce qu'elle
implique l'utilisation d'un ordinateur, d'un réseau ou d'un autre
appareil programmable. En conséquence, ne sont pas brevetables les
inventions consistant en des programmes d'ordinateur, qu'ils soient
exprimés en code source, en code objet ou sous toute autre forme, qui
mettent en oeuvre des méthodes pour l'exercice d'activités économiques,
des méthodes mathématiques ou d'autres méthodes, si ces inventions ne
produisent pas d'effets techniques au-delà des interactions physiques
normales entre un programme et l'ordinateur, le réseau ou un autre
appareil programmable sur lequel celui-ci est exécuté.

Analyse de la version du Conseil

Cet article constitue la deuxième brèche permettant la brevetabilité
totale des logiciels ainsi que des méthodes commerciales.

L'Article 4bis.1 stipule que les logiciels « en tant que
tels » ne sont pas brevetables. Cependant, aucune
définition de ce qu'est un « logiciel en tant que
tel » n'est donnée, et l'Article 4bis.2 revient à dire que
de tels logiciels n'existent pas.

L'Article 4bis.2 constitue une magnifique tentative d'enfumage. Si on
le débarasse de ses doubles négations, il revient à dire qu'on peut
effectivement breveter des programmes mettant en oeuvre des
méthodes commerciales, des méthodes mathématiques, ou d'autres
méthodes, à condition que ces programmes produisent un effet
« technique » autre que celui de s'exécuter sur
l'ordinateur. Or, comme il est dit dans le texte de la directive de la
Commission [05, page 16], l'OEB
considère qu'un logiciel fournit un effet
« technique » dès lors qu'on considère des
motivations « techniques » avant de le
programmer ou qu'on utilise des moyens
« techniques » pour le mettre en oeuvre.

Ainsi, dès qu'un logiciel sert à quelque chose et peut s'exprimer sous
forme de jargon technicisant, il est considéré comme
« technique » et donc brevetable, les logiciels
« en tant que tels » étant donc par contraposée
les logiciels qui ne servent à rien et qu'il n'est pas économiquement
utile de breveter.

De bons exemples de brevets de méthodes commerciales effectivement
délivrés par l'OEB se trouvent ici [ href="#r06">06]. Le premier de ces brevets, qui porte sur la
notion de commerce en ligne, a été accepté sans problème par l'OEB,
du fait de son écriture en jargon technicisant [ href="#r07">07], et tous les cabinets en brevets savent bien
comment faire en sorte que des brevets sur des méthodes commerciales
puissent être acceptés par les offices de brevets [ href="#r08">08].

Ceci montre bien que, dès le moment où on accepte l'idée que
certains logiciels puissent être brevetables, alors il n'y a aucun
moyen d'empêcher le brevetage effectif des méthodes commerciales,
car toutes ces méthodes sont en fait des algorithmes qui peuvent
être décrits par les ressources qu'ils mobilisent et la façon dont ils
les utilisent. Il est impossible de faire une quelconque
distinction entre logiciels « techniques »
et « non techniques » [ href="#r04">04], et la seule façon d'interdire le brevetage
des méthodes commerciales consiste à interdire totalement la
brevetabilité logicielle.

Version du Parlement (suite de l'Article 4)

Article 4

[...]

2. Les États membres veillent à ce que le fait qu'une invention mise
en oeuvre par ordinateur qui apporte une contribution technique
constitue une condition nécessaire à l'existence d'une activité
inventive.

3. Le caractère notable de la contribution technique est évalué en
prenant en considération la différence entre l'ensemble des
caractéristiques techniques de la revendication de brevet et
l'état de la technique, indépendamment du fait que ces
caractéristiques soient accompagnées ou non de caractéristiques non
techniques.

4. Pour déterminer si une invention mise en oeuvre par
ordinateur apporte une contribution technique, il y a lieu d'établir
si elle apporte une connaissance nouvelle sur les relations de
causalité en ce qui concerne l'utilisation des forces controlables de
la nature et si elle a une application industrielle au sens strict de
l'expression, tant sous l'angle de la méthode que sous celui du
résultat.

Analyse de la version du Parlement

La version du Parlement réaffirme la nécessité d'une contribution
technique dans le domaine physique, ayant une application industrielle
manifeste, pour pouvoir breveter une invention contrôlée par ordinateur.

En particulier, à la différence de la version du Conseil, l'Article
4.3 stipule que l'évaluation de la nouveauté de l'invention ne doit
se faire que par rapport aux seules caractéristiques techniques de
l'invention, qui seules légitiment la délivrance d'un brevet.

Il est à remarquer que les termes de l'Article 4bis.2 du Conseil sont
repris dans l'Article 5 de la version du Parlement. Ceci doit être
considéré comme un vestige du texte de la Commission, qui n'a en fait
pas d'importance puisque le texte du Parlement définit de façon précise
la notion de technicité.

Article 5

Version du Conseil

1. Les États membres veillent à ce qu'une invention mise en oeuvre par
ordinateur puisse être revendiquée en tant que produit, c'est-à-dire
en tant qu'ordinateur programmé, réseau informatique programmé ou
autre appareil programmé ou en tant que procédé réalisé par un tel
ordinateur, réseau informatique ou autre appareil à travers
l'exécution d'un logiciel.

2. Une revendication pour un programme d'ordinateur, seul ou sur
support, n'est autorisée que si ce programme, lorsqu'il
est chargé et exécuté dans un ordinateur, un réseau informatique
programmé ou un autre appareil programmable, met en oeuvre un
produit ou un procédé revendiqué dans la même demande de brevet,
conformément au paragraphe 1.

Analyse de la version du Conseil

L'Article 5.1 réitère la possibilité de breveter les logiciels, en
permettant le brevetage de procédés réalisés par un ordinateur.
Il ne s'agit pas ici d'un procédé physique contrôlé par
l'ordinateur, mais bien de ce que fait le programme d'ordinateur
proprement dit (en langue anglaise, cette confusion est renforcée
par l'utilisation du vocable « process » pour
désigner à la fois un procédé industriel brevetable mais aussi
l'exécution d'un processus informatique).

L'Article 5.2 constitue la troisième brèche. Ici encore, si l'on
se débarasse des doubles négations, il appert qu'on peut revendiquer
un programme sur tout support dès le moment où ce programme a été
revendiqué en tant que procédé, ce qui est justement permis par
l'Article 4bis. Cet article garantit la brevetabilité absolue des
logiciels, et nie de fait l'existence des prétendus logiciels
« en tant que tels » censés être non
brevetables.

Notons que cet article constitue une atteinte extrêmement grave à la
diffusion de la connaissance. Dès le moment où il existe un brevet sur
le commerce en ligne, par exemple, toute publication dans un livre ou
un périodique d'un programme permettant ce type
d'activité est attaquable en justice. Ceci concerne bien sûr le code
source, qui peut directement être exécuté sur un ordinateur au moyen
d'un interprêteur. Autre exemple parlant : toute personne
possédant chez elle un exemplaire d'un logiciel mettant en oeuvre une
« barre de progression » (EP 394160) [ name="t09" href="#r09">09] (barre servant à faire patienter
l'utilisateur) est attaquable par le détenteur du brevet.

Version du Parlement (Article 7)

Article 7

1. Les États membres veillent à ce qu'une invention mise en oeuvre par
ordinateur ne puisse être revendiquée qu'en tant que produit,
c'est-à-dire en tant qu'appareil programmé, ou en tant que procédé
technique de production.

2. Les États membres veillent à ce que les revendications de brevet
reconnues sur des inventions mises en oeuvre par ordinateur couvrent
uniquement la contribution technique qui fonde une revendication. Une
revendication de brevet sur un programme d'ordinateur, que ce soit sur
le seul programme ou sur un programme enregistré sur un support de
données, est irrecevable.

3. Les États membres veillent à ce que la production, la manipulation,
le traitement, la distribution et la publication de l'information, sous
quelque forme que ce soit, ne puisse jamais constituer une contrefaçon
de brevet, directe ou indirecte, même lorsqu'un dispositif technique est
utilisé dans ce but.

4. Les États membres veillent à ce que l'utilisation d'un programme
d'ordinateur à des fins qui ne relèvent pas de l'objet du brevet ne
puisse constituer une contrefaçon de brevet, directe ou indirecte.

5. Les États membres veillent à ce que, lorsqu'une revendication de
brevet mentionne des caractéristiques impliquant l'utilisation d'un
programme d'ordinateur, une mise en oeuvre de référence, opérationnelle
et bien documentée, de ce programme soit publiée en tant que partie de
la description, sans conditions de licence restrictives.

Analyse de la version du Parlement

Les Articles 7.1 et 7.2 de la version du Parlement stipule
explicitement qu'un programme ne peut faire l'objet d'une
revendication de brevet, celle-ci ne pouvant concerner que les
produits matériels ou les procédés industriels (et non les processus
informatiques).

L'Article 7.3 de la version du Parlement dispose que les méthodes de
traitement de l'information (qui sont en fait des descriptions
algorithmiques de méthodes mathématiques, analogues par nature à la
description de méthodes commerciales) ne puissent être brevetables.

L'Article 7.4 de la version du Parlement dit que jamais un brevet
sur une invention contrôlée par ordinateur ne permet de monopoliser
l'usage des algorithmes que le programme de contrôle met en oeuvre.

L'Article 7.5 de la version du Parlement rappelle l'obligation de
pérennisation et de diffusion du savoir inhérente au système des
brevets.

Article 6

Version du Conseil

Les droits conférés par un brevet délivré pour une invention relevant
du champ d'application de la présente directive n'affectent pas les
actes autorisés en vertu des articles 5 et 6 de la directive
91/250/CEE concernant la protection juridique des programmes
d'ordinateur par un droit d'auteur, et notamment de ses dispositions
relatives à la décompilation et à l'interopérabilité.

Analyse de la version du Conseil

Cet article est inopérant à garantir l'interopérabilité.
La possibilité de rétro-ingéniérie fonctionne dans le cas du
copyright, parce qu'un programmeur désirant interagir avec un
programme existant, par exemple en créant des fichiers d'un
format reconnu par ce programme, a le droit d'examiner
son fonctionnement et peut se servir de l'information
obtenue pour écrire ses propres routines de création de
fichiers, qui sont une oeuvre originale au sens du
copyright et ne constituent pas une copie servile du
programme initial.

En revanche, si un format de fichier est breveté, comme par exemple un
format de document de traitement de texte [ href="#r10">10], tout programmeur désireux d'écrire un programme
écrivant de tels fichiers, s'il a bien le droit d'analyser comment ces
fichiers sont crées, ne peut commercialiser librement son programme,
car celui-ci constituerait une contrefaçon du brevet, puisqu'il
contient des algorithmes permettant de créer des instances du format
breveté.

Cet article n'empêche donc aucunement la constitution de populations
d'utilisateurs captifs, obligés de continuer à utiliser les systèmes
informatiques du même fournisseur car celui-ci n'autoriserait pas
les programmes concurrents à importer légalement les formats de
données dont il détiendrait le monopole.

Version du Parlement (Articles 8 et 9)

Article 8

Les droits conférés par les brevets d'invention délivrés dans le cadre
de la présente directive ne portent pas atteinte aux actes permis en
vertu des articles 5 et 6 de la directive 91/250/CEE notamment en vertu
des dispositions particulières relatives à la décompilation et à
l'interopérabilité.

Article 9

Les États membres veillent à ce que, lorsque le recours à une technique
brevetée est nécessaire à une fin significative, par exemple pour
assurer la conversion des conventions utilisées dans deux systèmes
informatiques ou des réseaux différents, de façon à permettre entre eux
la communication et l'échange de données, ce recours ne soit pas
considéré comme une contrefaçon de brevet.

Analyse de la version du Parlement

La version proposée par le Parlement, ainsi d'ailleurs qu'une version
proposée au Conseil par le Luxembourg, permettaient effectivement de
garantir l'interopérabilité, en définissant une exception limitée au
droit des brevets, comme l'autorise l'Article 30 des ADPIC [ name="t11" href="#r11">11, page 5].

Si la directive empêchait réellement la brevetabilité logicielle, ce
type d'article ne serait pas nécessaire vis-à-vis des brevets
européens, mais cependant toujours nécessaire pour assurer en Europe
la possibilité d'interopérabilité vis-à-vis des brevets étasuniens.

Article 7

Version du Conseil

La Commission surveille l'incidence des inventions mises en oeuvre par
ordinateur sur l'innovation et la concurrence en Europe et dans le
monde entier, ainsi que sur les entreprises européennes, en
particulier les petites et moyennes entreprises et la communauté des
logiciels libres, de même que le commerce électronique.

Analyse de la version du Conseil

Au vu du biais pro-brevets déjà exprimé par le Conseil, des délais
induits par la collecte d'informations nécessaires à un tel suivi,
et au temps de réaction supplémentaire nécessaire à tout ajustement, cet
article est inopérant. Mieux vaut prévenir que tenter de guérir des
années après le mal qu'on aura soi-même causé.

Article 8

Version du Conseil

La Commission présente au Parlement européen et au Conseil, pour le
[trois ans à compter de la date indiquée à l'article 9, paragraphe 1]
au plus tard, un rapport indiquant :

a) l'incidence des brevets délivrés pour des inventions mises en
oeuvre par ordinateur sur les éléments mentionnés à l'article 7 ;

b) si les règles régissant la durée de validité et la détermination
des critères de brevetabilité en ce qui concerne plus précisément la
nouveauté, l'activité inventive et la portée des revendications sont
adéquates, et s'il serait opportun et juridiquement possible, compte
tenu des obligations internationales de la Communauté, d'apporter des
modifications à ces règles ;

c) si des difficultés sont apparues dans les États membres où les
aspects de la nouveauté et de l'activité inventive des inventions ne
sont pas examinés avant la délivrance d'un brevet et si des mesures
doivent être prises, le cas échéant, pour y remédier ;

c bis) si des difficultés sont apparues dans la relation entre la
protection par brevet des inventions mises en oeuvre par ordinateur et
la protection des programmes d'ordinateur par le droit d'auteur,
prévue par la directive 91/250/CEE, et si des abus du système de
brevet se sont produits en rapport avec les inventions mises en oeuvre
par ordinateur ;

c ter) la façon dont les exigences de la présente directive ont été
prises en compte dans la pratique de l'Office européen des brevets et
dans ses lignes directrices en matière d'examen ;

c quater) à quels égards il pourrait être nécessaire de préparer
une conférence diplomatique afin de réviser la Convention sur le
brevet européen ;

c quinquies) l'incidence des brevets conférés pour des inventions mises
en oeuvre par ordinateur sur le développement et la commercialisation
de programmes et de systèmes informatiques interopérables ;

c) si des difficultés sont apparues dans les États membres où les
aspects de la nouveauté et de l'activité inventive des inventions ne
sont pas examinés avant la délivrance d'un brevet et si des mesures
doivent être prises, le cas échéant, pour y remédier ;

[...]

Analyse de la version du Conseil

Tout ceci constitue une liste de voeux pieux, qui ne pourront de toute
façon pas corriger une situation qui aura tourné au désavantage de
l'Europe. Par exemple, si, à cause de failles béantes dans la
directive, les sociétés étasuniennes avaient la possibilité de
« faire leur marché » en Europe, et de racheter
ou couler les entreprises européennes concurrentes [ href="#r12">12] à fort potentiel innovant, il est difficile de
croire qu'un ré-examen de la directive pourrait restaurer ce qui aura
été perdu. Le cas de Gemplus illustre que la guerre économique pour le
contrôle des moyens d'accès à l'information existe bien, et qu'il
n'est pas utile de fournir à ses adversaires de moyens supplémentaires
de dominer.

Qui plus est, on trouve dans les alinéas quelques chevaux de Troie,
tels le b) et le c). L'Alinéa b) pourrait autoriser la Commission,
sur la base des pratiques des États-Unis et d'une interprétation
extrémiste des accords ADPIC, à lever toutes restrictions sur la
technicité, ouvrant ainsi la voie à une brevetabilité absolue. De
même, l'Alinéa c) pourrait autoriser la Commission à demander une
révision de la Convention Européenne du Brevet afin de supprimer
l'Article 52.2 stipulant que les logiciels ne sont pas brevetables,
vieux rêve des pro-brevets et qui semble toujours à leur agenda.

Synthèse

Version du Conseil contre version du Parlement

Contrairement à ce que ceux-ci ont toujours prétendu, le texte
soumis au Conseil [01] par les
représentants des offices de brevets siégeant au Coreper n'est
absolument pas un texte de compromis, comme a dû le reconnaitre devant
le Parlement Néerlandais la Secrétaire d'État van Gennip [ name="t13" href="#r13">13]. Mme van Gennip a, lors de ce débat
parlementaire, reconnu de même que la directive visait à légaliser la
pratique actuelle de l'OEB, qui délivre déjà des brevets purement
logiciels, et à autoriser le brevetage des algorithmes utilisés dans
le cadre de méthodes commerciales (comme le "shopping cart"
qu'elle donne elle-même en exemple).

Indépendemment du nombre d'amendements parlementaires repris ou non,
qui n'a aucune signification, il est important de voir en quoi
la version du Conseil diffère de celle du Parlement. Les amendements
parlementaires supprimés dans la version du Conseil concernent :

la définition positive de la technicité comme faisant
référence à un enseignement nouveau sur l'utilisation de
forces contrôlables de la nature, seule capable de limiter
la brevetabilité au monde physique et d'interdire
le brevetage des logiciels ainsi que des méthodes
commerciales, éducatives et de mathématiques
appliquées ;
l'examen des seules contributions techniques (c'est-à-dire physiques,
au sens de la définition ci-dessus) des revendications des brevets
pour l'analyse de l'activité inventive ;
l'interdiction de revendiquer des programmes sur leurs supports,
qui sinon constituerait un grave danger pour la transmission de
la connaissance ;
une vraie garantie de l'interopérabilité, puisque les textes de la
Commission et du Conseil n'autorisent pas la diffusion de logiciels
interopérables implémentant des protocoles brevetés, et ne peuvent
donc empêcher la monopolisation des protocoles de communication et des
formats de fichiers.

Ainsi, sous sa forme votée par le Conseil, la directive permettrait
effectivement la brevetabilité totale des logiciels, et n'offrirait
aucune limitation. Pour s'en convaincre, il suffit de voir que la
"barre de progression" [ href="#r09">09] reste toujours brevetable. Voici comment procéder
pour cela :

faute d'une définition non tautologique de la technicité, et en considérant la
pratique actuelle de l'OEB, la barre de progression a bien un effet
« technique ». En effet, grâce à elle, un
utilisateur peut savoir à quel moment son programme aura fini de
calculer, et peut donc décider de faire autre chose dans l'intervalle
au lieu d'attendre, gagnant ainsi en productivité et diminuant son
stress de l'attente. Ceci est un effet différent des seules
interactions normales entre le programme et l'ordinateur, dans un
cadre industriel, et peut donc être considéré comme un effet
technique. Voir pour s'en convaincre quelques unes de édifiantes
citations collationnées dans [14] ;
il est donc possible d'écrire une revendication de brevet faisant
intervenir l'exécution d'une barre de progression sur un
ordinateur. Il ne s'agit pas d'un programme « en tant que
tel », puisqu'on a démontré un effet technique ;
on peut alors breveter un programme mettant en
oeuvre une barre de progression, puisque ce programme, une fois chargé
dans un ordinateur, exécute bien le procédé breveté.

Si les « programmes en tant que tels » semblent
exclus du champ de la brevetabilité, en fait, de tels
programmes n'existent simplement pas. Ce que dit justement la
directive, c'est qu'est brevetable un programme dès le moment où on
l'exécute pour produire un effet utile, ce qui est justement la raison
pour laquelle on écrit des programmes.

La tentative de vouloir établir une discrimination entre logiciels
« techniques » et logiciels
« non-techniques » ne peut donc qu'être vouée à
l'échec [04] et donc, si les
brevets logiciels étaient légalisés, tous les algorithmes, y compris
l'implémentation sur ordinateur de méthodes commerciales, seraient
brevetables. Il suffit pour s'en convaincre de constater le
fonctionnement actuel de l'OEB où, en dépit du critère de technicité,
de tels brevets ont effectivement été délivrés, comme celui sur un
système informatique de distribution de recettes de cuisine dans les
super-marchés destiné à faire augmenter les ventes des ingrédients (EP
756731) [15], ou sur l'évaluation
d'élèves (EP 664041) [16].

Définition de la technicité et contrôle parlementaire de l'OEB

La définition de la technicité constitue l'enjeu majeur du texte,
ainsi que le moyen pour le politique de contrôler l'Office Européen
des Brevets. C'est pour cela que l'OEB rejette avec la plus grande
violence toute définition explicite de la technicité, car
l'existence d'une définition explicite de la technicité dans un
texte législatif obligerait l'OEB à demander une modification de ce
texte, et donc solliciter un débat public sur le bien fondé de sa
démarche, à chaque fois qu'il souhaiterait élargir son périmètre
d'action.

Brevets logiciels et Droit Français

L'irruption des brevets logiciels pose aussi question vis-à-vis du
Droit Français. L'Article 4 de la LCEN (Loi n° 2004-575 pour la
confiance dans l'économie numérique) [ href="#r17">17] dispose : « On entend par
standard ouvert tout protocole de communication, d'interconnexion ou
d'échange et tout format de données interopérable et dont les
spécifications techniques sont publiques et sans restriction d'accès
ni de mise en oeuvre ». La possibilité de breveter les
moyens d'accès aux données des collectivités, à travers le brevetage
des formats de fichier et des protocoles de communication [ name="t18" href="#r18">18], est donc en contradiction avec les
objectifs de l'État de fournir un service basé sur les protocoles et
standards ouverts, voire à base de logiciels libres comme l'a annoncé
M. Dutreil, Ministre de la Fonction publique [ href="#r19">19].

Références

[01]: http://register.consilium.eu.int/pdf/fr/04/st09/st09713.fr04.pdf
[02]: http://www2.europarl.eu.int/omk/sipade2?PUBREF=-//EP//TEXT+TA+P5-TA-2003-0402+0+DOC+XML+V0//FR&LEVEL=3&NAV=X#BKMD-
[03]: http://www.abul.org/brevets/articles/parlement_20030924.php3
[04]: http://www.abul.org/article190.html
[05]: http://europa.eu.int/comm/internal_market/en/indprop/comp/com02-92fr.pdf
[06]: http://webshop.ffii.org/
[07]: http://l2.espacenet.com/espacenet/viewer?PN=EP0803105&CY=gb&LG=en&DB=EPD
[08]: http://www.iusmentis.com/patents/businessmethods/epc/
[09]: http://l2.espacenet.com/dips/viewer?PN=EP394160&CY=fr&LG=fr&DB=EPD
[10]: http://www.microsoft.com/mscorp/ip/format/xmlpatentlicense.asp
[11]: http://gibuskro.lautre.net/informatology/ffii/trips.html
[12]: http://swpat.ffii.org/brevets/effets/openmint/swxai-openmint.fr.pdf
[13]: http://kwiki.ffii.org/?NlparlDetal040603En
[14]: http://swpat.ffii.org/papers/eubsa-swpat0202/tech/
[15]: http://l2.espacenet.com/dips/viewer?PN=EP756731&CY=fr&LG=fr&DB=EPD
[16]: http://l2.espacenet.com/dips/viewer?PN=EP664041&CY=fr&LG=fr&DB=EPD
[17]: http://www.legifrance.gouv.fr/WAspad/RechercheSimpleLegi.jsp
[18]: http://swpat.ffii.org/patents/effects/cifs/index.en.html
[19]: http://www.reuters.fr/locales/c_newsArticle.jsp?type=topNews&localeKey=fr_FR&storyID=5456227

La reproduction exacte et la distribution intégrale de cet article
sont permises sur n'importe quel support, pourvu que cette
notice et les mentions de copyright soient préservées.

Analysis of software patentability in Europe

François PELLEGRINI — 2004-05-17T02:43:50Z

Legal analysis of software patentability

Why the question of software patents is badly put

The proponents of software patentability justify it by the need to
protect the software components which are increasingly present within
innovative tangible inventions, and for which, according to them,
copyright does not give sufficient protection. An example that is
often considered by members of patent offices is the one of a new
washing machine that washes the linen more efficiently, and such
that the innovating washing sequence is implemented by means of a
computer. The software carried out by this computer would be,
within this framework, at the origin of the technical contribution
brought by this new machine, and should thus be covered by patent
claims.

This test case is used as a conceptual basis to postulate the existence
of "technical" software, as opposed to software "as
such" which would not be patentable because they do not
produce any technical contribution.

However, postulating the possible existence of a discrimination
between "technical" and "non-technical"software
based on the examination of their effects, which we call the
"doctrines of software technicality", cannot hold vis-a-vis a
rigorous analysis. In the above-mentioned case of the washing
machine, the technical effect is the improvement of the washing of
linen by the machine. This effect is obtained by application of an
innovating washing process, consisting in the dispensation of
detergent at such or such moment of the washing cycle, by the
realization of better mixing of water and of the linen, etc., all
operations carried out by the machine in the material world. The
software operating the machine does control this innovating
washing process, but is not, in itself, the source of it.
It is the process which is innovative and produces the technical
effect wished for, not the software.

Any software, carried out by a computer, does nothing but handling symbolic quantities according to a
pre-established program, independently of the way in which these
symbolic quantities are materialized within the computer which carries
out the program (electrons, photons, magnetic moments, quantum states,
etc). The computer, in order to interact with the physical world,
needs peripherals, which materialize the symbolic systems quantities
into physical actions in the outside world: activation of a servo unit,
displaying of a particular luminous information on a screen, etc.
The software which drives the washing machine can thus be carried out
on a simulator, and run exactly as it would do within the washing
machine, but without producing the expected technical effect. It is
because the technical effect is independant from the considered
software, but resides in the effective carrying on of the process.

The legislator had already analyzed this situation to draw the
conclusions which it imposes, and to authorize the claiming of
industrial processes. The manufacturer of innovative washing machines
can thus claim his process of innovative washing as well as the
machine which carries it out without needing software patents at all.

Let us notice to conclude this section that a software which would sum
the values of two quantities of reagents that are present in the tanks
of a chemical reactor could be regarded as "technical"
according to the doctrines of software technicality, while it would
not if it were used to compute the sum of the balances of two bank
accounts, while both software perform exactly the same process.

Similarly, one cannot consider that some software produces a technical
effect when it allows to "perform computations more
efficiently" or it "improves the efficiency of a
computer". Let us remark at first that these doctrines are even
more radical than the ones of software technicity, because it would
allow one to consider as "technical" any software that
provides better processing performance than any existing software,
without any reference to any given problem, or rather by considering
that any use of a computer constitutes in itself a technical application.

The actual efficiency of a given algorithm being completely
dependent on the architecture of the computer onto which it has
been implemented and is running, the alledgedly technical
features of an algorithm are not linked to it, but rather are
based on the adequacy between the subjacent hardwere and
implementation considerations that belong to the realm of
copyright, since they are specific to each individual
implementation of software on a given architecture.
The consideration of increased efficiency is therefore not
effective to define a stable frontier between alledgedly
"technical" and "non-technical"
software.

The impossible formalism of software technicity

The conceptual impossibility to discriminate between "technical"
and "non-technical" software condemns in advance to failure any
attempt to embody this discrimination into legislative texts.
An obvious example of this failure is the text proposed by the Irish
presidency which, while defending itself from allowing total
patentability of software, indeed achieves this result.

Recital 7b, supposed to limit software patentability, is contradicted by
Recital 13 and Article 2b which say explicitly that software alone can
carry out a "technical contribution", and by Article 5b which
allows the patenting of software carrying out such "technical
contributions". These articles allow any “inventor” to
patent any type of software, because those are always created to solve a
given problem. In the same way, Mr. David Sant, official representative of
the European Patent Office attached to the European institutions, confirmed
in a conference at the European Parliament the official interpretation of
the European Patent Office, which considers as a technical contribution
any situation within which one can say that one has to consider technical
factors before beginning to program, a situation encountered by all
computer programmers and which neutralizes Article 4a, allegedly
designed so as to limit software patentability only to
"technical" software.

The choice of the legislator thus cannot be a half-measure: either he
fully endorses the enablement of a regime of total software
patentability, or it entirely rejects it, as does the doctrines worked
out by the European Parliament during the vote of the directive in
first reading, which rejects claims on software, while still allowing
the patenting of material inventions and of industrial processes that
make use of software for their control, which was already the case in
the past, since it is the very meaning of Article 52.2 of the
European Patent Convention.

This binary choice, of considerable economic and strategic consequences,
cannot be done lightly, all the more than the extension of patentability
would be practically irreversible.

Are software patents legally mandatory?

Some players refer to Article 27 of the TRIPS Treaty, which requires
the existence of patents for any field of technology, to justify the
legal need for software patents. As underlined by Mr. Paul Hartnack,
General Comptroller of the United Kingdom Patent Office, this
interpretation is not the only possible one.

One can consider, like the Commission and the Council do in their
proposals for a directive, that software is intrinsically technical,
and that Article 27 of TRIPS requires to have software patents. One
can also consider, like the European Parliament, that software does
not reside within a field of technology but with that of intellectual
works, and thus beyond the range of Article 27 of TRIPS.

Here again, policy makers are free to decide, because the choice
between the two doctrines is still possible.

Software Patents and copyright are exclusive

Until now, the copyright and patent regimes had coexisted without
conflict, their purposes being different, since copyright dealt with
the protection of individual works of authors, while the purpose of
patents was to protect inventors of innovative processes implemented
within (non-unique) apparatuses designed to solve a given problem.

The extension of the patent system to software constitutes the first
major attack to copyright law, to which the legislator had, after deep
thinking, incorporated software. This assimilation was altogether
natural because software, just like books, consist in the production
of a textual original work (the source code of the program), resulting
from the combination of elementary ideas. For an adventure novel,
these elementary ideas can be: "love scene on a balcony",
"twins being mistaken one for another", etc. For software, it
can be: "alphabetical sorting in a list", "displaying a
progress bar telling the user to have patience", etc.

Unlike copyright, which protects final works, software patents, which
protect against the imitation of features, allows the protection of
these elementary ideas, and thus prevent whoever to realize a program
implementing a protected idea. This would amount, in the case of
books, to be allowed to claim elementary ideas such as the balcony
love scene, although the same idea can lead to very different
implementations, such as the balcony love scenes of Romeo and
Juliet and of Cyrano de Bergerac, which are not plagiarisms
one of the other.

Software patents, by allowing their holders to claim elemenary ideas,
thus constitutes an extremely powerful monopoly-building tool, because
the holder of a single patent can prevent the selling of all
software implementing this idea, whatever their application domains
can be.

In this extent, software patentability can be regarded as violating
the TRIPS and WIPO treaties. Indeed, Article 10 of TRIPS stipulates
that software belongs to the realm of copyright, and Article 13 of
TRIPS, as Article 10 of WIPO, that one cannot systematically prejudice
the legitimate interests of the rightholders. However, considering
software patentable indeed prejudices the rightholders, since the
author of an original software can be prevented from marketing it
for the reason that this software infringes on one or several
software patents, irrespective of legitimate exceptions such as
harm to public morals. As more and more artistic creations
make use of software (such as video games, for instance), the
occasions for litigation can only increase, at the detriment
of creation in the considered industries.

Although one can argue that these articles in TRIPS do apply only
to the exceptions which the legislator could introduce in the
copyright regime only, it is clear, considering the spirit of these
treaties, that the forging of software patentability, which has
no legal necessity, tends to have a destructuring, rather than
structuring, effect on existing intellectual property regimes that
exist to date, and no one knows what could be the long-term
consequences of the extension of the patent regime to fields for
which it had indeed not be designed for, neither for which it has
economic justification.

The decision to introduce software patents amounts to answering
implicitly the question of knowing which system, between the patent or
the copyright regimes, must have preeminence, without any possibility
of debate nor of being able to check the validity of this approach.

The copyright regime is oriented towards the protection of existing
works, already accessible to the public since already created, the
existence of the protection making it possible to regulate by
subsequent contracts the way the public can access these works.

The software patent regime allows one to claim an idea, irrespective
if there exist or not concrete achievements implementing these ideas
and being able to benefit to the public.

In the case of software, priviledging the patent regime compared to
the copyright regime thus amounts to priviledging the defensive and
anti-competitive behaviors which are inherent to the patent system,
based on exclusion and rent seeking, as opposed to the active behavior
of the creator of original works putting them at the disposition of
the public in a context of free competition.

Economic analysis of software patentability

The legal analysis of software patentability presented above made it
possible to show that there exists no legal obligation by international
treaties, TRIPS for example, to create them. Quite to the contrary
even, the existence of software patents creates incoherence and legal
insecurity for software rightholders. The decision to have or not
software patents within the European Union can thus be freely decided
on the basis of economic and strategic criteria only.

Another consequence of this analysis is that, contrary to what the
writers of the directive have announced, the conditions for software
patentability in Europe will indeed be similar to those into force in
the United States, with the result that the current situation of the
United States on the matter constitutes the exact reflection of what
the situation will be in Europe if the version of the Irish presidency
of the directive were accepted.

Let us also notice that, with respect to this analysis the conceptual
bases of which are simple and accessible to any person who has some
knowledge of the domain, , one can legitimately wonder about the
the apparent ingenuity of the writers of the directive who pretend
that there exist a discrimination between "technical" and
"non-technical" software.
If one gives them a minimum of credit, one will arrive at the
conclusion that they are fully aware of this impossibility, which
leads to wonder about their motivation to legitimate total software
patentability even at the price of a distortion of the truth.

If simple ideological motivation cannot be neglected, it is not
sufficient to account for all of the observed behaviors. One therefore
has to acknowledge the existence of a collusion of economic interests
between the leaders of the patent offices, the members of the various
commissions of experts involved in the drafting of the directives, and
the people in charge of the legal departments of some big companies,
with the deliberate purpose of providing these latter the most
efficient anti-competitive weapons as possible, considering that the
legal services of these companies are the biggest customers of the
patent offices, which themselves live on the fees of granted patents,
and considering that there exists an important professional porosity
between these three communities.

Software claims, interoperability, and monopolies

The analysis of the version of the directive endorsed by the Irish
presidency shows that most of this text is designed so as to favor the
creation and enforcement of monopolies on whole sectors of the
data-processing industry, without any counterpart for the consumer.

Article 5b of this text introduces program claims, which make it possible
to sue any software creator, vendor, or user, provided that a patent has
been granted on any of the elementary ideas that the software implements.
This would allow big companies with large legal departments to scare
potential users of competing software, well before inolving courts, thus
distorting competition in an insidious way.

This text also rejects any right to interoperability. Article 6 does
nothing but maintaining the exceptions of retro-engineering and
decompilation allowed by the directive of 1991 regarding the
protection of software by cupyright. But whereas these exceptions are
sufficient in the context of copyright, they are worthless in the
context of patents, since any manufacturer who reimplements, for the
sake of interoperability, processing methods for a patented file
format, would be infringing of this patent.

The mode of creation of software, based on cumulative innovation, as
well as the very short development cycles of this industry, do not
allow any longer to account for the existence of a patent system which
is expensive, heavy and slow.

Indeed, unlike in the material world, the time necessary for a
competitor to imitate some software is hardly any less than time taken
by the development of the original software, because the development
itself constitutes the most expensive activity in comparison to the
simple fact of having the idea of the software, which yields that, in
this very reactive market, initial innovators have time to profit from
their protucts before any competitor appears.

Moreover, any such competitor can gain market shares only if its
product is of better quality, brings additional innovations, or is
less expensive than the original product, which can only be, as
development costs are almost identical by what precedes, if the market
price of the original product were too high. A proof of this is that,
on any given market segment, a product of good quality and at a
reasonable price has little competitors.

Therefore, without software patents to build monopolies, competition,
innovation, and consumers win. These consumers are both private
individuals and companies of all sizes and all fields of activity,
because the impact of information technologies on productivity affects
every sector of the economy.

To conclude, let us note that patents does not bring any information
which is not already public, since the features of a software that are
protected by some patent naturally appear when using the software,
thus allowing any "person skilled in the art" to understand
its principles of operation. Let us also remark that the jargon used
to write these patents is in general incomprehensible to any computer
professional, and of a technical level which is so low that no
information is usable in practice, since the goal of the drafting of
the patent is to be as generic as possible in order to block as many
competitors as possible.

The economic threat of the software patents for the European data-processing industry

According to a report by the French Commissariat au Plan issued
in 2002, the French software sector is essentially made of small
structures. Indeed, 58 % of the 28,500 companies of the sector
have at most two employees. These figures are almost equivalent in
Germany and in the other countries of the Union. Small and
medium-sized enterprises of the software sector represent more than
70 % of jobs and wealth produced by this sector in Europe,
not counsidering the software departments of large industrial and
service companies (such as banks, insurance companies, etc) which
contribute to a great extent to the development of "in house"
software which will never be marketed but could nevertheless be
subject to software patent infringement lawsuits.

Small companies are on average more innovative, more reactive, and
more inclined to base their development on the creation of new
products than on an established system of monopolistic revenues. In
fact, since SMEs of the software sector represent its economic
majority, as well as a pool of creativity that is necessary to the
development of new technologies, all new regulations should be
developed for their benefit.

Regarding the introduction of software patentability in Europe, this
same report of the Commissariat Général au Plan sees in the
"abrupt decision to extend patentability to software[...]
real dangers for the European industry, because of the considerable
unbalance between the United States and Europe on the matter",
and insists that "Only the armed peace prevailing to date,
because of the legal uncertainty that remains around the notion
of software patent, indeed explains that existing patents [the
about 30,000 doubtful software patents already granted by the EPO]
are not used more often.".

A system of incentives for innovation cannot be effective unless it
encourages the production of final goods that benefit to citizens and
thus to the society at large. On the opposite, the monopolization
of upstream concepts disadvantages the production of such goods,
because it is then more profitable for an economic actor which has
patented a concept to seek rents from the entities taking the
commercial risk to carry out the final products, rather than to make
such products by itself and be under the risk of patent infringement
lawsuits from its likes. Consequently, the more the extent of the
patent is broad and lasting, the more behaviors of predation and risk
avoidance are favored, to the detriment of innovation. In the case of software,
the minimum duration of 20 years, which would be imposed by TRIPS if
one would consider software as patentable, represents more that 10 times
the average duration of the commercial life of any software, which is
an economic nonsense, as this blocks further developments by other
innovators who must, in order to enter the market, pay fees for basic
ideas the development cost of which, if any, has been paid back many
times already.

At best do large players agree on patent portfolio exchanges, which
allows them to pretend they live in a patentless world, but this has
several perverse effects. First, what economic interest is there for
these companies, and therefore for their customers and by extension
for the society at large, to finance the filing of patent being used
to counter the existence of other patents, whereas the absence of
patents would amount to exactly the same? Then, after such exchanges,
the only entities having to support the cost of the licenses are the
innovative small and medium-sized enterprises, which cannot enter the
markets which would reimburse their investments. The system thus
functions exactly the opposite as it should, wrongly penalizing the SMEs.

Software patents are moreover a danger for investors. Without patents,
any investor is certain to be able to market the software he financed,
and thus to have a return on investment if these products fulfill a
need. With software patents, any economically worthwile software may
be attacked, and the return on investment is more dubious. The very
recent exhaustive study carried out in the United States on more than
130.000 software patents and 1600 Usonian companies between 1976 and
to date showed that the expenditure in software patents replaced more
than 10 % of the expenditure of R&D of the companies, at the
national level.
During Federal Trade Commission hearings on the subject, some company
CEOs reported that they were going to devote up to 35 % of their
Research & Development expenditure to the building of software patent
portfolios, in order to try to protect themselves from infringement
lawsuits, although these costly portfolios could not be of any help to
protect them from the very high legal expenses that a competitor would
like them to spend, at the detriment of their middle and long-term
competitiveness.

In this context, it is legitimate to think that, because the market
allowing the best return on investment will be a Europe without
software patents, the companies that will succeed better will be
European companies, that will be more close to their customers, and more
able to provide the necessary R&D effort. Any company basing its
software development in the United States can be subject to
infringement lawsuits on the basis of US software patents, since
software developers may implement, knowingky or not, algorithms that
are patented in the United States. On the opposite, European developers
would be free to develop their software without constraints. Thus, an
Europe without software patents is likely to succeed in attracting
Usonian companies willing to secure their developments, reversing the
direction of the flow of emigration of computer professionals.

Let us notice by the way that nothing prevents a European company from
filing patents in the United States to try to improve its chances to
penetrate this market. This investment is small in comparison of the
one to obtain European patents, and without common measure with the
tribute which European SMEs should pay to large US companies if software
patents were legalized in Europe.

Last update : 16 May 2004
Author : François PELLEGRINI

Analyse de la brevetabilité logicielle en Europe

François PELLEGRINI — 2004-05-17T02:14:36Z

Analyse juridique de la brevetabilité logicielle

Pourquoi la question des brevets logiciels est mal posée

Les partisans de la brevetabilité logicielle justifient celle-ci par
la nécessité de protéger la partie logicielle qui est de plus en plus
présente au sein des biens matériels innovants, et pour laquelle le
régime du doit d'auteur n'offre pas selon eux de protection suffisante.

Un exemple couramment abordé par les membres des offices de brevets
est celui d'une machine à laver nouvelle, en ce qu'elle lave mieux le
linge, le programme de lavage innovant étant mis en oeuvre au moyen
d'un ordinateur. Le logiciel exécuté par cet ordinateur serait donc,
dans ce cadre, à l'origine de la contribution technique apportée par
cette nouvelle machine, et devrait donc être couvert par les
revendications du brevet.

Ce cas d'école sert de base conceptuelle pour postuler l'existence de
logiciels « techniques », par opposition aux
logiciels « en tant que tels », qui ne seraient,
eux, pas brevetables, car ne produisant pas de contribution technique.

Cependant, le postulat de l'existence d'une discrimination possible
entre logiciels « techniques » et
« non techniques », basée sur l'examen de leurs
effets, que nous appellerons la « doctrine de la technicité
logicielle », ne peut tenir face à une analyse rigoureuse.

Dans le cas pré-cité de la machine à laver, l'effet technique est
l'optimisation du lavage du linge par la machine. Cet effet est obtenu
par l'application d'un procédé de lavage innovant, consistant en
l'adjonction de lessive à tel ou tel moment du cycle de lavage, par la
réalisation d'un meilleur brassage de l'eau et du linge, etc., toutes
opérations effectuées par la machine dans le monde matériel. Le
logiciel de contrôle de la machine, lui, ne fait que mettre en oeuvre
ce procédé innovant de lavage, mais n'en est pas la source. C'est le
procédé qui est innovant et produit l'effet technique souhaité, et
non le logiciel.

Un logiciel, exécuté par un ordinateur, ne fait que manipuler des
quantités symboliques selon un programme pré-établi, indépendamment de
la manière dont ces quantités symboliques sont matérialisées à
l'intérieur de l'ordinateur qui exécute le programme (électrons,
photons, moments magnétiques, états quantiques, etc). L'ordinateur,
pour interagir avec le monde physique, a besoin de périphériques,
destinés à matérialiser les quantités symboliques manipulées par le
programme en actions physiques sur le monde extérieur :
activation d'un servo-commande, émission d'une information lumineuse
déterminée sur un afficheur, etc. Le logiciel de pilotage de la
machine à laver peut ainsi être exécuté sur un simulateur, et
s'exécuter de façon identique à celle dont il le ferait au sein de la
machine à laver, sans pour autant provoquer l'effet technique
attendu. C'est donc que l'effet technique est indépendant du logiciel
considéré, mais réside dans la mise en oeuvre effective du procédé.

Le législateur avait déjà analysé cette situation pour en tirer les
conséquences qui s'imposent, et autoriser la revendication de procédés
industriels. Le fabricant de machines à laver innovantes peut donc
revendiquer son procédé de lavage innovant et la machine qui le réalise
sans avoir besoin le moins du monde de brevets logiciels.

Remarquons pour conclure qu'un logiciel additionnant deux quantités de
réactifs dans les cuves d'un réacteur chimique pourrait être considéré
comme technique selon la doctrine de la technicité logicielle, mais ne
le serait pas s'il s'agissait d'additionner les soldes de deux comptes
bancaires d'un client, alors qu'il s'agit bien de la mise en oeuvre
du même processus.

On ne peut pas, de même, considérer qu'un logiciel produit un effet
technique lorsqu'il « permet d'effectuer des opérations
plus rapidement » ou « améliore l'efficacité
d'un ordinateur ». Remarquons tout d'abord que cette
doctrine est encore plus radicale que celle de la technicité
logicielle, en ce qu'elle permettrait de considérer comme
« technique » tout logiciel offrant de
meilleures performances de traitement que les logiciels existants,
sans référence à un problème donné, ou plutôt en considérant que toute
utilisation d'un ordinateur constitue en soi une application
technique.

L'efficacité réelle d'un algorithme donné étant entièrement dépendante
de l'architecture de l'ordinateur sur lequel il a été implémenté et
s'exécute, les caractéristiques prétendument techniques d'un
algorithme ne lui sont donc pas liées, mais sont basées sur
l'adéquation entre le matériel sous-jacent et des considérations
d'implémentation qui appartiennent au domaine du droit d'auteur, car
spécifiques à chaque réalisation particulière de logiciel pour une
architecture donnée. La considération d'efficacité accrue
n'est donc pas opérante pour définir une frontière stable entre logiciels
prétendument « techniques » et
« non-techniques ».

L'impossible formalisme de la doctrine de la technicité logicielle

L'impossibilité conceptuelle à discriminer entre logiciels
« techniques » et « non
techniques » voue d'avance à l'échec toute tentative de
mettre cette discrimination en oeuvre au sein de textes
législatifs. Un exemple flagrant de cet échec est le texte proposé par
la présidence Irlandaise qui, tout en se défendant d'autoriser une
brevetabilité logicielle totale, arrive effectivement à ce résultat.

Le Considérant 7b, censé restreindre la brevetabilité logicielle, est
contredit par le Considérant 13 et l'Article 2b qui disent explicitement
qu'un logiciel peut à lui seul effectuer une « contribution
technique », et par l'Article 5b qui autorise le brevetage
de logiciels effectuant de tels « contributions
techniques ». Ces articles permettent à n'importe quel déposant
de breveter tout type de logiciel, car ceux-ci sont toujours créés pour
résoudre un problème donné. Ainsi, M. David Sant, représentant officiel
de l'Office Européen des Brevets auprès des institutions européennes,
a confirmé dans une conférence au Parlement Européen l'interprétation
officielle de l'OEB, qui attribue une contribution
technique à toute situation dans laquelle on peut dire qu'il faut
considérer des facteurs techniques avant de commencer à programmer,
situation dans laquelle se retrouvent tous les concepteurs de
logiciel, et qui rend inopérant l'Article 4a censé limiter la
brevetabilité logicielle aux seuls logiciels prétendument
« techniques ».

Le choix du législateur ne peut donc, en l'espèce, être en
demie-teinte : ou bien il assume pleinement la mise en place
d'un régime de brevetabilité logicielle totale, ou bien il la rejette
entièrement, à l'image de la doctrine élaborée par le Parlement
Européen lors du vote de la directive en première lecture, qui rejette
les revendications logicielles, tout en autorisant le brevetage
d'inventions matérielles et de procédés recourant à des logiciels pour
leur mise en oeuvre, ce qui était déjà le cas par le passé, puisque
c'est là même le sens de l'Article 52.2 de la Convention Européenne du
Brevet.

Ce choix binaire, aux conséquences économiques et stratégiques
considérables, ne peut donc se faire à la légère, d'autant plus que
l'extension de la brevetabilité au logiciel serait en pratique
irréversible.

Les brevets logiciels sont-ils juridiquement nécessaires ?

Certains acteurs du dossier excipent de l'Article 27 des accords
ADPIC, qui requièrent l'existence de brevets pour tout domaine
de la technique, pour justifier la nécessité juridique des brevets
logiciels.

Comme l'a souligné M. Paul Hartnack, Comptroller General de l'Office
des Brevets du Royaume-Uni, cette interprétation n'est pas la seule
possible. On peut considérer, comme la Commission et le Conseil
l'ont fait dans leurs propositions de directive, que le logiciel est
intrinsèquement technique, et que donc l'Article 27 d'ADPIC oblige à
disposer de brevets logiciels. On peut tout aussi considérer, comme
l'a fait le Parlement Européen, que le logiciel n'appartient pas
au domaine de la technique mais à celui des oeuvres de l'esprit,
et donc au delà de la portée de l'Article 27 d'ADPIC.

Ici encore, toute latitude est laissée au politique pour trancher,
car le choix entre les deux doctrines reste possible.

Brevetabilité logicielle et droit d'auteur sont exclusifs

Jusqu'à présent, les régimes du droit d'auteur et du brevet
avaient coexisté sans conflit, leurs objets étant différents,
puisque le droit d'auteur s'attachait à la protection des
auteurs d'oeuvres individuelles, tandis que le brevet
s'attachait à la protection des inventeurs de procédés
innovants mis en oeuvre au sein d'appareils (non uniques)
permettant de résoudre un problème donné.

L'extention du système des brevets aux logiciels constitue le premier
empiètement majeur sur le régime du droit d'auteur, dans lequel le
législateur avait, après mûre réflexion, fait entrer le
logiciel. Cette assimilation était somme toute naturelle car le
logiciel, tout comme le livre, consiste en la production d'une oeuvre
textuelle originale (le code source du programme), résultant de la
mise en forme d'idées élémentaires simples. Pour un roman d'aventures,
ces idées élémentaires peuvent être : « scène d'amour
sur un balcon », « jumeaux se faisant passer
l'un pour l'autre », etc. Pour le logiciel, ce peuvent
être : « tri alphabétique dans une liste »,
« affichage d'une barre de progression pour faire patienter
l'utilisateur », etc.

À la différence du droit d'auteur, qui protège l'oeuvre finale, le
brevet logiciel, qui protège contre l'imitation des caractéristiques,
permet de protéger ces idées individuelles, et donc d'empêcher
quiconque de réaliser un programme mettant en oeuvre une idée
protégée. Ceci reviendrait dans le cas du livre à pouvoir revendiquer
des idées élémentaires comme la scène d'amour sur un balcon, alors que
pourtant la même idée donne lieu a des réalisations très différentes,
comme les scènes de Roméo et Juliette et celle de Cyrano de Bergerac,
qui ne sont pas des plagiats l'une de l'autre.

Le brevet logiciel, en premettant à son détenteur de revendiquer les
idées élémentaires, constitue donc un outil anti-concurrentiel
extrêmement puissant, car le détenteur d'un unique brevet peut exiger
l'arrêt de la commercialisation de tous les logiciels implémentant
cette idée, quels qu'en soit les domaines d'application.

En ce sens, la brevetabilité logicielle peut être considérée comme
contrevenant aux accords ADPIC et OMPI. En effet, l'Article 10 d'ADPIC
stipule explicitement que les logiciels doivent être régis par le
régime du droit d'auteur, et l'Article 13 d'ADPIC, tout comme
l'Article 10 de l'accord OMPI, que l'on ne peut systématiquement
porter préjudice aux intérêts légitimes des ayant-droits. Or, le fait
de considérer les logiciels comme brevetables porte effectivement
atteinte au droit des auteurs, puisque l'auteur d'un logiciel original
peut être empêché de le diffuser au prétexte que ce logiciel violerait
un ou plusieurs brevets logiciels, sans que des considérations
d'exceptions comme l'atteinte à la morale publique puissent être
invoquées. De plus en
plus de créations artistiques faisant intervenir des logiciels (les
jeux vidéo, par exemple), les occasions de conflit ne peuvent donc
que se multiplier, au détriment de la création dans les industries
concernées.

Même si l'on peut arguer que ces articles d'ADPIC ne s'appliquent
qu'aux seules exceptions que le législateur pourrait introduire au
sein même du droit d'auteur, il n'en reste pas moins que, vis-à-vis de
l'esprit de ces traités, la création de toutes pièces de la
brevetabilité logicielle, en dehors de toute nécessité juridique, a
plutôt un effet déstructurant que structurant sur les différents
régimes de propriété intellectuelle existant à ce jour, et nul
ne sait quelles pourraient être les conséquences à long terme
de l'extension du régime de la brevetabilité à des domaines pour
lesquels il n'avait certainement pas été conçu, ni pour lequel
il n'a de justification économique.

La décision d'introduire les brevets logiciels revient à
répondre implicitement à la question de savoir qui du système des
brevets ou du droit d'auteur doit avoir la prééminence, sans
aucune possibilité de débat ni pouvoir vérifier la validité de
cette approche.

Le système du droit d'auteur était orienté vers la protection des
oeuvres existantes, déjà accessibles au public puisque déjà créées,
l'existence de la protection permettant justement de régler de façon
contractuelle les modalités d'accès du public à ces oeuvres.

Le système du brevet logiciel permet, lui, de revendiquer une idée,
indépendamment du fait qu'il existe déjà ou non des réalisations
concrètes mettant en oeuvre ces idées et pouvant bénéficier au
public.

Dans le cas du logiciel, privilégier le brevet par rapport au droit
d'auteur équivaut donc à privilégier les comportements défensifs et
anti-concurrentiels inhérents aux brevets, basés sur l'exclusion et
l'obtention de rentes, par rapport au comportement actif du créateur
d'oeuvres originales mettant celles-ci à la disposition du public dans
un cadre de libre concurrence.

Analyse économique de la brevetabilité logicielle

L'analyse juridique de la brevetabilité logicielle présentée ci-dessus
a permis de montrer qu'il n'existe aucune obligation juridique, par
les traités internationaux ADPIC par exemple, de les créer. Bien
au contraire même, l'existence des brevets logiciels est créatrice
d'incohérence et d'insécurité juridique pour les ayant droits de
logiciels. La décision de disposer ou non d'une brevetabilité logicielle
totale au niveau de l'Union Européenne peut donc être librement décidée
sur la base des seuls critères économiques et stratégiques.

Une autre conséquence de cette analyse est que, contrairement à ce
qu'annoncent les rédacteurs de la directive, les conditions
de brevetabilité logicielle en Europe seront bien similaires à
celles en vigueur aux États-Unis, ce qui fait que la situation
actuelle des États-Unis en la matière consitue l'exact reflet
de ce qu'elle sera en Europe si la version de la présidence
Irlandaise de la directive était acceptée.

Remarquons également que, au vu de cette analyse dont les bases
conceptuelles sont simples et accessibles à toute personne un tant
soit peu familière avec le domaine, on peut légitimement s'interroger
sur l'apparente ingénuité des rédacteurs de la directive à vouloir
faire croire à l'existence d'une séparation entre logiciels techniques
et non techniques. Si on leur accorde un minimum de crédit, on
arrivera à la conclusion qu'ils ne peuvent qu'être au courant de cette
impossibilité, et il faut alors s'interroger sur leur motivation à
vouloir légitimer la brevetabilité logicielle totale fut-ce au prix
d'une entorse à la vérité.

Si le simple parti pris idéologique ne peut être écarté, il n'est pas
suffisant pour rendre compte de l'ensemble des comportements observés.
On ne peut donc que constater l'existence d'une collusion d'intérêts
économiques entre les dirigeants des offices de brevets, les membres
des différentes commissions d'experts sollicitées pour la rédaction
de la directive, et les responsables des services juridiques de
quelques grandes entreprises, dans le but avéré de donner à ces
dernières les armes juridiques anti-concurrentielles les plus
efficaces possibles, sachant que les services juridiques de ces
entreprises sont les plus gros clients des offices de brevets,
qui eux-mêmes vivent des redevances sur les brevets acceptés, et
qu'il existe une grande porosité professionnelle entre ces trois
milieux.

Revendications logicielles, interopérabilité, et monopoles

L'analyse de la version de la directive soutenue par la
présidence Irlandaise montre que ce texte fait une part très
importante à la possibilité de créer et maintenir des monopoles
sur des pans entiers de l'industrie informatique, sans aucune
contrepartie pour le consommateur.

L'Article 5b de ce texte introduit les revendications de
programmes, qui permettent de poursuivre tout créateur, vendeur, ou
utilisateur de logiciel, pour peu qu'un brevet ait été accordé sur
l'une des idées élémentaires que ce logiciel implémente. Ceci
permettrait aux grandes entreprises disposant de services juridiques
étoffés d'effrayer les utilisateurs potentiels de logiciels
concurrents, avant même le recours aux tribunaux, distordant ainsi la
concurrence de façon insidieuse.

Ce texte nie également tout droit à l'interopérabilité. L'Article 6 ne
fait que maintenir les exceptions de rétro-ingénierie et de
décompilation prévues par la directive de 1991 sur la protection du
logiciel par le droit d'auteur. Mais alors que ces exceptions sont
suffisantes dans le contexte du droit d'auteur, elles sont sans effet
dans le contexte des brevets, puisque tout fabricant de logiciel
réimplémentant, dans un but d'interopérabilité, des méthodes de
traitement d'un format de fichier breveté serait en contrefaçon du
brevet.

Le mode de création du logiciel, basé sur l'innovation cumulative,
et le cycle de développement très court de cet industrie, ne permettent
pas de plus de justifier l'existence d'un système des brevets jugé
coûteux, lourd et lent.

En effet, à la différence d'avec le monde matériel, le temps
nécessaire à un concurrent pour imiter un logiciel est à peine plus
faible que le temps pris pour développer le logiciel original, car le
développement proprement dit constitue l'activité la plus coûteuse en
comparaison du simple fait d'avoir l'idée du logiciel, ce qui fait que
dans ce marché très réactif les innovateurs initiaux ont le temps de
tirer le bénéfice de leurs produits avant qu'un compétiteur ne se
présente.

De plus, un tel compétiteur ne peut gagner des parts de marché que si
son produit est de meilleure qualité, apporte des innovations
supplémentaires, ou bien est moins cher que le produit original, ce
qui ne peut se faire, comme les coûts de développement sont identiques
d'après ce qui précède, que si le prix de vente du produit original
était trop élevé. La preuve en est que, sur un segment de marché
donné, un produit de bonne qualité et à un prix raisonnable a peu de
compétiteurs.

Ainsi, sans brevets logiciels pour construire des monopoles, la
compétition, l'innovation, et les consommateurs sont favorisés. Ces
consommateurs sont à la fois les particuliers et les entreprises de
toutes tailles et de tous secteurs d'activité, car l'impact des
technologies de l'information sur la productivité affecte tous les
secteurs de l'économie.

Pour conclure, notons que le brevet n'apporte de même aucune
information qui ne soit déjà publique, puisque les fonctionnalités du
logiciel protégées par le brevet apparaissent naturellement à l'usage
de ce logiciel, permettant à tout « homme de
l'art » d'en saisir le fonctionnement. Remarquons de plus
que le jargon utilisé pour rédiger ces brevets est en général
incompréhensible pour tout informaticien, et d'un niveau technique si
bas qu'il n'apporte aucune information utilisable en pratique, puisque
le but de la rédaction du brevet est d'être la plus généraliste
possible afin de bloquer le plus de compétiteurs possible.

La menace économique des brevets logiciels pour l'industrie informatique européenne

Selon un rapport du Commissariat général au Plan français datant de
2002, l'économie du logiciel en France repose pour l'essentiel sur de
petites structures. Ainsi, 58 % des 28 500 entreprises du secteur
comptent deux employés au maximum. Ces chiffres sont à peu près
équivalents en Allemagne et dans les autres pays de l'Union. Les
Petites et Moyennes Entreprises du secteur du logiciel représentent
plus de 70 % des emplois et de la richesse produite par ce
secteur en Europe, sans compter les services informatiques des grandes
entreprises industrielles et de services (banques, assurances, etc)
contribuant pour une très grande part au développement de logiciel
"maison", qui ne sera jamais distribué commercialement, mais pourraient
néanmoins faire l'objet d'attaques en contrefaçon de brevet logiciel.

Les petites entreprises sont en moyenne plus innovantes, plus
réactives, et plus enclines à baser leur développement sur la création
de nouveaux produits plutôt que sur un système établi de rentes
monopolistiques. De fait, puisque les PME du logiciel représentent
la majorité économique du secteur, et un vivier de créativité
nécessaire au développement de technologies nouvelles, c'est à leur
profit que doivent être conçues les règlementations.

Concernant l'introduction de la brevetabilité logicielle en Europe, ce
même rapport du Commissariat Général au Plan voit dans la
« décision abrupte d'extension de la brevetabilité aux
logiciels[...] des dangers réels pour l'industrie européenne,
du fait du déséquilibre considérable qui existe entre les États-Unis
et l'Europe en la matière », et précise que
« Seule la paix armée qui prévaut actuellement, du fait de
l'incertitude juridique qui entoure la notion de brevet de logiciel,
explique en effet que les brevets existants [les 30 000 brevets
logiciels douteux déjà délivrés par l'OEB] ne soient pas plus fréquemment
utilisés ».

Un système d'incitation à l'innovation ne peut être efficace que
s'il encourage effectivement la production de produits finis
bénéficiant aux citoyens et donc à la société dans son ensemble.
En revanche, la monopolisation des concepts amont défavorise la
production de tels biens, car il est alors plus rentable pour un
acteur économique ayant breveté un concept d'obtenir des royalties
vis-à-vis des entités prenant le risque commercial de réaliser les
produits finis, plutôt que de concevoir lui-même de tels produits et
de risquer de se trouver en butte aux attaques de la part de ses
semblables. Ainsi, plus la portée du brevet est large et étendue dans
le temps, et plus on encourage les comportements de prédation,
l'absence de prise de risque, au détriment de l'innovation. Dans le
cas du logiciel, la durée minimale de 20 ans, qui serait imposée par
les accords ADPIC si l'on considérait le logiciel comme brevetable,
représente plus de 10 fois la durée de vie commerciale moyenne d'un
logiciel, ce qui n'a économiquement aucun sens, car cela bloque les
développements ultérieurs d'autres innovateurs, qui doivent, pour
pénétrer le marché, acquitter des royalties sur des idées de base dont
le coût de développement, si tant est qu'il y en ait eu un, a déjà été
maintes fois remboursé.

Au mieux les grands acteurs passent-ils entre eux des accords
d'échanges de portefeuilles de brevets, ce qui leur permet de se
croire dans un monde sans brevets, mais ceci a plusieurs effets
pervers. D'abord, quel intérêt économique y a-t-il pour ces
entreprises, donc pour leur clients et par extenion pour la société
dans son ensemble, à financer le dépôt de brevets servant à contrer
l'existence d'autres brevets, alors que l'absence de brevets
reviendrait exactement au même ? Ensuite, à l'issue de tels
échanges, les seules entités ayant à supporter le coût des licences
sont les petites et moyennes entreprises innovantes, qui ne peuvent
ainsi accéder aux marchés qui rentabiliseraient leurs
investissements. Le système fonctionne donc exactement à l'opposé de
comme il le devrait, pénalisant abusivement les PME.

Les brevets logiciels sont de plus un danger pour les investisseurs.
Sans brevets, tout investisseur est certain de pouvoir commercialiser
les logiciels qu'il a financé, et donc d'avoir un retour sur
investissement si ces produits trouvent un marché. Avec un système de
brevets logiciels, tout logiciel économiquement valable est
attaquable, et le retour sur investissement est plus incertain. La
très récente étude exhaustive menée aux États-Unis sur plus de 130.000
brevets logiciels et 1600 entreprises étasuniennes entre 1976 et nos
jours a montré que les dépenses en brevets logiciels se sont
substituées à plus de 10 % des dépenses de R&D des entreprises,
au niveau national. Lors d'auditions de la Federal Trade Commission
sur le sujet, certains dirigeants d'entreprises étasuniens ont même
indiqué qu'ils allaient consacrer jusqu'à 35 % de leurs dépenses
de Recherche et Développement à se constituer des portefeuilles de
brevets logiciels afin de tenter de se prémunir contre des attaques en
contrefaçon, sans que ces coûteux portefeuilles les protègent
aucunement des frais de contentieux élevés qu'un concurrent pourrait
vouloir les voir débourser, au détriment de leur compétitivité à
moyen et long terme.

Dans ce contexte, il est légitime de penser que, parce que le marché
permettant le meilleur retour sur investissement sera une Europe sans
brevets logiciels, les entreprises les plus à même d'y réussir seront
les entreprises européennes, plus proches de leur clients, et plus à
même de fournir les efforts de R&D nécessaires. Toute entreprise
basant son développement logiciel aux États-Unis peut faire l'objet
d'une attaque en contrefaçon sur la base des brevets logiciels
étasuniens, puisque les développeurs codent, sciemment ou non, des
algorithmes brevetés sur le sol étasunien. En revanche, les
développeurs européens seront libres de réaliser leurs logiciels sans
contraintes. Ainsi, une Europe sans brevets logiciels peut même
réussir à attirer des entreprises étasuniennes soucieuses d'y
pérenniser leurs développements, renversant le sens des flux
migratoires des informaticiens.

Remarquons d'ailleurs que rien n'empêche une entreprise européenne de
déposer des brevets aux États-Unis pour essayer d'augmenter ses
chances de pénétrer ce marché. Cet investissement est minime en
comparaison de celui à réaliser pour obtenir des brevets européens, et
sans commune mesure avec le tribut que les PME européennes devraient
verser aux grandes entreprises étasuniennes si les brevets logiciels
étaient légalisés en Europe.

Dernière mise à jour : 16 mai 2004
Auteur : François PELLEGRINI

Enjeux stratégiques du contrôle de l'innovation immatérielle et logicielle

François PELLEGRINI — 2004-04-27T09:35:32Z

Introduction

La récente bataille au Parlement Européen au sujet de la brevetabilité logicielle est un épiphénomène d'un conflit de plus grande ampleur, dont les enjeux économiques et stratégiques sont considérables, car ils se situent, au delà même des rivalités industrielles, au niveau de la perpétuation des cultures et de leur accès au savoir.

Afin de rester d'une longueur raisonnable, cette note ne traite que des aspects stratégiques pour Europe de la privatisation des biens informationnels, et encore n'en aborde que certains. Elle a pour but de montrer en quoi il est important de suivre les recommandations du Parlement Européen en matière de (non-)brevetabilité logicielle, et surtout en quoi il est vital que ce mouvement soit poursuivi dans le cadre d'une réflexion stratégique cohérente et soutenue dans la durée.

Le lecteur intéressé par une description générale du sujet de la brevetabilité logicielle est invité à se reporter à [1] et, pour les arguments purement économiques justifiant le refus de la brevetabilité logicielle, à [2].

Les brevets logiciels, une aberration économique

Tout d'abord, comme l'ont montré de nombreuses études économiques menées sur le terrain [3,4], un système d'incitation à l'innovation ne peut être efficace que s'il encourage effectivement la production de produits finis bénéficiant aux citoyens et donc à la société dans son ensemble. En revanche, la monopolisation des concepts amont défavorise la production de tels biens, car il est alors plus rentable pour un acteur économique ayant breveté un concept d'obtenir des royalties vis-à-vis des entités prenant le risque commercial de réaliser les produits finis, plutôt que de concevoir lui-même de tels produits et de risquer de se trouver en butte aux attaques de la part de ses semblables. Ainsi, plus la portée du brevet est large et étendue dans le temps, et plus on encourage les comportements de prédation, l'absence de prise de risque, au détriment de l'innovation. Dans le cas du logiciel, la durée minimale de 20 ans, qui serait imposée par les accords TRIPS si l'on considérait le logiciel comme brevetable, représente plus de 10 fois la durée de vie commerciale moyenne d'un logiciel, ce qui n'a économiquement aucun sens, car cela bloque les développements ultérieurs d'autres innovateurs, qui doivent, pour pénétrer le marché, acquitter des royalties sur des idées de base dont le coût de développement, si tant est qu'il y en ait eu un, a déjà été maintes fois remboursé.

Au mieux les grands acteurs passent-ils entre eux des accords d'échanges de portefeuilles de brevets, ce qui leur permet de se croire dans un monde sans brevets, mais ceci a plusieurs effets pervers. D'abord, quel intérêt économique y a-t-il pour ces entreprises, donc pour leur clients et par extenion pour la société dans son ensemble, à financer le dépôt de brevets servant à contrer l'existence d'autres brevets, alors que l'absence de brevets reviendrait exactement au même ? Ensuite, à l'issue de tels échanges, les seules entités ayant à supporter le coût des licences sont les petites et moyennes entreprises innovantes, qui ne peuvent ainsi accéder aux marchés qui rentabiliseraient leurs investissements. Le système fonctionne donc exactement à l'opposé de comment il le devrait, pénalisant les PME, qui représentent plus de 70 % des emplois et de la richesse produite dans le secteur en Europe.

Il est donc peu surprenant que les pro-brevets soient majoritairement la communauté des conseils en « propriété intellectuelle » et des offices de brevets, qui prospèrent avec l'augmentation du nombre de brevets déposés et du contentieux généré, ainsi que les services brevets de quelques grandes entreprises, qui en retirent un pouvoir accru au sein de ces entreprises, alors même que les directions techniques y sont opposées (mais n'ont pas voix au chapitre, comme c'est le cas pour Alcatel, par exemple).

Les brevets logiciels, une menace stratégique pour l'Europe

L'argumentaire des quelques grandes entreprises qui lobbient pour la brevetabilité logicielle ne tient pas, et est dangereux à long terme pour les nations européennes.

Tout d'abord, remarquons que la majorité de ces entreprises ne produisent que marginalement du logiciel, même si celui-ci prend une part plus importante des fonctions logiques mises en œuvre au sein des dispositifs qu'ils produisent. Cependant, comme on l'a vu plus haut, c'est la capacité à réaliser des produits qu'il faut protéger, et non les fonctions logiques abstraites elles-mêmes. Ne parlons même pas du lobbying effectué par les entreprises des média (type Vivendi), qui ne sont que des utilisatrices de logiciel, et ne cherchent qu'à monopoliser les outils de visionnage de leurs contenus.

Ensuite, ces entreprises justifient du besoin de breveter les logiciels par la nécessité de contrôler l'innovation amont, tout en délocalisant la production effective des biens matériels vers des pays émergents comme la Chine ou l'Inde. Rappelons à ce propos la déclaration de Serge Tchuruk d'Alcatel, souhaitant que cette dernière soit une « entreprise sans usines ». Ce comportement est irréaliste et suicidaire, car :

il conduit à réduire de façon significative le nombre d'emplois européens, transformant ces « grandes » entreprises prétendument européennes en sociétés financières employant des ouvriers des pays émergents pour fournir les consommateurs européens en produits dont les bénéfices des ventes iront majoritairement à des actionnaires non-européens. Le solde des mouvements de capitaux créés est ainsi négatif pour la zone Europe ;
imaginer que des pays comme la Chine et l'Inde resteront les exécutants dociles de bureaux d'étude et de recherche européens, sous prétexte que ceux-ci détiendraient les brevets sur les technologies mises en oeuvre, est irréaliste. Vu les efforts d'éducation entrepris par l'Inde et la Chine, et le très faible coût de leur main d'œuvre ouvrière, mais aussi scientifique, il est plus économique pour ces pays de redévelopper leur propre technologie que de payer au prix fort les licences de tels brevets. L'intérêt de ces pays est, à l'heure actuelle, en profitant du savoir accumulé du fait des délocalisations des sites de production, de redévelopper à bas coût leurs propres technologies, et de les breveter à leur tour. Ces brevets leur garantiront le monopole sur leurs propres marchés nationaux, de plusieurs milliards de consommateurs au total, et non encore saturés, à la différence des marchés européen et nord-américain. Ces marchés ne pourront pas être pénétrés par les entreprises occidentales car celles-ci, pour pénétrer ces marchés et pour cela accéder aux brevets « locaux » protégeant les technologies locales, devront consentir à l'échange de leurs portefeuilles de brevets, qui ne leur seront donc plus d'aucune utilité, et auront toujours à amortir le coût d'une recherche et développement plus coûteuse. L'exemple du développement de la technologie EDV est éclairant sur ce point [5,6]. L'étape suivante sera donc que ces grandes entreprises, qui n'auront plus d'« européennes » que leur siège social, délocalisent elles aussi leurs laboratoires de recherche et développement, contribuant à l'apauvrissement scientifique de l'Europe. Il est donc dangereux de leur faire confiance et de relayer, au nom de l'Europe, leur demande de plus de « propriété intellectuelle », qui ne sert en fait que les intérêts privés immédiats de leurs actionnaires au détriment des intérêts à long terme de l'Europe.

Les mécanismes monopolistiques comme les brevets ne favorisent que les acteurs dominants [7].

D'ailleurs, les États-Unis n'ont pu émerger rapidement vis-à-vis de l'Europe, au début du vingtième siècle, qu'en violant allègrement nombre de brevets européens, comme en atteste la presse de l'époque... Au vu du déclin du financement de la recherche en France, et également en Europe, il n'est pas raisonnable de penser que l'Europe puisse prospérer dans un tel cadre, prise en étau entre la puissance industrielle encore supérieure mais déclinante des États-Unis, et la puissance croîssante des pays émergents comme la Chine et l'Inde. Rappelons pour mémoire que la troisième nation ayant accédé au vol spatial habité n'a pas été une nation européenne, mais la Chine.

Le seul moyen pour l'Europe de continuer à exister scientifiquement consiste à prôner l'ouverture et la collaboration, pour mutualiser les développements et, par ce faire, abaisser le coût global de sa recherche, lui permettant ainsi de ne pas avoir à la délocaliser. La période de progrès technique que nous connaissons est la continuité de près de quatre cents ans de libre diffusion de la connaissance, succédant aux habitudes de secret mathématique prévalant depuis l'antiquité et jusqu'avant la Renaîssance. Il est aberrant d'imaginer que certains puissent prôner un retour à la parcellisation de la connaissance en faisant passer cette régression historique pour un progrès.

Pour conclure, on ne peut que s'interroger sur le bénéfice pour l'Europe à adopter une législation prétendument censée la favoriser vis-à-vis des États-Unis et du Japon, alors que justement ces mêmes États-Unis font pression sur certains eurodéputés (majoritairement des conservateurs Anglais, les vieux réflexes ayant la vie dure) pour qu'ils la votent [8]. Seraient-ils masochistes à ce point ?

Actions à mener

Il est essentiel que le gouvernement français soutienne sans réserves la position adoptée par le Parlement Européen sur la non brevetabilité de l'immatériel [9] (idées, méthodes éducatives et commerciales, logiciels), qui constitue une position équilibrée, qui sera de plus bénéfique pour l'Europe sur les plans économique et stratégique.

Cette position consiste à rappeler que le logiciel ne peut en aucun cas être brevetable, et que, dans le cas de dispositifs hybrides faisant intervenir du matériel et du logiciel, ces dispositifs sont brevetables à la seule condition que la partie matérielle constitue une invention au sens de la loi des brevets. Cette doctrine est simple et efficace en ce que :

elle trace une délimitation claire entre ce qui est brevetable et ce qui ne l'est pas, à l'inverse de toutes les contorsions intellectuelles avancées par les offices des brevets pour créer une distinction entre logiciels « techniques » et « non-techniques », qui conduit en pratique à autoriser le brevetage de tous les logiciels, ainsi que des méthodes intellectuelles, commerciales, ou même des jeux ;
elle est consistante avec les accords ADPIC (TRIPS), en ce que, le logiciel n'étant pas considéré comme un domaine technique, celui-ci ne rentre pas dans le cadre de l'article ;27. En revanche, considérer que certains logiciels seraient laquo ; techniques » et donc brevetables obligerait, au sens de TRIPS, à ce que tous les logiciels le soient.

Références

[01]: http://www.abul.org/brevets/articles/tsuba_note.php3
[02]: http://www.abul.org/brevets/articles/parlement_20030924.php3
[03]: http://www.ftc.gov/os/2003/10/innovationrpt.pdf
[04]: http://www.researchoninnovation.org/swpat.pdf
[05]: http://www.china.org.cn/english/scitech/78549.htm
[06]: http://www.china.org.cn/english/scitech/80346.htm
[07]: http://www.theworld.com/obi/Bill.Gates/Challenges.and.Strategy, voir le paragraphe intitulé « PATENTS »
[08]: http://swpat.ffii.org/papers/eubsa-swpat0202/ustr0309/
[09]: http://swpat.ffii.org/papers/europarl0309/index.en.html

La reproduction exacte et la distribution intégrale de cet article sont permises sur n'importe quel support, pourvu que cette notice et les mentions de copyright soient préservées.

"EuroLUG party" au Parlement Européen

2004-04-25T07:37:16Z

euroLUGparty jeudi 15 Avril 2004 à 9h à Bruxelles : Conférence avec des groupes d'utilisateurs de logiciels libres au Parlement européen - bâtiment Spinelli, salle Petra Kelly (ASP 01G2)

Les Verts au Parlement européen invitent les représentants des groupes d'utilisateurs Linux des 25 États membres de la future Union européenne à une réunion à Bruxelles en vue de renforcer le travail de réseau au sein de la communauté du logiciel libre en Europe afin de préparer la deuxième lecture sur la directive brevet logiciel (plus particulièrement dans les nouveaux Etats membres) et d'informer au sein du Parlement Européen sur la nature du logiciel libre et son fonctionnement.

Cette conférence a lieu le lendemain de la conférence et manifestation contre les brevets logiciels organisée par la FFII et Eurolinux à Bruxelles.

Arguments contre les brevets logiciels

François PELLEGRINI — 2003-10-20T20:21:57Z

L'industrie du logiciel a été innovante bien avant que les brevets logiciels existent. Les brevets logiciels, en permettant la constitution de monopoles, sont une limitation de la liberté d'entreprendre, qui ne pourrait être acceptée que si cela procurait un bénéfice social global à la société dans son ensemble. Cependant, toutes les études économiques réalisées aux États-Unis depuis l'introduction des brevets logiciels ne montrent aucun effet positif, mais plutôt des effets négatifs sous la forme de procès en contrefaçon injustes et coûteux.

Alors que le cycle de développement d'un logiciel est de 18 mois en moyenne, la durée des brevets logiciels ne peut être inférieure à 20 ans du fait des accords TRIPS, ce qui correspond à un monopole sur 13 générations technologiques, hautement anti-compétitif. Le système des brevets, conçu pour les cycles de développement lents de l'industrie manufacturière, n'est pas adapté à une économie de biens immatériels.

La file d'attente d'examen des brevets à l'Office Européen des Brevets pour le domaine relatif aux logiciels est actuellement de plus de 4 ans, ce qui fait que les brevets seraient délivrés trop tard et ne pourraient pas protéger l'innovation. Leur seule utilité est donc en tant qu'instruments d'anti-compétition, et pour ce faire ils doivent avoir la plus grande « portée » possible, afin que leur rendement économique, pour qui les dépose, soit le meilleur possible.
Les rédacteurs de tels brevets sont donc enclins à écrire les revendications les plus larges possibles, et l'OEB est enclin pour sa part à accorder le plus de brevets possible, puisqu'il n'est pas touché par l'insecurité juridique qu'il provoque et vit des rentes sur les brevets accordés.

Le coût énorme des procès en contrefaçon de brevets (en moyenne de plus de 1 million de Dollars par partie aux États-Unis) est inacceptable pour la majorité des PME, pour qui le seul fait d'être attaquée constitue un risque légal majeur.
Comme c'est déjà le cas aux États-Unis, des brevets logiciels douteux pourraient être utilisés comme moyen de harcèlement juridique et de racket légal au détriment de PME innovantes [9,10, 11]
C'est sans doute une des raisons pour lesquelles les défenseurs des brevets logiciels proviennent majoritairement des départements juridiques de grandes entreprises de matériel, alors que leurs opposants sont majoritairement des professionnels de l'informatique et des PME, qui représentent la majorité des emplois et de la richesse produite dans ce secteur.

À la différence d'avec le monde matériel, le temps nécessaire à un concurrent pour imiter un logiciel est à peine plus faible que le temps pris pour développer le logiciel original, car le développement proprement dit constitue l'activité la plus coûteuse en comparaison du simple fait d'avoir l'idée du logiciel, ce qui fait que dans ce marché très réactif les innovateurs initiaux ont le temps de tirer le bénéfice de leurs produits avant qu'un compétiteur ne se présente.
De plus, un tel compétiteur ne peut gagner des parts de marché que si son produit est de meilleure qualité, apporte des innovations supplémentaires, ou bien est moins cher que le produit original, ce qui ne peut se faire, comme les coûts de développement sont identiques d'après ce qui précède, que si le prix de vente du produit original était trop élevé. La preuve en est que, sur un segment de marché donné, un produit de bonne qualité et à un prix raisonnable a peu de compétiteurs.
Dans tous les cas, sans brevets logiciels pour construire des monopoles, la compétition, l'innovation, et les consommateurs sont favorisés. Ces consommateurs sont à la fois les particuliers et les entreprises de toutes tailles et de tous secteurs d'activité, car l'impact des technologies de l'information sur la productivité affecte tous les secteurs de l'économie.