Dos familias, dos filosofías: el mapa de las licencias abiertas
Toda licencia open source garantiza las mismas cinco libertades: usar el software para cualquier propósito, copiarlo sin pagar regalías, crear y distribuir obras derivadas, acceder al código fuente y combinarlo con otro software. Si falta cualquiera de las cinco, no es open source, diga lo que diga el marketing. La diferencia entre licencias no está en lo que dan, sino en lo que exigen de vuelta. Y ahí el campo se divide en dos familias con filosofías opuestas.
Las licencias académicas (BSD, MIT, Apache) son una donación. Nacieron en universidades que decidieron que su software valía más circulando libremente que guardado bajo llave. Permiten todo, incluso incorporar el código en productos propietarios cerrados, sin obligación de devolver nada al procomún. La BSD entera cabe en una página; la MIT, en un párrafo largo. Son las donantes universales del ecosistema: su código puede entrar en cualquier proyecto, bajo cualquier licencia.
Las licencias recíprocas (GPL, LGPL, MPL, EPL) son un pacto. La GPL lo formula con precisión de trueque: puedes tener este software con la condición de que toda obra derivada que distribuyas se licencie bajo esta misma licencia. La exigencia es simetría: recibiste libertad, la devuelves. El resultado es un procomún que crece por diseño, porque las mejoras distribuidas no pueden privatizarse. Quien detesta la GPL suele ser quien quería llevarse las mejoras sin pagar el peaje de compartirlas.
Entre ambos polos hay gradientes que importan en la práctica. La MPL opera reciprocidad a nivel de archivo: los archivos que modificas vuelven al procomún, pero puedes combinarlos con código propio cerrado en una obra mayor. La LGPL relaja la GPL para bibliotecas, permitiendo que programas propietarios las enlacen. Y la AGPL extiende la reciprocidad al uso por red, cerrando una brecha de la que hablaremos en la próxima entrega.
El libro de Rosen, que guía esta serie, fotografió este mapa en 2004. Tres cosas cambiaron desde entonces y conviene tenerlas claras.
Primero, Apache 2.0 se convirtió en la licencia corporativa por defecto. Por ingeniería jurídica más que por ideología: incluye una concesión expresa de patentes y una cláusula de terminación defensiva (si demandas por patentes, pierdes la licencia) que las académicas clásicas no tienen. Kubernetes, TensorFlow y buena parte de la infraestructura de la IA contemporánea corren bajo Apache 2.0. Segundo, la GPL versión 3 (2007) incorporó lo que a la versión 2 le faltaba: tratamiento explícito de patentes, defensas contra la tivoización y mejores reglas de compatibilidad. Tercero, la proliferación de licencias que Rosen ya denunciaba empeoró: la OSI ha aprobado más de un centenar. La recomendación profesional sigue siendo la de entonces: no inventes tu licencia; el ecosistema no necesita analizar otra más, y tu proyecto no necesita el aislamiento que produce.
¿Cómo elegir? Es una decisión de estrategia, y se responde con tres preguntas previas. Una: ¿quieres poder incorporar a tu producto las mejoras que hagan terceros? Si sí, la reciprocidad trabaja para ti. Dos: ¿te importa que existan versiones derivadas cerradas de tu software? Si no te importa (porque tu negocio está en la marca, el soporte o los servicios), una académica maximiza adopción. Tres: ¿operas en un campo con densidad de patentes? Si sí, necesitas al menos Apache 2.0 o una recíproca moderna, nunca BSD o MIT a secas.
La licencia es la constitución de tu proyecto: define qué comunidad puede formarse a su alrededor y qué le pueden hacer los terceros. Se puede cambiar después, pero cambiar la constitución tiene costos y requisitos que casi nadie lee al firmar. De eso, exactamente, trata la entrega 6.
Próxima entrega: la pregunta de los millones. ¿Qué es una obra derivada de software y por qué nadie, en ninguna jurisdicción, puede respondértelo con certeza? certeza?