La pregunta de los millones: ¿qué es una obra derivada de software?
Todo el edificio de la reciprocidad descansa sobre un concepto que ninguna ley del mundo define con precisión para el software. La GPL obliga a licenciar en abierto las obras derivadas que se distribuyen. Perfecto. ¿Y qué es una obra derivada de un programa? De esa respuesta dependen decisiones de arquitectura de miles de millones de dólares, y la respuesta honesta es: depende, y nadie puede garantizarte de qué.
El marco general es conocido: la ley estadounidense habla de obras basadas en una o más obras preexistentes mediante transformación, adaptación o modificación; nuestras leyes (el artículo 5 de la Ley 17.336 chilena, la Decisión 351 andina) usan fórmulas equivalentes. El problema es la aplicación. ¿Modificar el código fuente crea un derivado? Sin duda. ¿Y enlazar una biblioteca? ¿Invocar una API? ¿Un plugin? ¿Un contenedor?
El debate clásico es el del enlace (linking). La Free Software Foundation ha sostenido que enlazar un programa con una biblioteca GPL crea una obra derivada del conjunto, con matices según el enlace sea estático o dinámico, y creó la LGPL como válvula de escape para bibliotecas. Rosen demolió esa posición con un argumento que comparto: la forma técnica del enlace es jurídicamente irrelevante. El derecho de autor no pregunta cómo se conectan dos módulos; pregunta si uno transforma, adapta o incorpora expresión protegida del otro. Combinar cajas negras que se comunican produce, en principio, una obra colectiva, no una derivada. Pero nótese el en principio: la cuestión nunca ha sido resuelta de manera definitiva por un tribunal, y la ambigüedad de la GPL en este punto es, sospecho, una elección de diseño de sus autores.
El caso que mejor ilustra cómo se administra esa ambigüedad en la práctica no es un fallo: es una nota. Linus Torvalds publicó Linux en 1991 bajo una licencia propia que prohibía la redistribución comercial; en 1992 lo relicenció bajo la GPL versión 2, decisión que años después describiría como la mejor que tomó en su vida. Su relación con la licencia nunca fue ideológica. Donde Stallman ve una cuestión moral (el software privativo como injusticia), Torvalds ve un mecanismo de ingeniería eficiente, un toma y daca: te doy mi código con la condición de que me devuelvas tus mejoras. Ese pragmatismo, contado con gracia en su autobiografía Just for Fun, explica sus dos decisiones más consecuentes como licenciante.
La primera es una nota interpretativa que encabeza el archivo de licencia del kernel desde los años noventa: los programas de usuario que invocan los servicios del sistema mediante llamadas normales no son obras derivadas del kernel, sino uso normal. Una sola frase, sin valor de ley ni de sentencia, que le dio a toda la industria la certeza que ninguna legislación ofrecía: sobre esa frase se construyó el ecosistema completo de software, libre y propietario, que corre sobre Linux. La segunda: mantener el kernel en GPL versión 2 exclusivamente, rechazando la versión 3 y sus cláusulas contra la tivoización, porque a su juicio el trabajo de una licencia es gobernar el código, no el hardware donde corre. Se puede discrepar de ambas decisiones (la FSF discrepa de las dos), pero la lección de técnica jurídica es indiscutible: ante un concepto legal indeterminado, la interpretación pública, temprana y consistente del licenciante puede producir más certeza que décadas de silencio de los tribunales. Guarden esa lección, porque es exactamente la que este texto recomienda para nuestra región, con el contrato en el lugar de la nota.
Cuando los tribunales estadounidenses analizan si un software deriva de otro, aplican el test de abstracción, filtración y comparación: descomponen el programa en niveles de abstracción, filtran todo lo no protegible (ideas, métodos, elementos dictados por eficiencia o compatibilidad, convenciones del lenguaje) y comparan solo lo que queda. Es un método serio y de resultado incierto. La mejor prueba de esa incertidumbre es Google contra Oracle: once años de litigio por 11.500 líneas de código declarativo de Java, dos jurados, tres instancias, y una Corte Suprema que en 2021 resolvió por fair use esquivando elegantemente la pregunta de fondo sobre la protegibilidad de las API. Si el sistema jurídico con más doctrina de software del planeta no puede darte una línea nítida, nadie puede.
Hay además una brecha que Rosen vio venir en 2004 y que definió la década siguiente: la reciprocidad clásica se gatilla con la distribución. Quien modifica software GPL y lo ofrece como servicio por internet no distribuye copias: nunca entrega el binario, solo el resultado. Ese es el resquicio SaaS con el que se construyeron negocios enteros sobre software libre sin devolver una línea. La licencia OSL de Rosen lo atacó primero con su cláusula de despliegue externo; la AGPL (2007) lo cerró para el ecosistema GPL redefiniendo la interacción por red como distribución. Si hoy publicas software de servidor y te importa la reciprocidad, la AGPL es la respuesta; si te aterra la AGPL, ya sabes qué modelo de negocio tienes.
¿Y América Latina? Cero jurisprudencia relevante sobre obra derivada de software. Ni un caso que esquivar, como hizo la Corte Suprema estadounidense. La consecuencia práctica es incómoda pero clara: en nuestras jurisdicciones, la asignación contractual del riesgo es la única herramienta real. Si tu negocio depende de dónde termina una obra derivada (qué componentes contaminan qué, qué debe liberarse y qué puede cerrarse), no esperes que un juez lo resuelva por ti dentro de esta década: escríbelo en el contrato, con definiciones propias, y deja que el contrato sea la ley entre las partes. En Chile, donde además no existe excepción de minería de datos ni doctrina de fair use, esta lógica contractual pesa doble. Sobre eso volveremos en la entrega 7.
Próxima entrega: patentes y estándares, o cómo la fórmula razonable y no discriminatorio se convirtió en la manera educada de cerrarle la puerta al software abierto. abierto.