Di che cosa parliamo
- Che cosa sono gli Open Science Data
- Come si brevetta il software in Europa
- Contratto e fiducia non sono alternativi
- Quali sono le quattro libertà del software libero
- Che cosa vuol dire open source
1. Che cosa sono gli Open Science Data
Una sottocategoria di open data entrati al centro del dibattito negli ultimi anni sono gli open data relativi alla ricerca scientifica, chiamati più comunemente open science data o anche open research data.
La diffusione delle tecnologie digitali e l’aumento esponenziale della capacità di archiviazione e di trasmissione di dati hanno fatto sì che negli ultimi decenni i ricercatori non si siano limitati a pubblicare i risultati dei loro studi nelle classiche forme testuali (tesi, articoli, saggi, monografie, report) o grafiche (diagrammi, tabelle, mappe), ma si siano spinti sempre più a diffondere anche i dataset su cui si sono fondati gli studi e da cui derivano le conclusioni raggiunte.
Si tratta di un passaggio indubbiamente rivoluzionario perché realizza a pieno titolo l’idea galileiana di un approccio scientifico basato sulla riproducibilità delle prove sperimentali e dei calcoli da parte di altri scienziati, i quali possono da un lato confermare o confutare i risultati estratti da quei dati, dall’altro possono partire dagli stessi dati per arrivare ad altri e ulteriori risultati.
I teorici che si sono occupati di questo tema (e del più ampio tema della open science) hanno individuato una serie di best practice per una virtuosa e innovativa condivisione dei dati della ricerca scientifica e hanno indicato le caratteristiche essenziali che tali dati devono avere: queste caratteristiche possono essere riassunte nell’acronimo FAIR, cioè Findable, Accessible, Interoperable, Reusable.
Come riferimenti in materia, si vedano l’articolo The FAIR Guiding Principles for scientific data management and stewardship di Wilkinson, Dumontier e Mons uscito su Nature / Scientific Data nel 2016 e il documento FAIR Principles.
Secondo il documento Fact Sheet on Creative Commons & Open Science realizzato dal chapter britannico di Creative Commons, la soluzione migliore per massimizzare il riuso dei dati della ricerca è sempre e comunque una dichiarazione di rilascio in pubblico dominio (come CC0). Secondo questo documento, dunque, anche una licenza di mera attribuzione risulta non ottimale se applicata ai dataset della ricerca scientifica (specie se si tratta di dataset prodotti da enti di ricerca pubblici o comunque nell’ambito di progetti di ricerca finanziati da fondi pubblici), perché comunque aggiunge un vincolo di tipo contrattuale rispetto alle modalità di menzione della paternità dell’opera e nello stesso tempo potrebbe comunicare l’errata percezione che esista sempre un diritto esclusivo sui dati, anche in quei casi in cui il dataset licenziato è invece per altre ragioni privo di qualsivoglia tutela.
2. Come si brevetta il software in Europa
Dopo che le scelte legislative degli anni Ottanta e Novanta avevano indicato la strada del copyright a scapito del brevetto, il dibattito sulla tutela del software non si assopì del tutto e a tratti registrava qualche voce a favore di un’introduzione della possibilità di brevettazione. E non come soluzione sostitutiva del copyright, bensì come soluzione aggiuntiva e complementare al copyright. Il software sarebbe quindi diventato uno dei più importanti casi di creazione intellettuale soggetto a una duplice tutela, o forse triplice se aggiungiamo la prassi ormai radicata di sfruttare l’istituto del segreto industriale sul codice sorgente.
L’aspetto bizzarro era che tra queste voci vi erano anche quelle di alcune aziende che invece solo un decennio prima avevano spinto decisamente verso la strada del copyright perché ritenuta meno complessa e dispendiosa. Una volta uscite dal mondo delle startup e diventate solide aziende multinazionali, quasi monopoliste nel loro settore, quelle stesse realtà magicamente avevano cambiato idea e iniziavano a trovare appetibile la strada del brevetto.
Il dibattito arrivò presto anche nelle corti statunitensi, che, sfruttando il diverso livello di creatività giuridica consentito ai giudici degli ordinamenti di common law, iniziarono a delineare alcuni casi di applicabilità del modello brevettuale al software in sovrapposizione al copyright e in sostanza a legittimare la prassi. L’ultimo step fu opera dell’Ufficio Brevetti degli Stati Uniti (USPTO), il quale nel 1996 pubblicò un documento intitolato Final Computer Related Examination Guidelines (Linee guida definitive per l’esame dei brevetti relativi ai computer) nel quale si stabiliva:
Non più brevetti ma computer implemented invention
L’applicazione pratica di un’invenzione relativa al computer è passibile di brevettazione. Questo requisito può essere separato dai divieti variamente formulati contro la brevettazione di idee astratte, leggi della natura o fenomeni naturali.
L’USPTO iniziò quindi ufficialmente ad accettare brevetti per quelle che vengono più propriamente chiamate computer implemented invention (ossia, invenzioni implementate attraverso il computer) ma che di fatto integrano una brevettazione di algoritmi e codice dunque di semplice software.
Il dibattito non riguardò solo gli USA ma arrivò anche da quest’altra parte dell’oceano, pur con qualche anno di ritardo. Si giunse quindi a una proposta di direttiva europea che aprisse formalmente la strada alla brevettazione di software anche nel vecchio continente: la Proposta di Direttiva CE COM(2002)0092 sulla brevettabilità delle invenzioni a mezzo elaboratore.
L’iter di approvazione (Francesco Paolo Micozzi nell’articolo I software e i brevetti offre una breve cronologia della proposta di direttiva. L’articolo è uscito sul numero 31 del 2005 della rivista LinuxPro ed è disponibile liberamente online sul sito dell’autore) venne però fermamente bloccato dal Parlamento Europeo con una storica votazione ad amplissima maggioranza che si è tenuta il 5 luglio 2006 e ha chiuso definitivamente un acceso confronto politico durato circa cinque anni. Visto il risultato schiacciante, la Commissione Europea all’epoca dichiarò che non avrebbe più riprovato a proporre una direttiva volta a introdurre la brevettazione di software.
Ciò nonostante, almeno negli USA i brevetti software rimangono una realtà ormai consolidata. E in Unione Europea, pur con la netta decisione del Parlamento, le aziende software riescono lo stesso a ottenere dall’Ufficio Brevetti Europeo la registrazione di computer implemented invention sfruttando l’elasticità delle maglie del sistema. Benché sia indiscusso il divieto di brevettare software in sé, le aziende interessate a ottenere una tutela brevettuale trovano il modo di camuffare le domande di brevetto e di dimostrare che l’invenzione oggetto della domanda di brevetto non è puro software ma qualcosa di più complesso di cui il software è solo una componente (anche se il più delle volte è la componente principale).
3. Contratto e fiducia non sono alternativi
Circola un equivoco molto pericoloso secondo cui contratto e fiducia siano alternativi l’uno all’altra. Come se mettere nero su bianco un accordo fosse necessariamente un sintomo di mancanza di fiducia tra le parti; e come se a firmare contratti fossero solo persone malfidenti e insicure dei propri rapporti interpersonali. Ma come, vuoi un contratto?! Allora non ti fidi di me? sembra essere una frase molto in uso nel mondo della progettazione e realizzazione di tecnologia. Corollario di questo modo di pensare è la frase prima iniziamo il lavoro, al contratto ci pensiamo dopo, anch’essa molto diffusa; salvo poi arrivare a fine lavori senza che nulla sia stato messo per iscritto, trovandosi a litigare per incomprensioni emerse in corso d’opera e senza avere un riferimento scritto per poter ricostruire quali fossero davvero gli accordi.
Sono tutti atteggiamenti che portano vantaggi solo a un’unica categoria: quella degli avvocati, i quali si trovano a dover risolvere con lunghe transazioni o addirittura cause giudiziali questioni che potevano essere chiarite senza problemi in una paginetta sottoscritta a inizio lavori.
Dovremmo quindi sforzarci di uscire da questa mentalità e provare a vedere la questione da un’ottica sostanzialmente opposta: se un mio cliente o un mio consulente/fornitore insiste per mettere nero su bianco i termini della collaborazione significa che ho a che fare con un soggetto abituato a lavorare con serietà e secondo determinati standard; e dunque il mio livello di fiducia aumenta invece di calare. Ecco che, in quest’ottica, fiducia e contratto non sono più alternativi ma complementari tra loro.
Ma di preciso che cos’è un contratto? Secondo la definizione molto chiara del nostro Codice Civile (articolo 1321):
il contratto è l’accordo di due o più parti per costituire, regolare o estinguere tra loro un rapporto giuridico patrimoniale.
In realtà, contrariamente all’immaginario collettivo, il contratto non è solo quello scritto; il contratto può essere anche concluso in forma orale (si veda il caso dei contratti conclusi dai call center telefonicamente), o anche attraverso un comportamento che esprima la volontà delle parti (si pensi al classico esempio dei distributori automatici di caffè o merendine, dove il semplice gesto di inserire la moneta e premere un tasto integra a tutti gli effetti un contratto di compravendita). Ciò nonostante in alcuni casi la legge indica espressamente che la forma scritta è necessaria per la validità del contratto (forma scritta ad substantiam) o per poter poi provare in giudizio l’esistenza del contratto (forma scritta ad probationem).
Salvo il caso della cessione dei diritti (che come vedremo più avanti in Italia prevede la forma scritta ad probationem), i contratti di cui ci occupiamo in questo capitolo sono per lo più a forma libera e i modelli di solito utilizzati provengono in buona parte dalla prassi contrattuale statunitense, che per ovvie ragioni è stata la prima a cimentarsi con l’ambito dello sviluppo di tecnologie informatiche.
Da ciò dipende che, tolti quei casi (che vedremo) in cui vi è una ben radicata prassi contrattuale da seguire, il contratto può risolversi in forme – per così dire – più liquide. In alcuni casi gli accordi tra le parti vengono definiti attraverso uno scambio di email, le quali però devono essere chiare, dettagliate, univoche e non ripudiabili, cioè devono poter essere ricondotte a un soggetto certo che abbia anche i poteri per impegnare l’azienda da un punto di vista giuridico. Un lungo, confuso e magari contraddittorio scambio di email costringerà, in caso di contestazioni tra le parti, a un lungo lavoro di ricostruzione del carteggio al fine di individuare la volontà contrattuale delle parti.
In altri casi, come nei rapporti di mera consulenza, un preventivo sufficientemente dettagliato (con chiari obiettivi, scadenze, termini di pagamento) e controfirmato per accettazione può rappresentare esso stesso il contratto, o quantomeno diventa il principale documento per ricostruire il rapporto contrattuale in caso di contestazioni tra le parti.
Detto questo, la via maestra, quella che mette al sicuro entrambe le parti da incomprensioni e da lunghe diatribe legali, rimane la redazione di un vero e proprio contratto, utilizzando i modelli contrattuali più solidi a disposizione e facendosi assistere da un legale esperto del settore.
4. Quali sono le quattro libertà del software libero
La distribuzione del software in formato binario senza la disponibilità del relativo codice sorgente è stata fin dagli anni ottanta una delle principali strategie applicate dalle software house per mantenere maggior controllo sulla circolazione delle proprie opere e sull’eventuale riproduzione e imitazione da parte di concorrenti. Questa scelta è in palese contrasto con i principi del software libero, perché di fatto, dal punto di vista di Richard Stallman e soci, va a inficiare tutte le libertà fondamentali degli utenti di software.
Infatti secondo la Definizione di Software Libero, testo manifesto del Progetto GNU, sono quattro le libertà fondamentali che devono essere sempre garantite affinché si possa parlare in modo legittimo di software libero.
Un programma è software libero se gli utenti del programma godono delle quattro libertà fondamentali:
– Libertà di eseguire il programma come si desidera, per qualsiasi scopo (libertà 0).
– Libertà di studiare come funziona il programma e di modificarlo in modo da adattarlo alle proprie necessità (libertà 1). L’accesso al codice sorgente ne è un prerequisito.
– Libertà di ridistribuire copie in modo da aiutare gli altri (libertà 2).
– Libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti da voi apportati (e le vostre versioni modificate in genere), in modo tale che tutta la comunità ne tragga beneficio (libertà 3). L’accesso al codice sorgente ne è un prerequisito.
Un programma è software libero se l’utente ha tutte queste libertà in modo adeguato. Altrimenti diciamo che è non libero. I modelli di distribuzione non liberi si possono differenziare a seconda di quanto si distanziano dall’essere liberi, ma per noi sono tutti non etici allo stesso modo.
Emerge con chiarezza quanto sia centrale la disponibilità del codice sorgente per la piena realizzazione delle libertà numero 1 e 3 (libertà di fare modifiche e di pubblicare versioni modificate) e dunque l’accessibilità al codice sorgente è una condizione essenziale e necessaria per il software libero.
A proposito di queste due libertà, infatti, il documento prosegue così.
Il codice sorgente deliberatamente offuscato non è vero codice sorgente e non può essere considerato tale.
La libertà 1 comprende la libertà di utilizzare una versione da voi modificata anziché l’originale. Se il programma è distribuito in un prodotto che, per scelta progettuale, esegue le versioni modificate da una specifica persona o azienda ma si rifiuta di eseguire quelle modificate da voi (tecnica nota come “tivoization” o come “lockdown” o come “secure boot” secondo la discutibile definizione che ne danno i suoi sostenitori), allora la libertà 1 diventa una richiesta vuota senza alcun valore concreto. La versione eseguibile di questi programmi non è software libero anche se il codice sorgente da cui sono stati ottenuti è libero.
Un importante modo di modificare un programma è quello di includervi funzioni e moduli liberi già esistenti. Se la licenza del programma prevede che non si possano includere moduli già esistenti (nonostante abbiano una licenza appropriata), ad esempio se richiede che voi possiate aggiungere solo codice di cui detenete il copyright, allora la licenza è troppo restrittiva per essere considerata libera.
5. Che cosa vuol dire open source
A metà degli anni Novanta si aprì un dibattito su come rendere più appetibile alle imprese dell’ICT (e quindi non più solo alla comunità degli hacker) lo sviluppo di software in uno spirito per l’appunto libero dalle barriere di natura tecnica e giuridica che abbiamo illustrato. Alcuni attivisti del settore proposero una nuova definizione per il fenomeno che potesse porre l’accento non tanto sull’aspetto etico della libertà quanto sull’aspetto più tecnico della disponibilità e apertura del codice sorgente (detto in inglese source code o semplicemente source).
Si iniziò così a parlare di open source e tale termine – pur osteggiato dai puristi – ebbe un notevole successo grazie alla sua particolare efficacia comunicativa. Superata la fase della scelta terminologica, bisognava redigere le linee guida di questa nuova realtà. Uno dei suoi massimi fautori, Bruce Perens, si preoccupò di redigere la Open Source Definition (OSD), una sorta di decalogo di riferimento per chiarire a priori che cosa potesse essere ricondotto al concetto di open source.
La differenza tra l’operato della Free Software Foundation (FSF) e quello della Open Source Initiative (OSI) sta più che altro nell’approccio. La prima ha creato una licenza di riferimento (la GPL) e invita gli sviluppatori a utilizzare quella per essere sicuri di muoversi in coerenza con i principi del software libero; in alternativa FSF consente l’utilizzo di altre licenze considerate compatibili con la GPL. La seconda, invece, procede in senso inverso, riconoscendo ex post la qualifica di open source a tutti i progetti (e quindi a tutte le licenze) che risultino coerenti con i parametri indicati nella Open Source Definition.
Tuttavia, dal punto di vista della sostanza, molti osservatori hanno fatto notare che in realtà le due scuole di pensiero non fanno altro che utilizzare due nomi per un unico grande fenomeno. Non a caso da un po’ di tempo si sente parlare in senso generico di FOSS (o a volte FLOSS), un acronimo un po’ cacofonico che però ha il merito di comprendere tutte le varie accezioni del fenomeno: significa infatti Free (Libre) and Open Source Software ed è utilizzato da tutti quegli studiosi che intendono trattare il tema senza dover ogni volta effettuare fastidiose precisazioni terminologiche.
Non vi è dubbio che l’aggettivo open ha riscosso un successo indiscutibile e infatti, al di là delle valutazioni terminologiche (e a volte ideologiche) interne al movimento, è ormai dato storico che tale aggettivo abbia visto allargare negli ultimi anni il suo ambito semantico fino ad altri campi non solo informatici e che sia stato utilizzato per individuare un movimento culturale, un nuovo approccio, per certi versi addirittura una filosofia. L’openness appunto.
Questo articolo richiama contenuti da Software Licensing & Data Governance ed è rilasciato sotto licenza Creative Commons Attribution – Non Commercial – Share Alike 4.0.
Immagine di apertura di Annie Spratt su Unsplash.
L'autore
Corsi che potrebbero interessarti
Strategie e modelli contrattuali per cedere e acquisire software
Big Data Analytics - Iniziare Bene
Data governance: diritti, licenze e privacy