Software livre não é sobre preço
A primeira coisa que as pessoas entendem errado quando perguntam o que é software livre é que se trata de software gratuito. A palavra livre vem do inglês "free" com o sentido de liberdade, não de valor zero. Isso cria confusão por causa da tradução e do marketing dos primeiros anos do movimento, mas é uma distinção prática importante porque define o que você pode ou não fazer com o programa. Software livre é aquele que concede quatro liberdades essenciais definidas pela Free Software Foundation: rodar o programa para qualquer propósito, estudar como ele funciona e adaptá-lo, redistribuir cópias, e distribuir versões modificadas. Essas liberdades só existem quando o código-fonte está acessível. Sem código-fonte, você não tem liberdade real, só uma licença bonitinha que não garante nada.
O que é software livre na prática técnica
Na prática, o que importa é a licença. Não basta o programa estar disponível no repositório do GitHub. Você precisa olhar qual licença específica está aplicando. Uma licença GPL v3, por exemplo, obriga que modificações também sejam distribuídas sob a mesma licença. Uma licença MIT ou BSD é muito mais permissiva e permite que você use o código em projetos proprietários sem compartilhar suas alterações. Isso muda completamente o que você pode fazer. Eu já vi times inteiros de engenharia terem problemas jurídicos sérios porque assumiram que todo código aberto era igualmente livre para uso comercial. Um projeto que parecia inofensivo tinha uma licença AGPL, que estende as obrigações da GPL para software usado via rede. Se você executar esse software como serviço, precisa liberar todo o código modificado para os usuários que interagem com ele pela rede. Isso pegou um time meu em 2022 desprevenido.
O problema específico foi o seguinte: estávamos usando uma biblioteca de renderização gráfica licenciada sob GPL v3 dentro de um pipeline de processamento de dados que rodevamos como um serviço interno. A gente tinha modificado partes dela para lidar com formatos de arquivo proprietários que o cliente exigia. Quando perguntaram os termos da licença para uma auditoria, percebemos que as modificações precisavam ser liberadas. A solução foi refatorar o código modificado para ficar em um módulo separado, vinculado por uma interface limpa, mantendo a biblioteca original intacta e não modificada. O custo foi cerca de duas semanas de desenvolvimento para o refatoramento, mas evitou uma violação de licença que poderia ter significado processos e perda de contratos. Um ponto que poucos iniciantes consideram: software livre não significa software auditado. A disponibilidade do código-fonte não garante segurança. Projetos como o Heartbleed no OpenSSL mostraram isso de forma brutal em 2014 — o código estava aberto para qualquer um verificar, mas a vulnerabilidade permaneceu anos porque ninguém a encontrou. O modelo de muitos olhos é uma vantagem potencial, não uma garantia. O que acontece na realidade é que projetos populares recebem mais olhares, mas projetos menos conhecidos, mesmo sendo livres, podem ter bugs críticos escondidos por anos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outra nuance técnica importante é a questão da distribuição. Para que uma licença seja considerada livre de verdade, o código-fonte precisa estar disponível no mesmo momento em que o binário é distribuído. Uma licença que diz "o código-fonte está disponível mediante solicitação" não atende esse requisito. A GPL exige que a oferta de código-fonte acompanhe a distribuição do binário, ou que você inclua uma written offer válida por pelo menos três anos. Isso é algo que revisores de compliance costumam perder. Se você quer começar a trabalhar com software livre no dia a dia, o primeiro passo prático é parar de tratar todas as licenças abertas como iguais. Aprenda a ler os textos das licenças, não apenas os resumos. A diferença entre MPL 2.0, LGPL, GPL v2, GPL v3, Apache 2.0 e MIT não é sutileza acadêmica — é a diferença entre poder usar um componente em um produto fechado e ter que abrir todo o seu código. Uma planilha simples comparando essas seis licenças em termos de obrigação de compartilhamento, patentes e uso em SaaS resolve a maior parte dos problemas que vejo em times iniciantes.
O ecossistema também tem um problema estrutural que raramente é mencionado: a sustentabilidade dos projetos. Software livre depende de voluntários, e a maioria dos projetos úteis é mantida por uma ou duas pessoas. Quando essas pessoas param, o projeto morre ou é forkado. O Linux é uma exceção porque tem apoio corporativo massivo, mas a maioria das bibliotecas e ferramentas que dependemos diariamente não tem esse nível de suporte. Projetos como o Ansible, que migrou de GPLv3 para uma licença mais permissiva em 2023, mostram como essa tensão entre liberdade e sustentabilidade econômica é real e constante. Para baixar e começar a usar, os repositórios mais confiáveis são o GNOME Packages, o Debian Packages, o Arch User Repository se você usa Arch, e o PyPI para pacotes Python. No Linux, o gerenciador da sua distribuição já resolve a maior parte das necessidades. Em Windows, o Chocolatey e o Scoop são as opções mais diretas. Em macOS, o Homebrew. Nenhum desses exige configuração complexa — a barreira principal é saber qual pacote corresponde à ferramenta que você procura.
O que eu diria para quem está entrando nessa área agora é que o conhecimento mais útil não é decorar licenças, mas desenvolver o hábito de verificar duas coisas antes de integrar qualquer dependência: qual é a licença exata e qual é o histórico de manutenção do projeto. Se um projeto não recebe commits há dois anos e não tem issues respondidas, você está construindo sobre algo que pode desaparecer. Isso vale tanto para software livre quanto para software proprietário, mas no mundo livre a responsabilidade de vigilância é ainda mais individual porque não há vendor para cobrar quando as coisas quebram.
