Open source no produto da empresa: licenças e obrigações

Nenhum time de desenvolvimento começa do zero. Framework de interface, biblioteca de validação, conector de banco de dados, gerador de relatório, ferramenta de build e trechos de exemplo copiados de repositório público entram no código antes de o produto existir comercialmente. Cada um desses componentes vem acompanhado de uma licença, e licença de software funciona como contrato: define o que pode ser feito, o que precisa ser mantido e o que precisa ser entregue junto com o que for distribuído.

A escolha do componente costuma seguir critério técnico, como maturidade, documentação, comunidade ativa e frequência de correções. A consequência dessa escolha, no entanto, recai sobre a empresa que coloca o produto no mercado. Quem incorpora código de terceiro ao próprio software assume as condições daquele licenciamento perante o titular do direito autoral, independentemente de quem selecionou a biblioteca ou de o time saber que havia condições a cumprir.

O primeiro passo para organizar o tema é separar uso interno de distribuição. Serviço que roda apenas nos servidores da empresa e é acessado por navegador tem tratamento diferente de aplicativo instalado no computador do cliente, e diferente ainda de biblioteca entregue dentro de outro sistema. Boa parte da confusão sobre open source nasce de aplicar a mesma régua a situações que a licença trata de formas distintas. A pergunta que abre a análise é simples: o componente chega às mãos de terceiro, e de que forma?

As licenças abertas se organizam em dois grupos que a prática conhece bem. O grupo permissivo, representado por licenças como MIT, BSD e Apache 2.0, permite uso comercial, modificação e redistribuição com poucas condições, em geral a manutenção do aviso de copyright, a inclusão do texto da licença e, no caso da Apache 2.0, tratamento expresso de patentes e indicação de alterações feitas nos arquivos. É o grupo mais usado em bibliotecas de propósito geral, porque oferece pouca fricção jurídica.

O grupo com copyleft, que inclui GPL, LGPL, AGPL e MPL, impõe condições sobre a obra derivada. A lógica é usar o direito autoral para garantir que o software e suas derivações continuem sob as mesmas liberdades. Na prática, isso significa que a forma de incorporação passa a importar: usar o componente como biblioteca separada, com chamada entre processos distintos, não produz os mesmos efeitos de incorporar o código ao próprio arquivo e compilar tudo junto. LGPL e MPL trazem graus intermediários, com obrigações que recaem sobre o próprio componente modificado e não sobre todo o produto.

Existem ainda licenças que circulam em repositórios públicos sem serem reconhecidas como abertas, com cláusulas de uso restrito, limitação a uso não comercial ou exigência de autorização por tipo de usuário. O efeito para a empresa é diferente: a restrição não se resolve com atribuição, ela pode simplesmente impedir o uso pretendido. Encontrar esse tipo de licença no inventário não é falha grave por si, é sinal de que a triagem precisa existir antes da incorporação, e não depois da entrega.

O copyleft preocupa porque sua consequência não é documental, é estrutural. Quando um componente sob GPL é incorporado ao produto distribuído, a licença pode alcançar o conjunto e exigir que o código correspondente seja oferecido a quem recebeu o software, sob a mesma licença. Cumprir isso depois do lançamento pode significar rever o que a empresa considera ativo estratégico, o que é discussão de negócio e não apenas de conformidade. Por isso a recomendação prática é decidir sobre copyleft antes de o componente virar parte do núcleo do produto.

A AGPL leva a lógica um passo adiante ao tratar o uso em rede como gatilho. A ideia é evitar que alguém modifique o software e o ofereça como serviço sem devolver as alterações à comunidade. Para quem opera plataforma acessada por navegador, esse detalhe muda a análise: a entrega deixa de ser o arquivo instalado e passa a ser o serviço disponibilizado. Empresas que tratam todo software interno como uso privado costumam ser surpreendidas justamente nesse ponto.

Há também a situação intermediária, que é a mais comum em produto comercial. O time isola o componente copyleft em serviço separado, com comunicação por rede, e presume que a questão está resolvida. Essa separação pode ser adequada, mas depende de como a licença descreve obra derivada e de como a arquitetura realmente funciona, incluindo bibliotecas compartilhadas, vinculação estática e código gerado. A conclusão sobre isolamento precisa nascer da leitura da licença combinada com a arquitetura real, e ficar registrada com data e responsável.

A forma mais rápida de explicar o tema para um time que não é jurídico é por cenário. O mesmo componente pode gerar obrigações diferentes conforme esteja embarcado no aplicativo, exposto como serviço, usado em ferramenta interna ou entregue como parte de um produto licenciado a cliente corporativo. Trocar o cenário sem trocar a licença muda o que a empresa precisa fazer, e é por isso que a triagem começa pela arquitetura e pela forma de entrega.

A tabela abaixo organiza cenários comuns e o que cada um costuma exigir. O quadro não substitui a leitura da licença específica, porque versões diferentes da mesma família têm regras próprias e texto próprio, mas serve para orientar a primeira conversa entre desenvolvimento, produto e jurídico sobre onde colocar esforço de verificação.

Ferramentas de análise de composição de software leem manifestos de dependências, arquivos de bloqueio de versão e metadados de pacote, e produzem uma lista de componentes com a licença declarada. Essa lista é o ponto de partida, não a conclusão. Metadata de pacote pode estar incompleta ou incorreta, componentes podem trazer licenças duplicadas ou arquivos com licenças diferentes dentro do mesmo diretório, e trechos copiados manualmente não aparecem em manifesto algum. Auditoria útil cruza três fontes: inventário automatizado, repositório de código e arquivos de licença efetivamente presentes.

O inventário precisa de recorte por produto, porque a obrigação depende da forma de distribuição de cada um. Misturar tudo em uma planilha única costuma produzir ruído: a biblioteca usada apenas em script interno aparece na mesma lista do componente embarcado no aplicativo vendido, e o time perde tempo analisando o que não gera obrigação. Separar por produto, por canal de entrega e por versão analisada torna o resultado utilizável e permite comparar auditorias ao longo do tempo.

Vale ainda registrar decisões, e não apenas achados. Quando o time decide manter um componente copyleft porque ele está isolado em serviço separado, essa conclusão precisa ficar escrita com a justificativa técnica e a data. Auditoria seguinte que encontra o mesmo componente sem contexto reabre a discussão do zero. O registro transforma verificação pontual em histórico, e histórico é o que sustenta a posição da empresa se a titularidade do componente for questionada mais adiante.

Boa parte do código de terceiro chega pela mão de fornecedor. Empresa contratada para desenvolver módulo, agência que entrega integração, freelancer que escreve serviço inteiro: todos podem incorporar componentes abertos sem informar. O contrato de desenvolvimento precisa tratar disso de forma explícita, com declaração de que o código entregue está devidamente licenciado, obrigação de informar componentes com copyleft e responsabilidade por reclamação de titular de direito autoral. Uma coisa é definir quem é dono do que foi criado, outra é a licença do componente aberto que entrou no meio: um contrato pode ceder todo o código à contratante e o produto continuar sujeito a GPL por causa de uma biblioteca embarcada, distinção tratada no texto sobre quem é dono do código, licença e escrow.

Do lado interno, o modo mais eficiente de reduzir risco não é auditar mais, é decidir antes. Uma política simples de licenciamento define quais licenças podem ser usadas sem consulta, quais exigem avaliação e quais dependem de autorização específica, com verificação automática no fluxo de desenvolvimento que bloqueia dependência não aprovada. A política também precisa indicar caminho de exceção, porque proibição sem alternativa costuma ser contornada: quando o time encontra componente sob copyleft que resolve problema real, deve existir fluxo para avaliar isolamento, testar substituição por alternativa permissiva ou negociar licença comercial com o titular.

Depois da entrega, restam obrigações que acompanham o produto enquanto ele circular. Manter arquivo de avisos atualizado, incluir texto de licenças no pacote, oferecer o código correspondente quando a licença exigir e preservar avisos em cada versão distribuída são tarefas contínuas, não etapas de lançamento. Quando o produto depende de API de terceiro que também impõe condições de uso, a análise se acumula, e o limite de responsabilidade nessas integrações é discutido em integração com API de terceiro e limite de responsabilidade.