Posted on by Andrea Monti

Scrivere una licenza open source

Linux&Co n.ro 17

na delle domande che ricevo più spesso riguarda il “come” scrivere una licenza open source valida all’interno dei nostri confini. Cosa non delle più semplici, anche solo considerando che nell’oceano del software libero c’è un mare di pesci simili ma anche molto diversi fra loro.

Fuor di metafora, quindi, una “GPL.it” non avrà la stessa identica forma di una licenza ispirata al modello Berkeley o Debian. La cosa si complica se pensiamo che a seconda della situazione può essere necessario personalizzare ulteriormente il documento. Come nel caso di un software “semplicemente” regalato al mondo, che richiede un trattamento diverso da un’applicazione sviluppata nell’ambito di un rapporto professionale.

Ciò non toglie che – in un poderoso sforzo di standardizzazione – si possono ipotizzare dei contenuti minimi che valgono per ogni tipologia di licenza d’uso.

L’ipotesi base è che abbiate sviluppato da soli un’intera applicazione da rilasciare in una delle forme Open Source ad un numero indeterminato di persone e a pagamento. Come ho detto, ci sono altre “variazioni sul tema” delle quali parlermo nei prossimi numeri.

Veniamo quindi al punto.

1 – gestione dei diritti morali e patrimoniali

La prima cosa da fare è identificarvi come autore. La legge sul diritto d’autore non prevede “registrazioni” o “depositi” che possano certificare la qualità di autore. Quindi per dimostrare di esserlo è opportuno che fin dal primo rilascio dell’applicazione questa possa esservi attribuita. Una possibilità è quella di firmare digitalmente il codice (se è veramente troppo corposo, limitatevi a porzioni significative)per poi esordire nella licenza con una dichiarazione che precisa dettagliatamente “come” volete che il vostro software venga utilizzato.

In particolare, si deve specificare se il software è concesso in licenza o trasferito in proprietà. La differenza è sostanziale, perché nel primo caso lo sviluppatore mantiene il pieno controllo sulla propria “creatura”. Nel secondo caso, invece, egli conserva solo i diritti morali (come quello di paternità, per esempio)ma non può intervenire più sugli aspetti economici e patrimoniali.

Sempre a proposito di diritti morali, la licenza può stabilire il testo dei “credits” che ogni ridistribuzione del software deve riportare e il divieto di rimuoverli.

Bisogna anche fare attenzione al fatto che – secondo la legge sul diritto d’autore e a certe condizioni – il software sviluppato da un dipendente appartiene al suo datore di lavoro. Prima di rilasciare l’applicazione, quindi, è necessario assicurarsi di essere “proprietario” del software, di fatto e di diritto.

2 – disclaimer sulla responsabilità e limitazioni di garanzia

In secondo luogo è necessario fornire le indicazioni in materia di garanzia e responsabilità.

Molto spesso il software viene distribuito “as is” cioè a rischio e pericolo di chi lo usa. Se questo può andar bene per ciò che è gratis, quando viene richiesto un corrispettivo le cose possono cambiare. E’ importante, quindi, chiarire ad esempio che garanzia e responsabilità possono sussistere solo se il codice non è stato modificato. In altri termini, se qualcuno prende i vostri sorgenti, ci smanetta un po’ su e poi subisce un dannosissimo crash, non può certo prendersela necessariamente con voi per quanto è accaduto. A questo proposito, però, è necessario un chiarimento: le clausole di esonero di responsabilità valgono se sono accettate specificamente e per iscritto. Se optate per una licenza che sia un semplice file di testo e volete godere della protezione offerta dalla legge dovete richiedere che il file vi venga rispedito firmato su carta. Altrimenti tanto vale scordarsi questo tipo di “oggetti” contrattuali.

 

3 – il reverse engineering

Andiamo oltre. Considerato che i software liberi circolano insieme ai sorgenti il problema del reverse engineering tecnicamente non si pone. E’ tuttavia utile specificare nella licenza le modalità con le quali è possibile “maneggiare” il software in ogni sua forma. Ad esempio, evidenziando che non ci sono limiti ai tipi di analisi e alle tecniche adottate per compierle.

4 – “maneggiare” i sorgenti

Un altro punto da non trascurare è la “gestione” dei sorgenti. Se il software è libero, necessariamente devono essere liberi anche i sorgenti. Se non state lavorando con software GPL dovete quindi verificare che sia effettivamente possibile rendere pubblico tutto ciò che state rilasciando. In altri termini, potreste aver utilizzato dei componenti proprietari (ad esempio, librerie) che non possono essere ridistribuiti o diffusi senza particolari autorizzazioni.

5 – la durata

Una cosa priva di senso è invece quella di regolare la durata della licenza. In pura teoria, l’autore potrebbe dire – ad un certo punto della vita di un programma – “bene, da questo momento in poi, questa versione non la usa più nessuno perché voglio che l’unica disponibile sia la più recente, migliore, più veloce, affidabile e facile da usare” (già sentito da qualche parte:)). E’ ovvio che in una “licenza proprietaria” questa scelta è perfettamente coerente e – per certi versi – applicabile. Non così per il software libero, a proposito del quale non si può certo parlare di obsolescenza programmata o programmabile.

6 – forma e modalità di pagamento

Non ci sono particolarità da segnalare. Ogni sistema è buono, dal bonifico bancario al pagamento via carta di credito. I problemi nascono semmai dovendo gestire le problematiche legate alle attività di e-commerce. Tenete solo presente che se esercitate l’attività di sviluppatore professionale, dovete dotarvi di partita iva.

7 – bollino SIAE

Se il software viene distribuito a pagamento in un qualsiasi supporto c’è poco da fare, tocca richiedere il bollino. Viceversa, se la cessione avviene online l’obbligo sembra non sussistere. Primo, perché la legge sul diritto d’autore parla esplicitamente di apposizione del bollino sul supporto. Secondo, perché per la normativa fiscale, il download di software non è “vendita” ma “erogazione di un servizio”. Una differenza che ai non esperti di diritto tributario può apparire priva di senso, ma che consentirebbe di non sottostare al balzello SIAE.

 

8 – creazione di una comunità

Senza con questo violare i sacri principi del software libero, potreste inserire nella licenza una clausola che chiede agli utenti normali e ai power user di segnalarvi bug, problemi o miglioramenti del programma.

 

9 – dati personali

Se richiedete i dati di chi scarica o comunque si procura il vostro software, la licenza deve contenere anche un riferimento al trattamento dei dati personali. In particolare, si deve informare l’utente delle finalità della raccolta dei dati (ad esempio: gestione clientela),del modo in cui verranno maneggiati e dei soggetti cui potranno essere comunicati. Deve essere inoltre specificata l’identità del titolare del trattamento (cioè la persona che avrà diritto di vita e di morte sui quei dati) e dovranno essere indicati i diritti che spettano al vostro cliente. Come quello di opporsi al trattamento, ottenere la rettifica o la cancellazione dei dati. Infine, si dovrà anche dichiarare per quanto tempo verranno conservati i dati e che fine faranno quando non dovessero essere più di alcuna utilità.

10 – gestione delle copie

Questo è uno dei punti più importanti che differenziano una licenza proprietaria da una “libera”.

Nell’ambito proprietario, è frequente trovare diciture tipo “all’utente è concesso di installare il software su un computer e su un portatile” oppure “all’utente è consentito effettuare una copia di riserva del software”. Si tratta di un’applicazione dell’art.64 ter della legge sul diritto d’autore. Secondo il quale non si può vietare all’utente di farsi una copia di riserva del software legittimamente acquistato. La norma sembrerebbe chiara, ma in realtà si presta a molte ambiguità. Ho il diritto di duplicare il CD contenente i file di installazione e contemporaneamente di creare un’immagine del disco sul quale è installato il software?

Nel software libero questi contorcimenti mentali non sono necessari. Però, considerando che spesso chi effettua i controlli (Guardia di finanza,Polizia) si è formato su modelli di licensing “tradizionali” e che quindi potrebbe non essere a conoscenza delle novità introdotte dall’open source, è bene riprendere l’argomento e specificare che la copia dell’applicazione è del tutto libera… ma in che senso? Si può stravolgere il codice senza problemi? si possono vendere le copie?

A questo punto cominciano a manifestarsi le differenze fra i vari approcci al fenomeno del software libero, e a questo punto si conclude questo articolo.

Il resto, alle prossime puntate.

p.s. Alla fine di tutto questo, prendete la licenza e firmatela digitalmente. Il valore legale non è ancora “a prova di bomba” ma è senz’altro meglio di niente:)

Possibly Related Posts: