 |
Questa pagina è stata trascritta, formattata e riletta. | |
| Brevetti e software:per chi suona la campana? | 117 |
lazione di codice sorgente che implementi il “trovato” brevettato, e il brevetto viene concesso sulla base di una vaga descrizione funzionale, la tutela viene garantita di molto in anticipo rispetto a qualsiasi dimostrazione di avere un’implementazione minimamente funzionante. Realizzare un’implementazione funzionante significa utilizzare molto tempo e risorse di programmazione, e niente, in questo passo, viene aiutato dalla presenza di una domanda di brevetto, che solitamente è anche in regime di segretezza, per cui probabilmente al momento dello sviluppo nessuno è nemmeno cosciente della sua esistenza. Siccome il sistema premia chi arriva per primo, vi è un forte incentivo ad ottenere il brevetto ancora prima di aver iniziato a creare una tale implementazione.
Una volta ottenuto il brevetto, la privativa consente in teoria di lucrare sull’investimento, rilevante, in ricerca e sviluppo (che nel software è sostanzialmente scrittura di codice e prova di corretto funzionamento) di altri, prima ancora di averlo fatto in proprio. Ciò è tra l’altro dimostrato dall’abbondare di “non practicing entities”, soggetti che non hanno magari mai nemmeno scritto una linea di codice, ma hanno saputo intuire dove nuove aree di progettazione del software si sarebbero mosse. Dunque l’incentivo non va a chi dovrebbe investire, anzi, ciò che dovrebbe essere un incentivo si trova ad essere un impedimento, in quanto sottrae risorse agli investimenti che dovrebbe promuovere.
Se devo muovere una critica al ragionamento del giudice Mayer, spesso il problema è l’inverso: si fornisce un incentivo quando è troppo tardi, nel senso che il “trovato” è un sottoprodotto di un’attività di programmazione che ci sarebbe comunque stata,
