Gerador de Licença

Próximo

Enviar um projeto sem um arquivo LICENSE significa tecnicamente “todos os direitos reservados”, ninguém pode reutilizar o código. Este gerador produz o texto completo e não modificado das licenças de código aberto mais populares, com seu nome e o ano atual substituídos no cabeçalho de copyright. Cole-o em um arquivo LICENSE na raiz do seu repositório e faça o push.

Como escolher e gerar uma licença

  1. 1

    Escolha uma licença

    MIT para permissiva, Apache-2.0 para permissiva + concessão de patente, GPLv3 para copyleft.

  2. 2

    Insira seu nome e ano

    O titular dos direitos autorais, seu nome legal ou o nome da sua empresa. O ano é o primeiro ano de lançamento.

  3. 3

    Revise o texto completo

    O texto da licença permanece exatamente como a OSI / FSF publica; apenas a linha de copyright muda.

  4. 4

    Coloque no LICENSE

    Salve na raiz do seu repositório. O GitHub detecta e exibe na barra lateral.

Escolhendo entre as opções populares

Não existe uma licença de código aberto “melhor” universalmente. A escolha depende do que você deseja que os usuários downstream possam, e não possam, fazer.

Licença Tipo Concessão de patente Copyleft? Usuários notáveis
MIT Permissiva Implícita Não Rails, pacotes Node, jQuery
Apache-2.0 Permissiva Explícita Não Kubernetes, Android AOSP
BSD-3-Clause Permissiva Não Não Biblioteca padrão Go, Nginx
GPL-3.0 Copyleft forte Sim Sim GCC, Bash, GIMP
LGPL-3.0 Copyleft fraco Sim Parcial glibc, Qt (historicamente)
MPL-2.0 Copyleft fraco Sim Parcial Firefox, Thunderbird
AGPL-3.0 Copyleft de rede Sim Sim MongoDB (pré-2018), Grafana
Unlicense / CC0 Dedicação ao domínio público - Não Pequenas bibliotecas utilitárias

As três perguntas práticas

  1. Você quer forks de código fechado? Permissiva (MIT, Apache, BSD) → sim. Copyleft (GPL, AGPL) → não.

  2. Você se preocupa com retaliação de patentes? Apache-2.0, GPLv3 e MPL-2.0 têm concessões de patente explícitas que terminam em litígios. MIT e BSD-2/3 não têm.

  3. Seu código roda como um serviço de rede? AGPL-3.0 fecha a “brecha do SaaS”, usuários do serviço contam como distribuição. Se isso importa, escolha-a; caso contrário, GPLv3 é mais simples.

Erros comuns a evitar

  • Não edite o texto da licença. Uma licença “MIT-com-minhas-emendas” é uma nova licença incompatível. Os tribunais rejeitam modificações ad-hoc.
  • Não use duas licenças sem entender a compatibilidade. Apache-2.0 e GPLv2 não são compatíveis; Apache-2.0 e GPLv3 são.
  • Não esqueça o identificador SPDX nos cabeçalhos de origem: SPDX-License-Identifier: MIT na linha 1 ajuda as ferramentas a detectar sua escolha.
  • Não use “Creative Commons” para software. Licenças CC são para obras criativas; use-as em documentação e imagens, não em código.

Licenciamento dual

Alguns projetos são enviados sob duas licenças, tipicamente uma copyleft, uma comercial, para que empresas possam comprar a saída dos termos copyleft. Qt e MySQL fazem isso notoriamente. É legalmente complexo; se você não está monetizando o projeto, fique com uma única licença aprovada pela OSI.

Perguntas frequentes

MIT é a mais popular como padrão para pequenos projetos de código aberto: curta, permissiva, amplamente compreendida e compatível com praticamente todas as outras licenças. Apache-2.0 é uma escolha um pouco mais segura se seu projeto tiver alguma novidade patenteável.

Sim. Sem um, seu código é totalmente protegido por direitos autorais e ninguém pode reutilizá-lo legalmente, o acesso público do GitHub não é uma licença. Adicione um arquivo LICENSE no mesmo dia em que tornar o repositório público.

O primeiro ano de lançamento (um único ano) ou um intervalo que termina no ano atual (por exemplo, “2019-2026”). Atualizar o ano todo janeiro é uma cortesia, não uma exigência legal na maioria das jurisdições.

Não, a substituição acontece no seu navegador e seu nome, ano e escolha de licença nunca são enviados para nós.

Ferramentas relacionadas

Ferramenta disponível em outros idiomas