Software libre versus código abierto: por qué la diferencia sigue importando en 2026

Vengo de los canales IRC de principios de los 2000, donde la discusión entre “free as in freedom” y “free as in free beer” era casi ritual. Con el tiempo, esa charla se volvió más sutil pero no menos importante. En 2026, cuando la mayoría de las infraestructuras críticas corren sobre código que cualquiera puede ver, vale la pena volver a separar los conceptos sin romanticismos ni eslóganes.

El software libre, tal como lo definió la Free Software Foundation, pone cuatro libertades en el centro: usar el programa para cualquier fin, estudiar cómo funciona y modificarlo, redistribuirlo y distribuir versiones mejoradas. Estas libertades no son solo un detalle legal; son la base para que una comunidad pueda sostener un proyecto sin que una empresa decida unilateralmente el futuro del código.

El movimiento del código abierto, que surgió en 1998 con la Open Source Initiative, eligió un enfoque pragmático. Su argumento era que hablar de “libertad” sonaba demasiado ideológico para convencer a empresas y ejecutivos. Por eso se centró en los beneficios técnicos y económicos: mejor calidad, más velocidad de desarrollo, menor costo de mantenimiento. La licencia sigue siendo abierta, pero la retórica cambió.

Hasta acá todo parece compatible. Y en la práctica lo es, en la mayoría de los proyectos. Pero el matiz aparece cuando miramos decisiones concretas de gobernanza y sostenibilidad.

Tomemos el caso de un proyecto que decide cambiar su licencia de copyleft (como la GPL) a una más permisiva para “atraer más empresas”. Desde la visión del software libre esto representa una pérdida de libertad para los usuarios finales, porque una corporación podría tomar el código, modificarlo internamente y no devolver las mejoras. Desde la visión estrictamente open source, si el proyecto gana más contribuidores y se mantiene mejor, el cambio se justifica.

En mi propia experiencia manteniendo servidores caseros, esta diferencia se nota cuando elijo herramientas. Si autohospedo un servicio de mensajería o un servidor de correo, prefiero paquetes bajo licencias copyleft fuertes. No es fanatismo: es una forma de asegurarme que si mañana una gran empresa decide crear una versión “enterprise” cerrada, la comunidad todavía tendrá la base libre para seguir adelante.

Otro punto donde se nota la grieta es en la financiación. Proyectos open source puros suelen tener más facilidad para atraer patrocinios corporativos o incluso ser adoptados como base de productos propietarios. Eso genera sostenibilidad a corto plazo, pero también crea dependencia. Cuando la empresa patrocinadora cambia de estrategia, el proyecto puede quedar huérfano. Los proyectos de software libre más estrictos suelen depender de donaciones individuales, fundaciones o cooperativas, lo que genera otro tipo de fragilidad pero mayor independencia a largo plazo.

La licencia AGPL, por ejemplo, es un caso interesante. Extiende la GPL para el mundo de los servicios en la nube: si ofreces el software como servicio, debes ofrecer el código a los usuarios. Muchas empresas open source la evitan porque limita su modelo de negocio SaaS. Para quien autohospeda su propia nube personal, en cambio, es una garantía de que nunca va a encontrarse con un servicio “gratuito” que en realidad está capturando sus datos sin dar nada a cambio.

En la comunidad hacker que frecuento todavía se escucha la frase “no es gratis, es libre”. Pero también escucho cada vez más voces que dicen que la distinción ya no importa, que “todo es open source” y que el copyleft es un obstáculo. Mi experiencia después de quince años manteniendo servidores propios es que sí importa, aunque no siempre de la forma que imaginábamos en los 2000.

Importa cuando una distribución decide incluir blobs binarios porque “el hardware no funciona sin ellos”. Importa cuando un proyecto decide cerrar partes de su código para poder vender soporte empresarial. Importa cuando elegís la herramienta que vas a correr durante los próximos diez años en tu hardware viejo reciclado.

La recomendación práctica que puedo dar después de todo este tiempo es simple: mirá la licencia, mirá la gobernanza y mirá quién toma las decisiones. Si el proyecto está controlado por una sola empresa, aunque el código sea abierto, estás confiando tu soberanía digital a esa empresa. Si el proyecto tiene una fundación independiente, una comunidad activa y una licencia que obliga a devolver cambios, tenés más chances de que sobreviva a los vaivenes del mercado.

Autohospedar sigue siendo, para mí, el acto concreto de aplicar esta filosofía. Cuando corro mi propio Nextcloud bajo AGPL, mi propio Matrix bajo Apache 2.0 pero con servidores propios, o mi propio servidor de correo con Postfix y Dovecot, no estoy solo usando software gratis. Estoy ejerciendo la libertad de no depender de Google, Microsoft o cualquier otro proveedor que pueda cambiar las reglas mañana.

La diferencia entre software libre y código abierto no es un debate académico. Es una decisión cotidiana sobre quién controla la tecnología que usamos para comunicarnos, almacenar nuestros datos y organizar nuestra vida digital. Y esa decisión, en 2026, sigue siendo tan política como técnica.