O que é software open source

Você usa Linux, Firefox, VS Code e Git todos os dias sem pagar nada. Aí alguém te explica que tudo isso é "open source" e você assume que open source significa gratuito. Faz sentido — só que não é exatamente isso, e a diferença importa bastante quando você começa a trabalhar profissionalmente com software.

O que open source realmente significa

Open source é sobre acesso ao código-fonte, não sobre preço.

Um software é considerado open source quando o código-fonte está disponível publicamente e você tem permissão legal para ler, modificar e redistribuir. A Open Source Initiative (OSI) mantém uma lista de licenças que qualificam como open source — hoje são mais de 80 licenças aprovadas.

O que define se um software é open source não é o preço cobrado por ele, mas os termos da licença. Um software pode ser open source e custar dinheiro. Um software pode ser gratuito e não ser open source (o Windows é gratuito para download em muitos cenários — você não pode ver o código-fonte).

O conceito foi formalizado em 1998 com a criação da OSI, mas vem de antes. O movimento de software livre liderado por Richard Stallman nos anos 80 e o projeto GNU já defendiam acesso ao código com bases filosóficas mais radicais. Open source surgiu como uma versão mais pragmática do mesmo princípio — focada em benefícios práticos de desenvolvimento, não em liberdade como valor moral.

As principais licenças (e o que cada uma permite)

Licença de open source não é detalhe burocrático — define o que você pode ou não fazer com o código.

MIT

A mais simples e permissiva. Você pode usar, copiar, modificar, distribuir, sublicenciar e vender sem restrições, desde que inclua a nota de copyright original. React, jQuery, Rails e centenas de outras bibliotecas populares usam MIT.

Copyright (c) 2024 Author Name

Permission is hereby granted, free of charge, to any person obtaining a copy...

Praticamente qualquer coisa é permitida. Não há obrigação de publicar seu código modificado.

Apache 2.0

Mais detalhada que MIT. Adiciona proteção explícita contra litígios de patente — quem contribui com código concede automaticamente uma licença de patente para o projeto. Kubernetes, Android (parcialmente) e muitos projetos da Apache Foundation usam essa licença.

A diferença prática em relação à MIT é principalmente a cláusula de patente. Para uso comum, o comportamento é semelhante.

GPL (e suas variantes)

A GPL (GNU General Public License) é a licença copyleft mais conhecida. Copyleft significa que qualquer software que incorpore código GPL precisa ser distribuído com o mesmo código-fonte e sob a mesma licença. A liberdade "contamina" o trabalho derivado.

Isso tem implicações sérias para software comercial: se você inclui código GPL num produto fechado que distribui para clientes, você é obrigado a distribuir o código-fonte desse produto. O Linux usa GPL v2. Git usa GPL v2.

Variantes importantes:

• LGPL (Lesser GPL): versão mais branda — você pode usar a biblioteca num software proprietário desde que não modifique a própria biblioteca
• AGPL (Affero GPL): estende a obrigação ao uso em rede — mesmo sem "distribuir" o software (como um SaaS), você precisa disponibilizar o código

BSD

Família de licenças permissivas, similar à MIT. A BSD 2-Clause é praticamente equivalente à MIT. A BSD 3-Clause adiciona uma restrição: você não pode usar o nome do projeto para endorsar seus produtos derivados sem permissão.

PostgreSQL usa a licença PostgreSQL License, que é BSD-style.

Open source não é sinônimo de gratuito

Esse mito vale repetir com exemplos concretos:

MongoDB era open source (AGPL) e cobrava por suporte enterprise. Em 2018, mudou para SSPL — uma licença criada pela própria empresa, não aprovada pela OSI, que exige que quem oferece MongoDB como serviço também publique o código da infraestrutura inteira. AWS continuou oferecendo MongoDB como serviço sem publicar o código → MongoDB criou a licença nova justamente para forçar a questão.

Red Hat Enterprise Linux (RHEL) é construído sobre código GPL (Linux, etc.). O código é open source. O produto — com suporte, certificações, garantias — custa dinheiro. Você pode baixar o código-fonte e compilar você mesmo (é o que o CentOS fazia, e depois o Rocky Linux e AlmaLinux fazem hoje). Mas o produto empacotado com suporte tem preço.

GitLab tem uma versão Community Edition (MIT) e uma Enterprise Edition paga com funcionalidades extras. Mesmo modelo que muitos projetos adotam: core open source, extensões proprietárias.

HashiCorp (Terraform, Vault, Consul) em 2023 migrou de MPL 2.0 para BSL (Business Source License) — que não é open source pela definição da OSI. Competidores que monetizavam Terraform como serviço geraram o fork OpenTofu.

O padrão se repete: a empresa usa open source para crescer e construir comunidade, depois fecha o que precisa proteger da competição das clouds.

Como open source se sustenta financeiramente

Se você pode usar de graça, como o projeto paga as contas?

Dual licensing: oferecem licença permissiva para uso pessoal e open source, e uma licença comercial para empresas. MySQL faz isso (GPL para open source, licença comercial para software proprietário).

Open core: core da aplicação é open source, funcionalidades enterprise são proprietárias. GitLab, Metabase, Sentry seguem esse modelo.

Suporte e serviços: vende o produto como SaaS ou vende suporte, consultoria e treinamento. Red Hat foi o caso clássico durante décadas.

Doações e fundações: projetos como Linux, Python, Apache e Rust contam com fundações sem fins lucrativos que recebem patrocínio corporativo. As empresas patrocinam porque dependem do software.

Contratação de contribuidores: grandes empresas (Google, Meta, Microsoft, Stripe) pagam engenheiros para contribuir com projetos open source dos quais dependem — React, Go, TypeScript, V8, etc. O código é open source, mas o trabalho é remunerado.

Contribuindo com projetos open source

A mecânica básica de contribuição é padrão na maioria dos projetos hospedados no GitHub ou GitLab:

# 1. Fork o repositório para sua conta
# 2. Clone o fork localmente
git clone https://github.com/seu-usuario/nome-do-projeto.git

# 3. Crie uma branch para sua mudança
git checkout -b fix/typo-in-readme

# 4. Faça a mudança, commit e push para o seu fork
git commit -m "fix: typo in contributing guide"
git push origin fix/typo-in-readme

# 5. Abra um Pull Request no repositório original

Antes de contribuir com algo substancial, verifique:

• O arquivo CONTRIBUTING.md — a maioria dos projetos tem instruções específicas
• As issues abertas — pode já existir uma discussão sobre o problema
• O código de conduta do projeto
• Se a licença é compatível com o que você quer fazer

Contribuição não precisa ser código. Documentação, tradução, testes, triagem de issues — tudo conta e é geralmente mais fácil de começar.

Perguntas frequentes

Posso usar código MIT num projeto comercial fechado?

Sim. Licença MIT permite uso em software proprietário sem obrigação de abrir o código. Você precisa incluir o aviso de copyright original no seu produto, mas pode fechar o restante. Verifique sempre a licença específica — alguns projetos combinam múltiplas licenças para partes diferentes.

O que acontece se eu usar código GPL sem seguir a licença?

Violação de licença GPL é uma questão legal real. A Software Freedom Conservancy e a FSF já processaram empresas por isso. Em casos típicos, a empresa é notificada e tem a opção de corrigir a situação (publicar o código ou remover o componente). Ignorar pode resultar em processo judicial e perda do direito de distribuir o produto.

"Source available" é a mesma coisa que open source?

Não. Source available significa que você pode ver o código-fonte, mas a licença pode restringir o que você faz com ele. BSL (Business Source License) e SSPL são exemplos: o código está visível, mas uso comercial pode ser restrito. A OSI não aprova essas licenças como open source.

Forks são sempre legais?

Depende da licença. Com MIT, Apache ou BSD, fork é livre — você pode pegar o código e criar seu próprio projeto. Com GPL, você pode fazer fork, mas precisa manter a GPL. Com licenças proprietárias ou source-available restritivas, fork pode ser proibido contratualmente.

Licença é o detalhe que ninguém lê até precisar

Open source resolve um problema real de desenvolvimento — você não precisa reinventar a roda para cada projeto, e o código foi revisado por muitas pessoas. Mas a licença não é detalhe secundário: define o que você pode construir em cima, se pode fechar o código, e o que acontece se você mudar de ideia depois.

Para projetos pessoais e experimentos, MIT ou Apache são escolhas seguras e amplamente aceitas. Para software que você vai distribuir ou vender, vale dez minutos lendo a licença antes de adicionar uma dependência — especialmente se ela for GPL ou AGPL.

Nota: o conteúdo editorial acabou aqui. O que vem abaixo é uma indicação de ferramenta relacionada ao tema do post.

Ferramenta relacionada

Se você está montando um repositório open source, um dos primeiros arquivos que vai precisar é um robots.txt caso o projeto tenha uma página web associada. Para gerar e validar o robots.txt com controle granular de bots, uso o Gerador de robots.txt — especialmente útil para projetos que querem controlar o que crawlers de AI indexam.