Se usan como sinónimos. No lo son.
En la mayoría de conversaciones técnicas y comerciales, software libre y código abierto se tratan como términos intercambiables. Ambos implican que el código fuente está disponible. Ambos se asocian con comunidades activas, coste de licencia bajo o nulo y una alternativa a los grandes proveedores propietarios.
Pero la diferencia no es semántica. Es filosófica y, sobre todo, práctica. Confundirlos lleva a tomar decisiones de tecnología con premisas incorrectas: elegir una herramienta pensando que tendrás control total sobre ella cuando en realidad no lo tendrás, o descartar opciones por asumir restricciones que no existen.
Este artículo no pretende resolver el debate histórico entre Richard Stallman y la Open Source Initiative. Pretende ayudarte a entender qué pregunta estás respondiendo cuando eliges entre software libre y código abierto, y por qué esa pregunta importa más de lo que parece cuando tomas decisiones de infraestructura a largo plazo.
La diferencia de fondo
El software libre, tal como lo define la Free Software Foundation, garantiza cuatro libertades fundamentales: usar el programa para cualquier propósito, estudiar cómo funciona y modificarlo, redistribuir copias y distribuir versiones modificadas. La clave está en que estas libertades son irrenunciables para cualquier receptor del software. Una licencia libre no puede quitarte esas libertades aunque el distribuidor quisiera hacerlo.
El código abierto, definido por la Open Source Initiative, comparte la mayoría de esos principios pero desde un ángulo diferente: el foco está en la metodología de desarrollo y en los beneficios prácticos que produce tener el código disponible (mayor calidad, más ojos revisando, innovación distribuida). Las licencias aprobadas por la OSI son variadas y algunas permiten restricciones que el software libre no toleraría.
La diferencia práctica más importante: el software libre pone los derechos del usuario en el centro. El código abierto pone la disponibilidad del código en el centro. En muchos casos coinciden. En los casos límite, no.
Licencias: cómo distinguirlas
La mayoría de problemas prácticos con software libre y código abierto vienen de no leer bien las licencias. Estas son las distinciones que más afectan a las decisiones de negocio:
- Licencias copyleft (GPL, AGPL, LGPL): Son las más asociadas con el software libre en sentido estricto. El copyleft obliga a que cualquier trabajo derivado se distribuya con la misma licencia. En la práctica esto significa que si integras código GPL en tu producto y lo distribuyes, ese producto también debe ser GPL. La AGPL va un paso más allá: cubre también el uso en red. Si ofreces un servicio basado en código AGPL, debes publicar el código fuente aunque no lo distribuyas como software. Esto tiene implicaciones importantes para modelos SaaS y para empresas que ofrecen servicios en la nube.
- Licencias permisivas (MIT, Apache 2.0, BSD): Permiten usar, modificar y redistribuir el código con muy pocas restricciones, incluyendo en productos propietarios. Son las más habituales en proyectos de código abierto orientados a la adopción masiva. No obligan a publicar las modificaciones. Apache 2.0 incluye además una cláusula de patentes: te otorga una licencia explícita sobre las patentes de los contribuyentes, lo que aporta seguridad jurídica en entornos corporativos.
- Licencias duales y licencias de fuente disponible: Muchos proyectos actuales usan licencias que no encajan ni en software libre ni en código abierto tradicional. Licencias como BUSL (Business Source License), SSPL o licencias propias de empresas como HashiCorp, Elasticsearch o MongoDB limitan el uso comercial o el uso como servicio competidor. Estas licencias nacieron como respuesta a empresas cloud que ofrecían servicios basados en proyectos open source sin contribuir al desarrollo. El resultado es código cuya fuente está disponible pero cuyo uso tiene restricciones importantes que conviene leer antes de construir sobre ellas.
Por qué la diferencia cambia decisiones de negocio
Soberanía tecnológica real
Elegir software libre (en sentido estricto) te garantiza que nadie puede quitarte las libertades que tienes hoy. Eso tiene valor cuando construyes infraestructura crítica: sabes que la licencia no va a cambiar, que puedes modificar el software si el proveedor desaparece y que puedes distribuirlo internamente sin restricciones.
El código abierto con licencia permisiva te da mucha libertad en la práctica, pero sin la garantía filosófica. Las licencias pueden cambiar en versiones futuras (como han hecho Redis, Terraform, Elasticsearch o MongoDB en los últimos años). Migrar una infraestructura construida sobre una herramienta que cambia de licencia tiene un coste real.
Riesgo de vendor lock-in encubierto
Hay proyectos que son formalmente open source pero cuya arquitectura, ecosistema de plugins o modelo de soporte hacen prácticamente inviable operarlos sin el soporte comercial del proveedor original. El código está disponible, pero la capacidad real de operar de forma independiente no lo está.
Al evaluar una herramienta open source conviene preguntarse no solo si el código está disponible, sino si existe una comunidad activa capaz de mantenerla independientemente del proveedor original, si hay alternativas de soporte y si los forks históricos del proyecto son viables.
Implicaciones en la cadena de suministro de software
Las dependencias de tu software heredan sus licencias. Un proyecto con dependencias GPL puede obligarte a publicar más código del que esperabas. Un proyecto que mezcla licencias MIT, Apache y LGPL puede tener implicaciones distintas según cómo lo uses o distribuyas.
En entornos regulados (sector público, defensa, banca, salud) el análisis de licencias de la cadena de suministro no es opcional. Herramientas como FOSSA, Black Duck o el proyecto SPDX de Linux Foundation ayudan a automatizar ese análisis.
La pregunta que conviene hacerse
Antes de elegir una herramienta por ser ‘open source’ o ‘software libre’, conviene hacerse tres preguntas concretas:
- ¿Qué libertades me garantiza la licencia hoy y en el futuro si el proveedor cambia de estrategia?
- ¿Existe una comunidad capaz de mantener este proyecto de forma independiente?
- ¿Qué implicaciones tiene esta licencia en los productos o servicios que construyo sobre ella?
La respuesta a estas preguntas no siempre lleva a elegir la licencia más libre en sentido estricto. A veces la licencia permisiva es la decisión correcta. Lo que importa es tomar la decisión con información real, no con la asunción de que todo lo que tiene el código fuente disponible es equivalente.
En Irontec llevamos años trabajando con tecnologías de software libre y código abierto, y ayudamos a las organizaciones a tomar estas decisiones con criterio de ingeniería real.
