Qué licencia de software elegir para tu proyecto (MIT, Apache, GPL...)

Subes tu proyecto a GitHub sin archivo LICENSE y, técnicamente, nadie tiene permiso legal para usar tu código, ni siquiera para copiarlo, aunque el repositorio sea público. La ausencia de licencia no significa "libre para todos": por defecto, el copyright protege el código y nadie puede reutilizarlo sin permiso explícito. Elegir una licencia es, literalmente, decidir qué le permites hacer a los demás con tu trabajo.

Qué decide una licencia de software

Una licencia responde a preguntas muy concretas: ¿puede alguien usar mi código en un proyecto comercial? ¿Puede modificarlo y redistribuirlo? Si lo modifica, ¿está obligado a compartir esos cambios? ¿Tengo que aparecer mencionado como autor original?

Las licencias más comunes, explicadas sin jerga legal

• MIT: la más permisiva y popular. Cualquiera puede usar, modificar y redistribuir tu código, incluso en proyectos comerciales cerrados, con la única condición de mantener el aviso de copyright original. Es la opción por defecto si quieres máxima adopción sin restricciones.

• Apache 2.0: similar a MIT en permisividad, pero añade una protección de patentes explícita: si alguien contribuye código y luego intenta demandar por patentes relacionadas con esa contribución, pierde el derecho a usar la licencia. Habitual en proyectos corporativos grandes.

• GPL 3.0: una licencia de tipo copyleft: si alguien modifica tu código y distribuye el resultado, está obligado a publicar esos cambios bajo la misma licencia GPL. Es la elección correcta si quieres garantizar que las mejoras al proyecto sigan siendo abiertas, aunque las empresas tienden a evitar dependencias con GPL por esta misma obligación.

• BSD (2 y 3 cláusulas): muy similar a MIT en permisividad; la versión de 3 cláusulas añade una restricción sobre usar el nombre del autor original para promocionar productos derivados sin permiso.

• ISC: funcionalmente equivalente a MIT, con un texto legal más corto y simplificado.

Cómo elegir la licencia correcta

• Quieres máxima adopción, incluso en software comercial cerrado: MIT o ISC.
• Quieres máxima adopción pero con protección explícita de patentes: Apache 2.0.
• Quieres que cualquier mejora al proyecto siga siendo open source: GPL 3.0.
• Prefieres el estilo MIT pero con una cláusula extra sobre el uso de tu nombre: BSD de 3 cláusulas.

Cómo generar tu archivo LICENSE

1. Elige la licencia que se ajusta a lo que quieres permitir.
2. Completa tu nombre y el año donde la licencia lo requiera.
3. Descarga o copia el texto generado como archivo LICENSE en la raíz del repositorio.

Puedes hacerlo gratis con el generador de LICENSE de esta web.

Por qué esto no es solo un formalismo

Sin un archivo LICENSE claro, cualquier empresa que quiera reutilizar tu código en un producto comercial no puede hacerlo con seguridad legal, por muy abierto que sea el repositorio en apariencia. Muchas empresas tienen políticas internas que directamente prohíben usar dependencias sin licencia explícita, precisamente por este riesgo. Un LICENSE correcto no es solo buena práctica: es lo que hace tu proyecto realmente utilizable por otros.

Preguntas frecuentes

¿Qué pasa si no pongo ninguna licencia? Por defecto, aplica el copyright estándar: nadie tiene permiso para usar, copiar o modificar tu código sin tu autorización explícita, aunque el repositorio sea público.

¿Puedo cambiar de licencia después? Es complicado si ya hay otros usando o contribuyendo al proyecto bajo la licencia anterior; lo ideal es decidir la licencia correcta desde el principio.

¿MIT y Apache 2.0 son prácticamente lo mismo? Son similares en permisividad, pero Apache 2.0 añade una cláusula específica de protección de patentes que MIT no tiene.

¿GPL me impide ganar dinero con mi proyecto? No, GPL no prohíbe el uso comercial; lo que exige es que las modificaciones distribuidas sigan siendo open source bajo la misma licencia.

Genera el archivo LICENSE correcto para tu proyecto gratis con el generador de LICENSE, con MIT, Apache 2.0, GPL 3.0, BSD e ISC.