Primero, define el objetivo
Elegir licencia no es cuestión de gustos, sino de qué quieres conseguir. La mayoría de los casos están en algún punto entre estos dos objetivos.
- Quiero que se use lo más posible — si quieres que entre sin trabas en productos de empresas, en otros proyectos de código abierto y en aplicaciones cerradas, te conviene una permisiva.
- Quiero que las mejoras vuelvan en abierto — si quieres que, cuando alguien modifique y distribuya tu código, esas modificaciones también se publiquen, lo adecuado es un copyleft.
Permisivas: adopción amplia, poca fricción
MIT, BSD, ISC y Apache-2.0 solo exigen, básicamente, conservar los avisos. La mayoría de los departamentos jurídicos de las empresas las tienen en su lista de preaprobadas, así que su adopción es rápida. A cambio, no puedes impedir que alguien modifique el código y lo incluya en un producto cerrado.
Dentro de las permisivas, la elección depende sobre todo de dos cosas.
- Patentes: si necesitas licencia de patentes explícita y cláusula de represalia, Apache-2.0; si no, MIT.
- Compatibilidad con GPL-2.0: la postura de la FSF es que Apache-2.0 no puede entrar en proyectos GPL-2.0-only, así que en el ecosistema del kernel de Linux resultan más cómodas MIT o BSD.
Copyleft: la cadena de la apertura
La GPL impone la obligación de publicar a todo el programa combinado; la LGPL, a la biblioteca; y la MPL, por archivo. Para software que se ejecuta en servidores, la AGPL cubre el hueco de la GPL. Con copyleft, algunas empresas pueden mostrarse reacias a usarlo o contribuir. En particular, muchas compañías restringen la AGPL en sus políticas internas. Puede ser un efecto buscado o un efecto secundario no deseado.
Las costumbres del ecosistema también cuentan
Una licencia genera menos fricción cuando coincide con las costumbres de la comunidad.
| Ecosistema | Licencias habituales | Observaciones |
|---|---|---|
| JavaScript (npm) | MIT, ISC | Muchos paquetes pequeños; se prefieren permisivas cortas |
| Rust (crates.io) | MIT OR Apache-2.0 | El propio Rust usa esta fórmula dual |
| Python (PyPI) | MIT, BSD-3-Clause, Apache-2.0 | En computación científica abunda BSD-3 |
| Go | BSD-3-Clause, MIT, Apache-2.0 | La biblioteca estándar de Go es BSD-3 |
| Módulos del kernel de Linux | GPL-2.0-only | Prácticamente obligatoria para combinarse con el kernel |
| Herramientas GNU de escritorio | GPL-3.0-or-later | La opción por defecto del proyecto GNU |
| Bibliotecas C/C++ | LGPL, MIT, BSL-1.0 | La forma de enlace influye en la elección |
Lista de comprobación para decidir
- Revisa las dependencias: comprueba que las licencias de las bibliotecas que ya usas no limitan tus opciones. Si vas a distribuir un programa combinado con una biblioteca GPL, las opciones se reducen a licencias compatibles con la GPL.
- Revisa la titularidad: el código escrito como parte de un trabajo suele tener como titular a la empresa. Comprueba si la política de código abierto de tu empresa fija una licencia.
- Forma de uso: el efecto del copyleft cambia según sea software instalable, una biblioteca o un servicio.
- Forma de contribución: si piensas aceptar contribuciones externas, ten en cuenta que después será difícil cambiar la licencia, porque se mezcla el copyright de varias personas.
- Modelo de ingresos: si piensas vender una licencia comercial aparte, considera a la vez una licencia dual copyleft + comercial y un acuerdo de licencia de contribuidor (CLA).
Resumen en una frase
- Lo primero es que se use mucho → MIT (Apache-2.0 si te preocupan las patentes)
- Quiero recuperar las mejoras de la biblioteca, pero que quien la usa sea libre → MPL-2.0 o LGPL-3.0
- Quiero que todos los programas derivados se publiquen → GPL-3.0
- Quiero que se publiquen incluso las versiones modificadas de software de servidor → AGPL-3.0
- No quiero poner ninguna condición → 0BSD, Unlicense, CC0
Si respondes a estos criterios en forma de preguntas en el asistente de elección, te mostrará candidatas y sus motivos.
Este artículo es información general y no constituye asesoramiento jurídico. Para decisiones importantes, consulta con un profesional.
Fuentes
- choosealicense.com — https://choosealicense.com/
- FSF, Various Licenses and Comments about Them — https://www.gnu.org/licenses/license-list.html
- Licencia de Rust (MIT OR Apache-2.0) — https://github.com/rust-lang/rust