Mal Uso de Licencias Open Source en Software Comercial
El espejismo del ‘código gratis’: una introducción a la realidad
En el vertiginoso mundo del desarrollo de software, la eficiencia es reina. Y nada parece más eficiente que tomar una pieza de código ya escrita, funcional y probada por una comunidad de miles, para integrarla en nuestro proyecto comercial. Es el sueño del pragmático: resolver un problema complejo con un simple ‘copiar y pegar’. A este universo de código se lo conoce como ‘open source’ o código abierto. La palabra ‘abierto’, y su prima hermana ‘libre’, han generado uno de los malentendidos más costosos del sector tecnológico. Muchos asumen que es gratis. Gratis como el aire, como un consejo no solicitado. Pero no es así.
El software, según nuestra Ley 11.723 de Propiedad Intelectual, es considerado una obra literaria, artística o científica, y por ende, está protegido por derechos de autor desde su creación. El autor tiene derechos exclusivos sobre su obra. Lo que hace el movimiento ‘open source’ no es anular estos derechos, sino ejercerlos de una forma particular a través de una licencia. La licencia es un contrato. Sí, ese documento de texto que acompaña al código, usualmente llamado ‘LICENSE.txt’ o ‘COPYING’, y que el 99% de los desarrolladores ignora olímpicamente, es un contrato en toda regla que establece los términos y condiciones bajo los cuales se puede usar, modificar y distribuir ese software.
Ignorar la licencia es como encontrar un auto de alta gama en la calle con las llaves puestas y suponer que ahora es nuestro y podemos usarlo para correr picadas o pintarlo de rosa. El dueño original nos dio permiso para usarlo, pero bajo ciertas condiciones que, de no cumplirlas, nos convierten en infractores. Las licencias open source se dividen, a grandes rasgos, en dos familias. Por un lado, las licencias permisivas (como MIT o BSD), que son el equivalente a que el dueño del auto te diga: ‘Usalo, hacé lo que quieras, pero no me hagas responsable si chocás y, si sos copado, mencioname’. Requieren poco más que mantener el aviso de copyright original. Son las favoritas del mundo corporativo por su flexibilidad.
Por otro lado, tenemos las licencias con copyleft (la más famosa siendo la GNU General Public License o GPL). Aquí el dueño del auto te dice: ‘Te presto mi auto, podés modificarlo, mejorarlo, pero cualquier mejora que le hagas o si lo usás como parte fundamental de un vehículo más grande que construyas, ese nuevo vehículo también debe prestarse bajo las mismas condiciones que yo te di’. Esta es la cláusula ‘viral’ o ‘recíproca’ que causa una pila de dolores de cabeza legales. No es una opción, es una obligación contractual. Creer que se puede tomar código GPL, meterlo en un producto comercial cerrado y venderlo felizmente es una fantasía que suele terminar en el estudio de un abogado, con cara de pocos amigos.
El campo de batalla: Derechos, obligaciones y el copyleft
El verdadero drama comienza cuando una empresa basa su producto estrella, su software propietario y secreto, en componentes con licencias de tipo copyleft fuerte, como la GPL. El término ‘copyleft’ es un juego de palabras con ‘copyright’ (derechos de autor). Mientras el copyright tradicional busca restringir la copia, el copyleft usa las leyes de copyright para asegurar que la obra y sus derivados permanezcan libres. Es una trampa brillante, si se quiere, para garantizar la expansión de la libertad del software.
La obligación principal de una licencia como la GPL es que cualquier ‘obra derivada’ debe ser distribuida bajo la misma licencia GPL. Y aquí está el meollo de la cuestión: ¿qué constituye una ‘obra derivada’? Si un desarrollador copia y pega fragmentos de código GPL directamente en el código fuente de su aplicación comercial, no hay debate: esa aplicación es una obra derivada. La consecuencia es devastadora para un modelo de negocio basado en la venta de licencias de software propietario. Significa que, si distribuye su aplicación, debe ofrecer el código fuente completo a quien la reciba, permitiéndole modificarlo y redistribuirlo libremente. En resumen, su secreto industrial deja de ser un secreto.
El argumento de que ‘solo es una pequeña parte’ o ‘una librería auxiliar’ rara vez funciona. La naturaleza ‘viral’ de la GPL está diseñada precisamente para que no importe el tamaño de la contribución. Si el componente GPL es esencial para el funcionamiento de su programa, es muy probable que todo el conjunto sea considerado una única obra a efectos de la licencia. La distinción técnica entre ‘enlace dinámico’ y ‘enlace estático’ es un campo de batalla legal en sí mismo, con interpretaciones variadas, pero es un nivel de detalle en el que nadie quiere encontrarse sin haberlo previsto. La Free Software Foundation tiene una postura muy clara y restrictiva al respecto. Ignorarla es jugar a la ruleta rusa con la propiedad intelectual de la compañía.
Estrategia para el acusador: Cómo reclamar lo que es tuyo
Supongamos que sos el autor de un valioso software bajo licencia GPL y descubrís que una empresa lo está usando en su producto comercial sin cumplir con los términos. Es decir, sin liberar el código fuente de su producto derivado. La primera reacción puede ser la furia, pero la estrategia debe ser fría y metódica. Tenés la ley de tu lado.
El primer paso formal es la intimación fehaciente. En nuestro sistema legal, esto se traduce en una carta documento. Es un instrumento de una belleza legal inigualable. No es una simple queja, es una notificación formal que interrumpe la prescripción y deja constancia de tu reclamo. En ella, un abogado detallará con precisión la infracción: qué software tuyo se está usando, en qué producto de ellos, y qué cláusulas de la licencia GPL se están violando. Se les dará un plazo razonable para ‘curar’ la infracción, es decir, para cumplir con la licencia (liberando su código) o cesar el uso de tu software.
El objetivo, en la mayoría de los casos, no es destruir a la empresa infractora. El objetivo es la conformidad (compliance) o, alternativamente, una negociación. Muchos proyectos open source ofrecen licencias duales: la GPL gratuita para quienes respetan sus términos, y una licencia comercial paga para quienes desean integrar el código en un producto propietario sin liberar el suyo. La carta documento es, a menudo, el inicio de una conversación que termina con la empresa infractora pagando por una licencia comercial que debió haber adquirido desde el principio. Es una forma elegante de decir: ‘Vimos que te quisiste hacer el vivo, ahora pagá lo que corresponde’.
La prueba es clave. Antes de enviar nada, hay que tener evidencia sólida. A veces es tan simple como que los desarrolladores de la empresa olvidaron borrar los comentarios del código original con tu nombre. Otras veces requiere un análisis técnico del binario del programa para encontrar ‘huellas’ de tu código. Una vez que tenés la prueba y enviaste la intimación, la pelota está en su campo. Si la ignoran, el siguiente paso es la mediación prejudicial obligatoria y, si no hay acuerdo, una demanda por infracción a la Ley 11.723, reclamando el cese del uso y los daños y perjuicios correspondientes.
Manual de supervivencia para el acusado: Negación, pánico y (con suerte) una solución
Recibir una carta documento es un rito de iniciación para muchas empresas tecnológicas. El gerente de legales, si existe, la lee con el ceño fruncido. El CEO entra en un estado que oscila entre la negación (‘¡Imposible, nuestro software es 100% nuestro!’) y la búsqueda de culpables (‘¿Qué desarrollador hizo esto?’). Lo primero es lo primero: no la ignores. Hacerse el distraído es la peor estrategia posible. Demuestra mala fe y agrava la situación legal.
El paso inmediato y no negociable es una auditoría de código fuente. Urgente, completa y brutalmente honesta. Hay que sentar al director de tecnología con un abogado especializado y revisar qué hay en las entrañas del producto. Existen herramientas automatizadas que ayudan a escanear el código en busca de licencias, pero se necesita un análisis humano para entender el contexto. Esta auditoría revelará la magnitud del problema. ¿Es una pequeña librería fácilmente reemplazable? ¿O es el motor central de la aplicación? La respuesta a esa pregunta definirá la estrategia.
Una vez conocido el daño, se abren varias vías de acción, ninguna de ellas agradable:
- Argumentar que no es una obra derivada: Esta es la defensa legal más compleja. Implica demostrar que tu software no está lo suficientemente ‘integrado’ con el componente GPL como para ser considerado un derivado. Por ejemplo, si tu programa simplemente llama a un ejecutable GPL a través de la línea de comandos y procesa su salida, el argumento es fuerte. Si copiaste código fuente, es casi indefendible. Es una batalla técnica y legal, cara y de resultado incierto.
- Cumplir con la licencia (Compliance): La cura que ofrece la propia GPL. Si estás en falta, cumplí. Esto significa liberar el código fuente de tu producto bajo la licencia GPL. Para una empresa cuyo valor reside en su software propietario, esta opción puede ser el equivalente a una sentencia de muerte comercial. Es una decisión de negocios drástica, pero a veces es la única salida legalmente limpia.
- Negociar una licencia comercial: La vía más pragmática. Contactar al titular de los derechos (el que te mandó la carta documento) y negociar la compra de una licencia comercial que te permita usar su código sin las obligaciones del copyleft. Básicamente, es pagar por el error. El costo dependerá de cuán importante es su código para tu producto y de cuánto perciban tu desesperación. Prepárate para abrir la billetera.
- Reemplazar el código (Rip and Replace): La solución técnica. Consiste en identificar todo el código infractor y reemplazarlo con una alternativa de licencia permisiva o con código desarrollado internamente. Este proceso puede ser extremadamente costoso, llevar meses de trabajo de desarrollo, introducir nuevos bugs y retrasar el lanzamiento de nuevas versiones. Es una cirugía mayor a corazón abierto en tu producto.
Al final, todo se reduce a una verdad incómoda pero simple: un par de horas de consulta legal y una política de uso de software al inicio del proyecto hubieran evitado un problema que ahora cuesta una pila de dinero, tiempo y estrés. Lo que comienza como un atajo para ahorrar unos pesos, a menudo termina siendo la deuda más cara de la empresa. Una lección de negocios servida en el frío y formal lenguaje de una carta documento.
