Un progetto open source non è fatto solo di codice. Ci sono la documentazione, le immagini dell'interfaccia, le icone, i tutorial, i file di esempio e spesso uno o più insiemi di dati. Le licenze software come MIT o GPL sono scritte pensando a programmi: parlano di codice sorgente, di compilazione, di collegamento. Applicarle a un manuale o a un dataset è possibile ma poco naturale. Per contenuti e dati esistono licenze più adatte, e conviene conoscerle per assegnare a ogni parte del progetto lo strumento giusto.
Le licenze Creative Commons
Le licenze Creative Commons sono pensate per opere come testi, immagini, audio, video e materiali didattici. Si costruiscono combinando pochi elementi:
| Sigla | Significato | Effetto |
|---|---|---|
| BY | Attribuzione | bisogna citare l'autore |
| SA | Condividi allo stesso modo | le opere derivate vanno rilasciate con la stessa licenza |
| NC | Non commerciale | vietato l'uso commerciale |
| ND | Non opere derivate | vietato modificare |
Le combinazioni più comuni sono CC BY, CC BY-SA, CC BY-NC, CC BY-NC-SA, CC BY-ND e CC BY-NC-ND. Esiste poi CC0, che non è una licenza in senso stretto ma uno strumento con cui l'autore rinuncia, per quanto la legge lo consente, ai propri diritti, avvicinando l'opera al pubblico dominio.
Quali sono davvero «aperte»
Non tutte le Creative Commons rispettano la definizione di contenuto libero. Le clausole NC e ND limitano l'uso commerciale o la modifica, e per questo le opere con queste clausole non sono considerate aperte nel senso usato nel mondo del software libero. Per la documentazione di un progetto open source le scelte coerenti sono in genere tre:
- CC BY: massima libertà, basta citare la fonte;
- CC BY-SA: l'equivalente del copyleft per i contenuti;
- CC0: nessuna condizione.
Perché non usarle per il codice
Creative Commons stessa sconsiglia di usare le proprie licenze per il software. I motivi sono pratici: non distinguono tra sorgente e compilato, non regolano i brevetti e non sono compatibili in modo chiaro con le principali licenze software. CC0 è un caso parzialmente diverso, ma anche lì manca qualsiasi clausola sui brevetti.
Le licenze per i dati
I dataset pongono problemi propri. In molti ordinamenti, compreso quello europeo, oltre al diritto d'autore esiste un diritto sui generis sulle banche dati, che protegge l'investimento fatto per raccogliere e organizzare i dati, anche quando i singoli dati non sono protetti.
ODbL
La Open Database License (ODbL), pubblicata dalla Open Knowledge Foundation, è pensata proprio per le banche dati. La sua applicazione più nota è OpenStreetMap. I suoi punti principali:
- si può usare, copiare e adattare la banca dati;
- bisogna attribuire la fonte;
- se si distribuisce una banca dati derivata, la si deve rilasciare sotto ODbL (una forma di copyleft per i dati);
- una produzione realizzata a partire dai dati, ad esempio una mappa stampata o un'immagine, può avere un'altra licenza, purché riporti l'attribuzione.
Questa distinzione tra banca dati derivata e opera prodotta è il cuore della licenza ed è ciò che la rende utilizzabile in pratica.
Alternative per i dati
- CC BY 4.0 e CC BY-SA 4.0: dalla versione 4.0 le Creative Commons coprono esplicitamente anche il diritto sui generis sulle banche dati, e sono molto usate per i dati aperti delle amministrazioni.
- CC0: preferita quando si vuole che i dati siano riutilizzati senza alcun ostacolo, ad esempio dati scientifici.
Come organizzare un progetto misto
Un progetto ben ordinato dichiara una licenza per ciascun tipo di materiale. Un esempio di struttura:
LICENSE -> licenza del codice (es. Apache-2.0)
docs/LICENSE -> licenza della documentazione (es. CC-BY-4.0)
data/LICENSE -> licenza dei dati (es. ODbL-1.0)
assets/LICENSE -> licenza di icone e immagini (es. CC-BY-SA-4.0)
Nel README conviene riassumere la situazione in poche righe, così chi vuole riutilizzare una parte sa subito cosa può fare.
Errori frequenti
- Mettere tutto sotto la licenza del codice, compresi loghi e marchi. Il logo del progetto spesso non deve essere modificabile liberamente: va gestito come marchio, con regole d'uso separate.
- Usare NC per «proteggersi» senza rendersi conto che esclude scuole private, aziende, editori e molti altri riutilizzi utili.
- Dimenticare il materiale di terzi: immagini prese da altre fonti mantengono la loro licenza, che va rispettata e indicata.
- Non specificare la versione: CC BY 3.0 e CC BY 4.0 sono testi diversi, con differenze importanti proprio sulle banche dati.
Esempio pratico
Una comunità sviluppa un'app per segnalare le fontanelle pubbliche. Il codice è sotto GPLv3, la documentazione sotto CC BY-SA 4.0 e i dati raccolti dagli utenti sotto ODbL. Un'azienda può creare un'app commerciale che usa i dati, purché citi la fonte; se pubblica una versione arricchita del database, deve rilasciarla sotto ODbL. Una rivista può pubblicare una mappa stampata ricavata dai dati con i propri diritti, indicando l'origine.
In sintesi
- Codice, documentazione e dati hanno esigenze diverse e meritano licenze diverse.
- Per i contenuti, CC BY, CC BY-SA e CC0 sono le scelte compatibili con lo spirito aperto; NC e ND no.
- Le Creative Commons non sono adatte al software.
- Per le banche dati, ODbL offre un copyleft specifico; CC BY 4.0 e CC0 sono alternative diffuse.
- Dichiarare una licenza per ogni cartella del progetto evita ambiguità.
