Cumplimiento de licencias de código abierto

Esta página ofrece información general, no asesoramiento jurídico. Para decisiones sobre un producto concreto, consulte a un abogado.

Tipos de licencias de código abierto

Tipo	Ejemplos	Qué suele exigir
Permisiva	MIT, BSD, Apache-2.0	Conservar los avisos de copyright y de licencia. Apache-2.0 incluye además condiciones sobre patentes.
Copyleft débil	LGPL, MPL-2.0	Compartir los cambios en el propio componente licenciado
Copyleft fuerte	GPL-2.0, GPL-3.0	El software distribuido con él debe ofrecerse en las mismas condiciones, con el código fuente
Copyleft de red	AGPL-3.0	Igual que el copyleft fuerte, y además se aplica cuando los usuarios interactúan con el software a través de una red
Código fuente disponible	BUSL, SSPL	No es código abierto: el código fuente es visible, pero su uso está restringido

¿Qué es una licencia copyleft?

Una licencia copyleft le permite usar, modificar y compartir software, con la condición de que lo que distribuya siga bajo las mismas condiciones. Así el código abierto sigue siendo abierto. El riesgo para un producto comercial es que un componente con copyleft fuerte enlazado con su código puede plantear la cuestión de si también debe publicar su propio código.

Que esto se aplique o no depende de cómo se use el componente y de cómo se entregue el producto. El software que distribuye a sus clientes está más expuesto que una herramienta interna, y un producto SaaS suele evitar las condiciones de distribución de la GPL, pero no las de la AGPL.

Riesgos habituales de cumplimiento

• Licencias transitivas. Un paquete permisivo puede depender de otro con copyleft. Comprobar solo las dependencias directas no lo detecta.
• Avisos que faltan. La mayoría de las licencias le pide conservar la atribución, y un archivo de avisos olvidado es el fallo más común.
• Licencias que cambian. Un proyecto puede cambiar de licencia en una nueva versión, de modo que una actualización puede cambiar sus condiciones.
• Declarada frente a real. Los metadatos de un paquete pueden ser erróneos o incompletos, y el código de terceros copiado en su proyecto puede tener su propia licencia.
• Due diligence. Los compradores y los grandes clientes piden un inventario de licencias, normalmente con poca antelación.

Cómo cumplir

1. Redacte una política. Decida qué licencias se permiten, cuáles requieren revisión y cuáles se prohíben, según el tipo de producto.
2. Cree un inventario. Una SBOM enumera cada componente con su licencia, incluidas las dependencias transitivas.
3. Compruebe automáticamente. Aplique la política en CI, para que una dependencia nueva falle en el momento de añadirla y no en una auditoría.
4. Cumpla las obligaciones. Genere archivos de avisos y proporcione el código fuente cuando una licencia lo exija.
5. Conserve los registros. Guarde el inventario por versión, porque la pregunta suele referirse a una versión que ya distribuyó.

Qué hace el software de cumplimiento de licencias

El cumplimiento de licencias es una parte habitual del análisis de composición de software. Las herramientas identifican los componentes, informan de sus licencias y señalan las infracciones de su política. Se diferencian en la profundidad:

• Licencias declaradas: la mayoría de las herramientas lee lo que cada paquete declara en sus metadatos. Es rápido y cubre el caso común.
• Escaneo profundo de licencias: FOSSA y Black Duck analizan además el texto de las licencias en el código y ayudan con los informes de atribución y la revisión legal. Consulte CRACI vs FOSSA y CRACI vs Black Duck.
• Herramientas gratuitas: muchos generadores de SBOM y escáneres SCA informan de las licencias declaradas sin coste. Consulte las mejores herramientas de SCA.

Dónde encaja CRACI

CRACI gestiona las licencias declaradas en el build. Como su runner de GitHub Actions, registra cada paquete que incorpora un job, y cada uno lleva su licencia declarada, de modo que las licencias copyleft se detectan antes de que acaben en el producto. Las reglas de política de licencias pueden bloquear un build por una licencia, y las exportaciones de SBOM en CycloneDX y SPDX incluyen la licencia declarada de cada componente. CRACI trabaja a partir de lo que declaran los paquetes, así que, si necesita flujos de revisión legal o análisis del texto de las licencias, use una herramienta especializada junto a él.

Cumplimiento de licencias de código abierto: preguntas frecuentes

¿Qué es el cumplimiento de licencias de código abierto?

Significa saber qué licencias de código abierto se aplican al software que utiliza y cumplir sus condiciones, como conservar los avisos o compartir el código fuente.

¿Qué es una licencia copyleft?

Una licencia que le permite usar y modificar software con la condición de que lo que distribuya siga bajo las mismas condiciones. La GPL es el ejemplo más conocido.

¿Se puede usar código GPL en software comercial?

Sí, pero si distribuye software que lo incluye, es posible que tenga que ofrecer el código fuente de ese software bajo la GPL. Importa cómo se combina el código, así que busque asesoramiento jurídico para su caso.

¿Se aplica el copyleft al SaaS?

Las condiciones de la GPL suelen activarse con la distribución, algo que el SaaS normalmente evita. La AGPL cierra esa laguna al extender las condiciones a los usuarios que interactúan con el software a través de una red.

¿Cuál es la licencia de código abierto más segura para uso comercial?

Las licencias permisivas como MIT, BSD y Apache-2.0 son las que menos exigen. Aun así, debe conservar sus avisos.

¿Cómo se comprueban las licencias de las dependencias?

Genere una SBOM que incluya las dependencias transitivas y las licencias declaradas, o use una herramienta de SCA. Aplique su política en CI, para que las nuevas infracciones hagan fallar el build.