Open source: código disponível não significa ausência de obrigações

Usar software open source não significa usar software “sem dono” ou “sem regra”. O código pode estar publicamente acessível e, ainda assim, o direito de copiar, modificar, redistribuir ou incorporar aquele componente depender de uma licença específica. A primeira pergunta, portanto, não é se o repositório é aberto: é qual licença rege aquela versão e o que o produto pretende fazer com ela.

Licenças abertas distribuem permissões e obrigações diferentes

A Lei de Software protege programas de computador e admite sua utilização por meio de contratos de licença. No ecossistema open source, a própria licença define as condições de uso. A Open Source Initiative mantém a relação de licenças aprovadas conforme a Open Source Definition, mas elas não são intercambiáveis.

Licenças permissivas, como MIT, BSD e Apache, em geral oferecem ampla liberdade com obrigações relativamente enxutas. Licenças copyleft podem impor condições relevantes à redistribuição, especialmente quando modificações ou obras derivadas são entregues a terceiros. O efeito concreto depende da licença, da arquitetura e da forma de distribuição.

O risco aparece na combinação, não apenas no componente isolado

Uma aplicação costuma reunir dezenas ou centenas de dependências. O problema jurídico raramente é “há open source?”; é saber quais componentes existem, sob quais versões e licenças, onde foram incorporados e como o produto é distribuído. Dependência transitiva esquecida pode carregar obrigação que ninguém avaliou.

Por isso, inventário de componentes, arquivo de licenças, política de aprovação e revisão automatizada fazem parte da governança. Se uma biblioteca crítica muda de licença entre versões, atualizar sem revisão pode alterar a posição jurídica do produto sem qualquer mudança perceptível ao usuário.

Compatibilidade precisa ser revisada antes da distribuição

Duas bibliotecas podem ser individualmente utilizáveis e, ainda assim, criar dúvidas quando combinadas sob formas de distribuição incompatíveis. O mesmo vale para código modificado internamente e depois incorporado a produto entregue a clientes. Antes de release relevante, vale registrar a licença de cada dependência material, a justificativa de compatibilidade e as obrigações de atribuição, disponibilização de texto de licença ou código correspondente quando aplicáveis.

Essa revisão fica especialmente importante em aquisições e investimentos: um comprador pode pedir o SBOM ou inventário de dependências para entender se o ativo vendido contém obrigações que limitam sua exploração. Descobrir isso na due diligence costuma ser mais caro do que manter o inventário desde o desenvolvimento.

Código aberto também precisa conversar com contrato e titularidade

O contrato com desenvolvedores deve separar criação própria, ferramentas preexistentes e componentes de terceiros. Declarar que “todo o código é exclusivo” quando o projeto incorpora bibliotecas abertas cria uma promessa impossível. No extremo oposto, dizer apenas que “pode haver open source” não informa quais obrigações chegam ao cliente.

Antes de distribuir, vender ou licenciar o produto, conecte o inventário de dependências à titularidade do código próprio e à licença de software oferecida ao usuário. O objetivo não é eliminar open source, mas utilizá-lo sabendo exatamente o que entrou no produto e quais condições vieram junto.