Italia
Microsoft, il più grande produttore di software mondiale, ha recentemente annunciato nuovi modelli di licenza software[1] per l’anno 2006. Si tratta di piani di licenza che, sul piano contrattuale e dell’analisi giuridica, che qui interessa, segnano una piccola rivoluzione. Qualche premessa è d’obbligo per discutere, se pure sinteticamente, del tema.
Quando, negli anni ’80, con il grande successo del foglio elettronico “VISICALC”, ci si rese conto che il software poteva essere fonte di un business autonomo dalla vendita di hardware, fu sviluppato un tipo di modello di cessione dei diritti che prevede che l’autore/produttore del software riservi per sé tutti i diritti “di permettere” e, attraverso una articolata “lista di divieti”, consente all’utilizzatore solo la fruizione del software, senza ulteriori diritti.
L’avanzata sul mercato dei modelli di licenza aperti, introdotti per la prima volta dalla Free Software Foundation e la contemporanea presenza di una serie di modelli di licenza più o meno gratuiti (freeware, shareware, ecc.) ha mostrato che il business del software può essere articolato secondo declinazioni diverse dalla chiusura totale dei diritti.
Il mercato del software c.d. “proprietario” sta dunque delineando strategie precise in risposta alla rivoluzione del software aperto che, inizialmente, ne ha sconvolto gli equilibri e le logiche.
Tali strategie vanno a incidere sulla licenza, sull’accordo cioè tra creatore ed utilizzatore del software, intendendo con tale termine il prodotto software[2] in quanto i “servizi” forniti attraverso software possono prescindere dalla licenza.
In tale ottica le licenze, pur nel rispetto della configurazione “chiusa”, fanno propri alcuni elementi tipici delle licenze di software aperto e, comunque, introducono elementi innovativi in un ottica di concorrenzialità rispetto all’open source.
Prima di vedere brevemente quali siano le nuove licenze, può essere di interesse accennare al fatto che il dibattito sulla validità delle “licenze” software e sulla loro natura contrattuale, che, pur a fasi alterne, ha a lungo impegnato la dottrina giuridica, non si è mai del tutto concluso: sulle linee di principio vi è generale accordo ma nei dettagli vi sono varie posizioni abbastanza variegate.
Dunque, è probabile che con l’emergere di “nuovi” tipi di licenza, sia sul fronte proprietario che sul fronte “open source”, nuove posizioni emergeranno sulla natura contrattuale delle licenze medesime.
In estrema sintesi[3], le posizioni della dottrina che si è occupata dell’argomento dei contratti di licenza sono di tre tipi e tutte partono dalla constatazione che la licenza di software è una forma di contratto non prevista dalle norme del codice civile e dunque ricade nella categoria dei cc.dd. “contratti atipici”: (i) alcuni da qui ritengono che la licenza software, in quanto contratto atipico, debba seguire regole sue proprie; (ii) altri ritengono che la licenza software, pur atipica, debba essere assimilata a contratti noti (es. locazione, appalto, compravendita); (iii) altri ancora ritengono che, proprio in quanto atipica, la licenza software possa essere regolata attraverso la contemporanea applicazione delle norme previste per più contratti “tipici”, possa cioè, ad esempio, seguire in parte le regole della locazione, in parte quelle della compravendita e in parte quelle dell’appalto.
Nell’esporre tali posizioni, i commentatori non hanno trascurato di approfondire il fondamentale interrogativo della validità complessiva e parziale del contratto di licenza software: esistono radicali dissensi in materia ed il dibattito è più che mai aperto sia in Europa che oltreoceano. In particolare, può alle volte creare incertezze il sistema dell’accettazione “shrink wrap” o “click wrap”, che va dunque attuato con una serie particolare di accortezze[4].
Alla luce di tale quadro, si possono finalmente analizzare i contenuti dei nuovi accordi di licenza recentemente proposti sul mercato dal market leader e che, per i loro contenuti innovativi, si apprestano, con ogni probabilità, a divenire il riferimento per chi produce e commercia software.
Le licenze in questione (denominate da Microsoft MS-PL “Permissive License”, MS-CL “Community License” e MS-RL “Reference License”) hanno tutte in comune l’elemento di consentire all’utenza di “visualizzare” il codice sorgente del software che hanno in licenza. Le più evolute consentono anche customizzazioni e modifiche del software.
La più “aperta” è certamente Permissive License che consente di vendere/distribuire copie di derivati del programma senza dover corrispondere royalties alla casa madre. Ciò si spiega in un’ottica di licensing di strumenti di sviluppo, che devono necessariamente essere “incorporati” nella programmazione e nei siti web realizzati da chi è programmatore di professione. Questi avrà acquistato la licenza da Microsoft per utilizzare lo strumento di sviluppo e, attraverso la Permissive License, potrà evitare di appesantire le licenze dei propri prodotti con clausole che riconoscono la terzietà di diritti su alcune parti del proprio creato. La licenza, in sostanza, richiama il meccanismo di funzionamento della licenza BSD, su un cui derivato si basa, peraltro, il cuore del sistema MAC OS X.
“Community License” opera secondo un meccanismo simile alla Mozilla license, consentendo al licenziatario di integrare con proprio codice quanto già sviluppato dal creatore del software. La licenza è anch’essa royalty-free. E’ la licenza che dovrebbe consentire forme di sviluppo collaborativo anche partendo da software proprietario con la differenza che il cerchio di sviluppatori, stavolta, include anche Microsoft.
Anche MS-RL, che consente la mera visualizzazione del sorgente, assolve ad una funzione altamente competitiva nel sistema.
Tale elemento assolve ad un’esigenza ormai fortemente sentita in certi mercati: rassicurare l’utilizzatore del software che non vi sono falle di sicurezza/privacy consentendo al proprio ufficio IT di analizzare il codice e sottoporlo a verifica/perizia.
Un esempio è quello della sanità pubblica o dei software assicurativi: tali software gestiscono dati sensibili e il rischio “privacy” è altissimo; è tanto alto da non poter tollerare “al buio” errori di programmazione della software house; è troppo alto perché al Cliente non sia consentito effettuare verifiche in prima persona sul codice sorgente e, se del caso, implementazioni di protocolli addizionali di sicurezza o richieste di modifica.
L’esempio appena portato consente di individuare uno degli elementi di competitività rispetto ai quali il software proprietario cerca di entrare in concorrenza con l’open source per il quale è crescente l’interesse della Pubblica Amministrazione.
L’elemento della visione del sorgente, nelle sue varie declinazioni, non deve però indurre in errore circa la natura del contratto stipulato: il sorgente non viene mai ceduto ma solo concesso (in visione, in uso, in modifica, ecc.).
Né d’altra parte le licenze Open Source sono diverse sotto tale profilo: anche la licenza Open Source per eccellenza, la GPL, non cede affatto la titolarità del sorgente ma si limita a cedere diritti aperti sul medesimo secondo la tecnica del copyleft.
In cosa allora risiede la differenza tra software proprietario “aperto” e software in licenza Open Source?
La differenza fondamentale è proprio nella tecnica copyleft: le licenze Open Source, attraverso la normativa sul diritto d’autore, impongono ai licenziatari di distribuire il software sempre alle medesime condizioni, accompagnato da copia della licenza e dei sorgenti e, dunque consentendo di effettuare le operazioni che ad essi sono state consentite. Una violazione di questo obbligo implica una violazione della licenza[5]. La licenza Open Source impone inoltre di rendere pubbliche le modifiche. In tal caso il licenziatario che modifica entra in contatto sia con l’autore che con comunità allargate di sviluppatori che mantengono l’unità di un progetto complesso (es. il “project samba”).
Nel caso del software proprietario l’apertura del codice è rivolta al primo e unico licenziatario. I rapporti concernenti le eventuali modifiche del software sono configurate nell’ambito di un rapporto con il proprietario del codice e non con terzi in quanto, per quanto riguarda le licenze dove sono consentite modifiche, il creatore rinuncia alla royalty. E’ in sostanza assente l’elemento del copyleft.
Rimane un fondamentale interrogativo giuridico che riguarda ambedue le tipologie di software: la possibilità offerta al licenziatario di conoscere il sorgente del software in utilizzo, è idonea a salvaguardare il creatore del software da responsabilità per eventuali malfunzionamenti? In sostanza, il licenziatario che, disponendo del sorgente, utilizza il software lo accetta “nello stato in cui si trova”, assumendosi in proprio il rischio che il prodotto non sia conforme a quanto desiderato? E se ciò è vero, chi si trova licenziatario di tali tipologie di software per applicazioni “mission critical”, si deve tutelare con idonee coperture assicurative di cui pure si discute in dottrina?
Tali tipi di problematiche dovranno essere affrontati e dovranno seguire l’evoluzione delle nuove modalità contrattuali che caratterizzano il moderno mercato del software.
______________________________
[1] Si vedano in Rete, tra le molte news al proposito: http://www.cwi.it/showPage.php?template=articoli&id=13770 e http://it.news.yahoo.com/051020/195/3g2dc.html
[2] Tra le più recenti trattazioni che esaminano il problema della differenza tra prodotti software e servizi software, cfr. CUSUMANO, M.A., The business of software, Free Press, 2004. L’orientamento è di ascrivere l’uso delle licenze software “vere e proprie” esclusivamente al software inteso come prodotto, mentre il software inteso come servizio, per quanto possa denominare l’accordo con il creatore “licenza”, utilizza modelli contrattuali di contenuto diverso (es. appalto).
[3] Per approfondire il tema, fra i tanti cfr. ROSSELLO, I contratti dell’informatica, Milano, 1997 e DE SANCTIS V. M., La protezione delle opere dell’ingegno, vol. II, Milano, 2003.
[4] Cfr. sul dibattito circa la invalidità delle licenze, MUSTI B., Il contratto di licenza d’uso del software, in Contratto e Impresa, Padova, 1998, 1289 ss.
[5] Azionabile anche in giudizio, cfr. caso tedesco Fortinet, http://www.gplviolations.org
