por Elegir una licencia suele dejarse para el final del proyecto. Subimos el código, añadimos un README y, cuando GitHub pregunta por MIT, Apache o GPL, escogemos la que hemos visto más veces. El problema es que esas tres licencias permiten usar, modificar y compartir el programa, pero no protegen el resultado de la misma forma.
No hay una licencia mejor para todos los proyectos. La pregunta útil es qué queremos permitir cuando otra persona copie nuestro código, lo modifique, lo incluya en un producto o distribuya una versión diferente.
Las tres son licencias de software libre
MIT, Apache 2.0 y GNU GPLv3 permiten utilizar el programa con cualquier finalidad, estudiar su código, modificarlo y redistribuirlo. Las tres aparecen como licencias aprobadas o libres en los repertorios habituales. La diferencia principal no está en si podemos modificar el código, sino en las condiciones que debemos cumplir cuando entregamos copias o versiones modificadas.
También pueden utilizarse en un proyecto comercial. Software libre no significa que tengamos prohibido venderlo, cobrar soporte o utilizarlo dentro de una empresa. Si esta parte todavía resulta confusa, conviene empezar por la diferencia entre software libre y software gratuito.
MIT: pocos requisitos y mucha libertad para reutilizar
La licencia MIT es corta y permisiva. Autoriza a utilizar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y vender copias. Su condición esencial es conservar el aviso de copyright y el texto de permiso en las copias o partes sustanciales del software.
Quien reciba el código puede incluirlo en un programa propietario y no tiene que publicar el resto del producto bajo MIT. Tampoco está obligado a enviarnos sus cambios. Esto facilita mucho la adopción de una biblioteca, pero acepta que las mejoras posteriores puedan terminar dentro de un producto cerrado.
MIT encaja bien cuando queremos reducir al mínimo las condiciones de reutilización: una biblioteca pequeña, un ejemplo, una herramienta que deseamos ver integrada en muchos entornos o un proyecto donde no nos preocupa que aparezcan derivados propietarios.
Apache 2.0: permisiva, con una parte de patentes más explícita
Apache 2.0 también permite crear derivados propietarios, pero su texto es más detallado. Incluye una concesión expresa de licencias de patentes por parte de los contribuidores para las aportaciones cubiertas, junto con una cláusula de terminación relacionada con determinadas demandas de patentes.
Al redistribuir debemos entregar una copia de la licencia, conservar los avisos pertinentes e indicar de forma destacada los archivos modificados. Si el proyecto contiene un archivo NOTICE, hay que mantener los avisos aplicables de la manera indicada por la licencia. Esto no obliga a convertir todo el producto en software libre, pero sí exige cuidar más la atribución.
Puede ser una elección razonable para bibliotecas, infraestructura o proyectos con contribuciones de varias empresas cuando interesa una licencia permisiva y una redacción de patentes más clara que la de MIT. La FAQ de la Apache Software Foundation explica además cómo aplicar correctamente la licencia y el archivo de avisos.
GPLv3: si se distribuye el derivado, conserva las libertades
GNU GPLv3 utiliza copyleft. Podemos ejecutar y modificar el programa de forma privada, también dentro de una empresa, sin publicar cada cambio. La obligación importante aparece cuando distribuimos o entregamos a otra persona una obra cubierta: debemos ofrecer el código fuente correspondiente y conservar la licencia para el conjunto cubierto por GPL.
Esto impide tomar una aplicación GPL, distribuir una versión modificada y negar a sus destinatarios las libertades que recibimos. No significa que cualquier programa instalado en el mismo ordenador se vuelva GPL ni que todo el código de una empresa tenga que publicarse.
GPLv3 es adecuada cuando queremos que las versiones distribuidas del programa sigan siendo libres. Suele tener más sentido en aplicaciones completas, herramientas y proyectos donde la posibilidad de estudiar y compartir los derivados forma parte del objetivo, no sólo del método de desarrollo.
Comparación rápida
| Situación | MIT | Apache 2.0 | GPLv3 |
|---|---|---|---|
| Permite uso comercial | Sí | Sí | Sí |
| Permite derivados propietarios | Sí | Sí | No al distribuir una obra derivada cubierta |
| Obliga a conservar licencia y avisos | Sí | Sí, con requisitos más detallados | Sí |
| Concesión expresa de patentes | No en su texto | Sí | Sí |
| Exige ofrecer código fuente al distribuir el derivado | No | No | Sí |
La tabla sirve para orientarnos, no para resolver combinaciones complejas. En un proyecto real puede haber código con varias licencias, bibliotecas enlazadas, recursos gráficos con condiciones diferentes y contribuciones cuyos derechos no están claros.
GPL no cubre automáticamente un servicio en Internet
Hay otra confusión frecuente. Si modificamos un programa GPL y sólo lo ejecutamos en nuestro servidor, la interacción de los usuarios mediante la red no se considera por sí sola una distribución de copias. Por eso existe GNU AGPLv3: añade una condición para que quienes interactúan con una versión modificada a través de la red puedan obtener su código fuente correspondiente.
AGPL no es una GPL «más nueva» ni una elección automática para cualquier web. Es una licencia distinta que debemos valorar cuando el programa está pensado principalmente para funcionar como servicio y queremos que las modificaciones desplegadas también queden disponibles.
Qué escoger en casos habituales
- Quiero que una biblioteca se utilice en casi cualquier proyecto: MIT ofrece el camino más sencillo. Apache 2.0 añade una protección de patentes más explícita.
- Quiero que las versiones distribuidas de mi aplicación sigan siendo libres: GPLv3 expresa mejor esa intención.
- El valor principal está en un servidor y quiero cubrir modificaciones ofrecidas por red: conviene estudiar AGPLv3.
- Mi empresa utiliza patentes o recibe muchas contribuciones corporativas: Apache 2.0 merece una revisión específica, aunque la licencia final debería validarse con quien lleve la parte legal.
Errores que conviene evitar
El primero es publicar un repositorio sin licencia y asumir que eso lo convierte en abierto. Sin un permiso, el resto puede leerlo en la plataforma, pero no obtiene automáticamente derechos generales para modificarlo o distribuirlo.
El segundo es copiar el nombre de una licencia en el README sin incluir el texto ni revisar si tenemos derecho a relicenciar todo lo que contiene el repositorio. Fuentes, imágenes, documentación, fragmentos ajenos y dependencias pueden necesitar un tratamiento separado.
El tercero es pensar sólo en lo que queremos permitir hoy. La licencia también decide qué podrá hacer la comunidad si dentro de cinco años dejamos de mantener el proyecto.
Para identificar los nombres exactos podemos consultar la lista de licencias SPDX. Para entender los efectos legales de una combinación concreta, especialmente en un producto comercial, hace falta revisar el caso y no quedarse únicamente con esta comparación.
Escoger licencia no debería bloquear el primer commit, pero tampoco merece un clic al azar. Basta con decidir si buscamos adopción permisiva, una concesión de patentes explícita o conservar las libertades en los derivados distribuidos. A partir de ahí, la elección suele reducirse bastante.
