E attenzione alla clausola

Roba open? Sia buona

di

thumbnail

13

set

2016

Ottanta licenze distinte, le conseguenze sulle opere derivate… fare una app con parti di software libero non è facile.

Come già avevo spiegato in un precedente articolo, spesso arrivano da me in modalità #mifacciolapp clienti che però non hanno sviluppato la loro applicazione scrivendo del codice completamente nuovo, ma sono partiti da pezzi di software già disponibili e quindi sviluppati da altri. Ovviamente cerco subito di focalizzare l’attenzione sulla titolarità del copyright e chiedo se il codice riutilizzato e spesso rimaneggiato non fosse coperto da diritti che invece ne impedivano l’utilizzo.

la risposta che spesso mi sento dare è questa:

Tranquillo, avvocato. Era tutta roba open source!

Ed è qui che arriva il momento thriller, in cui inizio a demolire le certezze del malcapitato; e non perché io sia bastardo dentro, ma perché è l’unico modo per arrivare a inquadrare correttamente la situazione giuridica.

Innanzitutto inizio con il chiedere se davvero si trattasse di roba open source; notoriamente il termine è oggetto di fraintendimenti e interpretazioni distorte e c’è sempre il rischio che venga confuso con freeware o shareware.

Se il cliente mostra di non essere caduto in questo equivoco (e per fortuna succede sempre meno), si passa allo step successivo:

Più precisamente, di quale licenze open source stiamo parlando?

Immagino possiate comprendere che ho usato roba open source non è un’informazione sufficiente nell’ambito di una consulenza legale. Ad oggi le licenze che rispondono ai requisiti definiti dalla Open Source Iniziative sono circa un’ottantina (ecco l’elenco completo in semplice ordine alfabetico), le quali in realtà sono a loro volta riconducibili a una manciata di modelli di base. Infine, l’ultima domanda:

Di preciso, quali utilizzi avete fatto dei vari pacchetti?

D’altronde, a livello operativo, ce ne facciamo poco di aver chiaro il quadro delle varie licenze che si vanno a toccare fino a che si arriva a capire se gli utilizzi fatti dei vari pacchetti risultano tra quelli consentiti dalle rispettive licenze. Alcune licenze, infatti, pur rientrando genericamente nella definizione di open source, potrebbero imporre alcune limitazioni specifiche per la realizzazione di opere derivate e la loro ridistribuzione o commercializzazione.

La limitazione più frequente, nonché quella che disorienta maggiormente il cliente, è la famigerata clausola copyleft, per effetto della quale lo status giuridico dell’opera originaria si trasmette anche sulle opere derivate. In altre parole, se l’applicazione sviluppata dal cliente è a tutti gli effetti un’opera derivata di una preesistente opera sotto licenza con clausola copyleft, anche l’opera derivata dovrà essere rilasciata con la stessa licenza e anche le righe di codice sorgente sviluppate ex novo dovranno essere rese disponibili.

Sono un entusiasta del modello copyleft. Tuttavia sono consapevole che non sempre questo approccio è compatibile con i progetti e con il modello di business dello sviluppatore della nuova applicazione; quindi è cosa buona conoscere queste dinamiche fin dall’inizio.

Il testo di questo articolo è sotto licenza Creative Commons Attribution – Share Alike 4.0.




Simone Aliprandi (@simonealiprandi) ha un dottorato di ricerca in Società dell’Informazione ed è un avvocato che si occupa di consulenza, ricerca e formazione nel campo del diritto d’autore e più in generale del diritto dell’ICT. È responsabile del progetto copyleft-italia.it, è membro del network Array e collabora come docente con alcuni istituti universitari; ha pubblicato articoli e libri sul mondo delle tecnologie open e della cultura libera, rilasciando tutte le sue opere con licenze di tipo copyleft. Maggiori informazioni sul suo blog.

In Rete: www.aliprandi.org

Letto 2.209 volte | Tag: , , ,

Lascia il tuo commento