$ npm ls --all | license-check
Qué hay en tu código, bajo qué licencia y qué te obliga. Antes de que lo pregunte un inversor, un comprador o un cliente.
Primera consulta: gratuita · Después: 60 €/h + IVA · Presupuesto cerrado antes de empezar
// 01 — cuándo
La due diligence técnica revisa licencias y titularidad. Un hallazgo tarde baja la valoración o retrasa el cierre.
El comprador exigirá garantías sobre el código. Mejor saber qué firmas antes de firmarlo.
Piden SBOM, cuestionarios de cumplimiento y garantías de no infracción.
Apps, instalables, on-premise o firmware. Distribuir activa las obligaciones del copyleft.
Los fabricantes deben documentar sus componentes en un SBOM y vigilar sus vulnerabilidades.
Tu equipo incorpora dependencias cada día. Sin reglas claras, el riesgo crece en cada merge.
// 02 — proceso
01
Partimos de tu SBOM (SPDX o CycloneDX) o de los manifiestos de dependencias. Directas e indirectas.
02
Licencia de cada componente, compatibilidad entre ellas y modo de integración: enlace, red, distribución.
03
Semáforo por componente: verde, ámbar, rojo. Visual, priorizado, legible por negocio y por ingeniería.
04
Sustituir, aislar, cumplir o licenciar. Con NOTICE, atribuciones y política de uso para que no se repita.
// 03 — entregables
01
Hallazgos, riesgo de cada uno y acción recomendada. Listo para el data room.
02
Componente, versión, licencia (identificador SPDX), obligaciones y estado de cumplimiento.
03
Textos de licencia y avisos de copyright que debes incluir en tu producto.
04
Licencias permitidas, prohibidas y a revisar. Flujo de aprobación de dependencias.
05
Revisión de las manifestaciones y garantías sobre software del contrato de inversión o compraventa.
// 04 — riesgos
AGPL en un SaaS
Obligación de ofrecer el código fuente de la versión modificada a los usuarios.
GPL en una app distribuida
Obligación de publicar el código de la obra derivada bajo GPL.
Atribuciones ausentes
Incumplimiento de MIT, BSD o Apache-2.0. Fácil de corregir, frecuente y visible.
Licencias incompatibles
Combinaciones que no se pueden distribuir juntas, como Apache-2.0 con GPL-2.0-only.
Código sin licencia
Copiado de foros o repositorios sin LICENSE. Todos los derechos reservados.
Source-available
BUSL, SSPL o Commons Clause tomadas por open source. Restricciones comerciales ocultas.
Titularidad incierta
Código de freelances o socios sin cesión escrita (art. 43 LPI).
// 05 — faq
Software Bill of Materials: la lista de componentes de un software, con versión y licencia. Los formatos estándar son SPDX y CycloneDX. El Cyber Resilience Act obliga a los fabricantes a elaborarlo, al menos para las dependencias de primer nivel.
Normalmente no. Basta con el SBOM o los manifiestos de dependencias (package.json, pom.xml, requirements.txt, go.mod…). Si hace falta revisar código, firmamos un acuerdo de confidencialidad. Además, todo lo que nos cuentas está protegido por el secreto profesional.
Depende del número de componentes y del objetivo (ronda, venta, CRA). Tras la consulta gratuita te damos presupuesto cerrado y plazo. Tarifa de referencia: 60 €/h + IVA.
Detecta licencias, no decide. Una herramienta no sabe si enlazas dinámicamente, si distribuyes o si das el servicio por red. Esa es la parte legal.
Cuatro opciones: sustituir el componente, aislarlo, cumplir sus condiciones o negociar una licencia comercial con su titular. Te decimos cuál conviene y cuánto cuesta cada una.
$ ./reservar
Cuéntanos el caso en una videollamada gratuita. Si podemos ayudarte, te enviamos presupuesto cerrado. Si no, te lo decimos.