codigolibre.clNosotros
← Licencias

Qué licencia elegir para tu proyecto de código abierto

Una guía por objetivos para elegir entre MIT, Apache 2.0, GPL, LGPL, AGPL y MPL, con los casos en que cada una encaja y los errores más comunes.

Por Martín Olave4 min de lectura

En este artículo
  1. Paso 1: define qué quieres lograr
  2. Paso 2: mira qué usa tu ecosistema
  3. Paso 3: revisa tus dependencias
  4. Paso 4: piensa en el modelo de negocio
  5. Las licencias que no recomendamos
  6. Errores comunes
  7. Cómo aplicarla
  8. Preguntas frecuentes

Para la mayoría de los proyectos la decisión se reduce a una pregunta: ¿te importa que otros puedan tomar tu código y cerrarlo? Si no te importa, elige una licencia permisiva: MIT si quieres lo más simple, Apache 2.0 si te importan las patentes. Si te importa, elige una copyleft: GPL para aplicaciones y AGPL para software que se usa por internet. Si quieres primero el mapa completo, lee tipos de licencias de software.

El resto de esta guía afina esa respuesta. Si prefieres que te guiemos paso a paso, usa el asistente para elegir licencia.

Paso 1: define qué quieres lograr

Lo que más te importa Licencia
Que lo use la mayor cantidad de gente y empresas, sin fricción MIT
Lo mismo, con protección explícita de patentes Apache 2.0
Que toda versión distribuida siga siendo libre GPL v3
Lo mismo, incluso si se ofrece como servicio web AGPL v3
Que una biblioteca se pueda usar desde software cerrado, pero sus mejoras vuelvan LGPL v3 o MPL 2.0
Renunciar a todos tus derechos CC0 o Unlicense

Paso 2: mira qué usa tu ecosistema

Cada comunidad tiene costumbres, y seguirlas reduce fricción:

  • JavaScript y npm: MIT es mayoría.
  • Rust: es habitual la licencia doble “MIT o Apache 2.0”, a elección del usuario.
  • Python: MIT, BSD y Apache 2.0 dominan.
  • Go y Kubernetes: Apache 2.0 y BSD.
  • Herramientas de sistema y escritorio Linux: mucha GPL.
  • WordPress: GPL, porque los complementos y temas se consideran obras derivadas del núcleo GPL.

Si tu proyecto es un complemento de otro, la licencia del proyecto principal puede decidir por ti.

Paso 3: revisa tus dependencias

Tu licencia debe ser compatible con las de tu código:

  • Si dependes de código GPL e integras ese código en tu programa, tu proyecto distribuido tendrá que ser GPL.
  • Código MIT, BSD y Apache 2.0 se puede incluir en casi cualquier proyecto.
  • Apache 2.0 no es compatible con “solo GPL v2”.

Paso 4: piensa en el modelo de negocio

Si piensas vivir del proyecto, la licencia es parte de la estrategia:

  • Soporte y servicios: cualquier licencia sirve.
  • Licenciamiento dual: necesitas una licencia copyleft (GPL o AGPL) para la comunidad y ser dueño de todo el código. Esto exige que quienes contribuyen firmen un acuerdo de cesión o de licencia (CLA).
  • Servicio gestionado: la AGPL desalienta que un competidor ofrezca tu software como servicio sin aportar.

Las licencias “de código visible” como la BSL o la SSPL, que algunas empresas adoptaron en los últimos años, no son de código abierto según la Open Source Initiative. Si las eliges, no describas tu proyecto como abierto.

Las licencias que no recomendamos

  • Ninguna licencia. Un repositorio público sin licencia no es abierto: por defecto, el autor conserva todos los derechos y nadie puede usar el código legalmente.
  • Licencias inventadas o modificadas. Agregar “pero no para uso militar” o “solo para fines no comerciales” a una licencia conocida crea una licencia nueva, incompatible con todo y que ningún área legal va a aprobar.
  • Licencias de Creative Commons para código (salvo CC0). Están pensadas para obras culturales y no tratan temas como el código fuente o las patentes.

Errores comunes

  1. No poner el archivo LICENSE. Mencionar la licencia en el README no basta para las herramientas que la detectan.
  2. Olvidar el año y el titular en las licencias que los piden.
  3. Cambiar de licencia sin permiso. Para cambiar la licencia de un proyecto con contribuciones de terceros necesitas el acuerdo de todos los titulares, salvo que hayan firmado un CLA.
  4. Elegir GPL esperando que la adopten empresas. Muchas tienen políticas que la restringen. Si la adopción corporativa es tu objetivo, una licencia permisiva funciona mejor.

Cómo aplicarla

  1. Agrega el texto completo en un archivo LICENSE en la raíz del repositorio. GitHub y GitLab ofrecen plantillas.
  2. Declara el identificador SPDX en el archivo de paquete (package.json, pyproject.toml, Cargo.toml).
  3. Opcionalmente, agrega el identificador en el encabezado de cada archivo:
/* SPDX-License-Identifier: GPL-3.0-or-later */
  1. Si aceptas contribuciones, aclara en el CONTRIBUTING.md bajo qué licencia quedan.

Para entender la diferencia de fondo entre los dos movimientos, lee software libre frente a código abierto.

Preguntas frecuentes

¿Cuál es la licencia de código abierto más usada? La MIT. Es la más usada en GitHub y la mayoritaria en el ecosistema de JavaScript y npm.

¿Qué pasa si publico mi código en GitHub sin licencia? Nadie puede usarlo legalmente. Sin licencia, el autor conserva todos los derechos por defecto, aunque el repositorio sea público.

¿Puedo cambiar la licencia de mi proyecto después? Sí, si eres el único titular del código. Si hay contribuciones de terceros, necesitas el acuerdo de todos los titulares, salvo que hayan firmado un CLA, y las versiones ya publicadas siguen disponibles con la licencia anterior.

¿Qué licencia elegir para que nadie cierre mi código? Una licencia copyleft: GPL para aplicaciones y AGPL si el software se usa como servicio por internet. Así toda versión distribuida tiene que seguir siendo libre.

¿Qué diferencia hay entre MIT y Apache 2.0? Las dos son permisivas y permiten usar el código en productos cerrados. Apache 2.0 agrega una licencia explícita de patentes, y MIT es más corta y simple.

Fuentes

Sigue leyendo