Lavoce.info

Oltre Linux

Si può trasferire l’esperienza dell’open source in campo informatico ad altri aspetti del progresso tecnologico? A dispetto del problema del free-riding, la ricerca sullo sviluppo di un input comune a più processi produttivi può risultare addirittura maggiore in un contesto di General Public Licence rispetto a un regime di monopolio protetto da brevetto. Accade quando si ha un effetto di accrescimento del profitto totale dell’industria dovuto a un miglioramento tecnologico dell’input comune. Ciò suggerisce una nuova politica della brevettabilità.

Il dibattito sull’open source, o più propriamente sulla General Public Licence, è generalmente centrato sul software, dove in termini di miglioramento del prodotto la Gpl ha dato risultati estremamente positivi, in particolare con Linux.
Lavoce.info ha già discusso gli aspetti fondamentali del problema negli articoli di Gambardella e Santarelli-Bono. (LINK) Vorremmo aggiungere qualche commento su un’altra questione: cosa possiamo astrarre dall’esperienza di Linux pensando al progresso tecnologico in generale, non necessariamente “digitale”?

I due problemi dell’open source

Conviene tener distinte le due fasi principali del ciclo di vita di un nuovo prodotto: (i) la nascita, con l’invenzione primaria (per il software si pensi alla versione 0.01 di Linux, che Linus Torvalds mise in giro a beneficio di un centinaio di hackers, o al sistema Dos di Microsoft) e (ii) il successivo sviluppo, generato dai miglioramenti apportati da ricerca incrementale (ad opera della collettività degli sviluppatori o del monopolista proprietario del brevetto). Della General Public Licence si dice che permette a ognuno di “dare un mattone per avere in cambio una casa intera”. (1)
Ma lo slogan non racconta proprio tutto: primo, qualcuno deve aver gettato le fondamenta. (2) Secondo, vero è che in fase di sviluppo uno può dare un mattone e avere una casa intera in cambio, ma è altrettanto vero che la casa è sua anche se il mattone non ce lo mette: quindi, perché sprecarlo? In altre parole, l’adozione della Gpl presenta due problemi. Il primo, classico, è che l’assenza di brevettabilità riduce l’incentivo a inventare – in fase (i). L’altro, che a invenzione avvenuta, miglioramenti incrementali di qualità possono essere frustrati dal free-riding – in fase (ii).
Il primo problema, discusso già da Schumpeter e poi da Nordhaus in un famoso libro del 1969, è ancora più chiaro alla luce della teoria della crescita contemporanea che individua nel processo innovativo il motore principale dello sviluppo economico. (3) La prospettiva di profitti monopolistici garantita dalla brevettabilità rende profittevole l’attività di ricerca in quanto consente di recuperare costi iniziali che vendendo al costo marginale andrebbero inevitabilmente perduti. Fortunatamente, i processi innovativi non si arrestano del tutto in assenza di brevettabilità, e Linux ne è esempio eloquente. D’altra parte, è difficile contestare il fatto che tipicamente la brevettabilità costituisce un importante incentivo alla ricerca. (4)

Se l’input è comune a più processi produttivi

Il problema di free-riding creato dalla Gpl sugli sviluppi della nuova invenzione, con conseguente livello subottimale dell’investimento, è tipico dei beni pubblici (il risultato della ricerca diventa un bene pubblico con la General Public Licence). Tuttavia, il volume di ricerca su Linux ha di gran lunga superato quello messo in atto da Microsoft su Windows, e da un paio d’anni allo sviluppo di Linux concorre un pool di grosse imprese di telecomunicazioni e di produttori di hardware (in concorrenza fra loro) che finanziano l’Open Source Development Labs, dove non a caso lavora Torvalds a tempo pieno. Cosa sta succedendo? La nostra opinione è che stia accadendo qualcosa che non ha tanto a che fare con la natura digitale di Linux, quanto con la sua funzione di input comune a molteplici processi produttivi  (5).
Per ricorrere a un esempio non digitale e non high-tech, si pensi agli impianti frenanti che entrano nella produzione delle automobili, dei camion, degli aeroplani. La nostra idea, confermata nel contesto di un modello biperiodale, è che a dispetto del problema di free-riding, la ricerca sullo sviluppo di un input comune a più processi in un contesto di General Public Licence può risultare addirittura maggiore che in regime di monopolio protetto da brevetto. Accade quando a fronte dell’effetto negativo di bene pubblico, è presente un abbastanza forte effetto di accrescimento del profitto totale dell’industria dovuto alla qualità dell’input comune e alla conseguente crescente produttività dei processi produttivi delle singole imprese. In altre parole, l’impresa investe nell’input/bene comune nonostante così facendo avvantaggi non solo se stessa ma anche i concorrenti, se al contempo accresce abbastanza la dimensione della “torta” da dividere con loro. Questa dei beni intermedi largamente usati sembra dunque la categoria di prodotti su cui concentrarsi, al di là del software, per pensare alla possibilità di adozione della Gpl.

Quale politica dei brevetti

Ristretta in tal modo l’attenzione a un campo di applicazione potenzialmente proficuo, emerge comunque un tradeoff per la politica dei brevetti: orientarsi sulla brevettabilità, favorendo innovazioni primarie che andrebbero incontro a uno sviluppo di prodotto relativamente lento. Oppure imporre una Gpl sulle nuove invenzioni (del tipo in questione) garantendo uno sviluppo sostenuto di qualità, accettando però un rallentamento del loro tasso di natalità. Ci sono vie d’uscita? Alla ricerca di un intervento pubblico che riesca ad aggirare il tradeoff appena descritto, sembrerebbe ragionevole esplorare la possibilità di mantenere sì la brevettabilità, ma poi per quei beni in cui c’è più ricerca incrementale con Gpl che sotto regime di monopolio (del tipo da noi individuato), lo Stato acquisti i brevetti, e li rilasci con licenza Gpl.

(1) Sono parole di Ganesh Prasad, un web designer affascinato dalle implicazioni economiche e sociali di Linux, che utilizza dal 1996.
(2) Per Linux è stato Linus Torvalds, un finlandese freddoloso che voleva fare tutto da casa, come ricorda nella sua autobiografia “Rivoluzionario per caso” pubblicata da Garzanti.
(3) Si vedano ad esempio i capitoli disponibili dell’Handbook edito da Philippe Aghion e Steven Durlauf, di prossima pubblicazione.
(4) Il caso della brevettabilità del software piuttosto che la sua protezione con copyright, che tocca anche delicate questioni di brevettabilità delle idee, potrebbe essere un’eccezione, anche a causa degli intricati problemi legali che verrebbero a crearsi. Vedi il sito della Foundation for a Free Information Infrastructure,
ffii.org, per il dibattito in Europa.
(5) Aghion, P. e Modica S., “Open Source without Free-Riding”, in preparazione.

Lavoce è di tutti: sostienila!

Lavoce.info non ospita pubblicità e, a differenza di molti altri siti di informazione, l’accesso ai nostri articoli è completamente gratuito. L’impegno dei redattori è volontario, ma le donazioni sono fondamentali per sostenere i costi del nostro sito. Il tuo contributo rafforzerebbe la nostra indipendenza e ci aiuterebbe a migliorare la nostra offerta di informazione libera, professionale e gratuita. Grazie del tuo aiuto!

Leggi anche:  Metodo Pnrr per le politiche europee di sviluppo *
Leggi anche:  Se il robot fa valere i suoi diritti

Precedente

Sommario 15 giugno 2005

Successivo

L’Agenzia e la base imponibile delle addizionali locali

  1. francesco bogliacino

    Ho apprezzato molto l’articolo ma vi sono alcune cose che non mi tornano.
    In merito alla questione Linux sono assolutamente d’accordo sulla sua peculiarità, che discende essenzialmente dal costituire una infrastruttura fondamentale, l’insieme di vettori che ritagliano lo spazio in cui molte delle grandi corporations, oltre a centinaia di normali programmatori, hackers utenti si muovono.
    suggerirei però attenzione nel parlare di esclusività, tutta questa sottolineatura del sistema di incentivi tende a escludere tutto il problema degli incentivi non monetari, che non è affatto ininfluente. Basti pensare alla criminalizzazione della ricerca pubblica come inefficiente, quando gli Stati Uniti trainano il mondo proprio con la ricerca fatta da Nasa, Pentagono et similia. O per fare un esempio che quasi nessuno conosce i principali medicinali anti Aids sono stati realizzati interamente da laboratori privati e “approppriati” da Corporations.
    Inoltre l’inefficienza del sistema attuale (ancora peggio saranno i Trips) si vede bene nel fatto che una percentuale sconsiderata di innovazioni prodotte a basso livello sono poi comprate da aziende per “toglierle” semplicemente dal mercato.
    D’altra parte è sufficiente un banale modello a vontage capital per mostrare che in condizioni non concorrenziali ci può essere incentivo a resistere ai cambiamenti, in particolare quelli di “paradigma”.
    Per concludere, l’importanza delle curve di apprendimento e se vogliamo anche la peculiarità di molte innovazioni permette di usufruire di vantaggi, al punto che una tutela troppo ampia genera un costo troppo elevato in termini di scarsa diffusione delle innovazioni.
    Cordialmente
    Francesco Bogliacino

  2. Antonio

    Egr. Autori mi complimento per il vostro articolo ma credo che oltre alle vostre osservazioni bisogna aggiungere altri fattori per comprendere i successi/problemi dell’open source, i quali sono:
    1)Perche’ un programmatore (sia inteso come professionista sia come giovane studente) dovrebbe perdere tempo e soldi per programmare una cosa che dovra’ distribuirla gratis?
    la risposta e’ molto semplice, per essere visibile/famoso e quindi poter essere contattato da aziende per prestare i propri servigi. Infatti gia’ nell’ambito della sicurezza informatica sono molti gli hacker che oggi lavorano, con lauti stipendi, in aziende di sicurezza e lo stesso sta’ avvenendo/avviene con vari programmatori dei vari progetti Open Source.
    2)Oggi nel modo dello sviluppo software c’e’ un attore che ha una forza economica/politica
    spropositata rispetto agl’altri attori, infatti questo soggetto sfrutta la sua posizione monopolistica nei Sistemi Operativi per allargarsi in altri settori mettendo in forte difficolta’ le altre imprese informatiche.
    Infatti questo e’ il reale motivo che muove molte imprese a sostenere l’open source,
    le quali, seguendo la linea del male minore, risulta’ piu’ profittevole aiutare/finanziare progetti open source, e quindi eventualmente poter guadagnare su eventuali consulenze/corsi ecc., che intentare una lotta impari contro il Grande Monopolista.
    Concludendo le vostre tesi sono esatte ma come ho cercato di illustrare mancano di due attori fondamentali, uno e’ il programmatore/Hacker e l’altro e’ lo scontro tra il Grande Monopolista e le altre aziende del mondo I.T.

Lascia un commento

Non vengono pubblicati i commenti che contengono volgarità, termini offensivi, espressioni diffamatorie, espressioni razziste, sessiste, omofobiche o violente. Non vengono pubblicati gli indirizzi web inseriti a scopo promozionale. Invitiamo inoltre i lettori a firmare i propri commenti con nome e cognome.

Powered by WordPress & Theme by Anders Norén