Software libre vs open source: la diferencia que sí importa
Arnold Wender · · 9 min de lectura
Ver todo: Cultura geekEn 1998, un grupo de desarrolladores se reunió en Palo Alto para decidir cómo presentarle al mundo empresarial algo que la comunidad técnica ya construía desde hacía quince años. El problema no era técnico: era de comunicación. La frase “software libre” —en inglés, free software— confundía a los ejecutivos porque “free” significa tanto “libre” como “gratuito”. Necesitaban un término que vendiera la idea sin asustar a los departamentos de finanzas.
Lo que eligieron ese día —“open source”, código abierto— cambió la historia de la industria. Y también creó una división filosófica que sigue activa hoy: no entre personas que hacen cosas diferentes, sino entre personas que hacen las mismas cosas por razones completamente distintas. Esa distinción no es semántica. Define qué licencias usas, a qué proyectos contribuyes, y cómo piensas sobre el software que corres en tu máquina.
Lo que realmente diferencia software libre de open source
- “Free software” significa libre, no gratuito — la FSF define cuatro libertades específicas que el usuario debe tener sobre el software
- Open source es estrategia, software libre es ética — la OSI promueve el código abierto por sus beneficios prácticos; la FSF lo hace por razones morales
- Todo software libre es open source, pero no al revés — Android AOSP es open source, pero la FSF lo considera mayormente no-libre
- La diferencia real aparece en las licencias — copyleft (GPL) vs. permisivas (MIT, Apache): la primera protege la libertad, la segunda protege la flexibilidad del desarrollador
- La tivoización es el caso límite perfecto — TiVo usaba Linux bajo GPL pero bloqueaba las modificaciones de los usuarios con hardware; GPLv3 lo prohíbe, el kernel Linux sigue en GPLv2
- Conocer la distinción cambia tus decisiones prácticas — qué licencia pones en tu proyecto, qué dependencias usas en software comercial, cómo proteges el trabajo de tu comunidad
Visita Cultura geek en GeekShop para más análisis de fondo sobre la tecnología que usamos.
El origen del problema: dos movimientos del mismo árbol
HISTORIA
1983-1998: del Proyecto GNU a la Open Source Initiative
La historia empieza con Richard Matthew Stallman, nacido en 1953, programador del MIT que en 1983 lanzó el Proyecto GNU con un objetivo explícito: construir un sistema operativo completamente libre. No libre de costo, sino libre en el sentido de que cualquier usuario pudiera usarlo, estudiarlo, modificarlo y redistribuirlo sin restricciones.
En 1985 fundó la Free Software Foundation (FSF). En 1989 publicó la primera versión de la GNU General Public License (GPL), la licencia que codificó el concepto de copyleft: una inversión del copyright tradicional que usa la ley de derechos de autor para garantizar que el software y todas sus derivaciones permanezcan libres. La lógica es elegante y subversiva a la vez: si quieres usar mi código, tienes que mantenerlo libre. No puedes tomarlo, cerrarlo y redistribuirlo como software propietario.
En 1991, Linus Torvalds publicó el kernel Linux —inicialmente bajo una licencia propia— y en 1992 lo relicenció bajo GPL. La combinación del kernel Linux con las herramientas del Proyecto GNU creó el primer sistema operativo completamente libre que también era técnicamente competitivo.
El movimiento creció durante los noventa. Pero el vocabulario de Stallman —libertad, derechos, moral— no funcionaba en salas de juntas. En febrero de 1998, cuando Netscape anunció que abriría el código de su navegador, un grupo que incluía a Eric S. Raymond y Bruce Perens vio la oportunidad. Se reunieron en Palo Alto y acuñaron el término “open source”. Días después, Raymond y Perens cofundaron la Open Source Initiative (OSI).
La OSI tomó como base la Debian Free Software Guidelines —un documento que Perens había redactado para el proyecto Debian— y las adaptó como la Open Source Definition: diez criterios que una licencia debe cumplir para ser “open source”. Técnicamente son muy similares a los criterios de la FSF. La diferencia está en el framing: la OSI habla de eficiencia de desarrollo, calidad de código, y beneficios empresariales. La FSF habla de libertad, ética y derechos fundamentales.
Las cuatro libertades vs. los diez criterios
El corazón de la diferencia está en cómo cada movimiento define qué hace a un software “bueno” en este sentido.
La FSF define el software libre mediante cuatro libertades que el usuario debe tener:
- Libertad 0: ejecutar el programa como quieras, para cualquier propósito
- Libertad 1: estudiar cómo funciona el programa y modificarlo a tu necesidad (requiere acceso al código fuente)
- Libertad 2: redistribuir copias para ayudar a otros
- Libertad 3: distribuir copias de tus versiones modificadas (requiere acceso al código fuente)
La OSI define el open source mediante diez criterios aplicados a la licencia: distribución libre, código fuente disponible, distribución de trabajos derivados permitida, no discriminación por personas, campos de actividad o tecnología, entre otros.
En la práctica, casi todo software que cumple los criterios de la FSF también cumple los de la OSI. Pero no al revés: hay software que la OSI considera open source y la FSF considera no-libre, porque la OSI no exige el mismo nivel de protección de las libertades del usuario final.
Para la FSF, el código abierto es un medio para un fin —la libertad del usuario. Para la OSI, el código abierto es el fin en sí mismo —un modelo de desarrollo superior.
Licencias: donde la diferencia se vuelve concreta
LICENCIAS
Copyleft vs. permisivas: el mapa real
La distinción filosofía-vs-estrategia tiene consecuencias muy concretas cuando eliges una licencia para tu proyecto.
Licencias copyleft (estilo FSF/GPL): Si usas código GPL en tu proyecto y lo distribuyes, tu proyecto completo debe ser GPL. Las modificaciones que distribuyas deben tener el código fuente disponible bajo los mismos términos. El copyleft “se propaga” hacia arriba en la cadena de dependencias. Esto protege la libertad del usuario final —cualquiera que reciba el software tiene garantizado el acceso al código fuente— pero limita el uso en software propietario.
Licencias permisivas (estilo OSI/MIT/Apache): Puedes tomar código MIT o Apache, modificarlo, y distribuir el resultado bajo cualquier licencia, incluyendo propietaria. Solo tienes que mantener el aviso de copyright original. Apache 2.0 añade además protección explícita de patentes. Estas licencias maximizan la adopción comercial pero no garantizan que los usuarios del software resultante tengan acceso al código fuente.
La diferencia práctica: una empresa puede tomar React (licencia MIT, de Meta), construir un producto con él, y distribuirlo sin compartir ni una línea de su código propio. Eso es exactamente lo que hacen miles de empresas. En cambio, si esa misma empresa usa WordPress (GPL), cualquier tema o plugin que distribuyan públicamente debe ser GPL también —razón por la que el ecosistema WordPress es completamente GPL y todas sus extensiones comerciales siguen siendo software libre.
Tabla comparativa
| Dimensión | Software Libre (FSF) | Open Source (OSI) |
|---|---|---|
| Fundación | Free Software Foundation (1985) | Open Source Initiative (1998) |
| Figura central | Richard Stallman | Eric Raymond, Bruce Perens |
| Marco conceptual | Ético / filosófico | Pragmático / empresarial |
| Pregunta central | ¿El usuario tiene libertad? | ¿El modelo produce mejor código? |
| Licencia emblemática | GPL v2, GPL v3, LGPL | MIT, Apache 2.0, BSD |
| Propagación | Copyleft fuerte (GPL) | Permisiva (sin propagación obligatoria) |
| Compatibilidad con propietario | No (GPL) / Limitada (LGPL) | Sí (MIT, Apache) |
| Ejemplo paradigmático | GNU Emacs, Linux kernel | Android AOSP, React, VS Code |
| Posición sobre tivoización | En contra (GPLv3 la prohíbe) | Neutral / A favor (Torvalds) |
Errores comunes
El caso límite que lo define todo: TiVo y la tivoización
Hay un ejemplo que hace toda la diferencia abstracta completamente concreta: TiVo.
TiVo construyó sus grabadoras de video digital usando el kernel Linux, que es GPL. Cumplían con la licencia: cuando los usuarios lo pedían, entregaban el código fuente del kernel que usaban. Hasta ahí, todo legal. El problema era que también diseñaban el hardware de sus dispositivos para verificar firmas criptográficas del software antes de ejecutarlo. Podías tener el código fuente, modificarlo, compilarlo —y el dispositivo físico lo rechazaba. La libertad 3 era técnicamente posible pero prácticamente inútil.
Stallman acuñó el término “tivoización” para este patrón. En 2007, GPLv3 incluyó explícitamente una cláusula que lo prohíbe: si distribuyes GPL v3 en hardware que controlas, debes proporcionar también la información necesaria para que el usuario pueda instalar versiones modificadas del software en ese hardware.
Torvalds dijo que consideraba que TiVo no había hecho nada malo. El kernel Linux permaneció en GPL v2.
Esa diferencia de opinión —¿importa que el hardware bloquee las modificaciones si el código está disponible?— es exactamente la diferencia entre software libre y open source en su forma más pura. Para la FSF, la libertad sin control del hardware no es libertad real. Para parte de la comunidad open source, el código disponible ya es suficiente.
Para lectores que quieran ir más profundo
El debate entre software libre y open source es parte de conversaciones más amplias sobre cómo construimos y compartimos conocimiento técnico. Si te interesa continuar con esa línea, dos recursos del propio catálogo de GeekShop:
- Libros imprescindibles para programadores — incluye Free Software, Free Society de Stallman y The Cathedral and the Bazaar de Raymond: los dos manifiestos de los dos movimientos
- Los mejores podcasts y canales tech en español — varios episodios de estas comunidades tocan regularmente el tema de licencias, propiedad intelectual y ética del software
FAQ
¿Android es software libre o open source?
Android AOSP (Android Open Source Project) es open source bajo Apache 2.0. La FSF lo considera mayormente no-libre por dos razones: el kernel Linux incluido está modificado con drivers binarios no-libres (blobs), y los servicios de Google que cualquier teléfono certificado debe incluir —Google Play Services, Maps, Gmail— son completamente propietarios. El “Android abierto” que existe en papel no es el Android funcional que corren los dispositivos reales.
¿Puedo usar código GPL en mi proyecto comercial?
Depende de cómo lo uses y distribuyas. Si usas software GPL solo internamente —sin distribuirlo a terceros— no tienes obligación de liberar tu código. Si lo distribuyes como producto —ya sea como binario, como SaaS, o como hardware— las obligaciones cambian. GPL v2 no cubre explícitamente el SaaS (puedes correr software GPL en un servidor y ofrecer el servicio sin compartir tu código); GPL v3 y especialmente AGPL v3 sí lo cubren. Consulta un abogado antes de tomar decisiones comerciales basadas en interpretaciones de licencias.
¿Qué diferencia hay entre GPL y LGPL?
LGPL (Lesser GPL) es una versión menos restrictiva diseñada específicamente para bibliotecas. Permite que software propietario enlace dinámicamente contra una biblioteca LGPL sin que eso obligue al software propietario a convertirse en GPL. Si la biblioteca la modificas y redistribuyes, esas modificaciones siguen siendo LGPL. Es el equilibrio que eligió, por ejemplo, la biblioteca de C GNU (glibc): suficientemente libre para ser adoptada universalmente, sin forzar a todo el software de usuario a ser GPL.
¿Stallman sigue activo?
Richard Stallman (nacido en 1953) reveló en septiembre de 2023 que le habían diagnosticado linfoma folicular. Posteriormente informó que el tratamiento lo puso en remisión. En 2024 y 2025 continuó con giras de conferencias y mantiene críticas públicas activas, incluyendo posiciones sobre los modelos de lenguaje (LLMs) que considera perjudiciales para la libertad del software. Sigue siendo presidente de la FSF.
¿Qué licencia debo elegir para mi proyecto?
Depende de tu objetivo. Si quieres maximizar adopción y no te importa que empresas usen tu código en productos propietarios: MIT o Apache 2.0 (Apache añade protección de patentes). Si quieres que cualquier trabajo derivado también sea libre y que tus contribuidores no puedan cerrarte el código: GPL v2 o v3. Si construyes una biblioteca y quieres que sea adoptada ampliamente pero con las modificaciones a la biblioteca misma siempre libres: LGPL. Si haces SaaS y quieres que quien use tu código en un servidor también tenga que liberar sus modificaciones: AGPL v3. La herramienta choosealicense.com (mantenida por GitHub) tiene un comparador claro para casos comunes.
Fuentes
Las definiciones se apoyan en las fuentes primarias:
- Definición de Software Libre — GNU / Free Software Foundation
- The Open Source Definition — Open Source Initiative