Introducción

El desarrollo de software moderno es un tapiz tejido con hilos de código que pueden ser propios, pero también de innumerables componentes desarrollados previamente por terceros. Como consecuencia, nacen los "proyectos híbridos" desarrollados con una agilidad y velocidad sin precedentes, pero al mismo tiempo, presentan una complejidad legal ineludible: compatibilizar las diversas licencias que rigen los componentes de dichos proyectos de software a fin de determinar si podrían afectar o no el proyecto final de un cliente/empresa en términos de titularidad y formas de explotación del mismo.

Habitualmente nos referimos al software en términos de “sistema” dado que se encuentra estructurado por una multiplicidad de componentes. Entre ellos, el principal es el denominado código fuente. Desde la óptica legal, al código fuente lo podemos definir como el conjunto de instrucciones o líneas de texto escritas en un lenguaje de programación determinado, comprensible por un programador o desarrollador, que constituye la base para la creación de un programa informático. A diferencia, por ejemplo, del denominado "código objeto" (versión binaria y ejecutable por una computadora), el código fuente es la expresión original de la obra de software, considerada una creación intelectual y, por ende, protegida por las leyes de propiedad intelectual y derechos de autor en la mayoría de los países, otorgando a su autor derechos exclusivos sobre su reproducción, modificación, distribución y explotación comercial, a menos que una licencia específica establezca lo contrario.

Otro de los componentes habituales en el desarrollo del software, son las librerías, cuya definición se abordará más adelante. Se aclara que en este artículo se ha optado por emplear el término "librería" en lugar de "biblioteca". Si bien "biblioteca" es la traducción académicamente correcta del inglés "library", la palabra "librería" se ha consolidado como el uso predominante y ampliamente aceptado en la industria del desarrollo de software de habla hispana. Tanto al código fuente como a las librerías de software, les son aplicables los mismos principios legales en materia de licenciamiento, tal como se verá en este artículo.

En materia de desarrollo de software, los diferentes esquemas de licenciamiento, en la actualidad, plantean ciertas alternativas cuyas condiciones varían conforme los distintos intereses y objetivos de sus creadores. Así, podemos enumerar, a grandes rasgos, tres tipos diferentes de esquemas de licencias: Licencias Propietarias, Licencias de Código Abierto (Open-Source, en inglés) o Software Libre (Free Software, en inglés).

Aunque los términos software libre y software de código abierto suelen usarse indistintamente, sus principales diferencias legales radican en la filosofía que los impulsa. El software libre se enfoca en garantizar las "cuatro libertades" del usuario planteadas por la Free Software Foundation: ejecutar, estudiar, distribuir y mejorar el software. Esto se logra mediante licencias como la GPL, que abordaremos más adelante, que aseguran una sólida protección de la libertad del usuario y establecen la obligación de compartir las modificaciones realizadas. Por otro lado, el software de código abierto prioriza los beneficios prácticos de tener el código fuente disponible para su revisión y colaboración. Sus licencias pueden ser más permisivas y no siempre exigen la reciprocidad en la distribución de las modificaciones, siempre y cuando cumplan con ciertos criterios planteados por la Open Source Initiative (OSI).

El desafío central versa sobre comprender la interacción entre el desarrollo de código “propio”, “Software Propietario” o “privativo” (Software que no es libre ni de código abierto. Su código fuente generalmente no se encuentra disponible para el público y su uso, distribución y modificación están restringidos por el titular de los derechos de autor) y las licencias de "copyleft fuerte" (mecanismo legal que utiliza los principios del derecho de autor para asegurar que el software y sus versiones modificadas permanezcan libres y de código abierto. Requiere que las obras derivadas se distribuyan bajo las mismas o compatibles condiciones de licencia que la obra original) como la General Public License (GPL), en particular, cuando se incorporan “librerías” (colección de código preescrito que proporciona funcionalidades específicas y que puede ser utilizada por otros programas para evitar tener que reescribir ese código) GPL en software que se desea mantener bajo licencias de software propietario. Es por esto que múltiples empresas expresan su preocupación en relación a la posibilidad de que estos proyectos híbridos sean encuadrados como "obra derivada". El concepto de “obra derivada” no se encuentra expresamente definido en nuestra ley 11.723 de Propiedad Intelectual pero en su artículo 4 inc c enumera quienes serán titulares de derechos de propiedad intelectual (autor) y establece lo siguiente: “los que con permiso del autor la traducen, refunden, adaptan, modifican o transportan sobre la nueva obra intelectual resultante”. Es decir que en el caso de que una obra encuadre como “obra derivada o resultante” el titular de la obra derivada deberá obtener el permiso del autor y/o titular de la obra original para poder modificarla y por ende en el caso que nos ocupa, quedar sujetos a determinados términos y condiciones de una licencia u autorización que probablemente no se encuentren en línea con su estrategia y objetivo comercial. En este sentido, cabe preguntarnos ¿cuándo la vinculación con una biblioteca o componente bajo licencia GPL podría transformar un software en una "obra derivada" y de esta manera quedar sujeto a cumplir con determinados términos de la licencia del software original (GPL)?

El desafío de la integración híbrida

Las licencias de software se despliegan en un espectro que va desde las altamente permisivas (licencias de software de código abierto que imponen pocas restricciones sobre cómo se puede usar, modificar y distribuir el software. Generalmente permiten la incorporación del software en proyectos propietarios sin exigir que estos últimos se licencien bajo los mismos términos), como Apache 2.0 y MIT, hasta aquellas con un marcado efecto "copyleft", como las diversas versiones de la GPL. Las primeras otorgan amplias libertades para usar, modificar y distribuir el software, incluso dentro de proyectos propietarios o “software privativo”, con requisitos mínimos de atribución. En el otro extremo, las licencias con "copyleft" se encuentran diseñadas para asegurar que cualquier obra basada en el software original también se mantenga bajo términos similares, garantizando la perpetuidad del código libre o abierto, según se interprete.

La complejidad se materializa cuando un proyecto intenta integrar un componente licenciado bajo GPL (por ejemplo, una biblioteca con una funcionalidad específica) dentro de una base de código que el desarrollador pretende licenciar o incluso mantener como “Software Propietario”. Es en este punto donde la pregunta sobre si se ha creado una "obra derivada" bajo los términos de la GPL se vuelve crítica. Si la respuesta es afirmativa, el proyecto completo podría verse obligado a adoptar la licencia GPL, por lo que que la empresa estaría legalmente obligada a liberar el código fuente completo de ese proyecto híbrido bajo los términos de la licencia GPL. Esto incluye no solo el componente GPL original que se utilizó, sino también todo el código propietario que la empresa desarrolló y que ahora se considera parte de esa obra., contraviniendo las intenciones originales del objetivo comercial de la empresa y potencialmente impactando en el modelo de negocio, pues en términos generales las empresas invierten capital en un desarrollo a fin de poder obtener un beneficio económico exclusivo del mismo.

El corazón del debate:

¿Qué constituye una "Obra Derivada" al vincular código GPL?

La GPL establece que cualquier obra "basada en" el software licenciado bajo sus términos debe, a su vez, licenciarse bajo la GPL. La controversia surge al determinar si la simple vinculación, especialmente la vinculación dinámica (donde el programa principal y la biblioteca GPL son archivos separados que se comunican en tiempo de ejecución), convierte al software principal en una "obra basada en" dicha biblioteca.

• Argumentos a favor del “efecto viral GPL”: Quienes adoptan una interpretación más estricta de la GPL sostienen que cualquier forma de vinculación crea una dependencia funcional tan intrínseca que el software principal se convierte inevitablemente en una obra derivada. Se argumenta que el software utiliza las funcionalidades esenciales de la biblioteca GPL para operar, por lo que está "basado en" ella en un sentido profundo y significativo. Esta perspectiva se alinea con el objetivo de la GPL de asegurar que todas las mejoras y obras extendidas permanezcan dentro del ecosistema de código abierto.
• Argumentos a favor de la separación y la vinculación permisible: En contraposición, otros defienden que la vinculación dinámica con una biblioteca GPL no necesariamente crea una obra derivada. Esta visión es particularmente defendida si la biblioteca se utiliza como una herramienta independiente, comunicándose a través de interfaces bien definidas, y no se integra de forma que se convierta en un componente estructural o operativo fundamental del software principal. Desde esta óptica, el software principal y la biblioteca GPL pueden considerarse obras separadas, cada una con sus propios derechos de autor.

Factores clave en el análisis legal de la "Obra Derivada"

La interpretación de qué constituye una "obra derivada" es fundamental y depende de una serie de factores técnicos y legales:

• Tipo de Vinculación (Estática vs. Dinámica): La vinculación estática, donde el código GPL se incluye directamente en el ejecutable de un programa propietario, generalmente se considera la creación de una obra derivada.

La vinculación dinámica es un método de integración de software donde un programa principal no incorpora el código de una librería directamente en su ejecutable durante la compilación. En su lugar, el programa principal (el "enlazador" o "linker") resuelve las dependencias con la librería en el momento de la ejecución (“runtime”). Esto implica que la librería bajo licencia GPL es un archivo separado que el programa principal carga y utiliza solo cuando lo necesita.

Desde una perspectiva técnica, la vinculación dinámica ofrece beneficios como el ahorro de recursos (múltiples programas comparten una misma copia de la librería en memoria) y la facilidad de actualización (la librería puede actualizarse sin recompilar todos los programas que la usan).

Sin embargo, desde una perspectiva legal, la vinculación dinámica con una librería bajo licencia GPL plantea la pregunta clave: ¿es suficiente esta interacción en tiempo de ejecución para considerar que el programa principal está "basado en" la librería GPL y, por lo tanto, se convierte en una obra derivada sujeta a la GPL?

Existen dos posturas principales en este debate:

• Argumento de la "Obra Unitaria": Esta postura sostiene que si el programa principal necesita la librería GPL para funcionar y el usuario final solo puede ejecutarlo si ambos componentes están presentes y se comunican, el resultado es una "obra unitaria". La comunicación, aunque sea en tiempo de ejecución, se considera tan fundamental que el programa principal no cumpliría su propósito sin la librería GPL, llevándolo a ser una obra derivada.
• Argumento de la "Distribución Conjunta": La postura contraria argumenta que la vinculación dinámica es una forma "distribución conjunta", donde el programa principal y la librería GPL son entidades separadas con derechos de autor distintos, simplemente distribuidas juntas. Si la comunicación se da a través de interfaces "estándar" o "comunes" que no implican una adaptación profunda del programa principal a la lógica interna de la librería GPL, se defiende una mayor separación e independencia conceptual y funcional entre ambas obras.

Naturaleza de la interfaz: Si la comunicación entre el software principal y la librería GPL se limita a llamadas de función claras y bien delimitadas a través de interfaces estándar, podría argumentarse una mayor separación entre las obras.

Significado funcional de la “Librería”: A la luz de lo anterior, entendemos que la importancia de la funcionalidad proporcionada por la librería GPL para el software principal es un factor crucial y eventualmente determinante. Si la librería es esencial para el funcionamiento central del programa, la balanza podría inclinarse hacia la consideración de obra derivada, lo que gatillaría el “efecto viral” de la licencia GPL sobre la totalidad del software, obligando a su titular a licenciarlo bajo los mismos términos (de la licencia GPL)

Disponibilidad de alternativas “No GPL”: La existencia de librerías alternativas con licencias permisivas que puedan realizar funciones similares podría influir en la percepción de la necesidad de usar la biblioteca GPL y, por ende, en la naturaleza de la dependencia.

Las "Excepciones" como Herramientas de Mitigación:

Reconociendo estos desafíos, han surgido "excepciones" a ciertas licencias GPL, como la notable GNU Classpath Exception, generalmente asociada con la LGPL o Lesser General Public License, un subtipo de licencias GPL con condiciones algo más permisivas que la GPL. Estas excepciones están diseñadas específicamente para permitir la vinculación de librerías con software bajo otras licencias (incluso propietarias) sin que el efecto viral del "copyleft" se extienda a todo el proyecto. Comprender el alcance y las limitaciones de estas excepciones es vital para los desarrolladores que navegan por proyectos híbridos. La ausencia de una excepción similar para la GPL "pura" a menudo refuerza los argumentos a favor de una interpretación más estricta de esta última.

Consideraciones y Recomendaciones Legales Estratégicas:

Ante este panorama, una estrategia legal anticipada resulta esencial, a continuación, tres bullet points a tener en consideración:

• Diligencia rigurosa en la selección de licencias: Antes de incorporar cualquier componente de terceros, es imperativo analizar meticulosamente su licencia y evaluar su compatibilidad con la licencia deseada para el proyecto principal.
• Diseño consciente de la arquitectura del software: Una arquitectura que aísle los componentes con diferentes licencias, permitiendo la comunicación a través de interfaces bien definidas y estándar, puede mitigar algunos riesgos de "contaminación", aunque no garantiza la inmunidad legal.
• Documentación clara y exhaustiva: Mantener un registro detallado y preciso de las licencias de todos los componentes utilizados en el proyecto no es solo una buena práctica, sino una herramienta esencial para demostrar el cumplimiento y la debida diligencia.

Conclusión

La creación de proyectos de software híbridos es una realidad ineludible y beneficiosa, ofreciendo acceso a una vasta gama de tecnologías y acelerando la innovación. Sin embargo, la interacción entre las diversas licencias de software, y en particular la interpretación del concepto de "obra derivada" al integrar componentes GPL, requiere una comprensión profunda de los principios legales y técnicos involucrados. No existe una respuesta única o simple, y el análisis debe ser casuístico. Una estrategia de licenciamiento proactiva, informada y respaldada por asesoramiento legal especializado es crucial para navegar este complejo laberinto, asegurar el cumplimiento y evitar costosas disputas legales que podrían poner en jaque la viabilidad de un proyecto tecnológico.

Referencias:

- Lipszyc, D. (2019). Régimen de la Propiedad Intelectual. Derecho de Autor y Derechos Conexos. Hammurabi.

- Fernández Delpech, H. (2014). Manual de Derecho Informático. Abeledo Perrot.

- Carranza Torres, M. (2004). Problemática jurídica del software libre. LexisNexis.

- Free Software Foundation https://www.fsf.org/  

- Open-Source Initiative (OSI) https://opensource.org/