Il calderone magico/Perché il valore di vendita è problematico
 |
Questo testo è completo. | |
| ◄ | Modelli che promuovono il valore d'uso - Il caso Cisco: ripartizione del rischio | Modelli basati sul valore di vendita indiretto | ► |
L’open source rende piuttosto difficile trarre un valore di vendita diretto dai software. Non si tratta di una difficoltà
tecnica: il codice sorgente non è né più né meno copiabile del binario e l’istituzione del copyright e di diritti di
licenza che permettano la riscossione del valore di vendita, non sarebbe necessariamente più difficile per i prodotti
open source che per quelli commerciali.
La difficoltà sta piuttosto nella natura del contratto sociale che si trova alla base dello sviluppo open source. Per tre motivi che si rinforzano a vicenda, la principale licenza open source proibisce la maggior parte delle forme di restrizione d’uso, ridistribuzione e modifica che faciliterebbero la riscossione di profitti derivanti dal valore di vendita. Per comprendere questi motivi, occorre esaminare il contesto sociale nel quale si sono evolute le licenze: la cultura hacker di Internet <http://www.catb.org/~esr/faqs/hacker-howto.html>.
Nonostante i miti sulla cultura hacker ancora assai diffusi (nel 1999) al suo esterno, nessuna di queste ragioni ha a che fare con l’ostilità nei confronti del mercato. Se è vero che una minoranza di hacker resta ancora ostile alla logica del profitto, la volontà generalizzata da parte della comunità di cooperare con aziende i cui prodotti si basano su Linux, come Red Hat, SUSE e Caldera dimostra che la maggioranza degli hacker sarebbe felice di lavorare a fianco del mondo dell’impresa, quando è nei loro interessi. Le ragioni reali per cui gli hacker guardano con scetticismo alle licenze che consentono guadagni diretti, sono assai più sottili e interessanti.
Una delle ragioni riguarda la simmetria. Mentre la maggior parte degli sviluppatori open source non oppone obiezioni sostanziali al fatto che altri traggano profitto dai loro doni, i più chiedono che nessuno (ad eccezione, eventualmente, del creatore di una parte del codice) si trovi in una posizione privilegiata per fare profitti. Il signor John Smith Hacker è d’accordo che la Fubarco tragga profitti dalla vendita del suo software o delle sue patches, ma solo nel caso che anche lui stesso, almeno in teoria, possa farlo.
Un’altra ragione riguarda le conseguenze indesiderate. Gli hacker hanno osservato che le licenze che comportano la restrizione e il pagamento di contributi per uso "commerciale" o vendita (il tentativo più comune e, a prima vista, nemmeno tanto assurdo, di recuperare il valore di vendita diretto) hanno effetti davvero inquietanti. Un caso specifico è la possibilità di controllare segretamente la legalità di attività come la ridistribuzione in antologie economiche su CD-ROM, che in linea di massima sarebbero da incoraggiare. Più in generale, le restrizioni sull’uso, la vendita, le modifiche, la distribuzione (e altre clausole presenti sulle licenze) comportano spese aggiuntive per la conformità della distribuzione e (con l’aumento dei pacchetti in circolazione e in utilizzo) una combinazione esplosiva di incertezza soggettiva e potenziali rischi legali. Poiché questi risultati si considerano dannosi, si registra una forte pressione sociale per mantenere le licenze semplici ed esenti da restrizioni.
L’ultima e più importante ragione riguarda la dinamica di revisione e di cultura del dono descritta in [HtN]. Le restrizioni sulle licenze, designate per proteggere la proprietà intellettuale o per percepire un valore di vendita diretto, hanno spesso l’effetto di rendere legalmente impossibile la biforcazione dei progetti (questo avviene, per esempio, per le licenze di Sun, le cosiddette "Community Source", per Jini e Java). Se la biforcazione incontra molto scetticismo ed è considerata come l’ultima risorsa (per le ragioni spiegate diffusamente in [HtN]), la presenza di quest’ultima risorsa si considera di capitale importanza in caso di incompetenza o defezione del gestore (a causa, per esempio, di una licenza troppo restrittiva).
La comunità hacker mostra una certa elasticità in materia di simmetria: per questo, tollera licenze, come NPL di Netscape, che concedono alcuni privilegi in materia di profitti agli autori originali del codice (nel caso specifico di NPL, il diritto esclusivo di utilizzare il codice open source di Mozilla in prodotti derivati, anche commerciali). Ma ha meno elasticità nei confronti delle conseguenze indesiderate e nessuna sul mantenimento della possibilità di biforcazione (ed è per questo che gli schemi elaborati dalla Sun per la "Community License" di Java e Jini sono stati in gran parte rifiutati dalla comunità).
Queste ragioni spiegano le clausole della Open Source Definition, scritta per esprimere il parere congiunto della comunità hacker sui requisiti essenziali delle licenze standard (GPL, licenza BSD, licenza MIT e Licenza Artistica). Queste clausole hanno l’effetto (ma non l’intenzione) di rendere molto difficile l’ottenimento di un valore di vendita.