Tu proyecto personal acaba de superar las 500 estrellas, y un desconocido ha abierto el primer pull request serio: 2.000 líneas que solucionan un problema que llevas meses evitando. Quieres hacer clic en fusionar. Pero antes de hacerlo, hazte la pregunta incómoda: ¿tienes realmente el derecho legal de distribuir ese código — y de seguir distribuyéndolo bajo tu licencia, para siempre, sin importar para quién trabaje ese colaborador?
Si tu repositorio no tiene una política de contribución, la respuesta honesta es que no estás seguro. El colaborador sigue siendo dueño de los derechos de autor de cada línea que escribió, y la licencia de tu proyecto por sí sola no siempre resuelve quién concedió qué a quién. Esa incertidumbre permanece invisible hasta el día en que importa: un relicenciamiento, una adquisición, un usuario corporativo haciendo diligencia debida de licencias, o el empleador de un colaborador reclamando que el trabajo era suyo desde el principio.
Dos mecanismos resuelven este problema, y casi todos los proyectos de código abierto eligen uno de ellos: el Acuerdo de Licencia de Colaborador (CLA, por sus siglas en inglés) y el Certificado de Origen del Desarrollador (DCO). Ambos existen para establecer que un colaborador tiene permitido hacer la contribución y que el proyecto tiene el derecho de distribuirla. Difieren enormemente en peso, fricción y en lo que te permiten hacer después. Esta guía explica cómo funciona cada uno, cuándo elegir cuál y cómo configurar tu elección en una tarde.
Por qué tu proyecto necesita una política de contribución
Los derechos de autor se otorgan automáticamente. En el momento en que alguien escribe código, es su dueño — sin registro, sin aviso de copyright requerido. Cuando lo envían a tu proyecto, tu licencia de código abierto cubre mucho, pero deja vacíos que solo cierra una política de contribución:
- La concesión entrante. Tu licencia saliente (MIT, Apache-2.0, GPL) dice a los usuarios qué pueden hacer con tu código. Una política de contribución deja explícito que las contribuciones entrantes llegan bajo términos compatibles, para que puedas distribuir el trabajo combinado sin rastrear la procedencia archivo por archivo a mano.
- Reclamaciones de empleadores. La mayoría de los contratos laborales asignan la propiedad intelectual de proyectos paralelos al empleador, al menos para el trabajo relacionado con el puesto del empleado. Una política que pide a los colaboradores confirmar que tienen el derecho de enviar la contribución pone esa responsabilidad — y el rastro documental — sobre el colaborador.
- Opcionalidad de relicenciamiento. Si alguna vez quieres cambiar licencias, añadir una edición comercial o donar el proyecto a una fundación, necesitas derechos de todos los colaboradores. Reunir ese permiso de forma retroactiva de docenas de colaboradores pasados está entre lo doloroso y lo imposible. Una política elegida el primer día decide si esa puerta permanece abierta.
- Protección de patentes. Las contribuciones de código pueden llevar consigo derechos de patente. Algunas políticas incluyen una concesión explícita de patentes; otras no, lo cual importa más de lo que la mayoría de los mantenedores se da cuenta.
Nada de esto requiere un bufete de abogados en nómina. Requiere elegir CLA o DCO, escribirlo en tu repositorio y hacerlo cumplir automáticamente. Esto es lo que implica cada elección.
¿Qué es un Acuerdo de Licencia de Colaborador (CLA)?
Un Acuerdo de Licencia de Colaborador es un documento legal firmado entre el colaborador y el proyecto (o la empresa o fundación que lo respalda). El colaborador firma una vez, y esa firma cubre todas sus contribuciones futuras.
A diferencia de las licencias de código abierto, los CLA no están estandarizados. Cada proyecto escribe el suyo, pero la mayoría cae en dos formas conocidas:
CLA individual vs. corporativo
- CLA individual (ICLA): firmado por una persona que contribuye en su propio nombre. Normalmente concede al proyecto una licencia amplia de copyright y a menudo una licencia de patentes, mientras el colaborador conserva sus propios derechos de autor.
- CLA corporativo (CCLA): firmado por una empresa, autorizando a sus empleados a contribuir. La empresa concede los mismos derechos para el trabajo que envían sus empleados. Los proyectos que aceptan contribuciones corporativas sin un CCLA confían en que el gerente de cada empleado lo sabe — y lo aprueba —, que es exactamente el tipo de confianza que se evapora durante la diligencia debida.
Concesión de licencia vs. cesión de derechos de autor
La mayoría de los CLA modernos son concesiones de licencia: el colaborador conserva la propiedad y da al proyecto una licencia perpetua, mundial y libre de regalías — a menudo lo bastante amplia como para permitir el relicenciamiento. El ICLA de la Apache Software Foundation es el ejemplo canónico.
Una minoría de proyectos usa la cesión de derechos de autor, donde el colaborador transfiere la propiedad directamente (el enfoque de la Free Software Foundation). La cesión da al proyecto la máxima libertad para hacer cumplir y relicenciar, pero es lo que más exige a los colaboradores y ha caído en desgracia entre los proyectos impulsados por la comunidad.
Lo que un CLA te cuesta a ti y a tus colaboradores
El compromiso es la fricción. Un colaborador primerizo debe salir del pull request, leer un documento legal, firmarlo (normalmente de forma electrónica) y esperar a que la verificación de estado se ponga en verde antes de que un mantenedor revise su código. Las herramientas lo han hecho casi indoloro — bots como CLA Assistant comentan en el pull request con un enlace de firma y registran la firma automáticamente —, pero sigue siendo una barrera entre "arreglé tu bug" y "puedes fusionar mi arreglo". Algunos colaboradores ocasionales se desaniman y se van.
A cambio, el proyecto obtiene un registro firmado y auditable: esta persona, en esta fecha, concedió estos derechos. Para proyectos con respaldo corporativo, proyectos con doble licencia y cualquier cosa que algún día pueda ser adquirida, ese rastro documental vale dinero real.
¿Qué es el Certificado de Origen del Desarrollador (DCO)?
El Certificado de Origen del Desarrollador fue introducido por la Linux Foundation en 2004 para el kernel de Linux, precisamente para evitar el peso de un CLA. No es un contrato que un colaborador firma y archiva. Es una certificación breve — cinco párrafos, versión 1.1 — que el colaborador afirma con cada commit añadiendo una línea Signed-off-by al mensaje 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]>Añadir la línea es un solo flag: git commit -s la agrega automáticamente usando tu identidad de Git configurada. Al firmar, el colaborador certifica que:
- Creó la contribución (total o parcialmente) y tiene el derecho de enviarla bajo la licencia de código abierto del proyecto, o
- Su contribución se basa en trabajo previo ya bajo una licencia de código abierto apropiada que permite este envío, o
- Recibió la contribución de alguien más que certificó uno de los puntos anteriores, y no la modificó, y
- Entiende que la contribución y su registro — incluida su firma — son públicos y se conservan indefinidamente.
Ese es todo el mecanismo. Sin documento aparte, sin vinculación de cuentas, sin incorporación por proyecto. La aplicación es una verificación de estado: la app DCO o una verificación equivalente comprueba que cada commit del pull request lleva una firma válida, y los mantenedores fusionan solo cuando está en verde.
Las limitaciones deliberadas del DCO
Fíjate en lo que el DCO no hace. No concede ninguna licencia más allá de lo que ya transmite la licencia saliente del proyecto — se apoya en que la contribución llegue bajo los términos de licencia del proyecto. No contiene concesión de patentes. Y como no se firma ni se archiva nada por colaborador, no hay un registro central de quién aceptó qué; el propio historial de git es el registro.
Sus defensores lo consideran una ventaja: la baja barrera del DCO es precisamente el punto. El kernel de Linux, GitLab (que cambió de un CLA en 2017) y Chef (que cambió en 2016) concluyeron que la atestación por commit les da la procedencia que necesitan sin gravar a cada colaborador. El Comité Técnico de OpenStack resolvió en 2025 reemplazar su CLA por el DCO para todas las contribuciones. La tendencia de la industria es inconfundible — pero una tendencia no es un veredicto para tu proyecto, como explican las siguientes secciones.
CLA vs. DCO en paralelo
| Dimensión | CLA | DCO |
|---|---|---|
| Mecanismo legal | Acuerdo firmado, archivado una vez por colaborador | Atestación por commit en el mensaje del commit |
| Qué hace el colaborador | Firma un documento (normalmente mediante un enlace de bot) | Añade Signed-off-by con git commit -s |
| Manejo de derechos de autor | Concesión explícita de licencia (o cesión) al proyecto | La contribución llega bajo la licencia del proyecto; sin concesión aparte |
| Concesión de patentes | Normalmente incluida | Ninguna |
| Libertad de relicenciamiento | Las concesiones amplias a menudo lo permiten | Sin derechos adicionales; relicenciar requiere el consentimiento de cada colaborador |
| Fricción para el colaborador | Mayor: leer, firmar, esperar la verificación | Mínima: un flag de Git |
| Herramientas de aplicación | CLA Assistant, EasyCLA, bots personalizados | App DCO, verificaciones del mensaje de commit |
| Registro de consentimiento | Base de datos de firmas | El propio historial de git |
| Cobertura empresarial | El CLA corporativo cubre a los empleados explícitamente | El colaborador autocertifica que tiene el derecho de enviar |
| Mejor encaje | Proyectos con respaldo corporativo, doble licencia o relevantes para adquisiciones | Proyectos comunitarios donde la fricción de contribución importa más |
Cuándo un CLA es la decisión correcta
Elige el CLA cuando el futuro del proyecto pueda depender de derechos que el DCO no captura:
- Planeas doble licencia o relicenciar. Si una edición comercial, un cambio de licencia o un paso de copyleft a permisiva es siquiera remotamente plausible, un CLA con una concesión amplia de vuelta es la única forma ligera de mantener esa opción abierta. Reconstruir el consentimiento años después es el escenario de pesadilla.
- Una empresa respalda el proyecto. Patrocinadores corporativos, compradores y clientes empresariales que hacen diligencia debida de PI quieren un registro de firmas, no arqueología. Google, los proyectos de Apache y Canonical usan CLA exactamente por esta razón.
- Las patentes importan en tu dominio. Códecs, protocolos inalámbricos, arquitecturas de modelos de ML — en campos con muchas patentes, la concesión explícita de patentes del CLA hace un trabajo real que el DCO omite silenciosamente.
- Una fundación lo exige. Algunas fundaciones exigen su CLA como condición para alojar o graduar un proyecto. Verifícalo antes de asumir que el DCO basta.
Si tomas este camino, mantén el CLA en sí estándar y aburrido: parte del ICLA de Apache o de una plantilla de Harmony en lugar de redactarlo desde cero, publica versiones individual y corporativa, y conecta un bot de firma desde el primer día para que la fricción sea un clic, no un ida y vuelta de PDF.
Cuándo gana el DCO
Elige el DCO cuando las contribuciones son el alma del proyecto y la fricción es el enemigo:
- Proyectos comunitarios con muchos colaboradores ocasionales. Correcciones de documentación, arreglos de erratas, pequeños parches de bugs — las contribuciones más propensas a desanimarse ante una barrera de firma son también las que un DCO maneja con gracia.
- Licencia permisiva, sin planes de relicenciar. Si el proyecto permanecerá en MIT o Apache-2.0 para siempre y no hay una edición comercial en el horizonte, los derechos adicionales del CLA te aportan poco.
- Mantenedores en solitario y equipos pequeños. El DCO no necesita infraestructura de firmas, ni una entidad legal que retenga acuerdos, ni un proceso para refrendar formularios corporativos. Es gobernanza que puedes gestionar desde un archivo
CONTRIBUTING.mdy una verificación de estado. - Postura de máxima compatibilidad. Algunos colaboradores — particularmente los empleados por grandes empresas con políticas estrictas de PI — pueden firmar un DCO pero no pueden firmar un CLA externo sin revisión legal. El DCO mantiene esa puerta abierta.
Elijas lo que elijas, escribe la decisión. Un CONTRIBUTING.md que establece la política, muestra el flujo exacto de firma o sign-off y enlaza el texto completo elimina la fuente más común de confusión: colaboradores adivinando los requisitos a partir de una verificación de estado fallida.
5 errores que socavan cualquiera de las dos opciones
1. Decir ambas cosas. El fallo más común en el mundo real es un CONTRIBUTING.md que exige firmas DCO en un párrafo y firmas CLA en otro — normalmente tras una migración a medias. Los colaboradores siguen una instrucción, la otra verificación falla, y los mantenedores fusionan de todos modos, lo que anula el propósito de ambas. Elige un mecanismo, hazlo cumplir y borra todo rastro del otro.
2. Ninguna aplicación automatizada. Una política enunciada solo en prosa es una sugerencia. Conecta la verificación a tu flujo de trabajo de pull requests como una verificación de estado requerida — la app DCO para los sign-offs, CLA Assistant o EasyCLA para las firmas — para que una contribución sin acuerdo no pueda fusionarse por accidente o por fatiga del mantenedor.
3. Ignorar a los colaboradores corporativos. Si las empresas usan y parchean tu proyecto, los empleados enviarán código en horario laboral. Bajo una política de CLA, eso significa conseguir el CCLA firmado pronto, mientras la relación es cordial. Bajo una política de DCO, significa asegurarte de que el requisito de sign-off sea lo bastante visible para que la primera contribución de nadie se convierta en un incidente de PI.
4. Asumir que los contratos laborales permiten contribuir. La otra cara de la misma moneda: si contribuyes a otros proyectos, revisa primero tu propio contrato laboral. Muchos asignan la PI de proyectos paralelos relacionados con el trabajo al empleador por defecto. La certificación del DCO ("tengo el derecho de enviar esto") solo es cierta si ese papeleo lo dice.
5. Ninguna política para código asistido por IA. Las contribuciones generadas por máquinas plantean preguntas de procedencia que ni el texto del DCO de 2004 ni la mayoría de las plantillas de CLA anticiparon. Decide tu postura — permitido con revisión, divulgado o prohibido — y declárala en CONTRIBUTING.md junto a tu política de CLA/DCO, antes de que llegue tu primer pull request generado por IA en lugar de después.
No olvides el lado financiero de tu proyecto
Aquí está la parte que los mantenedores posponen hasta la temporada de impuestos: en el momento en que tu proyecto gana su primer dólar — pagos de GitHub Sponsors, donaciones de Open Collective, un encargo de consultoría que llegó gracias a tu README — tiene finanzas, y las finanzas necesitan libros.
La misma disciplina que hace auditable la procedencia de las contribuciones hace manejable el dinero del proyecto. Registra los ingresos por patrocinio por separado de tu salario para saber qué es ingreso tributable por trabajo autónomo. Registra los gastos del proyecto — renovaciones de dominio, minutos de CI, la tarde que un abogado pasó revisando tu CLA — en sus propias cuentas para que las deducciones no se evaporen en los estados de cuenta personales. Si el proyecto crece hasta convertirse en una LLC o se une a un anfitrión fiscal, los registros históricos limpios hacen que la transición sea aburrida en lugar de forense.
La contabilidad de texto plano encaja inusualmente bien con este flujo de trabajo: tu libro mayor vive en el control de versiones junto a tu código, cada asiento tiene un historial y nada se esconde en un formato propietario. Nuestra documentación explica cómo poner en marcha un primer libro mayor en minutos.
Mantén las cuentas de tu proyecto tan limpias como su historial de Git
Elegir entre un CLA y un DCO lleva una tarde; desenredar la procedencia o las finanzas del proyecto años después lleva semanas. Toma la decisión de contribución ahora, automatiza su aplicación y da al dinero del proyecto el mismo cuidado que das a sus commits. Beancount.io ofrece contabilidad de texto plano que te da total transparencia y control sobre tus datos financieros — sin cajas negras, sin dependencia de proveedor. Empieza gratis y descubre por qué desarrolladores y profesionales de las finanzas se están pasando a la contabilidad de texto plano.
