Guía práctica para aplicar una licencia

1. El archivo LICENSE en la raíz del repositorio

Lo primero es colocar el texto de la licencia como archivo LICENSE (o LICENSE.txt, LICENSE.md) en la raíz del repositorio. GitHub, GitLab y los gestores de paquetes buscan este archivo para reconocer la licencia. En el generador puedes elegir la licencia, introducir el año y el titular y descargarlo al momento.

• No modifiques el texto: rellena solo marcadores como [year] y [fullname] de MIT, BSD o ISC y deja el resto tal cual. Si cambias frases, dejará de reconocerse como licencia estándar y pueden surgir problemas de interpretación.
• Las licencias GNU van íntegras: los textos de GPL, LGPL y AGPL no tienen nada que rellenar. El titular y la cláusula de versión se indican con el aviso de cada archivo.

2. Cómo indicar el año y el titular

• Año: lo habitual es poner el año de la primera publicación. También se usan rangos como 2019-2026. No existe obligación legal de actualizarlo cada año.
• Titular: si el código lo escribió una persona, su nombre; si se escribió como parte de un trabajo, normalmente el titular es el empleador (depende del país y del contrato). En proyectos con muchos contribuidores también se escribe algo como The Example Project Authors y se mantiene la lista en un archivo AUTHORS.
• El aviso de copyright no crea el derecho, sino que lo comunica. Aunque no haya aviso, el copyright existe.

3. Archivos complementarios según la licencia

El NOTICE de Apache-2.0 no es obligatorio, pero quien redistribuya código que ya tenga un NOTICE debe conservar su contenido. La ASF recomienda poner en NOTICE solo los avisos de atribución legalmente necesarios, sin agradecimientos ni textos completos de licencias.

4. Cabecera de los archivos fuente

Si cada archivo lleva una cabecera breve, la información de licencia viaja con él aunque se copie por separado.

# SPDX-FileCopyrightText: 2026 Example Inc.
# SPDX-License-Identifier: Apache-2.0

GNU, Apache y MPL también recomiendan su aviso oficial, pero cada vez más proyectos lo sustituyen solo por las dos líneas SPDX. Para más detalles, consulta la guía de SPDX.

5. Metadatos del paquete y README

• Pon el identificador SPDX en el campo license de package.json, Cargo.toml, pyproject.toml, etc.
• Añade al final del README una sección de 'Licencia' con un resumen de una o dos líneas (p. ej., 'This project is licensed under the MIT License — see LICENSE').

6. Avisos de código de terceros

Si distribuyes incluyendo código de otras personas, también debes cumplir las obligaciones de sus licencias.

• En el código copiado, conserva en el archivo correspondiente el aviso de copyright y la licencia originales.
• Si distribuyes binarios o una aplicación, reúne la lista de componentes de código abierto usados y los textos completos de sus licencias en un archivo THIRD_PARTY_NOTICES o en la pantalla de 'licencias de código abierto' de la aplicación.
• Si tienes muchas dependencias, genera la lista automáticamente con herramientas SBOM o con la función de informes de licencias del gestor de paquetes.

7. Al aceptar contribuciones: DCO o CLA

Al aceptar contribuciones externas, el copyright queda repartido entre varias personas. Hay dos formas de gestionarlo.

• DCO: el contribuidor añade Signed-off-by: al commit para confirmar que 'tiene derecho a enviar este código bajo la licencia del proyecto'. Es ligero y lo usa el kernel de Linux.
• CLA: contrato por el que el contribuidor concede al proyecto amplios derechos, incluida la relicencia. Hace falta si vas a ofrecer una licencia dual comercial o quieres dejar margen para cambiar de licencia más adelante.

Las normas de contribución se escriben en CONTRIBUTING.md.

8. Al cambiar de licencia

• El titular puede aplicar otra licencia a las versiones futuras. Los permisos concedidos para las versiones ya distribuidas normalmente no se revocan.
• Si hay código de otros contribuidores, necesitas su consentimiento (salvo que hayas obtenido derechos de relicencia mediante un CLA).
• Pasar de permisiva a copyleft es relativamente fácil (el código permisivo puede entrar en proyectos copyleft), pero pasar de copyleft a permisiva es prácticamente imposible sin el consentimiento de todos los titulares.
• Deja constancia clara en el CHANGELOG y el README de cuándo se cambió, por qué y a partir de qué versión.

Lista de comprobación

1. Texto de LICENSE (solo con los marcadores rellenados)
2. Archivos complementarios (NOTICE, COPYING.LESSER, etc.)
3. Cabeceras de archivo (dos líneas SPDX)
4. Metadatos del paquete y README
5. Avisos de terceros
6. Normas de contribución (DCO o CLA)

Este artículo es información general y no constituye asesoramiento jurídico. Para decisiones importantes, consulta con un profesional.

Fuentes

• GitHub Docs, Adding a license to a repository — https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
• Apache, Applying the Apache License · Assembling LICENSE and NOTICE — https://www.apache.org/legal/apply-license.html
• GNU, How to Use GNU Licenses for Your Own Software — https://www.gnu.org/licenses/gpl-howto.html
• REUSE Specification — https://reuse.software/spec/
• Developer Certificate of Origin — https://developercertificate.org/