Tempo de leitura: 11 min · Publicado em 08/10/2026
Usar software open source não obriga automaticamente a publicar todo o código da empresa. Os exemplos deste artigo abrangem MIT, Apache 2.0, GPLv3 e AGPLv3; outras licenças exigem exame próprio. A resposta depende da licença, da versão utilizada, das modificações e da forma de disponibilização: uso interno, entrega de cópias e acesso remoto são situações diferentes. Antes de lançar um produto ou entregar uma aplicação ao cliente, identifique os componentes e as condições aplicáveis. Código visível na internet, sem licença identificada, não significa autorização irrestrita para copiar ou distribuir.
Identifique a licença da versão que realmente foi usada
Comece pelo componente instalado, sua versão e a origem do arquivo. Preserve o texto da licença, os avisos de autoria e eventuais exceções. O projeto pode ter mudado de licença entre versões ou oferecer modalidades alternativas. A página atual do fornecedor não substitui a conferência das condições que acompanham o material efetivamente incorporado.
Observe dependências diretas e indiretas, componentes incluídos em imagens de distribuição e trechos copiados. Uma lista com apenas o nome da biblioteca principal pode deixar de fora outros termos. O inventário técnico deve dialogar com a análise jurídica, mostrando onde cada componente aparece e como chegará ao destinatário.
Este recorte é diferente da titularidade de código desenvolvido por encomenda. Saber quem detém direitos sobre a parte criada para o cliente não elimina as condições dos componentes de terceiros, nem permite prometer uma exclusividade que a licença não admite.
Licenças permissivas também exigem cumprimento de condições
A licença MIT autoriza usos amplos, mas exige preservação do aviso de direitos autorais e da permissão nas cópias ou porções substanciais. Não é uma obrigação geral de abrir o código próprio apenas porque um componente MIT foi usado. Também não significa que avisos possam ser removidos para apresentar o material como criação integral da empresa.
A Apache License 2.0 possui condições próprias sobre redistribuição, cópia da licença, avisos, identificação de alterações e tratamento de arquivo NOTICE quando existente. Não se deve reduzir seu cumprimento a acrescentar a palavra “Apache” em uma página de créditos. É preciso conferir quais materiais acompanham a entrega e quais requisitos se aplicam.
Essas licenças não autorizam automaticamente usar marcas de terceiros como endosso comercial. Também não resolvem garantia contratual, dados pessoais ou segurança do produto. Licenciamento do código e qualidade do serviço são planos diferentes, que podem exigir documentos e verificações próprios.
Na GPLv3, uso interno e transferência de cópias são distintos
A GPLv3 distingue execução e cópias privadas das formas de disponibilização que permitem a terceiros receber cópias. A mera interação por rede, sem transferência de uma cópia, não é definida como essa disponibilização. Por isso, usar um programa internamente não gera, apenas por esse fato, dever geral de publicar um repositório da empresa.
Quando há entrega de cópias de obra abrangida, devem ser examinadas as condições das seções 4 a 6. A disponibilização de código objeto exige atenção ao código-fonte correspondente e à forma de fornecê-lo. A licença admite alternativas com requisitos específicos; não basta oferecer qualquer arquivo ou uma promessa vaga de entrega futura.
Também importa identificar a obra abrangida. Uma reunião de trabalhos separados e independentes não recebe necessariamente o mesmo tratamento de uma obra combinada sujeita à licença. Nomear um módulo como “separado” não comprova essa independência: arquitetura, integração e natureza do material precisam ser examinadas, sem concluir automaticamente que todo código próprio esteja dentro ou fora do escopo.
AGPLv3 exige uma pergunta adicional sobre interação remota
A seção 13 da AGPLv3 prevê, para versão modificada que comporte interação remota, oferta destacada aos usuários que interagem por rede da oportunidade de receber seu código-fonte correspondente, sem cobrança pelo acesso, pelos meios previstos. Assim, a análise não pode terminar apenas na pergunta sobre entrega de um instalador.
Isso não representa obrigação universal de colocar todo código empresarial em repositório público. É necessário delimitar versão modificada, usuários abrangidos e código correspondente. Um serviço pela internet pode envolver vários componentes e regimes; não se deve atribuir a todos a mesma obrigação só porque uma parte usa AGPL.
Exemplo hipotético: uma empresa modifica um programa AGPLv3 e permite que clientes interajam com essa versão pela rede. A equipe deve avaliar a oferta prevista na seção 13 e seu conteúdo. A ausência de download do executável não afasta, sozinha, essa regra específica, diferente da análise usual de transferência de cópias na GPLv3.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
O que significa fornecer o código-fonte correspondente?
Na GPLv3, a definição envolve o material necessário para gerar, instalar, executar e modificar a obra, com as ressalvas da licença. Isso pode alcançar scripts e elementos pertinentes, não apenas um diretório escolhido por conveniência. Um arquivo com comentários ou uma versão antiga pode não corresponder ao executável entregue.
Associe cada entrega à versão do produto. Preserve a identificação do pacote, os componentes, a licença e a localização do material correspondente. Se houver uma oferta escrita ou acesso por servidor, examine duração, destinatários e condições próprias da modalidade escolhida. Não existe uma fórmula única de link público que cumpra qualquer hipótese de distribuição.
Não inclua segredos de acesso ou dados pessoais para tornar o pacote reproduzível. Organize configuração e documentação de maneira adequada, distinguindo o que precisa acompanhar a obra de credenciais operacionais que não devem ser expostas. A revisão técnica deve testar o material e registrar lacunas, sem usar a proteção de segredos como justificativa genérica para descumprir a licença.
O contrato com o cliente não afasta direitos de terceiros
Um contrato pode estabelecer entrega de código, documentação, manutenção e responsabilidades entre desenvolvedor e cliente. Não pode, por simples declaração, retirar direitos ou condições de uma licença de terceiro. Se o instrumento promete código integralmente exclusivo e depois incorpora componentes com outros regimes, existe uma divergência que deve ser esclarecida antes da entrega.
Identifique o que foi criado no projeto, o que veio de terceiros e quais condições continuam aplicáveis. A Lei 9.609/1998 disciplina direitos sobre programas e contrato de licença. Seu artigo 11 tem recorte específico de transferência de tecnologia; não deve ser usado como obrigação automática de entregar código-fonte em qualquer contratação de software.
A discussão sobre recusa de entrega do código ao fim do contrato examina a obrigação contratual. Ela não substitui a conferência do licenciamento open source, que pode impor condições adicionais ou ter destinatários distintos.
Revise a entrega antes de distribuir ou colocar a versão em serviço
Monte uma relação de componentes, versão, licença, modificações e forma de uso. Acrescente a entrega pretendida: aplicativo, dispositivo, pacote para cliente ou serviço por rede. Para cada linha, identifique avisos necessários, possível fornecimento de código e quem verificará o cumprimento. Uma ferramenta de inventário ajuda, mas não decide sozinha o enquadramento jurídico.
- Confira arquivos de licença e avisos presentes no pacote.
- Identifique alterações feitas em componentes de terceiros.
- Delimite destinatários e modo de disponibilização.
- Verifique a correspondência entre produto e fontes quando exigida.
- Preserve registros da revisão e da versão efetivamente entregue.
Exemplo hipotético: o produto inclui uma biblioteca permissiva e um componente GPLv3 entregue ao cliente. Um aviso único e genérico pode não cumprir os dois regimes. A equipe precisa separar as condições de cada material e avaliar a combinação, sem presumir que a licença mais simples governe todos os arquivos.
Se a entrega já ocorreu, reconstrua a versão antes de corrigir
Preserve o pacote distribuído, o contrato, os avisos e a comunicação com os destinatários. Identifique qual condição pode ter faltado e seu alcance. Não apague arquivos ou altere silenciosamente o histórico para aparentar que a versão anterior já continha o material necessário. Registre a correção e sua relação com a entrega afetada.
A troca de uma biblioteca em versões futuras não resolve automaticamente o que ocorreu nas anteriores. Cessação, correção e possíveis efeitos do descumprimento dependem da licença e dos fatos. Se houver alternativa comercial oferecida por titulares habilitados, confirme seu alcance; comprar outra licença depois não demonstra, sozinho, regularização retroativa.
O registro de software no INPI tem outra finalidade. Registrar material próprio não converte componentes de terceiros em propriedade exclusiva nem comprova cumprimento de todas as licenças usadas.
Perguntas frequentes
Open source obriga a publicar todo código da empresa?
Não automaticamente. Licença, obra abrangida, modificações e forma de disponibilização determinam o exame.
Um repositório visível sem licença permite qualquer uso?
Não. Visibilidade não equivale a autorização irrestrita. Identifique direitos e condições antes de copiar ou distribuir.
MIT dispensa avisos de autoria?
Não. A licença possui condições de preservação dos avisos, embora não imponha abertura geral do código próprio.
GPLv3 sempre exige um repositório público?
Não. A licença define modalidades e condições de fornecimento. Um link público não é a única hipótese nem serve automaticamente para todas.
AGPLv3 e GPLv3 tratam acesso remoto da mesma forma?
Não. A AGPLv3 contém exigência específica para versão modificada com interação remota, conforme sua seção 13.
O artigo 11 da Lei de Software vale para qualquer licença?
Não. Seu recorte é transferência de tecnologia, não todo contrato ou uso de programa.
Na prática, relacione licença, versão e destino do produto
O caminho começa pelo inventário real e termina na conferência da entrega. Separe código próprio, componentes e suas condições, registrando como cada versão será usada. Essa análise evita tanto a abertura indiscriminada quanto a promessa de sigilo absoluto sobre material sujeito a obrigações de disponibilização.
Quando um produto comercial, uma entrega ao cliente ou um contrato relevante envolve vários componentes, a análise jurídica deve transformar o inventário técnico em matriz de obrigações por licença, versão e destinatário. Confronte as promessas contratuais com o pacote entregue, identifique divergências e organize a regularização com a equipe técnica. A revisão não garante ausência de risco nem substitui a verificação de cada obrigação aplicável.
Leia também
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
Fontes oficiais consultadas
- Lei 9.609/1998, arts. 2º, 4º, 9º e 11 — direitos, licença e recorte de transferência de tecnologia.
- MIT — texto da licença, permissão e preservação de avisos.
- Apache License 2.0, seção 4 — condições de redistribuição.
- GNU GPLv3 — texto da licença no catálogo SPDX, seções 0–6.
- GNU AGPLv3 — texto da licença no catálogo SPDX, seção 13: interação remota de versão modificada.
