Licencias open source: guía completa de GPL, MIT, Apache y más

Las licencias de software libre y open source son el marco legal que hace posible la colaboración masiva entre millones de desarrolladores en todo el mundo. Sin ellas, proyectos como Linux, Firefox, WordPress o Python simplemente no existirían. Sin embargo, elegir la licencia equivocada — o ignorar sus términos — puede acarrear problemas legales graves. Esta guía te ofrece una visión completa, rigurosa y práctica de las licencias open source más importantes, sus diferencias y cómo elegir la adecuada para tu proyecto.

📜 ¿Qué es una licencia de software open source?

Una licencia de software es un contrato legal que define qué puede y qué no puede hacer un tercero con un programa informático. En el software propietario (Windows, Adobe Photoshop, Microsoft Office), la licencia generalmente restringe el acceso al código fuente, prohíbe la modificación y limita la redistribución. En el software open source, la licencia hace exactamente lo contrario: garantiza derechos que de otro modo no existirían.

Es un error muy extendido pensar que «open source» significa «sin licencia» o «se puede hacer lo que quieras». La realidad es la opuesta: todo software open source tiene una licencia, y esa licencia establece obligaciones concretas que el usuario debe cumplir. Sin licencia, el código fuente está protegido por copyright por defecto — publicar código en GitHub sin licencia no lo convierte en software libre.

Las licencias open source cumplen tres funciones fundamentales:

La Open Source Initiative (OSI) es la organización que certifica oficialmente qué licencias cumplen los criterios de «open source». Para ser aprobada, una licencia debe cumplir los 10 criterios de la Open Source Definition, que incluyen libre redistribución, acceso al código fuente, permiso de obras derivadas y no discriminación de personas, grupos o campos de actividad.

🔍 Software libre vs open source: ¿son lo mismo?

Aunque coloquialmente se usan como sinónimos, «software libre» y «open source» son conceptos que nacen de filosofías diferentes y que, en la práctica, generan tensiones ideológicas que conviene entender.

Software libre (Free Software) es un término acuñado por Richard Stallman y la Free Software Foundation (FSF) en 1983. Se define por las cuatro libertades esenciales:

Open source es un término creado en 1998 por Christine Peterson, Eric Raymond y Bruce Perens como alternativa pragmática al término «free software», que generaba confusión con «gratuito» en inglés. La Open Source Initiative (OSI) adoptó una definición técnica basada en 10 criterios que se centran en el acceso al código y la redistribución, sin el componente filosófico de la FSF.

En la práctica, el 99% de las licencias aprobadas por la OSI también cumplen las cuatro libertades de la FSF, y viceversa. La diferencia es principalmente filosófica y retórica: la FSF enfatiza la ética y la justicia social del software libre, mientras que la OSI enfatiza los beneficios prácticos y empresariales del modelo de desarrollo abierto.

Para este artículo, usaremos «open source» como término general que engloba ambas tradiciones, siguiendo la convención más extendida en la industria.

📊 Tipos de licencias: permisivas vs copyleft

Las licencias open source se dividen en dos grandes familias según el grado de obligaciones que imponen a quien utiliza o modifica el software:

Licencias permisivas (MIT, BSD, Apache): permiten hacer casi cualquier cosa con el código, incluyendo incorporarlo a software propietario y distribuirlo sin compartir las modificaciones. Solo exigen mantener el aviso de copyright y la exención de responsabilidad.

Licencias copyleft (GPL, LGPL, AGPL, MPL): exigen que las obras derivadas se distribuyan bajo la misma licencia (o una compatible). Esto garantiza que el código permanezca libre «para siempre» — nadie puede tomar código copyleft, modificarlo y cerrarlo.

Entender esta distinción es crucial porque determina la compatibilidad entre licencias: puedes mezclar código MIT con código GPL (el resultado será GPL), pero no puedes mezclar código GPL con código propietario si distribuyes el resultado.

🟢 Licencia MIT: la más popular del mundo

La licencia MIT (Massachusetts Institute of Technology) es, con diferencia, la licencia open source más utilizada del mundo. Según GitHub, más del 40% de los repositorios con licencia explícita usan MIT. Su popularidad se debe a su extrema simplicidad: cabe en un párrafo y cualquier persona puede entenderla sin necesidad de un abogado.

El texto completo de la licencia MIT dice, en esencia, lo siguiente: «Se concede permiso, de forma gratuita, a cualquier persona que obtenga una copia de este software, para usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y/o vender copias del software, siempre que el aviso de copyright y este permiso se incluyan en todas las copias.»

Proyectos que usan MIT incluyen: React (Meta), Node.js, Vue.js, jQuery, Ruby on Rails, .NET (Microsoft), Visual Studio Code, Angular y Electron.

🔵 Licencia Apache 2.0: permisiva con protección de patentes

La licencia Apache 2.0, creada por la Apache Software Foundation, es una licencia permisiva similar a MIT pero con dos adiciones importantes: una concesión explícita de patentes y una cláusula de terminación por litigio de patentes.

La concesión de patentes significa que, si el contribuidor tiene patentes que cubren el código que contribuye, automáticamente otorga una licencia gratuita e irrevocable sobre esas patentes a todos los usuarios. La cláusula de terminación establece que si un usuario demanda al proyecto por infracción de patentes, pierde automáticamente todos los derechos que la licencia le concedía.

Estas cláusulas hacen que Apache 2.0 sea la licencia preferida por grandes empresas tecnológicas que quieren protegerse de guerras de patentes. Proyectos como Android (AOSP), Kubernetes, Hadoop, Spark, Kafka, TensorFlow, Swift y Rust usan Apache 2.0.

🟡 Licencias BSD: la tradición de Berkeley

Las licencias BSD (Berkeley Software Distribution) tienen su origen en la Universidad de California, Berkeley, donde se desarrolló una de las variantes más influyentes de Unix en las décadas de 1970 y 1980. Existen varias versiones:

BSD 2-Clause («Simplified»): prácticamente idéntica a MIT. Solo exige mantener el aviso de copyright en el código fuente y en la documentación de redistribuciones binarias.

BSD 3-Clause («New» o «Revised»): añade la cláusula de no endoso — prohíbe usar el nombre de la organización o los contribuidores para promocionar productos derivados sin permiso escrito. Esta es la versión más utilizada.

BSD 4-Clause («Original»): históricamente incluía una cláusula de publicidad que obligaba a mencionar a Berkeley en toda publicidad del software derivado. Esta versión está en desuso por la impracticabilidad de la cláusula cuando centenares de contribuidores la incluyen.

Proyectos con licencia BSD: FreeBSD, OpenBSD, NetBSD, Nginx (BSD 2-clause), Django, Flask, PostgreSQL (su propia licencia tipo BSD) y gran parte del stack de red de macOS y iOS.

🔴 GPL: la licencia que «protege la libertad»

La GNU General Public License (GPL) es la licencia copyleft más importante y la segunda más utilizada después de MIT. Creada por Richard Stallman en 1989, su objetivo fundamental es asegurar que el software libre permanezca libre — que nadie pueda tomar código libre, modificarlo y distribuir el resultado como software propietario.

Existen tres versiones principales:

GPL v2 (1991): la versión que usa el kernel Linux (por decisión explícita de Linus Torvalds, que rechazó migrar a v3). Establece que cualquier «obra derivada» que se distribuya debe publicar su código fuente completo bajo GPL v2.

GPL v3 (2007): añade protecciones contra la tivoización (usar hardware para impedir que los usuarios ejecuten versiones modificadas del software, como hacía TiVo con Linux), requisitos anti-DRM, y mejor compatibilidad con Apache 2.0.

AGPL v3 (2007): la versión más restrictiva. Extiende la GPL para cubrir el uso en red: si ejecutas software AGPL modificado como servicio web (SaaS), debes proporcionar el código fuente a los usuarios del servicio, incluso si no «distribuyes» el software en el sentido tradicional.

Ejemplo del efecto copyleft:

            1. Proyecto A tiene licencia GPL v3
            2. Tú tomas código de A y lo modificas → Proyecto B
            3. Si distribuyes B → DEBES publicar el código de B bajo GPL v3
            4. Si solo usas B internamente → NO tienes obligación de publicar

            Con AGPL:
            5. Si ofreces B como servicio web → DEBES publicar el código de B

🟣 LGPL y MPL: el copyleft «con matices»

Entre las licencias permisivas y la GPL existen opciones intermedias que aplican copyleft de forma más limitada:

LGPL (Lesser General Public License): aplica copyleft solo a la librería en sí, no al software que la utiliza. Si modificas la librería LGPL, debes publicar las modificaciones. Pero si tu aplicación simplemente enlaza (link) con la librería LGPL sin modificarla, puedes mantener tu aplicación bajo cualquier licencia, incluida propietaria. Proyectos: Qt (edición open source), FFmpeg, glibc (la librería C de GNU/Linux).

MPL 2.0 (Mozilla Public License): aplica copyleft a nivel de archivo individual. Si modificas un archivo MPL, debes publicar las modificaciones de ese archivo. Pero puedes añadir archivos nuevos bajo cualquier licencia. Esto permite combinar código MPL con código propietario en el mismo proyecto sin «contaminar» los archivos nuevos. Proyectos: Firefox, Thunderbird, LibreOffice (dual MPL/LGPL).

La MPL 2.0 es particularmente interesante para empresas que quieren un equilibrio entre compartir y proteger: las mejoras al código existente se comparten, pero las extensiones propietarias son posibles.

🎨 Creative Commons: licencias para contenido no-software

Las licencias Creative Commons (CC) no están diseñadas para software sino para contenido creativo: textos, imágenes, música, vídeos, datos, documentación, material educativo. Sin embargo, aparecen constantemente en el ecosistema Linux porque las documentaciones, wikis, iconos y recursos multimedia de muchos proyectos usan CC.

Las licencias CC se construyen combinando cuatro módulos:

Las combinaciones más relevantes para el ecosistema Linux son:

CC BY 4.0: la más permisiva (excluyendo CC0). Solo exige atribución. Usada por Wikipedia (junto con GFDL), Stack Overflow, OpenStreetMap y muchas documentaciones de proyectos.

CC BY-SA 4.0: atribución + copyleft. Es el equivalente de la GPL para contenido. Wikipedia y muchos wikis de proyectos usan esta licencia.

CC0: dominio público efectivo. Ideal para datos, metadatos y contenido donde la atribución es impracticable. Usado por Unsplash (para fotos) y muchos datasets científicos.

🔗 Compatibilidad entre licencias: la guía definitiva

La compatibilidad entre licencias es uno de los aspectos más complejos y malinterpretados del ecosistema open source. Cuando combinas código de diferentes proyectos con diferentes licencias, el resultado debe cumplir todas las licencias simultáneamente. Si dos licencias son incompatibles, simplemente no puedes combinar ese código legalmente.

Las reglas generales de compatibilidad son:

Permisiva + Permisiva: siempre compatible. Puedes mezclar código MIT con código Apache 2.0 sin problemas. El resultado cumple ambas licencias.

Permisiva → Copyleft: compatible en una dirección. Puedes tomar código MIT y añadirlo a un proyecto GPL. El resultado será GPL. Pero no al revés: no puedes tomar código GPL y ponerlo en un proyecto MIT (porque MIT permitiría cerrar el código, violando la GPL).

GPL v2 vs GPL v3: incompatibles entre sí, a menos que el código GPL v2 incluya la cláusula «or any later version». Esta incompatibilidad es la razón por la que el kernel Linux (GPL v2 sin «or later») no puede incorporar código GPL v3.

GPL vs Apache 2.0: Apache 2.0 es compatible con GPL v3 pero incompatible con GPL v2, debido a las cláusulas de patentes de Apache que añaden restricciones no contempladas en GPL v2.

💼 Dual licensing y licencias comerciales

El dual licensing (licencia dual) es un modelo de negocio donde el mismo software se ofrece bajo dos licencias diferentes: una open source (generalmente copyleft) para la comunidad, y una licencia comercial/propietaria para empresas que no quieren cumplir las obligaciones del copyleft.

El caso más conocido es MySQL/MariaDB: el código está disponible bajo GPL, lo que significa que cualquier software que lo incorpore debe ser también GPL. Pero Oracle (propietaria de MySQL) vende licencias comerciales a empresas que quieren incorporar MySQL en productos propietarios sin cumplir la GPL. Qt sigue un modelo similar con LGPL + licencia comercial.

Otros modelos de negocio basados en licencias open source incluyen:

Open core: el núcleo del software es open source, pero las funcionalidades empresariales (alta disponibilidad, gestión centralizada, soporte) son propietarias. Modelo usado por GitLab, Elastic, Redis.

SSPL (Server Side Public License): creada por MongoDB en 2018, exige que si ofreces el software como servicio, debes publicar el código fuente de toda la infraestructura usada para proveer el servicio. La OSI no la ha aprobado como open source. Elastic y Redis también adoptaron licencias similares (SSPL, RSALv2) por conflictos con AWS que ofrecía sus productos como servicio sin contribuir al desarrollo.

Estas tensiones entre proyectos open source y proveedores cloud representan uno de los debates más activos de la industria en 2026.

🎯 ¿Cómo elegir la licencia correcta para tu proyecto?

Elegir la licencia adecuada es una de las decisiones más importantes al iniciar un proyecto open source, porque cambiarla después requiere el consentimiento de todos los contribuidores (o reescribir el código de los que no consientan). Aquí tienes un árbol de decisión práctico:

¿Quieres máxima adopción sin restricciones? → MIT. La opción por defecto si no tienes una razón específica para elegir otra. Ideal para librerías, herramientas y proyectos donde la adopción masiva es el objetivo principal.

¿Quieres protección contra litigios de patentes? → Apache 2.0. Recomendada si el proyecto opera en un sector donde las patentes de software son prevalentes (cloud, machine learning, sistemas distribuidos).

¿Quieres que las mejoras se devuelvan a la comunidad? → GPL v3 o MPL 2.0. GPL si quieres copyleft fuerte (todo derivado es GPL); MPL si quieres copyleft solo a nivel de archivo (permite extensiones propietarias).

¿Tu proyecto es una librería que quieres que usen todos? → MIT o LGPL. LGPL si quieres que las mejoras a la librería se compartan, pero que las aplicaciones que la usen puedan ser propietarias.

¿Tu proyecto es un servicio web/SaaS? → AGPL v3 si quieres que quienes lo ofrezcan como servicio compartan sus modificaciones.

¿Es documentación o contenido creativo? → CC BY 4.0 (permisiva) o CC BY-SA 4.0 (copyleft). CC0 para datos y metadatos.

🛠️ Cómo aplicar una licencia a tu proyecto

Aplicar una licencia correctamente a un proyecto requiere más que copiar un archivo. Estos son los pasos necesarios:

# 1. Crear archivo LICENSE en la raíz del proyecto
            # Copiar el texto íntegro de la licencia elegida
            cp /usr/share/common-licenses/MIT ./LICENSE

            # 2. Añadir aviso de copyright al inicio de cada archivo fuente
            # Para MIT/BSD/Apache:
            cat << 'EOF' > header.txt
            # Copyright (c) 2026 Tu Nombre o Empresa
            #
            # Permission is hereby granted, free of charge, to any person obtaining a copy
            # of this software...
            # [texto completo de la licencia]
            EOF

            # 3. Si es un proyecto nuevo en GitHub:
            # - Seleccionar licencia al crear el repositorio
            # - O añadir archivo LICENSE manualmente

            # 4. Verificar que el archivo package.json / setup.py / Cargo.toml
            #    incluye el campo "license":
            # package.json: "license": "MIT"
            # setup.py: license="Apache-2.0"
            # Cargo.toml: license = "MIT OR Apache-2.0"

            # 5. Para proyectos con múltiples contribuidores, considerar un CLA
            # (Contributor License Agreement) que facilite cambios futuros

Es importante usar el identificador SPDX (Software Package Data Exchange) al declarar licencias en metadatos. SPDX estandariza los nombres de licencias para evitar ambigüedades: «MIT» en lugar de «The MIT License» o «Expat License»; «Apache-2.0» en lugar de «Apache License Version 2.0». La lista completa está en spdx.org/licenses.

Si tu proyecto usa dependencias de terceros con diferentes licencias, herramientas como license-checker (npm), pip-licenses (Python) o cargo-license (Rust) pueden generar un inventario automático de todas las licencias de tus dependencias.

📋 Tabla comparativa de las principales licencias

* MongoDB y Grafana migraron posteriormente a SSPL/AGPLv3 respectivamente.

⚠️ Errores frecuentes y mitos sobre licencias open source