CLA vs. DCO: Quin acord de contribuïdor hauria d'utilitzar el teu projecte de codi obert?

El teu projecte personal acaba de superar les 500 estrelles, i un desconegut ha obert la primera pull request seriosa: 2.000 línies que arreglen un problema que has estat evitant durant mesos. Vols fer clic a fusionar. Però abans de fer-ho, fes la pregunta incòmoda: tens realment el dret legal de distribuir aquest codi — i de seguir distribuint-lo sota la teva llicència, per sempre, independentment de per a qui treballi aquest contribuïdor?

Si el teu repositori no té cap política de contribució, la resposta honesta és que no ho saps del cert. El contribuïdor continua sent el titular dels drets d'autor de cada línia que ha escrit, i la llicència del teu projecte per si sola no sempre resol qui va cedir què a qui. Aquesta incertesa roman invisible fins al dia que importa: una relicenciació, una adquisició, un usuari corporatiu fent una auditoria de llicències, o l'empresa d'un contribuïdor reclamant que la feina era seva des del principi.

Dos mecanismes resolen aquest problema, i gairebé tots els projectes de codi obert n'escullen un: l'Acord de Llicència de Contribuïdor (CLA) i el Certificat d'Origen del Desenvolupador (DCO). Tots dos existeixen per establir que un contribuïdor té permís per fer la contribució i que el projecte té dret a distribuir-la. Difereixen enormement en pes, fricció i en què et permeten fer després. Aquesta guia explica com funciona cadascun, quan triar-ne un o l'altre, i com configurar la teva elecció en una tarda.

Per què el teu projecte necessita una política de contribució​

Els drets d'autor s'adjunten automàticament. En el moment que algú escriu codi, en és el propietari — no cal registre ni avís de copyright. Quan el lliura al teu projecte, la teva llicència de codi obert cobreix moltes coses, però deixa buits que només una política de contribució tanca:

• La cessió entrant. La teva llicència de sortida (MIT, Apache-2.0, GPL) diu als usuaris què poden fer amb el teu codi. Una política de contribució fa explícit que les contribucions entrants arriben sota termes compatibles, de manera que pots distribuir l'obra combinada sense fer un seguiment manual de la procedència fitxer a fitxer.
• Reclamacions de l'ocupador. La majoria de contractes laborals assignen la propietat intel·lectual dels projectes personals a l'ocupador, almenys per a la feina relacionada amb el lloc de treball de l'empleat. Una política que demana als contribuïdors confirmar que tenen dret a lliurar la contribució posa aquesta responsabilitat — i el rastre documental — en mans del contribuïdor.
• Opcionalitat de relicenciació. Si algun dia vols canviar de llicència, afegir una edició comercial o donar el projecte a una fundació, necessites drets de tots els contribuïdors. Recollir aquest permís retroactivament de desenes de contribuïdors passats és entre dolorós i impossible. Una política triada el primer dia decideix si aquesta porta queda oberta.
• Protecció de patents. Les contribucions de codi poden portar drets de patent associats. Algunes polítiques inclouen una cessió explícita de patents; d'altres no, cosa que importa més del que la majoria de mantenidors s'adonen.

Res d'això requereix un bufet d'advocats a sou. Requereix triar CLA o DCO, deixar-ho per escrit al teu repositori i fer-ho complir automàticament. Això és el que implica cada elecció.

Què és un Acord de Llicència de Contribuïdor (CLA)?​

Un Acord de Llicència de Contribuïdor és un document legal signat entre el contribuïdor i el projecte (o l'empresa o fundació que hi ha al darrere). El contribuïdor el signa una vegada, i aquesta signatura cobreix totes les seves contribucions futures.

A diferència de les llicències de codi obert, les CLA no estan estandarditzades. Cada projecte escriu la seva pròpia, però la majoria cauen en dues formes conegudes:

CLA individuals vs. corporatives​

• CLA individual (ICLA): signada per una persona que contribueix en nom propi. Normalment atorga al projecte una llicència àmplia de drets d'autor i sovint una llicència de patents, mentre el contribuïdor conserva els seus propis drets d'autor.
• CLA corporativa (CCLA): signada per una empresa, que autoritza els seus empleats a contribuir. L'empresa atorga els mateixos drets per a la feina que lliuren les seves persones. Els projectes que accepten contribucions corporatives sense una CCLA confien que el cap de cada empleat ho sap — i ho aprova —, que és exactament el tipus de confiança que s'evapora durant una auditoria.

Cessió de llicència vs. cessió de drets d'autor​

La majoria de CLA modernes són cessions de llicència: el contribuïdor conserva la propietat i dona al projecte una llicència perpètua, mundial i lliure de royalties — sovint prou àmplia per permetre la relicenciació. La ICLA de l'Apache Software Foundation n'és l'exemple canònic.

Una minoria de projectes utilitzen la cessió de drets d'autor, en què el contribuïdor transfereix la propietat directament (l'enfocament de la Free Software Foundation). La cessió dona al projecte la màxima llibertat per fer complir i relicenciar, però demana el màxim als contribuïdors i ha caigut en desgràcia entre els projectes impulsats per la comunitat.

Què et costa una CLA a tu i als teus contribuïdors​

El compromís és la fricció. Un contribuïdor novell ha de deixar la pull request, llegir un document legal, signar-lo (normalment electrònicament) i esperar que la comprovació d'estat es posi verda abans que un mantenidor revisi el seu codi. Les eines ho han fet gairebé indolor — bots com CLA Assistant comenten a la pull request amb un enllaç de signatura i registren la signatura automàticament —, però continua sent una barrera entre "he arreglat el teu error" i "pots fusionar la meva solució". Alguns contribuïdors ocasionals es desanimen.

A canvi, el projecte obté un registre signat i auditable: aquesta persona, en aquesta data, va atorgar aquests drets. Per a projectes amb suport corporatiu, projectes amb doble llicència i qualsevol cosa que algun dia pugui ser adquirida, aquest rastre documental val diners de veritat.

Què és el Certificat d'Origen del Desenvolupador (DCO)?​

El Certificat d'Origen del Desenvolupador el va introduir la Linux Foundation el 2004 per al nucli de Linux, precisament per evitar el pes d'una CLA. No és un contracte que un contribuïdor signi i arxivi. És una certificació curta — cinc paràgrafs, versió 1.1 — que el contribuïdor afirma amb cada commit afegint una línia Signed-off-by al missatge del 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]>

Afegir la línia és un sol indicador: git commit -s l'afegeix automàticament utilitzant la teva identitat de Git configurada. En signar, el contribuïdor certifica que:

1. Ha creat la contribució (totalment o parcialment) i té dret a lliurar-la sota la llicència de codi obert del projecte, o
2. La seva contribució es basa en feina prèvia ja sota una llicència de codi obert adequada que permet aquest lliurament, o
3. Ha rebut la contribució d'algú altre que va certificar un dels punts anteriors, i no l'ha modificada, i
4. Entén que la contribució i el seu registre — incloent-hi la seva signatura — són públics i es conserven indefinidament.

Aquest és tot el mecanisme. Cap document separat, cap vinculació de comptes, cap incorporació per projecte. L'aplicació és una comprovació d'estat: l'aplicació DCO o una comprovació equivalent verifica que cada commit de la pull request porta una signatura vàlida, i els mantenidors només fusionen quan està verda.

Les limitacions deliberades de la DCO​

Fixeu-vos en què no fa la DCO. No atorga cap llicència més enllà del que ja transmet la llicència de sortida del projecte — es basa en que la contribució arriba sota els termes de la llicència del projecte. No conté cap cessió de patents. I com que no es signa ni s'arxiva res per contribuïdor, no hi ha cap registre central de qui va acceptar què; l'historial de git mateix és el registre.

Els defensors ho consideren una virtut: la barrera baixa de la DCO és precisament el punt. El nucli de Linux, GitLab (que va canviar d'una CLA el 2017) i Chef (que va canviar el 2016) van concloure que l'atestació per commit els dona la procedència que necessiten sense gravar cada contribuïdor. El Comitè Tècnic d'OpenStack va resoldre el 2025 substituir la seva CLA per la DCO per a totes les contribucions. La tendència del sector és inconfusible — però una tendència no és un veredicte per al teu projecte, com expliquen les seccions següents.

CLA vs. DCO cara a cara​

Quan una CLA és la decisió correcta​

Tria la CLA quan el futur del projecte pugui dependre de drets que la DCO no recull:

• Tens previst fer doble llicència o relicenciar. Si una edició comercial, un canvi de llicència o un pas de copyleft a llicència permissiva és fins i tot remotament plausible, una CLA amb una cessió àmplia de tornada és l'única manera lleugera de mantenir aquesta opció oberta. Reconstruir el consentiment anys després és l'escenari de malson.
• Hi ha una empresa al darrere del projecte. Els patrocinadors corporatius, els adquiridors i els clients empresarials que fan auditoria de propietat intel·lectual volen un registre de signatures, no arqueologia. Google, els projectes d'Apache i Canonical utilitzen CLA exactament per aquesta raó.
• Les patents importen en el teu àmbit. Còdecs, protocols sense fils, arquitectures de models d'ML — en camps amb moltes patents, la cessió explícita de patents de la CLA fa una feina real que la DCO omet silenciosament.
• Una fundació ho requereix. Algunes fundacions imposen la seva CLA com a condició per allotjar o graduar un projecte. Comprova-ho abans de donar per fet que la DCO és suficient.

Si segueixes aquest camí, mantén la CLA mateixa estàndard i avorrida: parteix de la ICLA d'Apache o d'una plantilla de Harmony en lloc de redactar-la des de zero, publica tant les versions individuals com les corporatives, i connecta un bot de signatures el primer dia perquè la fricció sigui un clic, no un anar i venir de PDFs.

Quan guanya la DCO​

Tria la DCO quan les contribucions són la sang vital i la fricció és l'enemic:

• Projectes comunitaris amb molts contribuïdors ocasionals. Correccions de documentació, esmenes de faltes, pedaços petits d'errors — les contribucions amb més probabilitats de desanimar-se davant una barrera de signatura també són les que una DCO gestiona amb gràcia.
• Llicència permissiva, sense plans de relicenciació. Si el projecte es quedarà com a MIT o Apache-2.0 per sempre i no hi ha cap edició comercial a l'horitzó, els drets extres de la CLA t'aporten poc.
• Mantenidors individuals i equips petits. La DCO no necessita infraestructura de signatures, ni una entitat legal que guardi acords, ni cap procés per contrasignar formularis corporatius. És governança que pots gestionar des d'un fitxer CONTRIBUTING.md i una comprovació d'estat.
• Postura de màxima compatibilitat. Alguns contribuïdors — particularment els empleats de grans empreses amb polítiques estrictes de propietat intel·lectual — poden signar una DCO però no poden signar una CLA externa sense revisió legal. La DCO manté aquesta porta oberta.

Tria el que triïs, deixa la decisió per escrit. Un CONTRIBUTING.md que exposa la política, mostra el flux exacte de signatura o certificació i enllaça el text complet elimina la font de confusió més comuna: contribuïdors endevinant els requisits a partir d'una comprovació d'estat fallida.

5 errors que soscaven qualsevol de les dues opcions​

1. Dir les dues coses. La fallada més comuna al món real és un CONTRIBUTING.md que exigeix certificacions DCO en un paràgraf i signatures CLA en un altre — normalment després d'una migració a mig fer. Els contribuïdors segueixen una instrucció, l'altra comprovació falla, i els mantenidors fusionen de totes maneres, cosa que anul·la el sentit de les dues. Tria un sol mecanisme, fes-lo complir i elimina qualsevol rastre de l'altre.

2. Cap aplicació automatitzada. Una política expressada només en prosa és un suggeriment. Connecta la comprovació al flux de treball de les pull requests com a comprovació d'estat requerida — l'aplicació DCO per a les certificacions, CLA Assistant o EasyCLA per a les signatures — de manera que una contribució no acordada no es pugui fusionar per accident o per fatiga del mantenidor.

3. Ignorar els contribuïdors corporatius. Si les empreses utilitzen i pedacen el teu projecte, els empleats lliuraran codi en horari laboral. Sota una política CLA, això significa aconseguir la signatura de la CCLA aviat, mentre la relació és càlida. Sota una política DCO, significa assegurar-te que el requisit de certificació sigui prou visible perquè la primera contribució de ningú es converteixi en un incident de propietat intel·lectual.

4. Assumir que els contractes laborals permeten contribuir. L'altra cara de la mateixa moneda: si contribueixes a altres projectes, comprova primer el teu propi contracte laboral. Molts assignen la propietat intel·lectual dels projectes personals relacionats amb la feina a l'ocupador per defecte. La certificació de la DCO ("tinc dret a lliurar això") només és certa si aquest paper ho diu així.

5. Cap política per al codi assistit per IA. Les contribucions generades per màquines plantegen qüestions de procedència que ni el text de la DCO de l'era del 2004 ni la majoria de plantilles de CLA van anticipar. Decideix la teva postura — permesa amb revisió, declarada o prohibida — i exposa-la al CONTRIBUTING.md juntament amb la teva política CLA/DCO, abans que arribi la teva primera pull request generada per IA, no després.

No oblidis la part financera del teu projecte​

Aquí hi ha la part que els mantenidors posposen fins a la temporada d'impostos: en el moment que el teu projecte guanya el seu primer dòlar — pagaments de GitHub Sponsors, donacions d'Open Collective, un encàrrec de consultoria que va arribar gràcies al teu README — té finances, i les finances necessiten llibres.

La mateixa disciplina que fa auditable la procedència de les contribucions fa manejable els diners del projecte. Registra els ingressos per patrocini per separat del teu sou per saber quina part és renda per compte propi subjecta a impostos. Registra les despeses del projecte — renovacions de dominis, minuts de CI, la tarda que un advocat va passar revisant la teva CLA — en els seus propis comptes perquè les deduccions no s'evaporin en extractes de targetes personals. Si el projecte creix fins a convertir-se en una LLC o s'uneix a un amfitrió fiscal, uns registres històrics nets fan que la transició sigui avorrida en lloc de forense.

La comptabilitat en text pla encaixa inusualment bé amb aquest flux de treball: el teu llibre major viu al control de versions al costat del teu codi, cada entrada té un historial, i res no s'amaga en un format propietari. La nostra documentació explica com posar en marxa un primer llibre major en minuts.

Mantén els llibres del teu projecte tan nets com el seu historial de git​

Triar entre una CLA i una DCO requereix una tarda; desembolicar la procedència o les finances del projecte anys després requereix setmanes. Pren la decisió sobre les contribucions ara, automatitza la seva aplicació, i dona als diners del projecte la mateixa cura que dones als seus commits. Beancount.io ofereix comptabilitat en text pla que et dona transparència i control complets sobre les teves dades financeres — sense caixes negres, sense dependència de proveïdor. Comença gratis i descobreix per què els desenvolupadors i els professionals de les finances s'estan passant a la comptabilitat en text pla.