Il tuo side project ha appena superato le 500 stelle, e uno sconosciuto ha aperto la prima pull request seria: 2.000 righe che risolvono un problema che stavi evitando da mesi. Vuoi cliccare su merge. Ma prima di farlo, poniti la domanda scomoda: hai davvero il diritto legale di distribuire quel codice — e di continuare a distribuirlo con la tua licenza, per sempre, indipendentemente da chi sia il datore di lavoro di quel contributore?
Se il tuo repository non ha una politica di contribuzione, la risposta onesta è che non ne sei sicuro. Il contributore possiede ancora il copyright su ogni riga che ha scritto, e la sola licenza del tuo progetto non sempre chiarisce chi ha concesso cosa a chi. Questa incertezza resta invisibile fino al giorno in cui conta: un cambio di licenza, un'acquisizione, un utente aziendale che fa due diligence sulle licenze, o il datore di lavoro di un contributore che rivendica che il lavoro era suo fin dall'inizio.
Due meccanismi risolvono questo problema, e quasi ogni progetto open source ne sceglie uno: il Contributor License Agreement (CLA) e il Developer Certificate of Origin (DCO). Entrambi esistono per stabilire che un contributore è autorizzato a fare il contributo e che il progetto ha il diritto di distribuirlo. Differiscono enormemente per peso, attrito e per ciò che ti permettono di fare in seguito. Questa guida spiega come funziona ciascuno, quando scegliere l'uno o l'altro, e come impostare la tua scelta in un pomeriggio.
Perché il tuo progetto ha bisogno di una politica di contribuzione
Il copyright si applica automaticamente. Nel momento in cui qualcuno scrive del codice, ne è proprietario — nessuna registrazione, nessun avviso di copyright richiesto. Quando lo invia al tuo progetto, la tua licenza open source copre molto, ma lascia lacune che solo una politica di contribuzione colma:
- La concessione in entrata. La tua licenza in uscita (MIT, Apache-2.0, GPL) dice agli utenti cosa possono fare con il tuo codice. Una politica di contribuzione rende esplicito che i contributi in entrata arrivano a condizioni compatibili, così puoi distribuire il lavoro combinato senza tracciare a mano la provenienza file per file.
- Rivendicazioni dei datori di lavoro. La maggior parte dei contratti di lavoro assegna al datore di lavoro la proprietà intellettuale dei side project, almeno per il lavoro correlato al ruolo del dipendente. Una politica che chiede ai contributori di confermare di avere il diritto di inviare mette quella responsabilità — e la tracciabilità documentale — sul contributore.
- Opzionalità di ricollocazione della licenza. Se mai volessi cambiare licenza, aggiungere un'edizione commerciale o donare il progetto a una fondazione, ti servono i diritti da ogni contributore. Raccogliere quel permesso retroattivamente da decine di contributori passati è qualcosa tra il doloroso e l'impossibile. Una politica scelta dal primo giorno decide se quella porta resta aperta.
- Protezione brevettuale. I contributi di codice possono portare con sé diritti brevettuali. Alcune politiche includono una concessione di brevetto esplicita; altre no, il che conta più di quanto la maggior parte dei maintainer realizzi.
Niente di tutto ciò richiede uno studio legale a contratto. Richiede di scegliere CLA o DCO, scriverlo nel tuo repository e applicarlo automaticamente. Ecco cosa comporta ciascuna scelta.
Cos'è un Contributor License Agreement (CLA)?
Un Contributor License Agreement è un documento legale firmato tra il contributore e il progetto (o l'azienda o la fondazione che vi sta dietro). Il contributore firma una volta, e quella firma copre tutti i suoi contributi futuri.
A differenza delle licenze open source, i CLA non sono standardizzati. Ogni progetto scrive il proprio, ma la maggior parte rientra in due forme familiari:
CLA individuali vs. aziendali
- CLA individuale (ICLA): firmato da una persona che contribuisce per proprio conto. Tipicamente concede al progetto un'ampia licenza sul copyright e spesso una licenza brevettuale, mentre il contributore mantiene il proprio copyright.
- CLA aziendale (CCLA): firmato da un'azienda, che autorizza i suoi dipendenti a contribuire. L'azienda concede gli stessi diritti per il lavoro che le sue persone inviano. I progetti che accettano contributi aziendali senza un CCLA confidano che il manager di ogni dipendente sappia — e approvi — il che è esattamente il tipo di fiducia che evapora durante la due diligence.
Concessione di licenza vs. cessione del copyright
La maggior parte dei CLA moderni sono concessioni di licenza: il contributore mantiene la proprietà e concede al progetto una licenza perpetua, mondiale, esente da royalty — spesso abbastanza ampia da permettere la ricollocazione della licenza. L'ICLA della Apache Software Foundation è l'esempio canonico.
Una minoranza di progetti usa la cessione del copyright, in cui il contributore trasferisce la proprietà in modo definitivo (l'approccio della Free Software Foundation). La cessione dà al progetto la massima libertà di far valere i diritti e di ricollocare la licenza, ma chiede moltissimo ai contributori ed è caduta in disgrazia presso i progetti guidati dalla comunità.
Quanto costa un CLA a te e ai tuoi contributori
Il compromesso è l'attrito. Un contributore alla prima volta deve lasciare la pull request, leggere un documento legale, firmarlo (di solito elettronicamente) e aspettare che il controllo di stato diventi verde prima che un maintainer esamini il suo codice. Gli strumenti hanno reso tutto questo quasi indolore — bot come CLA Assistant commentano la pull request con un link per la firma e registrano automaticamente la firma — ma è comunque un cancello tra "ho corretto il tuo bug" e "puoi fare il merge della mia correzione". Alcuni contributori occasionali si bloccano lì.
In cambio, il progetto ottiene un registro firmato e verificabile: questa persona, in questa data, ha concesso questi diritti. Per i progetti sostenuti da aziende, i progetti a doppia licenza e qualsiasi cosa che un giorno potrebbe essere acquisita, quella tracciabilità documentale vale soldi veri.
Cos'è il Developer Certificate of Origin (DCO)?
Il Developer Certificate of Origin è stato introdotto dalla Linux Foundation nel 2004 per il kernel Linux, proprio per evitare il peso di un CLA. Non è un contratto che un contributore firma e archivia. È una breve certificazione — cinque paragrafi, versione 1.1 — che il contributore afferma con ogni commit aggiungendo una riga Signed-off-by al messaggio di commit:
Fix off-by-one error in retry backoff calculation
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
Signed-off-by: Alex Rivera <[email protected]>Aggiungere la riga è un solo flag: git commit -s la aggiunge automaticamente usando l'identità Git configurata. Firmando, il contributore certifica che:
- Ha creato il contributo (in tutto o in parte) e ha il diritto di inviarlo sotto la licenza open source del progetto, oppure
- Il suo contributo si basa su lavoro precedente già sotto una licenza open source appropriata che permette questa presentazione, oppure
- Ha ricevuto il contributo da qualcun altro che ha certificato uno dei punti precedenti, e non lo ha modificato, e
- Comprende che il contributo e il suo registro — inclusa la sua firma — sono pubblici e conservati a tempo indefinito.
Questo è l'intero meccanismo. Nessun documento separato, nessun collegamento di account, nessun onboarding per progetto. L'applicazione è un controllo di stato: l'app DCO o un controllo equivalente verifica che ogni commit della pull request porti una firma valida, e i maintainer fanno il merge solo quando è verde.
I limiti deliberati del DCO
Nota cosa il DCO non fa. Non concede alcuna licenza oltre a quella che la licenza in uscita del progetto già trasmette — si affida al fatto che il contributo arrivi alle condizioni di licenza del progetto. Non contiene alcuna concessione di brevetto. E poiché nulla viene firmato e archiviato per contributore, non esiste un registro centrale di chi ha accettato cosa; la cronologia git stessa è il registro.
I sostenitori lo considerano un pregio: la bassa barriera del DCO è il punto. Il kernel Linux, GitLab (che è passato da un CLA nel 2017) e Chef (che è passato nel 2016) hanno tutti concluso che l'attestazione per commit fornisce la provenienza necessaria senza tassare ogni contributore. Il Technical Committee di OpenStack ha stabilito nel 2025 di sostituire il suo CLA con il DCO per tutti i contributi. La tendenza del settore è inequivocabile — ma una tendenza non è un verdetto per il tuo progetto, come spiegano le prossime sezioni.
CLA vs. DCO a confronto
| Dimensione | CLA | DCO |
|---|---|---|
| Meccanismo legale | Accordo firmato, archiviato una volta per contributore | Attestazione per commit nel messaggio di commit |
| Cosa fa il contributore | Firma un documento (di solito tramite un link di un bot) | Aggiunge Signed-off-by con git commit -s |
| Gestione del copyright | Concessione esplicita di licenza (o cessione) al progetto | Il contributo arriva sotto la licenza del progetto; nessuna concessione separata |
| Concessione di brevetto | Di solito inclusa | Nessuna |
| Libertà di ricollocazione della licenza | Le concessioni ampie spesso la permettono | Nessun diritto extra; la ricollocazione richiede il consenso di ogni contributore |
| Attrito per il contributore | Più alto: leggere, firmare, attendere il controllo | Minimo: un flag Git |
| Strumenti di applicazione | CLA Assistant, EasyCLA, bot personalizzati | App DCO, controlli sul messaggio di commit |
| Registro del consenso | Database delle firme | La cronologia git stessa |
| Copertura del datore di lavoro | Il CCLA copre esplicitamente i dipendenti | Il contributore autocertifica di avere il diritto di inviare |
| Ideale per | Progetti sostenuti da aziende, a doppia licenza o rilevanti per acquisizioni | Progetti comunitari dove l'attrito sulla contribuzione conta di più |
Quando un CLA è la scelta giusta
Scegli il CLA quando il futuro del progetto potrebbe dipendere da diritti che il DCO non cattura:
- Prevedi una doppia licenza o un cambio di licenza. Se un'edizione commerciale, un cambio di licenza o un passaggio da copyleft a licenza permissiva è anche solo remotamente plausibile, un CLA con un'ampia licenza di ritorno è l'unico modo leggero per mantenere aperta quell'opzione. Ricostruire il consenso anni dopo è lo scenario da incubo.
- Un'azienda sostiene il progetto. Sponsor aziendali, acquirenti e clienti enterprise che fanno due diligence sulla proprietà intellettuale vogliono un registro delle firme, non l'archeologia. Google, i progetti Apache e Canonical usano tutti i CLA esattamente per questo motivo.
- I brevetti contano nel tuo dominio. Codec, protocolli wireless, architetture di modelli ML — in campi ad alta densità brevettuale, la concessione esplicita di brevetto del CLA fa un lavoro reale che il DCO salta silenziosamente.
- Una fondazione lo richiede. Alcune fondazioni impongono il proprio CLA come condizione per l'hosting o la graduazione. Verifica prima di dare per scontato che il DCO sia sufficiente.
Se scegli questa strada, mantieni il CLA stesso standard e noioso: parti dall'ICLA di Apache o da un template Harmony invece di redigere da zero, pubblica sia la versione individuale che quella aziendale, e collega un bot per le firme dal primo giorno così l'attrito è un clic, non un andirivieni di PDF.
Quando vince il DCO
Scegli il DCO quando i contributi sono linfa vitale e l'attrito è il nemico:
- Progetti comunitari con molti contributori occasionali. Correzioni di documentazione, refusi, piccole patch di bug — i contributi che più probabilmente si bloccano a un cancello di firma sono anche quelli che un DCO gestisce con grazia.
- Licenza permissiva, nessun piano di ricollocazione. Se il progetto resterà MIT o Apache-2.0 per sempre e non c'è un'edizione commerciale in programma, i diritti extra del CLA ti danno poco.
- Maintainer solitari e piccoli team. Il DCO non ha bisogno di infrastruttura per le firme, di un'entità legale che conservi gli accordi, né di un processo per controfirmare moduli aziendali. È una governance che puoi gestire da un file
CONTRIBUTING.mde un controllo di stato. - Postura di massima compatibilità. Alcuni contributori — in particolare quelli impiegati da grandi aziende con rigide politiche di proprietà intellettuale — possono firmare un DCO ma non un CLA esterno senza una revisione legale. Il DCO mantiene aperta quella porta.
Qualunque cosa tu scelga, metti per iscritto la decisione. Un CONTRIBUTING.md che enuncia la politica, mostra l'esatto flusso di firma o sign-off e collega il testo completo elimina la fonte più comune di confusione: contributori che tirano a indovinare i requisiti da un controllo di stato fallito.
5 errori che minano entrambe le scelte
1. Dire entrambe le cose. Il fallimento reale più comune è un CONTRIBUTING.md che richiede sign-off DCO in un paragrafo e firme CLA in un altro — di solito dopo una migrazione a metà. I contributori seguono un'istruzione, l'altro controllo fallisce, e i maintainer fanno comunque il merge, il che annulla il senso di entrambi. Scegli un solo meccanismo, applicalo ed elimina ogni traccia dell'altro.
2. Nessuna applicazione automatica. Una politica enunciata solo in prosa è un suggerimento. Collega il controllo al flusso di lavoro delle pull request come controllo di stato obbligatorio — l'app DCO per i sign-off, CLA Assistant o EasyCLA per le firme — così un contributo non concordato non può essere unito per errore o per stanchezza del maintainer.
3. Ignorare i contributori aziendali. Se le aziende usano e correggono il tuo progetto, i dipendenti invieranno codice in orario di lavoro. Con una politica CLA, questo significa far firmare il CCLA presto, finché la relazione è calda. Con una politica DCO, significa assicurarsi che il requisito di sign-off sia abbastanza visibile che il primo contributo di nessuno diventi un incidente di proprietà intellettuale.
4. Dare per scontato che i contratti di lavoro permettano di contribuire. L'altro lato della stessa medaglia: se contribuisci ad altri progetti, controlla prima il tuo contratto di lavoro. Molti assegnano al datore di lavoro la proprietà intellettuale dei side project legati al lavoro, per impostazione predefinita. La certificazione del DCO ("ho il diritto di inviare questo") è vera solo se quelle carte lo dicono.
5. Nessuna politica per il codice assistito dall'IA. I contributi generati da macchine sollevano questioni di provenienza che né il testo del DCO dell'era 2004 né la maggior parte dei template CLA avevano previsto. Decidi la tua posizione — consentito con revisione, dichiarato o proibito — e dichiarala nel CONTRIBUTING.md insieme alla tua politica CLA/DCO, prima che arrivi la tua prima pull request generata dall'IA anziché dopo.
Non dimenticare il lato finanziario del tuo progetto
Ecco la parte che i maintainer rimandano fino alla stagione delle tasse: nel momento in cui il tuo progetto guadagna il suo primo dollaro — pagamenti di GitHub Sponsors, donazioni su Open Collective, un incarico di consulenza arrivato grazie al tuo README — ha finanze, e le finanze hanno bisogno di contabilità.
La stessa disciplina che rende verificabile la provenienza dei contributi rende gestibile il denaro del progetto. Traccia i ricavi da sponsorizzazione separatamente dal tuo stipendio, così sai quale è reddito da lavoro autonomo tassabile. Registra le spese del progetto — rinnovi di domini, minuti di CI, il pomeriggio che un avvocato ha dedicato a esaminare il tuo CLA — in conti dedicati, così le detrazioni non evaporano negli estratti conto della carta personale. Se il progetto cresce fino a diventare una LLC o si unisce a un fiscal host, registri storici puliti rendono la transizione noiosa invece che forense.
La contabilità in testo semplice si adatta insolitamente bene a questo flusso di lavoro: il tuo libro mastro vive nel controllo di versione accanto al tuo codice, ogni voce ha una cronologia e nulla si nasconde in un formato proprietario. La nostra documentazione spiega come avviare un primo libro mastro in pochi minuti.
Mantieni i conti del tuo progetto puliti come la sua cronologia Git
Scegliere tra un CLA e un DCO richiede un pomeriggio; districare la provenienza o le finanze del progetto anni dopo richiede settimane. Prendi ora la decisione sulla contribuzione, automatizzane l'applicazione e dedica al denaro del progetto la stessa cura che dedichi ai suoi commit. Beancount.io offre contabilità in testo semplice che ti dà completa trasparenza e controllo sui tuoi dati finanziari — nessuna scatola nera, nessun vendor lock-in. Inizia gratuitamente e scopri perché sviluppatori e professionisti della finanza stanno passando alla contabilità in testo semplice.
