Validez de licencias de software de código abierto en lo comercial
El espejismo del software «gratis»
Existe una creencia casi conmovedora en el ecosistema tecnológico: la idea de que el software de código abierto es un buffet libre universal. Un paraíso donde uno puede tomar lo que quiera, sin consecuencias, porque la palabra «gratis» parece anular cualquier otra consideración. Es una lástima tener que pinchar ese globo, pero el derecho tiene la mala costumbre de ser inmune a las buenas intenciones. En la práctica, el software, sin importar su modelo de distribución, es una obra protegida por la Ley 11.723 de Propiedad Intelectual. Goza de la misma tutela que una novela, una canción o una película. El autor tiene derechos exclusivos sobre su creación.
Entonces, ¿qué es una licencia de código abierto? Es, sencillamente, un contrato. No es una declaración de principios filosóficos ni una sugerencia. Es un instrumento legal que le otorga a usted, el licenciatario, un permiso para usar la obra bajo condiciones estrictas. Al descargar, incluir o usar ese código en su proyecto, usted está manifestando su consentimiento. Es un clásico contrato de adhesión: toma las cláusulas como están o las deja. No hay negociación posible. Hacerse el distraído y argumentar que «no leí los términos y condiciones» es tan efectivo como decirle a un oficial de tránsito que uno no vio la señal de contramano. La ignorancia de la ley —o en este caso, del contrato que uno mismo aceptó— no excusa su cumplimiento.
El «gratis» del software libre se refiere al precio de adquisición, no a la ausencia de obligaciones. Es «gratis» como un cachorro regalado: el animal no cuesta nada, pero las vacunas, la comida y las visitas al veterinario corren por su cuenta. En el mundo del software, esas «visitas al veterinario» son las obligaciones de atribución, de compartir el código fuente o de mantener la misma licencia, entre otras. Ignorarlas es el equivalente a dejar que el cachorro destroce el sillón del vecino; tarde o temprano, alguien vendrá a reclamar.
Licencias, esas novelas de ficción legal
No todas las licencias son iguales, por supuesto. Navegarlas es como caminar por un campo minado de buenas intenciones con consecuencias legales devastadoras. Se pueden agrupar en dos grandes familias, cada una con su propia filosofía y, más importante, su propio nivel de riesgo comercial.
Por un lado, tenemos las licencias permisivas, como las archiconocidas MIT, Apache 2.0 o BSD. Son las favoritas del mundo corporativo, y con razón. Son el equivalente legal a un «hacé lo que quieras, pero no te olvides de quién te lo dio». Permiten usar el código en proyectos propietarios, modificarlo, venderlo y no obligan a compartir las modificaciones. Su única exigencia, generalmente, es mantener el aviso de copyright y el texto de la licencia original en alguna parte del producto. Es una condición tan simple, tan básica, que resulta asombroso la cantidad de empresas que fallan en cumplirla, a menudo por desidia. Es el error más tonto y, sin embargo, uno de los más comunes. Un simple descuido puede poner a una compañía en situación de incumplimiento.
Por otro lado, está la familia del copyleft o licencias recíprocas, con la General Public License (GPL) como su matriarca indiscutida. Aquí es donde la cosa se pone seria. Estas licencias, en sus distintas versiones (GPLv2, GPLv3, AGPL), se basan en un principio que algunos llaman «viralidad»: si usas mi código, tu obra derivada debe ser distribuida bajo la misma licencia GPL. Esto significa que, si usted integra un componente GPL en su software propietario, podría verse legalmente obligado a liberar el código fuente completo de su propio producto. Es como construir un auto con un motor que te regalaron, pero el contrato del motor dice que ahora tenés que regalar los planos del auto entero. La Affero GPL (AGPL) va un paso más allá y aplica esta obligación incluso si el software se ofrece como un servicio a través de una red, sin distribuirse directamente. Para una empresa cuyo valor reside en su código propietario, usar un componente copyleft sin entender las consecuencias es un acto de auto-sabotaje de una pureza admirable.
El campo de batalla: cuando la teoría choca con la caja registradora
El conflicto casi siempre estalla en torno a una pregunta aparentemente técnica: ¿qué constituye una «obra derivada»? Es una zona gris pantanosa donde los ingenieros hablan de vinculación estática versus dinámica y los abogados sonreímos porque la ambigüedad es nuestro hábitat natural. ¿Usar una librería a través de una API bien definida crea una obra derivada? ¿Y si se vincula estáticamente, fusionando el código en un solo ejecutable? La Free Software Foundation tiene opiniones muy firmes al respecto, pero sus opiniones no son ley. En un tribunal argentino, un juez tendría que interpretar los principios generales de la Ley 11.723 para determinar si una obra es una «transformación» o «modificación» de otra. La falta de jurisprudencia específica convierte cada caso en una apuesta costosa.
La acusación, por lo general, no es un acto de brujería. El titular de los derechos (sea una empresa o un desarrollador individual) puede usar herramientas que escanean binarios en busca de fragmentos de código conocidos. O, más simple, puede revisar la lista de dependencias que muchos proyectos publican. Una vez que se identifica el uso del código licenciado, se verifica si el licenciatario cumple con las condiciones. Para una licencia GPL, la pregunta es simple: ¿dónde está el código fuente que están obligados a ofrecer? Si no está, hay un incumplimiento flagrante.
Frente a una carta documento, las defensas suelen ser un catálogo de excusas previsibles. «No sabíamos» es la más popular e inútil; el incumplimiento contractual no requiere dolo ni culpa. «Fue un desarrollador que ya no trabaja acá» es irrelevante; la empresa es responsable por sus dependientes. «Ya lo corregimos» es una admisión de culpa, no una defensa. La única defensa seria es argumentar que la obra no es derivada, un camino largo, caro y de resultado incierto. En la mayoría de los casos, la evidencia del incumplimiento es tan contundente que la disputa no se centra en si hubo una falta, sino en cuál será el remedio.
Consejos no solicitados para navegar el temporal
En este escenario, las partes suelen atrincherarse en posiciones que mezclan el orgullo herido con el cálculo financiero. Sin embargo, la lógica debería prevalecer sobre el dramatismo.
Para el Acusador (El Justiciero del Código): Su principal activo es la claridad de la licencia. Su estrategia debe ser metódica, no emocional. Primero, documente todo: capturas de pantalla, análisis de binarios, archivos de instalación. La carga de la prueba recae sobre usted. Segundo, sea específico en su reclamo. Una carta documento bien redactada, que identifique el software, la licencia, la cláusula incumplida y el remedio exigido (por ejemplo, la publicación del código fuente o el cese del uso), es mucho más efectiva que un posteo furioso en un blog. Su objetivo no es iniciar una guerra santa, sino lograr el cumplimiento. La amenaza de litigio es una herramienta, no un fin en sí mismo. A veces, la simple exposición pública del incumplimiento es suficiente para que una empresa, temerosa del daño a su reputación, entre en razón.
Para el Acusado (El Oportunista Descubierto): Primero, respire hondo y no haga nada estúpido, como borrar evidencia o responder con soberbia. Segundo, llame a un abogado que entienda del tema, no al primo que hace divorcios. Su primera acción debe ser una auditoría interna de código para confirmar y dimensionar el problema. A menudo, el incumplimiento es real. En ese caso, la estrategia más inteligente es la del control de daños. Ponerse en cumplimiento lo más rápido posible es fundamental. Negociar un acuerdo confidencial casi siempre es más barato que enfrentar un juicio. Intentar argumentar en un tribunal que una licencia estándar como la GPL no es válida es una estrategia heroica y suicida, reservada para quienes tienen una pila de dinero para quemar en honorarios legales con una probabilidad de éxito ínfima. Es más digno y económico admitir el error, corregirlo y emitir una declaración corporativa sobre su «renovado y profundo compromiso con la comunidad de código abierto».
A modo de cierre, queda una reflexión incómoda. La causa raíz de la mayoría de estos conflictos es una falla humana básica: la aversión a leer. Profesionales capaces de diseñar arquitecturas de software complejas fallan en comprender un documento legal de pocas páginas. Implementar una política de cumplimiento de licencias, que incluya revisión de dependencias y formación para los desarrolladores, es una inversión trivial en comparación con el costo de un solo litigio. Es el equivalente a revisar el aceite del auto antes de salir a la ruta. Nadie lo hace con entusiasmo, pero evita que el motor explote en medio de la nada.
