≡En resumen
- Que el código se pueda ver no basta: para ser open source, la licencia tiene que permitir usarlo, modificarlo y redistribuirlo sin discriminar personas ni usos.
- Open source y software libre describen casi el mismo software, pero con acentos distintos: práctico uno, ético el otro.
- Las licencias permisivas (MIT, Apache 2.0) permiten cerrar el código derivado; las copyleft (GPL, AGPL) obligan a compartirlo en las mismas condiciones.
- La SSPL de MongoDB y la BSL no están aprobadas por la OSI: son código disponible, no código abierto.
- Las empresas ganan dinero con el open source vendiendo soporte, servicios en la nube, funciones de pago o licencias duales.
01 ¿Qué es el open source o código abierto?
El término nació el 3 de febrero de 1998 en una reunión en Palo Alto, semanas después de que Netscape anunciara que liberaría el código de su navegador. Christine Peterson lo propuso para presentar el software libre con un lenguaje más cercano a las empresas, y a finales de ese mes Eric Raymond y Bruce Perens fundaron la Open Source Initiative (OSI), que custodia la definición y aprueba las licencias.
02 La Open Source Definition: los 10 requisitos de la OSI
Una licencia solo es open source si cumple los diez criterios de la Open Source Definition (versión 1.9), que la OSI derivó de las directrices de software libre de Debian:
- ✓Redistribución libre: no puede impedir vender o regalar el software.
- ✓Código fuente: debe incluirse o estar accesible en una forma que permita modificarlo.
- ✓Obras derivadas: debe permitir modificaciones y distribuirlas.
- ✓Integridad del código del autor: puede exigir que los cambios se distribuyan como parches o con otro nombre.
- ✓Sin discriminación de personas o grupos.
- ✓Sin discriminación de ámbitos de uso: no puede prohibir, por ejemplo, el uso comercial.
- ✓Distribución de la licencia: los derechos se aplican a todos los que reciben el programa.
- ✓La licencia no puede depender de que el programa forme parte de un producto concreto.
- ✓La licencia no puede restringir otro software distribuido junto a él.
- ✓La licencia debe ser neutral respecto a la tecnología.
03 Open source vs software libre vs freeware
| Tipo | ¿Código disponible? | ¿Puedes modificarlo y redistribuirlo? | Ejemplo |
|---|---|---|---|
| Open source | Sí | Sí, según una licencia aprobada por la OSI | Linux, Kubernetes, React |
| Software libre | Sí | Sí; la FSF lo define por cuatro libertades: usar, estudiar, compartir y mejorar | Proyectos GNU, GIMP |
| Freeware | Normalmente no | No; solo usarlo gratis | Muchos lectores de PDF o utilidades gratuitas |
| Source available | Sí | Con restricciones (uso comercial, servicios en la nube, competencia) | MongoDB (SSPL), proyectos con BSL |
| Propietario | No | No | Microsoft Office, Adobe Photoshop |
Casi todo el software libre es open source y viceversa; la diferencia es de enfoque. El movimiento del software libre, que Richard Stallman impulsó con el proyecto GNU en 1983, lo plantea como una cuestión de libertad del usuario; el open source pone el acento en las ventajas prácticas de desarrollar en abierto. No confundas ninguno de los dos con el freeware: gratis no significa abierto.
04 Licencias open source: MIT, Apache, GPL, AGPL y la polémica SSPL
| Licencia | Tipo | Qué te obliga a hacer | Ejemplos de uso |
|---|---|---|---|
| MIT | Permisiva | Mantener el aviso de copyright y la licencia | React, Laravel, Node.js |
| Apache 2.0 | Permisiva con cesión de patentes | Mantener avisos, indicar cambios y respetar la cesión expresa de patentes | Kubernetes, Jitsi Meet |
| BSD | Permisiva | Mantener el aviso de copyright | FreeBSD |
| MPL 2.0 | Copyleft débil (por archivo) | Compartir los cambios en los archivos con licencia MPL | Firefox |
| GPL v2 / v3 | Copyleft fuerte | Distribuir el código de las obras derivadas con la misma licencia | Linux (v2), WordPress |
| AGPL v3 | Copyleft fuerte en red | Además, ofrecer el código a quien use el programa a través de la red | Nextcloud, Redis 8 (como una de sus opciones) |
| SSPL | No aprobada por la OSI | Publicar el código de todo el servicio si ofreces el programa como servicio | MongoDB desde octubre de 2018 |
Las licencias permisivas dejan que integres el código en un producto cerrado; las de copyleft exigen que las obras derivadas sigan siendo abiertas. La GPL solo obliga cuando distribuyes el programa, por eso la AGPL (noviembre de 2007) añadió el caso del software que se usa a través de internet.
La SSPL nació en 2018 cuando MongoDB quiso impedir que los grandes proveedores de nube vendieran su base de datos como servicio sin contribuir. Va más allá de la AGPL y la OSI no la ha aprobado, así que MongoDB ya no es open source en sentido estricto. El mismo debate llevó a HashiCorp a pasarse a la BSL en 2023, lo que originó la bifurcación OpenTofu, y a Redis a abandonar su licencia BSD en marzo de 2024; con Redis 8, en mayo de 2025, Redis volvió a ofrecer una licencia aprobada por la OSI, la AGPLv3.
05 Cómo se gana dinero con el open source
Suscripciones de soporte
El software es gratis; se pagan las actualizaciones certificadas, el soporte y la garantía. Es el modelo de Red Hat.
Open core
El núcleo es abierto y las funciones empresariales (seguridad, auditoría, gestión) son de pago.
Servicio gestionado en la nube
Se cobra por alojar y mantener el software: WordPress.com frente a WordPress.org, o MongoDB Atlas.
Licencia dual
El mismo código se ofrece con licencia copyleft o con licencia comercial para quien no quiera compartir su código, como hace Oracle con MySQL.
Servicios y desarrollo
Agencias y consultoras cobran por implantar, adaptar y mantener software abierto.
Fundaciones y patrocinio
Fundaciones como la Apache Software Foundation o la Linux Foundation financian proyectos con aportaciones de empresas.
La licencia dual de MySQL es un buen ejemplo de cómo el copyleft puede ser un modelo comercial. Y proyectos como Jitsi Meet, con licencia Apache 2.0, muestran la otra cara: una empresa puede mantener un servicio gratuito y a la vez permitir que cualquiera lo instale en su propio servidor.
06 Ventajas, riesgos y open source en la inteligencia artificial
Ventaja: sin dependencia de un proveedor
Si el proveedor cierra o sube precios, puedes seguir usando el código o contratar a otro equipo.
Ventaja: seguridad auditable
Cualquiera puede revisar el código, aunque eso no garantiza que alguien lo haga.
Riesgo: mantenimiento
Muchos proyectos dependen de pocos voluntarios; revisa la actividad y la comunidad antes de adoptar uno.
Riesgo: cumplimiento
Licencias incompatibles y vulnerabilidades en dependencias exigen control del inventario de software.
En IA, la OSI publicó en octubre de 2024 la Open Source AI Definition 1.0: para que un modelo sea open source hay que publicar, además de los pesos, el código de entrenamiento e información suficiente sobre los datos. Por eso muchos modelos de «pesos abiertos» con licencias que restringen usos no cumplen la definición, mientras que otros, como los gpt-oss que OpenAI publicó en agosto de 2025 con licencia Apache 2.0, ofrecen sus pesos con una licencia aprobada por la OSI.
En la UE, la Ley de Ciberresiliencia trata de forma específica el software libre y de código abierto: sus obligaciones de notificación de vulnerabilidades se aplican desde el 11 de septiembre de 2026 y las principales, desde el 11 de diciembre de 2027.
La mayoría de los proyectos a medida se construyen sobre piezas abiertas (frameworks, bases de datos, librerías) y el valor está en cómo se combinan. Si dudas entre adaptar una herramienta existente o construir la tuya, repasa cuándo compensa el software a medida frente a un SaaS. En nuestros proyectos de desarrollo de aplicaciones web a medida y de desarrollo de SaaS revisamos las licencias de cada dependencia para que puedas explotar el producto sin sorpresas.
Preguntas frecuentes sobre Open Source
Significa código abierto: software cuyo código fuente se publica con una licencia que permite usarlo, estudiarlo, modificarlo y redistribuirlo, también con fines comerciales, según la Open Source Definition de la OSI.
No necesariamente. Casi siempre se puede obtener sin pagar, pero la licencia permite venderlo, y muchas empresas cobran por soporte, alojamiento o funciones adicionales. Lo que define al open source son las libertades, no el precio.
Designan casi el mismo software. El software libre, definido por la FSF, subraya la libertad del usuario como principio ético; el open source, definido por la OSI, destaca las ventajas prácticas del desarrollo abierto.
Si quieres la máxima adopción, una permisiva como MIT o Apache 2.0, que además incluye cesión de patentes. Si quieres que las mejoras vuelvan a la comunidad, una copyleft como GPL, o AGPL si el software se usa como servicio web.
No en sentido estricto. Desde el 16 de octubre de 2018 sus nuevas versiones usan la licencia SSPL, que la OSI no ha aprobado. Su código es visible, pero es source available.
Linux, Android (AOSP), Firefox, WordPress, LibreOffice, Kubernetes, MySQL, PostgreSQL, Python, Node.js, React y Laravel, entre muchos otros.
Sí, todas las licencias open source lo permiten. Lo que cambia son las obligaciones: con MIT basta mantener el aviso de copyright; con GPL o AGPL puedes tener que publicar el código de tu producto.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗