Pode usar código do GitHub no seu produto comercial em 2026?

Está a desenvolver um produto e encontra no GitHub uma peça já pronta: uma biblioteca, um modelo ou um projeto inteiro que faz exatamente aquilo de que precisa. O Claude sugere que o inclua no seu projeto. E depois hesita: o código parece estar disponível publicamente, mas pode mesmo usá-lo, quanto mais vender um produto que o inclua? O autor poderá vir atrás de si mais tarde?

Vou explicar por ordem: porque é que o código aberto no GitHub não constitui, por si só, uma autorização; que licenças permitem usar código e vender um produto; que condições copyleft podem exigir código-fonte correspondente de uma obra abrangida; e como verificar uma licença num minuto antes de usar o código. Sem «depende da situação».

Encontra informações práticas sobre como trabalhar com o Ailoot na documentação.

É verdade que, se o código está no GitHub, pode usá-lo gratuitamente?#

A principal armadilha aqui está na palavra «aberto». Consegue ver o código-fonte e, por isso, parece que, como não estava oculto, tem autorização para o usar. Essa lógica está errada. «Aberto para leitura» e «licenciado para utilização» são coisas diferentes.

Por predefinição, qualquer obra criativa, incluindo código, está protegida por direitos de autor desde o momento em que é criada. Até o autor conceder autorização explicitamente, não pode usá-la. É assim que o GitHub descreve a situação na sua própria página de referência sobre licenças.

A segunda camada é o próprio GitHub. As pessoas pensam que, por terem aceitado as regras do GitHub ao publicar código, também podem usar o código de outras pessoas que lá encontram. As regras dizem exatamente o contrário. Ao tornar um repositório público, o autor permite apenas que outras pessoas o consultem e criem um fork — isto é, uma cópia dentro do próprio GitHub. Isso não autoriza a utilização do código no seu próprio trabalho.

As palavras-chave estão na última frase: «dentro das funcionalidades do GitHub» e «os direitos adicionais decorrem de uma licença». Um fork continua dentro do GitHub. Assim que quiser usar o código no seu próprio produto, quanto mais vendê-lo, precisará de uma licença separada do autor. Sem licença, não há direito — mesmo que o código esteja ali, à vista de todos.

O que determina se pode usar código de outra pessoa?#

Tudo depende de um único ficheiro. Um repositório bem mantido contém um ficheiro de licença — normalmente LICENSE, por vezes LICENSE.md, ou uma menção diretamente no README. Trata-se da autorização do autor, que especifica os termos em que pode usar o código. O GitHub costuma apresentar o nome da licença na barra lateral da página do repositório, antes mesmo de abrir o próprio ficheiro.

Para não se perder na linguagem jurídica, é útil ler a licença através de três perguntas sobre a sua situação:

1. Pode usar este código num produto comercial pelo qual as pessoas pagam?
2. Pode modificar o código de acordo com as suas necessidades?
3. Tem de abrir depois o código-fonte do seu produto, ou pode mantê-lo fechado?

Quase todas as diferenças entre licenças se resumem a respostas diferentes à terceira pergunta. Quanto às duas primeiras, as licenças abertas populares dizem mais frequentemente «sim»: use-o, modifique-o, venda-o. Mas é na questão de a licença o obrigar a abrir o seu próprio código que as pessoas tropeçam. A seguir, vamos percorrer os principais tipos com base nestas três perguntas.

Que licenças permitem usar código e vender um produto?#

Comecemos pelas boas notícias. Para quem está a criar um produto para vender, a melhor opção é um grupo de licenças chamadas permissivas. Há várias, mas três são as mais comuns: MIT, Apache 2.0 e BSD. As três respondem «sim» às duas primeiras perguntas e permitem-lhe manter fechado o seu próprio código-fonte.

A mais comum e simples é a MIT. O seu texto cabe num único parágrafo.

Em termos mais simples, a MIT permite-lhe fazer quase tudo com o código, incluindo vender o produto e manter fechado o seu próprio código-fonte. A única obrigação é incluir o texto da licença e a linha de atribuição. Babel, .NET e Rails, por exemplo, são distribuídos ao abrigo da MIT, por isso, é quase certo que já utilizou código com esta licença.

A Apache 2.0 funciona de forma semelhante, mas acrescenta dois pontos importantes. Primeiro, proteção explícita contra reclamações de patentes: os autores do código prometem não processá-lo por causa de patentes sobre esse código. Segundo, mais alguns requisitos formais de utilização.

A BSD (nas versões com 2 e 3 cláusulas) é, na prática, semelhante à MIT: use-a, modifique-a, venda-a e preserve o aviso de direitos de autor. Reuni as três numa tabela para poder ver as diferenças de relance.

Como interpretar isto na prática: se vir MIT, Apache 2.0 ou BSD no código de outra pessoa, pode ficar descansado: pode usá-lo num produto comercial, modificá-lo e manter fechado o seu próprio código-fonte. Só tem de evitar remover o ficheiro de licença e a atribuição da parte que utilizou.

Como se aplicam as obrigações de código-fonte GPL e AGPL?#

Copyleft mantém a obra abrangida e derivações na mesma licença quando se aplicam as condições. Em GPLv3, distribuir cópias em fonte ou objeto de uma obra abrangida ou derivada combinada exige cumprir licença e código-fonte correspondente. Não se aplica automaticamente a todos os programas independentes do produto ou servidor.

Alojar uma biblioteca GPL no seu servidor sem dar cópias aos utilizadores não exige, por si só, publicar todo o serviço. Distribuir uma aplicação combinada abrangida pode acionar obrigações GPL; verifique integração e licença para decidir o código a fornecer. O cliente entregue ao navegador é uma questão separada de distribuição.

AGPLv3 acrescenta uma condição de rede: se modificar o programa e utilizadores interagirem remotamente com essa versão, tem de oferecer-lhes de forma destacada o código-fonte correspondente. É mais preciso do que afirmar que alojar qualquer componente AGPL abre todo o serviço independente.

Num produto proprietário, examine obra abrangida, combinação de componentes, distribuição de cópias e interação de rede AGPL. Escolha alternativa permissiva compatível ou obtenha autorização separada se não conseguir cumprir. Uso comercial é permitido; importa cumprir a licença e integração concretas.

O que deve fazer se o repositório não tiver qualquer ficheiro de licença?#

Um erro comum é presumir que, se não houver licença, não há restrições e pode usar o código livremente. É o contrário. A ausência de licença não é autorização; por predefinição, significa que não tem autorização. O código sem licença continua protegido pela totalidade dos direitos de autor do autor e não pode mexer nele.

Volta a aplicar-se a regra com que começámos: por predefinição, o código está protegido por direitos de autor e, sem autorização explícita, não pode copiá-lo, modificá-lo ou distribuí-lo. A possibilidade de o consultar e criar forks dentro do GitHub não ultrapassa essa barreira — não lhe concede o direito de usar o código no seu próprio produto.

Na prática, se o código não tiver licença, mas precisar mesmo dele, faça o seguinte:

1. Escreva ao autor. Pergunte diretamente na secção de discussões do repositório ou por e-mail se pode usar o código e em que termos. Por vezes, o autor simplesmente se esqueceu de acrescentar uma licença e acrescenta-a quando alguém lha pede.
2. Procure uma alternativa. Para quase qualquer tarefa, há um segundo, terceiro e décimo repositório semelhante — entre eles, encontrará um com uma licença MIT ou Apache adequada.
3. Não o utilize. Se não tiver autorização e não houver alternativa, o código não lhe pertence e não pode incluí-lo num produto que pretende vender. A tentação de pensar «quem é que vai descobrir?» acaba mal assim que o produto começa a dar dinheiro e a chamar a atenção.

E se o próprio Claude tiver acrescentado código de outra pessoa ao projeto?#

Há aqui uma segunda camada que é fácil confundir com a primeira. Uma coisa é visitar um repositório e copiar um ficheiro: nesse caso, tudo o que foi dito acima sobre a licença é uma obrigação direta sua. Outra coisa é o Claude escrever código em resposta a um pedido seu.

Em situações normais, a IA produz texto próprio, composto para a sua tarefa, em vez de uma cópia do ficheiro de outra pessoa. A questão passa então para outra área: a quem pertence o código gerado e pode vendê-lo? Esse é um tema vasto por si só, que abordei num artigo sobre a quem pertence o código escrito por IA.

Mas há uma exceção a ter em conta. Por vezes, a IA produz uma parte reconhecível do código de outra pessoa quase palavra por palavra — uma função inteira de uma biblioteca conhecida. Nesse caso, a licença da biblioteca continua a aplicar-se, independentemente de quem carregou fisicamente nas teclas. Por isso, os grandes blocos prontos que o Claude integrou na íntegra devem ser verificados como se os tivesse copiado pessoalmente.

Como verificar uma licença antes de usar código: passos a seguir#

Vamos resumir tudo numa breve lista de verificação para analisar qualquer código de terceiros antes de o incluir no seu projeto. Siga os passos pela ordem indicada.

1. Encontre o nome da licença na página do repositório

   Abra o repositório no GitHub. O nome da licença costuma estar visível na coluna da direita ou por baixo da lista de ficheiros — por exemplo, «MIT License», «Apache-2.0» ou «GPL-3.0». Se o campo estiver vazio e não houver ficheiro de licença, isso já é um sinal de alerta; volte a este ponto no último passo.

2. Abra o próprio ficheiro de licença

   Encontre LICENSE, LICENSE.md ou COPYING na lista de ficheiros e abra-o. Confirme que o nome corresponde ao que aparece na barra lateral e que a licença se aplica ao código que está a utilizar, não apenas a uma parte separada do repositório.

3. Identifique o tipo: permissiva ou copyleft

   MIT, Apache 2.0 e BSD são permissivas; pode usar o código num produto comercial fechado. GPL e AGPL são copyleft; verifique obra abrangida, distribuição e condição de rede AGPL para determinar obrigações. O nome não estabelece que componentes independentes ficam abrangidos.

4. Compare-a com a sua situação

   Responda a três perguntas: vai vender o produto, vai modificar o código e quer manter fechado o código-fonte? MIT, Apache e BSD são adequadas a um produto fechado para venda. Para GPL e AGPL, determine que obra abrangida ou combinada exige código-fonte correspondente e quando surge a obrigação; avalie se a consegue cumprir.

5. Sem licença, não use o código

   Se não houver ficheiro de licença e o README nada disser sobre autorização, não pode usar o código. Escreva ao autor e peça autorização ou encontre um equivalente com uma licença adequada. «Está disponível publicamente» não significa que tenha autorização.

Esta verificação parece maçadora até à primeira vez que o seu produto cresce, começa a dar dinheiro e alguém pergunta pelo código de terceiros que inclui. Dois minutos no início custam menos do que lidar com um litígio mais tarde. Abordo separadamente o que fazer com o produto depois disso, para que não fique parado após o lançamento: Criei um produto com IA; e agora?.

Aceder ao Ailoot.