Quase todo projeto moderno usa código de outras pessoas: bibliotecas, frameworks, trechos de exemplos. Esse código só pode ser usado de acordo com a licença que o autor escolheu. Ignorar isso pode gerar problemas de direitos autorais, principalmente quando o projeto vira um produto. Entender o básico das licenças mais comuns evita surpresas.
Este conteúdo é informativo e não substitui orientação jurídica. Para projetos comerciais, consulte um advogado especializado.
O que é código aberto, de verdade
Código aberto (open source) não quer dizer apenas que o código pode ser lido. Significa que ele é distribuído sob uma licença que permite usar, estudar, modificar e redistribuir, com certas condições. Quem define essas condições é a licença, e cada uma é diferente.
Código visível mas sem licença, ou sob licença que proíbe uso comercial, não é código aberto no sentido estrito. Por isso, antes de copiar qualquer coisa, procure um arquivo chamado LICENSE ou COPYING no repositório.
Licenças permissivas
Dão muita liberdade e exigem pouco.
MIT
É uma das mais populares e das mais curtas. Permite usar, copiar, modificar, mesclar, publicar, distribuir e até vender, inclusive em software fechado. A condição principal é manter o aviso de copyright e o texto da licença junto com o código. O software é fornecido “como está”, sem garantias.
Apache 2.0
Também permissiva, com algumas diferenças relevantes: inclui uma concessão expressa de patentes (quem contribui autoriza o uso das patentes envolvidas), exige indicar alterações feitas nos arquivos e pede a manutenção de avisos. É muito usada em projetos de empresas.
BSD
Família parecida com a MIT, com variações sobre a exigência de não usar o nome dos autores para promover derivados.
Para a maioria dos projetos pessoais e comerciais, usar bibliotecas com essas licenças é simples: basta preservar os avisos (muitos projetos fazem isso listando as licenças das dependências em uma página).
Licenças copyleft
O copyleft é a ideia de que as liberdades devem se manter nos trabalhos derivados.
GPL
Se você modifica ou incorpora código GPL em um programa e distribui esse programa, ele também precisa ser disponibilizado sob a GPL, com o código-fonte. É a licença usada por projetos como o kernel Linux. Quem quer manter o código próprio fechado deve evitar incorporar código GPL na distribuição do seu software.
LGPL e a LGPD: não confunda
A LGPL é uma versão mais flexível da GPL, pensada para bibliotecas: permite usar a biblioteca em software com outra licença, desde que as alterações na biblioteca em si sejam compartilhadas. Já LGPD é a lei brasileira de proteção de dados, outro assunto, tratado em LGPD para pequenas empresas.
AGPL
Estende a GPL a software usado por rede: se você oferece como serviço na web um programa baseado em código AGPL, pode ser obrigado a disponibilizar o código aos usuários. Exige atenção redobrada em SaaS.
Resumo comparativo em palavras
- MIT: liberdade quase total; mantenha o aviso.
- Apache 2.0: como a MIT, com proteção de patentes e registro de alterações.
- GPL: o derivado distribuído também precisa ser GPL.
- LGPL: foco em bibliotecas; mais flexível que a GPL.
- AGPL: a GPL aplicada também a serviços na rede.
O que conferir ao usar uma biblioteca
- Procure o arquivo de licença no repositório e na página do pacote.
- Verifique as dependências das dependências. Uma biblioteca permissiva pode depender de uma copyleft.
- Mantenha os avisos exigidos (copyright e texto da licença).
- Registre o que você usa, numa lista simples de pacotes e licenças. Isso ajuda quando o projeto cresce, é auditado ou é vendido.
- Cuidado com trechos copiados de fóruns, tutoriais e repositórios sem licença clara.
- Pergunte antes se a licença for incomum ou ambígua.
Ferramentas de gerenciadores de pacotes e serviços de análise listam as licenças das dependências automaticamente em muitos casos, vale buscar uma para a linguagem que você usa.
E o código gerado por IA?
O tema é novo e as regras ainda estão sendo discutidas. O trecho que uma IA devolve pode lembrar código existente com licença própria, e a proteção do que foi gerado varia conforme o país. Boas práticas: não pedir que reproduza código de um projeto específico, revisar o que recebe (veja como revisar código gerado por IA) e seguir a política da empresa, se houver. Para um panorama geral de direitos autorais em tecnologia, leia licenças e direitos autorais em apps.
Erros comuns com licenças
- Achar que público no GitHub é livre: sem licença, não há permissão clara de uso.
- Remover o aviso de copyright de um código MIT ao copiá-lo.
- Misturar código GPL em produto fechado sem perceber a obrigação de liberar o fonte ao distribuir.
- Ignorar as dependências indiretas, que também trazem suas licenças.
Escolhendo a licença do seu projeto
Se você quer publicar seu código:
- Quer que usem à vontade, inclusive em produtos fechados: MIT ou Apache 2.0.
- Quer proteção de patentes e registro de mudanças: Apache 2.0.
- Quer garantir que melhorias continuem abertas: GPL ou AGPL.
- Quer manter privado: não publique e deixe claro que todos os direitos são reservados.
Inclua um arquivo LICENSE na raiz do repositório com o texto completo da licença escolhida. O GitHub oferece um assistente para isso ao criar o repositório. Se o projeto tem fins comerciais ou muitos colaboradores, vale uma consulta a um advogado para definir licença e contribuições.
O resumo prático: antes de usar, leia a licença; antes de publicar, escolha uma. Sem esse cuidado, o que parecia atalho pode virar problema justamente quando o projeto começa a dar certo.