¿Qué licencia open-source debes elegir?
Elegir una licencia open source para un proyecto no es obvio. ¿MIT? ¿Apache? ¿GPL? Cada una tiene reglas distintas sobre qué puede hacer otra gente con tu código, si tienen que darte crédito, si sus trabajos derivados también tienen que ser open source.
Esta herramienta te ayuda a elegir. Dos modos: asistente (unas pocas preguntas sí/no/cualquiera reducen la lista) o explorar (la lista completa de 16 licencias con comparación side-by-side).
Tras escoger, rellena tu nombre + año, luego copia o descarga un fichero LICENSE listo para soltar en la raíz de tu proyecto.
Cómo usarla
- Elige un modo arriba: Asistente (guiado por preguntas) o Explorar (con búsqueda).
- En el asistente, responde 4 preguntas: si los derivados deben ser OSS, uso comercial, atribución obligatoria, concesión de patentes necesaria. La lista se acota en vivo.
- Pulsa una licencia para ver detalles: permisos (qué pueden hacer otros), condiciones (qué deben hacer), limitaciones (qué descargas).
- Rellena tu nombre y el año para insertarlos en el texto de la licencia.
- Copia el resultado o descarga un fichero LICENSE. Suéltalo en la raíz de tu repositorio.
Cuándo es útil
Situaciones del día a día en las que necesitas elegir una licencia:
- Publicar tu primera librería npm: sin licencia nadie puede usarla legalmente. Elección más popular: MIT (corta, simple, usada por React/Vue/Angular).
- Librería corporativa, preocupado por patentes: Apache 2.0 tiene una concesión explícita de patentes que protege tanto a contribuidores como a usuarios. Requerida por CNCF y muchos programas enterprise.
- Quieres que cada cambio se quede abierto: GPL-3.0 fuerza a los derivados a usar la misma licencia. AGPL-3.0 añade obligación de divulgar el código fuente incluso cuando tu herramienta solo se hospeda como SaaS.
- Estás escribiendo documentación o haciendo arte: usa MIT/Apache para código, pero para docs e imágenes típicamente elige CC BY 4.0 (atribución) o CC BY-SA 4.0 (atribución + copyleft).
- Quieres monetizar pero mostrar la fuente: BSL 1.1 (HashiCorp Terraform) o Elastic 2.0 (Elasticsearch): source-available con restricciones sobre hosting comercial. Nota: NO están aprobadas por OSI.
- Sin restricciones en absoluto: Unlicense o CC0 para dominio público completo. WTFPL es una broma pero legalmente funcional.
- Añadir un fichero LICENSE a un repo existente: elígela, rellena tus detalles, copia en un fichero `LICENSE` (o `LICENSE.md`) en la raíz.
Herramientas relacionadas: el generador de .gitignore para bootstrapping de nuevos proyectos. El validador de package.json comprueba el campo `"license"` en tu manifest.