Guia prático de aplicação de licenças

1. Arquivo LICENSE na raiz do repositório

A primeira coisa a fazer é colocar o texto da licença em um arquivo LICENSE (ou LICENSE.txt, LICENSE.md) na raiz do repositório. GitHub, GitLab e os gerenciadores de pacotes procuram esse arquivo para reconhecer a licença. No gerador, escolha a licença, informe ano e titular e baixe na hora.

• Não altere o texto: preencha apenas marcadores como [year]·[fullname] da MIT, BSD e ISC e deixe o resto das frases como está. Se mudar as frases, a licença não será reconhecida como padrão e podem surgir problemas de interpretação.
• Licenças GNU com o texto integral: os textos de GPL, LGPL e AGPL não têm campos a preencher. O titular e a cláusula de versão são declarados no aviso dos arquivos.

2. Ano e titular

• Ano: o comum é indicar o ano da primeira publicação. Também se usa um intervalo, como 2019-2026. Não há obrigação legal de atualizar todo ano.
• Titular: código escrito por uma pessoa leva o nome dela; código escrito no trabalho geralmente tem o empregador como titular (varia conforme o país e o contrato). Projetos com muitos contribuidores às vezes escrevem The Example Project Authors e mantêm a lista em um arquivo AUTHORS.
• O aviso de copyright não cria o direito, apenas o anuncia. Mesmo sem aviso, o direito autoral existe.

3. Arquivos complementares por licença

O NOTICE da Apache-2.0 não é obrigatório, mas quem redistribui um código que já tem NOTICE precisa manter seu conteúdo. A ASF recomenda colocar no NOTICE apenas os avisos de atribuição exigidos por lei, sem agradecimentos nem o texto integral de licenças.

4. Cabeçalho dos arquivos-fonte

Com um cabeçalho curto em cada arquivo, a informação de licença acompanha o arquivo mesmo quando ele é copiado isoladamente.

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

GNU, Apache e MPL também recomendam avisos oficiais, mas cada vez mais projetos os substituem apenas pelas duas linhas SPDX. Veja detalhes no guia SPDX.

5. Metadados do pacote e README

• Informe o identificador SPDX no campo license de package.json, Cargo.toml, pyproject.toml etc.
• No fim do README, inclua uma seção 'Licença' com um resumo de uma ou duas linhas (por exemplo, 'This project is licensed under the MIT License — see LICENSE').

6. Avisos de código de terceiros

Se você distribui incluindo código de outras pessoas, também precisa cumprir as obrigações dessas licenças.

• No código copiado, mantenha no respectivo arquivo o aviso de copyright e a licença originais.
• Se distribui como binário ou app, reúna a lista do open source usado e o texto integral das licenças em um arquivo THIRD_PARTY_NOTICES ou na tela de 'licenças open source' do app.
• Com muitas dependências, gere a lista automaticamente com ferramentas de SBOM ou com o relatório de licenças do gerenciador de pacotes.

7. Ao receber contribuições: DCO ou CLA

Ao aceitar contribuições externas, os direitos autorais ficam divididos entre várias pessoas. Há duas formas de lidar com isso.

• DCO: o contribuidor inclui Signed-off-by: no commit, confirmando que 'tem o direito de enviar este código sob a licença do projeto'. É leve e usado pelo kernel Linux.
• CLA: contrato pelo qual o contribuidor concede ao projeto amplos direitos, incluindo relicenciamento. É necessário para fazer licença dupla comercial ou para manter a possibilidade de trocar de licença no futuro.

As regras de contribuição ficam no CONTRIBUTING.md.

8. Ao trocar de licença

• O titular pode aplicar outra licença às versões futuras. A permissão já concedida às versões distribuídas normalmente não é revogada.
• Se houver código de outros contribuidores, é preciso o consentimento deles (exceto se o CLA tiver concedido direito de relicenciamento).
• Passar de permissiva para copyleft é relativamente fácil (código permissivo pode entrar em projetos copyleft), mas de copyleft para permissiva é, na prática, impossível sem o consentimento de todos os titulares.
• Registre com clareza no CHANGELOG e no README quando, por que e a partir de qual versão a mudança vale.

Checklist

1. Texto da LICENSE (só os marcadores preenchidos)
2. Arquivos complementares (NOTICE, COPYING.LESSER etc.)
3. Cabeçalhos de arquivo (duas linhas SPDX)
4. Metadados do pacote e README
5. Avisos de terceiros
6. Regras de contribuição (DCO ou CLA)

Este texto é informação geral e não constitui aconselhamento jurídico. Para decisões importantes, consulte um profissional.

Fontes

• 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/