La licencia MIT deja hacer casi todo con el código: usarlo, modificarlo, venderlo y meterlo en un producto cerrado. La única condición es conservar el aviso de copyright y el texto de la licencia. La GPL funciona al revés: si distribuyes un programa que incluye código GPL, tienes que distribuir el programa completo bajo GPL y entregar su código fuente.
Para una agencia en Latinoamérica la diferencia importa cuando quiere licenciar o vender un producto propio. Una dependencia GPL bien escondida puede impedir licenciarlo como código cerrado.
Qué permite la licencia MIT
La MIT es la licencia más corta y la más usada en paquetes de npm y PyPI y en repositorios públicos. Su texto da permiso para:
- usar, copiar y modificar;
- fusionar con otro código y publicar;
- distribuir y sublicenciar;
- vender copias.
La condición es una sola: el aviso de copyright y el texto de la licencia deben ir en todas las copias o partes sustanciales del software. La licencia, además, excluye garantías.
Qué exige la licencia GPL
La GPL es una licencia copyleft. Su idea es que el software derivado siga siendo libre. La versión 3 (GPL v3) dice, en sus secciones 5, 6 y 10:
- Si distribuyes una obra basada en código GPL, la obra completa se licencia bajo GPL.
- Tienes que ofrecer el código fuente correspondiente a quien recibe el programa.
- No puedes agregar restricciones a los derechos que da la GPL.
La palabra clave es “distribuir” (en la v3, convey). Si el software corre solo en tus servidores y nadie más recibe una copia, la GPL no obliga a publicar el código.
Las licencias que vas a encontrar en un repositorio
| Licencia | Tipo | Qué tienes que hacer | ¿Se puede incluir en un producto cerrado? |
|---|---|---|---|
| MIT | Permisiva | Conservar aviso y licencia | Sí |
| BSD 2 y 3 cláusulas | Permisiva | Conservar aviso y licencia; la de 3 cláusulas prohíbe usar el nombre del autor para promocionar | Sí |
| Apache 2.0 | Permisiva | Conservar avisos y el archivo NOTICE, marcar archivos modificados; incluye licencia de patentes | Sí |
| LGPL | Copyleft débil | Permitir reemplazar la librería; publicar cambios a la librería misma | Sí, enlazada como librería |
| GPL v2 y v3 | Copyleft | Licenciar la obra completa bajo GPL al distribuirla y dar el código fuente | No, si se distribuye |
| AGPL v3 | Copyleft de red | Lo de la GPL, y además dar el código a quienes usan el programa por red | No, y también alcanza a un SaaS si modificas el código |
La AGPL es la que más sorprende a las agencias. Su sección 13 obliga a ofrecer el código fuente a los usuarios que interactúan con el programa modificado a través de una red. Un SaaS basado en código AGPL modificado queda alcanzado.
Qué significa para el código que tu agencia quiere licenciar
Cuando licencias un producto propio, licencias tu código. Las dependencias siguen con sus licencias y el licenciatario las recibe en esos términos. Eso tiene tres consecuencias:
- Con dependencias permisivas puedes licenciar tu producto como código cerrado. Solo agrega los avisos.
- Con una dependencia GPL integrada no puedes ofrecer una licencia cerrada del conjunto si el cliente recibe una copia. Hay que reemplazar la dependencia o aislarla.
- Con AGPL el problema llega aunque el producto sea un SaaS.
En México, el artículo 30 de la Ley Federal del Derecho de Autor exige que las licencias de uso consten por escrito; si no, son nulos de pleno derecho. Por eso el contrato con tu cliente debe incluir, como anexo, la lista de componentes open source con su licencia. Los demás puntos del contrato están en contrato de licencia de software.
Cómo revisar las licencias de un repositorio
Haz esto antes de licenciar, vender o entregar un producto:
- Genera la lista de dependencias directas y transitivas con un escáner de licencias del ecosistema (npm, pip, Maven, Composer).
- Marca todo lo que sea GPL, AGPL, LGPL o sin licencia declarada.
- Revisa si hay código copiado de foros, gists o repos sin licencia. Sin licencia, no tienes permiso de uso.
- Decide por cada caso: reemplazar, aislar como servicio separado o aceptar y documentar.
- Guarda el reporte con la fecha y el hash del commit. El comprador lo va a pedir.
Cuándo publicar tu propio código como open source
Publicar una librería bajo MIT o Apache 2.0 da visibilidad y atrae talento. También significa que cualquiera puede usarla gratis, tu competencia incluida.
- Publica lo que es infraestructura genérica y no tiene valor de licencia.
- No publiques lo que resuelve un problema de negocio que alguien pagaría por resolver.
- Si dudas, revisa primero cuánto vale ese código en cuánto vale el código.