Quando proponi una modifica a un progetto open source, prima o poi ti viene chiesto di accettare qualcosa: firmare un modulo elettronico, aggiungere una riga ai commit, confermare una dichiarazione. Non è burocrazia fine a se stessa. Ogni contributo è un'opera protetta dal diritto d'autore, e il progetto ha bisogno di sapere con certezza che può distribuirla sotto la sua licenza. Gli strumenti più usati sono due, il CLA e il DCO, e hanno conseguenze molto diverse.
Il problema che risolvono
Se il progetto accetta il tuo codice senza alcuna dichiarazione, la sua posizione si basa su un'assunzione implicita: che tu abbia inviato il contributo sotto la stessa licenza del progetto (il principio spesso riassunto come «inbound = outbound») e che tu avessi il diritto di farlo. Nella maggior parte dei casi funziona. Ma i dubbi emergono in situazioni concrete:
- il contributore era dipendente e il codice appartiene in realtà al suo datore di lavoro;
- il codice è stato copiato da un altro progetto con licenza incompatibile;
- il progetto vuole in futuro cambiare licenza o offrirne una commerciale.
CLA e DCO affrontano questi rischi in modi diversi.
Il Developer Certificate of Origin
Il DCO è una breve dichiarazione, nata nell'ambito del kernel Linux, con cui chi contribuisce certifica, tra l'altro, di aver scritto il codice o di avere il diritto di inviarlo sotto la licenza indicata, e di essere consapevole che il contributo e la firma resteranno pubblici.
In pratica si esprime con una riga in fondo al messaggio di commit:
Correggi il calcolo dei giorni lavorativi a cavallo d'anno
Signed-off-by: Mario Rossi <mario.rossi@example.org>
Git la aggiunge automaticamente con l'opzione -s:
git commit -s -m "Correggi il calcolo dei giorni lavorativi"
Caratteristiche del DCO:
- nessun trasferimento di diritti: il copyright resta a te, il contributo entra con la licenza del progetto;
- nessun modulo da firmare: basta la riga nel commit, verificabile automaticamente;
- simmetria: progetto e contributori sono sullo stesso piano, nessuno può ricollocare il codice sotto altre licenze senza il consenso di tutti gli autori.
Il Contributor License Agreement
Il CLA è un contratto vero e proprio tra contributore e un soggetto, di solito l'azienda o la fondazione che gestisce il progetto. Esistono due varianti principali:
- licenza ampia: tu mantieni il copyright ma concedi al soggetto una licenza molto estesa, spesso comprensiva di brevetti, irrevocabile e con facoltà di sublicenziare;
- cessione del copyright: trasferisci la titolarità del codice al soggetto, che ne diventa proprietario.
Spesso esistono due moduli: uno individuale e uno aziendale, da firmare quando contribuisci come dipendente per conto dell'azienda.
Cosa permette al gestore:
- difendere il codice in giudizio con una titolarità chiara;
- cambiare licenza in futuro senza dover rintracciare ogni contributore;
- offrire lo stesso codice con licenze commerciali, il cosiddetto dual licensing.
È proprio quest'ultimo punto a generare diffidenza: un CLA che consente di sublicenziare senza limiti dà al gestore la possibilità di rendere proprietario il lavoro di tutti.
Confronto diretto
| Aspetto | DCO | CLA con licenza | CLA con cessione |
|---|---|---|---|
| Chi resta titolare | Il contributore | Il contributore | Il gestore |
| Modulo da firmare | No | Sì | Sì |
| Il gestore può cambiare licenza da solo | No | Spesso sì | Sì |
| Attrito per chi contribuisce | Basso | Medio | Alto |
| Revisione legale per le aziende | Raramente | Spesso | Quasi sempre |
Cosa controllare prima di firmare un CLA
Leggere un CLA richiede pochi minuti e conviene farlo. Le domande utili:
- Concedi una licenza o cedi i diritti? La differenza è sostanziale.
- Il gestore si impegna a distribuire sempre il codice con una licenza open source? Alcuni CLA lo prevedono esplicitamente e limitano così il rischio.
- Sono inclusi i brevetti? Se lavori per un'azienda, potresti concedere diritti che non sono tuoi.
- Puoi firmare? Molti contratti di lavoro attribuiscono al datore il codice scritto anche fuori orario. In quel caso serve il CLA aziendale o un'autorizzazione.
Quale scegliere se gestisci un progetto
Se il progetto è comunitario e non prevedi modelli di licenza commerciale, il DCO è quasi sempre sufficiente: protegge dai contributi di provenienza dubbia senza scoraggiare nessuno. Un controllo automatico nella pipeline può rifiutare le pull request senza Signed-off-by.
Un CLA ha senso quando c'è un motivo concreto: una strategia di doppia licenza, la necessità di una titolarità unica per tutelare il progetto, o requisiti di una fondazione. In quel caso conviene scegliere un testo noto e pubblicamente discusso invece di scriverne uno da zero, e dichiarare con chiarezza nel CONTRIBUTING.md perché viene richiesto.
In sintesi
- Ogni contributo è un'opera protetta: il progetto deve sapere che può distribuirla.
- Il DCO è una dichiarazione nel commit, senza trasferimento di diritti.
- Il CLA è un contratto che concede licenze ampie o cede il copyright al gestore.
- Un CLA può permettere al gestore di cambiare licenza: leggilo prima di firmare.
- Per la maggior parte dei progetti comunitari il DCO è la scelta più semplice ed equa.
