Licencias open source: riesgos de GPL, MIT y Apache

El software de código abierto es gratuito, pero no está libre de condiciones. Las licencias permisivas, como MIT y Apache 2.0, permiten casi cualquier uso, también en productos propietarios, siempre que se conserven los avisos exigidos; las licencias copyleft, como la GPL, obligan a que, si usted distribuye software basado en código GPL, licencie toda la obra bajo la GPL y facilite el código fuente. Conocer los riesgos de las licencias open source y gestionarlos es ya una pregunta habitual en rondas de inversión, adquisiciones y contratos con clientes. Esta guía se dirige a directores técnicos, asesores internos y fundadores cuyos productos incluyen código de terceros.

En resumen

Las licencias open source son licencias de derechos de autor: usar el código fuera de sus términos es una infracción, y la GPL se extingue automáticamente con el incumplimiento.
MIT y Apache 2.0 exigen sobre todo reconocimiento; Apache 2.0 añade una licencia de patentes que se extingue si usted demanda por patentes sobre ese código.
Las obligaciones de la GPL se activan principalmente al distribuir el software; la AGPL las extiende a los usuarios que interactúan en red con una versión modificada.
Cuente con que compradores e inversores le pidan un inventario de componentes y licencias; ISO/IEC 5230 e ISO/IEC 5962 (SPDX) ofrecen un marco reconocido.

¿Por qué las licencias open source son una cuestión de PI?

El software está protegido por derechos de autor como programa de ordenador si es original (TRLPI, art. 96, en España). Los derechos exclusivos del titular abarcan la reproducción, incluida la carga y ejecución cuando requieren una copia, la transformación y cualquier forma de distribución pública (art. 99). Una licencia open source es la autorización que le permite realizar esos actos con código ajeno. Si se sale de sus condiciones, está usando el código sin permiso.

La GPL lo dice expresamente. Según la GPL versión 3 (29 de junio de 2007), cualquier intento de propagar o modificar la obra fuera de lo que permite la licencia es nulo y extingue automáticamente sus derechos (sección 8). La versión 3 permite a quien incumple por primera vez recuperar la licencia si corrige el incumplimiento dentro de los 30 días siguientes a la notificación del titular; la GPL versión 2 (junio de 1991) no prevé ese plazo de subsanación (sección 4).

GPL, MIT y Apache: comparativa

Licencia	Tipo	Condiciones principales	Patentes
MIT	Permisiva	Conservar el aviso de copyright y el de permiso en todas las copias o partes sustanciales	Sin cláusula expresa de patentes
Apache 2.0	Permisiva	Entregar copia de la licencia, marcar los archivos modificados, conservar los avisos y reproducir las atribuciones del archivo NOTICE	Licencia expresa de patentes de los contribuidores, que se extingue si usted demanda alegando que la obra infringe una patente
GPL v2	Copyleft	Las obras distribuidas basadas en el programa deben licenciarse en su conjunto bajo la GPL, con el código fuente	Sin licencia expresa de patentes
GPL v3	Copyleft	Como la v2 para la «transmisión» (conveying), con reglas detalladas para facilitar el código fuente correspondiente	Licencia expresa de patentes de cada contribuidor
AGPL v3	Copyleft de red	Como la GPL v3, y además ofrecer el código fuente de una versión modificada a quienes interactúan con ella en red	Como la GPL v3

Fuentes: Licencia MIT (Open Source Initiative), Licencia Apache 2.0 (enero de 2004), secciones 3 y 4, y los textos de las licencias GNU.

¿Cuándo se activan realmente las obligaciones de la GPL?

Las obligaciones copyleft van ligadas a la distribución. La GPL v2 exige que toda obra que usted distribuya o publique y que contenga el programa o derive de él se licencie en su conjunto bajo la GPL (sección 2.b), con el código fuente (sección 3). La GPL v3 utiliza el término «convey» (transmitir) y obliga a licenciar la obra entera bajo la GPL a quien reciba una copia (sección 5.c) y a facilitar el código fuente correspondiente junto con el código objeto (sección 6).

De ahí se derivan tres consecuencias prácticas:

El uso y la modificación puramente internos, sin distribuir copias, no activan la obligación de publicar el código fuente.
El software como servicio se trata de forma distinta en cada licencia: la GPL v3 aclara que la mera interacción con un usuario a través de una red, sin transferencia de una copia, no es transmisión; en cambio, la AGPL v3 le obliga a ofrecer a los usuarios remotos el código fuente de su versión modificada (sección 13).
Incluir código GPL junto a programas separados e independientes en un mismo soporte (un «agregado») no extiende la GPL a estos, pero combinar el código en un programa mayor, por lo general, sí.

Las apps, el firmware, el software instalado en casa del cliente y los dispositivos se distribuyen, y por eso concentran la mayoría de los problemas de copyleft.

Las licencias open source en una due diligence

En una due diligence, compradores e inversores pueden pedir una lista de materiales de software (SBOM), es decir, la relación de componentes y sus licencias. La especificación SPDX, un formato común para esa información, está reconocida como la norma internacional ISO/IEC 5962:2021. Para los procesos, la especificación OpenChain se convirtió en ISO/IEC 5230:2020 en diciembre de 2020; fija los requisitos clave de un programa de cumplimiento de licencias open source, incluidos roles y responsabilidades. Ninguna es obligatoria, pero ambas dan una respuesta creíble cuando la otra parte pregunta cómo gestiona usted el open source.

Una revisión suele buscar archivos de atribución ausentes, componentes copyleft dentro de productos distribuidos, licencias poco claras en código copiado de foros o repositorios y lagunas en el registro de qué versiones de cada componente se usaron.

Qué significa para su empresa

Elabore y mantenga un inventario de componentes y licencias por producto, a ser posible en formato SPDX.
Adopte una política open source breve: qué licencias están preaprobadas, cuáles requieren revisión (por ejemplo, GPL y AGPL en productos distribuidos) y quién decide.
Compruebe cómo llega cada producto al cliente: distribuido, instalado en dispositivos o solo como servicio.
Cumpla las obligaciones de avisos: textos de licencia, avisos de copyright y archivos NOTICE de Apache en sus distribuciones.
Refleje el open source en los contratos: garantías de desarrolladores y proveedores y declaraciones precisas a clientes e inversores.

Nuestro equipo de derechos de autor sobre software y licencias open source puede revisar su inventario y su política y ayudarle a resolver conflictos antes de que lleguen a la mesa de negociación.

Dónde se suelen equivocar las empresas

Confundir «gratuito» con «sin condiciones». Toda licencia tiene condiciones, aunque solo sean de atribución.
Ignorar cómo se entrega el producto. El mismo componente puede ser de bajo riesgo en un servicio alojado y de alto riesgo en una app distribuida.
Olvidar la AGPL. Usar en red un componente AGPL modificado puede obligar a publicar su código fuente.
No dejar registro. Sin inventario no se puede acreditar el cumplimiento en una due diligence, y la subsanación se convierte en una carrera contra la fecha de cierre.
Dejarlo para la operación. Nuestra due diligence de PI en operaciones transfronterizas cubre el open source, pero los problemas son más baratos de resolver meses antes.

Preguntas frecuentes

¿Puedo usar código con licencia MIT o Apache en un producto propietario?

Sí. Ambas son licencias permisivas que permiten usar, modificar y distribuir el código en productos cerrados. MIT exige conservar su aviso de copyright y de permiso en todas las copias o partes sustanciales. Apache 2.0 exige entregar la licencia, marcar los archivos modificados, conservar los avisos y reproducir las atribuciones del archivo NOTICE, y extingue la licencia de patentes de quien demande alegando que la obra infringe una patente.

¿Tengo que publicar mi código fuente si uso software GPL?

Solo si distribuye una obra basada en el programa GPL. En ese caso, la GPL exige licenciar toda la obra bajo la GPL y facilitar el código fuente correspondiente. El uso interno no activa esa obligación y, según la GPL v3, ofrecer software en red sin transferir copias no es transmisión. La AGPL es más estricta con el uso en red de versiones modificadas.

¿Qué ocurre si incumplimos una licencia open source?

La autorización decae y el uso puede tratarse como una infracción de derechos de autor. La GPL v2 se extingue automáticamente con el incumplimiento. La GPL v3 también, pero quien incumple por primera vez y lo corrige dentro de los 30 días siguientes a la notificación del titular recupera la licencia de forma permanente. Los incumplimientos también afloran en las due diligence y pueden afectar a la valoración.

¿Puede IP Global Guard auditar nuestro uso de open source antes de una ronda o una venta?

Sí. Revisamos su inventario de componentes y licencias, identificamos problemas de copyleft y de atribución, proponemos cómo subsanarlos y redactamos la política open source y las cláusulas contractuales, en coordinación con su equipo técnico. Trabajamos en Europa, Latinoamérica y África desde un único interlocutor.

Cómo le ayuda IP Global Guard a gestionar el riesgo open source

IP Global Guard, la línea de servicios de propiedad industrial e intelectual de META Channel Corporation Limited, asesora en derechos de autor sobre software, licencias y due diligence de PI a empresas en más de 25 jurisdicciones de Europa, Latinoamérica y África, con una sola estrategia y una única relación de facturación; consulte nuestra cobertura en el corredor.

Cuéntenos qué productos distribuye, cómo llegan a sus clientes y si tiene una operación en el horizonte. Le propondremos una revisión open source ajustada a su calendario. Hable con nuestro equipo de licencias de software.

Este artículo es información general y no constituye asesoramiento jurídico ni sustituye el análisis de su software y sus licencias concretas.