Auditoría de licencias open-source para repos heredados: un plan práctico

Por qué los repos heredados crean riesgo de licencias

Cuando un repositorio cambia de manos, heredas más que código. Heredas cada elección de licencia, cada dependencia y cada aviso faltante que el equipo anterior omitió. Si el proyecto empezó como un prototipo rápido (o fue generado por una herramienta de codificación por IA), las licencias a menudo se tratan como algo “para después” hasta que alguien fuera del equipo hace preguntas difíciles.

Los modos de fallo suelen ser simples, pero caros:

• Una dependencia está bajo una licencia que un cliente no aceptará.
• Textos de licencia o avisos de copyright requeridos no se incluyen en lo que entregas.
• La build incorpora paquetes transitivos que nadie revisó.
• Un fragmento copiado, fuente, icono o activo tiene términos que no coinciden con tu uso previsto.

Los clientes y partners piden pruebas porque se están protegiendo. Si ellos entregan tu software, incorporan tu SDK o revenden tu producto, también pueden volverse responsables del cumplimiento. Los equipos de procurement empresarial comúnmente solicitan un Software Bill of Materials (SBOM), un archivo de third-party notices y una declaración clara de cómo cumples las obligaciones de licencia. Si no puedes producir eso, los tratos se ralentizan, las revisiones se vuelven más estrictas y los equipos legales pueden bloquear el despliegue.

Un malentendido común es considerar la propiedad del repo como derechos de licencia. Ser propietario de la organización en GitHub (o que un contratista te entregue el código) no te concede automáticamente permiso para usar, modificar o distribuir todo lo que hay dentro. Las licencias open-source son permisos con condiciones. Quieres saber qué condiciones aplican antes de distribuir, especialmente si distribuyes binarios, vendes un SaaS pago o das una copia a partners.

El objetivo práctico de una auditoría es sencillo: encontrar lo que realmente está incluido, detectar huecos temprano y producir artefactos de cumplimiento claros. No reemplazará el asesoramiento legal, ni resolverá todos los casos límite, pero puede sacar a la luz problemas mientras aún es barato arreglarlos.

Conceptos básicos de licencias (sin jerga legal)

Una licencia es el reglamento sobre cómo puedes usar el código de otra persona. Cuando heredas un repositorio, también heredas sus reglas y su papeleo. Un primer paso útil es separar las “licencias de baja fricción” de las “licencias de compartir igual” y luego confirmar que has cumplido las obligaciones básicas.

Licencias permisivas (como MIT y Apache-2.0) por lo general permiten su uso en casi cualquier producto, incluidos comerciales. El coste es administrativo: conserva avisos de copyright, incluye el texto de la licencia cuando se requiere y no afirmes que fuiste el autor original.

Licencias copyleft (como GPL) también permiten uso, pero pueden exigir que si distribuyes un producto que incluye el código, compartas el código fuente del trabajo combinado bajo los mismos términos. AGPL es similar, pero puede extender el disparador de “compartir el código” al software ofrecido a través de la red, por eso los equipos de SaaS a menudo la evitan.

En la práctica, “obligaciones de licencia” suelen significar trabajo poco glamuroso:

• Incluir textos de licencia y avisos de copyright requeridos con tu distribución
• Proporcionar atribución en un archivo THIRD-PARTY-NOTICES (o similar)
• Rastrear modificaciones cuando la licencia lo espera
• Para copyleft, estar preparado para compartir el código fuente cuando sea requerido
• Evitar usar marcas o nombres de forma que la licencia lo prohíba

Las licencias duales sorprenden porque el mismo proyecto puede ofrecerse bajo dos conjuntos de reglas distintos. Una librería puede ser “GPL para proyectos open-source” y “licencia comercial para productos cerrado”, o puede contener archivos bajo distintas licencias. Si alguien tomó código del lugar equivocado, puedes acabar con términos más estrictos de los esperados.

No necesitas memorizar cada detalle de licencias. Necesitas saber cuáles son fáciles de cumplir, cuáles cambian tus deberes de distribución y cuáles pueden bloquear un trato cuando el equipo de cumplimiento de un cliente las detecta.

Dónde se esconden las licencias en un repo moderno

La mayoría de los problemas de licencia en código heredado no están en la dependencia única que recuerdas haber añadido. Aparecen en lugares que la gente no revisa hasta que un cliente pide pruebas.

Empieza con dependencias directas (paquetes listados en archivos como package.json, requirements.txt, go.mod, Gemfile). La sorpresa mayor son las dependencias transitivas: paquetes que tus paquetes traen consigo. Una librería directa puede traer docenas de licencias transitivas, y esas pueden cambiar tras un pequeño bump de versión.

Los repos frontend añaden otro lugar donde esconderse: activos incluidos. Las herramientas de build a menudo empaquetan código en un único archivo minificado, y ese proceso puede eliminar encabezados o avisos que normalmente viajarían con el código fuente. Fragmentos copiados son similares. Una función auxiliar pegada desde un blog, un gist o una respuesta en Stack Overflow aún puede llevar requisitos de licencia.

También revisa lo que se entrega alrededor de tu app, no solo la app. Contenedores e imágenes base pueden incluir paquetes del SO (y sus licencias) que terminen en producción. Si heredaste un Dockerfile, heredaste su equipaje de licencias también.

Lugares comunes donde se esconden:

• Manifiestos de dependencias y lockfiles (directos y transitivos)
• Carpetas vendor, librerías copiadas y directorios “utils”
• Bundles frontend construidos e fuentes/iconos embebidos
• Imágenes base de contenedor y paquetes instalados del SO
• “Código misterioso” agregado rápidamente, incluido código generado por IA que puede reproducir fuentes con licencia

Señales de alerta que puedes detectar en 10 minutos

No necesitas una auditoría completa para identificar problemas probables. Una revisión rápida puede decirte si un repo podría fallar la revisión de un cliente o partner.

Mira primero los manifiestos de dependencias y los lockfiles. Cientos de dependencias sin lockfile (o lockfiles múltiples que no coinciden) son una señal de que no podrás demostrar qué se envió. Observa dependencias de registries privados o dependencias apuntando a repos Git. Esas a menudo carecen de metadatos de licencia claros.

Luego, revisa si hay artefactos de build comprometidos en el repo. Carpetas como dist, build, vendor, third_party o bundles minificados copiados son fuentes comunes de avisos faltantes. Si el código está copiado en lugar de instalarse con un gestor de paquetes, puede que no tengas una forma automática de recopilar textos de licencia.

Si el repo es un monorepo (por ejemplo, packages/* o libs/*), abre algunos paquetes internos. La falta de archivos LICENSE o notas de propiedad poco claras puede convertirse en un lío cuando los paquetes se publican por separado.

Finalmente, comprueba lo que realmente se entrega. Si no hay un archivo de third-party notices (a menudo THIRD_PARTY_NOTICES o NOTICE) en releases, instaladores o imágenes de contenedor, ese es un hueco común de cumplimiento.

Una triage rápida:

• Lockfiles ausentes o inconsistentes con la build
• Dependencias basadas en Git o con “licencia desconocida”
• Código de terceros comprometido en el repo (vendor o bundles)
• Ningún archivo de avisos en el proceso de release

Si aparece más de uno de estos, planea una revisión más profunda antes de que alguien más lo descubra.

Paso a paso: ejecutar una auditoría de licencias open-source

Las auditorías de licencias fluyen mejor si las tratas primero como inventario y luego como papeleo. Empieza identificando lo que realmente entregas, porque las obligaciones a menudo dependen de la distribución.

1) Construye un inventario limpio de lo que se entrega

Lista cada artefacto que sale de tu control: un bundle web, una app móvil, un instalador de escritorio, una imagen de contenedor, un paquete on-prem, incluso un ZIP que envías a un partner.

Luego recopila los archivos que definen tu grafo de dependencias. Las versiones importan.

• Manifiestos de build como package.json, pyproject.toml, requirements.txt, Gemfile, go.mod
• Lockfiles como package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, Gemfile.lock, go.sum, Cargo.lock, composer.lock
• Archivos de contenedor y despliegue (Dockerfiles, charts de Helm, pipelines de build)
• Carpetas vendor o código copiado (vendor/, third_party/, a veces libs/)
• Metadatos de tiendas de apps o pantallas “Acerca de” (lugares comunes para mostrar avisos)

2) Escanea, confirma y registra obligaciones

Un flujo de trabajo práctico que la mayoría de equipos puede seguir:

1. Genera una lista de dependencias (directas y transitivas) a partir de lockfiles y la salida de build.
2. Identifica la licencia para cada versión de dependencia. Marca todo lo “desconocido” o “personalizado”.
3. Cruz-checkea los datos de licencia entre fuentes (metadatos del registry, LICENSE del repo, encabezados de archivos).
4. Registra las obligaciones que debes satisfacer (atribución, inclusión de texto de licencia, ubicación de avisos, disparadores de compartir código).
5. Decide qué es aceptable según cómo entregas el software (solo SaaS vs distribuir binarios u on-prem).

Una app de escritorio normalmente necesita avisos de terceros incluidos con el instalador. La distribución SaaS puede ser distinta, pero los clientes y partners aún esperan registros claros.

Los repos heredados a menudo vienen con lockfiles faltantes y código copiado. Si no puedes reproducir el conjunto de dependencias, arregla eso primero. De lo contrario, cada decisión de licencia es inestable.

Errores comunes que provocan problemas de cumplimiento

La mayoría de los problemas de cumplimiento no surgen por mala intención. Ocurren porque equipos heredan un repo, lanzan rápido y nunca verifican qué hay dentro.

Problemas recurrentes:

• Los metadatos no coinciden con la realidad. Un README afirma “MIT”, pero los metadatos del paquete son incorrectos o faltan identificadores SPDX.
• Snippets copiados sin atribución. “Solo una función auxiliar” aún puede acarrear condiciones de licencia.
• Copyleft fuerte en el lugar equivocado. Dependencias GPL/AGPL pueden crear obligaciones que no se alinean con tu modelo de venta u hospedaje.
• Activos no-code ignorados. Fuentes, iconos, imágenes y kits UI suelen tener licencias separadas.
• Alguien confió en oídas. Un post de blog o un comentario no es una licencia. El texto de la licencia y los metadatos del paquete son lo que importa.

Incluso si tu dependencia directa es permisiva, una dependencia transitive traída silenciosamente puede no serlo. Revisar solo paquetes de primer nivel deja pasar los problemas que los clientes suelen encontrar.

Un escenario común: heredas un prototipo, ves un único archivo LICENSE y asumes que cubre todo el repo. Más tarde, un cliente empresarial pide third-party notices y descubres activos empaquetados con sus propios términos y sin atribución en ningún lado.

Cómo arreglar hallazgos: avisos, reemplazos y documentación

Después de una auditoría, el objetivo no es la perfección. Es claridad: qué usas, qué debes entregar con ello y qué no puedes hacer.

Empieza creando (o actualizando) un archivo THIRD-PARTY-NOTICES. Mantenlo aburrido y completo. Para cada dependencia, incluye el nombre, la versión, la licencia y dónde aparece (web app, servidor, móvil, imagen de contenedor). Esto suele ser lo primero que buscan los partners.

Luego, añade los textos de licencia requeridos. Si una licencia exige que el texto o aviso de copyright se incluya con las distribuciones, recopila esos textos en una carpeta licenses/ y refiérelos desde THIRD-PARTY-NOTICES.

Si encuentras una licencia de alto riesgo para tu modelo de negocio (por ejemplo, copyleft fuerte en una librería enlazada a un producto cerrado), generalmente tienes tres caminos: reemplazarla, aislarla detrás de un límite de servicio o obtener una licencia comercial. La elección correcta depende de cómo se usa el componente, no solo de la etiqueta de la licencia.

Para que esto sea repetible, añade un corto COMPLIANCE.md que explique cómo generas el inventario y dónde vive el papeleo. Manténlo práctico: qué lockfiles están en alcance, qué excluyes (herramientas dev-only, frameworks de prueba) y por qué, y qué comandos reproducen el escaneo.

Finalmente, establece una regla ligera de incorporación para nuevas dependencias: no merges una nueva librería hasta que se conozca su licencia (con un identificador SPDX real cuando sea posible) y hasta que las actualizaciones de avisos estén manejadas cuando se requiera.

Qué suelen querer ver los partners en un paquete de cumplimiento

La mayoría de los partners no piden un ensayo legal. Quieren prueba de que sabes qué software de terceros está dentro de tu producto, qué reglas aplican y quién lo mantiene actualizado.

Un buen paquete suele comenzar con un resumen corto: qué familias de licencias aparecen en lo que envías (permisivas como MIT/Apache, copyleft débil como LGPL, copyleft fuerte como GPL/AGPL), más el alcance del escaneo y la fecha.

Luego viene la evidencia: un inventario de dependencias que alguien más pueda verificar, con nombres, versiones exactas, licencias detectadas y dónde se encontró cada elemento (lockfile, directorio vendor, capa de contenedor, output de build).

Casi siempre necesitarás textos reales y atribuciones, no solo etiquetas.

Mínimo práctico para incluir

• Un resumen breve de licencias para el producto enviado
• Una lista de dependencias con nombres, versiones y licencias
• Third-party notices (atribuciones necesarias y textos de licencia completos cuando se requieran)
• Notas sobre excepciones (licencias comerciales, aprobaciones por escrito)
• Un propietario nombrado y una cadencia simple de revisión

Un detalle que reduce ida y vuelta: indicar las áreas grises desde el principio. Ejemplos: “El paquete X no tenía archivo de licencia, así que lo reemplazamos” o “Una herramienta dev GPL fue removida de la imagen de producción y se excluye del SBOM.”

Escenario de ejemplo: prototipo heredado, revisión empresarial

Una startup compra un prototipo funcional a un contratista y lo pone en producción rápidamente. Las demos se ven bien, así que el equipo se centra en características y ventas. Tres meses después, un cliente empresarial inicia una revisión de seguridad y procurement y pregunta: “¿Pueden proveer una lista de todo el software de terceros y sus licencias?”

El equipo ejecuta una auditoría y encuentra una dependencia copyleft (GPL/AGPL) en el flujo central. Ahorró tiempo al principio, pero los términos no coinciden con cómo la startup planea vender y distribuir el producto.

Pausan el trato y hacen tres cosas en paralelo: confirman la dependencia/versión exacta y dónde se usa, la reemplazan por una alternativa permisiva y refactorizan la integración, y ordenan el papeleo para que el cliente vea una historia completa y consistente.

Lo que envían de vuelta es corto y específico:

• Una lista de dependencias con nombres, versiones y licencias
• Un archivo de third-party notices que coincide con lo que se entrega
• Una nota documentando la dependencia removida y su reemplazo
• Un registro de la fecha del escaneo y la configuración de la herramienta

Después de cerrar el trato, añaden una verificación de licencias en CI, requieren actualizaciones de avisos antes de releases y mantienen una “lista de licencias permitidas” que coincida con su modelo de negocio.

Lista rápida y siguientes pasos

Trata el trabajo de licencias como un requisito de release, no como un apuro único. Antes de conversaciones serias con clientes, deberías poder responder: “¿Qué exactamente enviamos y bajo qué licencias?”

Una línea base pre-release:

• Inventario completo de lo que entregas (incluyendo dependencias transitivas y activos empaquetados)
• Versiones fijadas y licencias conocidas (sin “desconocido”, “personalizado” o “ver README” sin resolver)
• Avisos listos para enviar (third-party notices, avisos de copyright requeridos, textos de licencia requeridos)
• Builds reproducibles (lockfiles comprometidos y realmente usados)
• Un propietario claro para actualizaciones continuas

Si tienes un lanzamiento en las próximas 1 a 2 semanas, prioriza avisos y builds reproducibles primero. Eso es lo que los partners pueden verificar rápidamente. Si tienes más tiempo, añade una regla de incorporación de dependencias para que las licencias no se redescubran durante procurement.

Si el repo es heredado o generado por IA, espera huecos: lockfiles faltantes, paquetes no usados, código copiado sin encabezados y artefactos de build que empaquetan archivos de terceros. Cuando la base de código ya es inestable, a menudo es más rápido arreglar la build y el inventario primero, luego hacer el papeleo.

Pedir ayuda cuando el repo está desordenado o fue generado por IA

Cuando un repositorio está heredado y a medio funcionar, el trabajo de licencias puede sentirse como adivinanza. Se complica si el código fue producido rápidamente por herramientas de IA, porque pueden añadirse dependencias sin mucha revisión, los snippets pueden carecer de encabezados y los artefactos enviados pueden incluir archivos de terceros que nadie recuerda.

Ayuda dividir el trabajo en dos pistas:

• Decisiones legales: interpretar obligaciones (por ejemplo, si tu distribución dispara términos copyleft, o cómo manejar releases pasadas que no incluyeron avisos).
• Limpieza de ingeniería: inventario, automatización y arreglar el repo para que puedas repetir el proceso en cada release.

Un patrón práctico es que los ingenieros produzcan los hechos (lista de dependencias, licencias, avisos) y el asesor legal revise casos límite y apruebe el texto.

Si necesitas ayuda práctica para convertir un prototipo heredado y roto en algo que puedas enviar y defender durante revisiones, FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar codebases generados por IA o heredados, incluyendo refactorización, hardening de seguridad y preparación para despliegue. Una build limpia y estable suele ser la ruta más rápida a un inventario de dependencias confiable y un paquete de avisos que los partners aceptarán.

Antes de pedir ayuda a alguien, reúne unos básicos para que el trabajo sea preciso: acceso al repo (o una exportación saneada), tus pasos actuales de build y release, un artefacto de ejemplo que se haya enviado (imagen/zip/instalador/bundle) y cualquier cuestionario de cliente que ya hayas recibido.