Você pode usar este aplicativo auto-hospedado na sua empresa? Um checklist de diligência sobre licenças de código aberto
A auto-hospedagem pode mudar a forma como um aplicativo é operado, mas não responde, por si só, a questões de licenciamento, redistribuição, marcas ou divulgação do código-fonte. Use este checklist prático para reunir evidências, definir o uso pretendido e saber quando buscar aconselhamento jurídico qualificado.
A auto-hospedagem não responde a todas as questões de licenciamento
“Código aberto” não é um único nível de permissão, e o acesso a um repositório público de código-fonte não basta para determinar se uma empresa pode usar, modificar, hospedar, aplicar marca ou redistribuir um aplicativo da forma pretendida. A Open Source Initiative (OSI) faz essa distinção diretamente: código aberto diz respeito aos termos de distribuição, bem como ao acesso ao código-fonte.
Se um aplicativo estiver de fato sob uma licença de código aberto em conformidade com a OSI, essa licença não pode restringir o uso em um campo de atuação específico, incluindo o uso empresarial. Isso é útil, mas não encerra a análise. Sua implantação pode incluir componentes, ativos ou plugins licenciados separadamente; sua atividade planejada pode envolver distribuição; e nomes, logotipos e domínios podem ser regidos por regras de marcas, e não pela licença do software.
Considere este artigo como uma estrutura operacional de diligência, e não como aconselhamento jurídico. O objetivo é substituir suposições por um registro verificável e identificar as situações que justificam aconselhamento jurídico qualificado antes da implantação.
- Não equipare “código-fonte disponível” a “código aberto”.
- Não equipare hospedagem interna à permissão para redistribuir cópias a clientes ou consumidores.
- Não presuma que uma licença na raiz do repositório abrange todos os itens da implantação.
- Analise regras de marcas e nomenclatura separadamente dos termos da licença de software.
Comece pelo uso pretendido, não pela lista de recursos do aplicativo
Antes de ler o texto da licença, descreva o que sua organização realmente fará. As questões de licença ficam mais claras quando vinculadas a um modelo concreto de implantação e distribuição, em vez de a um desejo genérico de “usar o software comercialmente”.
Uma ferramenta usada somente por seus próprios funcionários apresenta um cenário factual diferente de um serviço voltado ao cliente, uma implantação personalizada para um cliente ou um produto que incorpora o aplicativo para redistribuição. A mesma distinção é importante se você pretende fornecer uma imagem Docker, um instalador, uma árvore de código-fonte modificada ou uma instância gerenciada a outra pessoa.
Torne essa declaração suficientemente específica para que um colega possa compará-la com a licença. Se o uso pretendido mudar mais tarde, reabra a análise em vez de confiar na conclusão anterior.
- Ferramenta interna: Quem pode acessá-la e a equipe irá modificá-la?
- Serviço voltado ao cliente: Usuários externos interagirão remotamente com o aplicativo?
- Implantação para cliente: Você está entregando uma cópia, uma imagem, código-fonte ou uma compilação modificada?
- Produto redistribuído: Você está incorporando o aplicativo ou componentes substanciais à sua própria oferta?
- Marca: Você usará o nome do projeto, o logotipo ou um nome semelhante em um produto, serviço ou domínio?
- Integração: Quais plugins, bibliotecas, modelos, fontes, temas, conectores e ativos serão incluídos?
Encontre evidências de licença autoritativas e fixe a versão analisada
Comece com evidências primárias para a versão exata do aplicativo que você pretende implantar. O arquivo LICENSE de um repositório é um ponto de partida importante, mas deve ser verificado junto com a distribuição do código-fonte, a documentação do fornecedor ou projeto, os avisos de direitos autorais e qualquer material LICENSE ou NOTICE incluído.
Registre a versão de lançamento, a tag da imagem quando aplicável, ou o commit de código-fonte analisado. Uma conclusão sobre licença sem uma referência de versão é difícil de revisar quando uma atualização altera dependências, avisos ou materiais de distribuição.
Quando o aplicativo for distribuído sem código-fonte, a definição da OSI também é relevante: para uma licença de código aberto, o código-fonte é a forma preferencial para modificação, e os termos de distribuição devem fornecer uma forma amplamente divulgada de obtê-lo quando o código-fonte não é distribuído com o produto. Não deduza que um projeto está em conformidade com a OSI apenas porque existe um repositório.
- Registre a URL da fonte e a data de acesso.
- Salve ou crie um link para o texto exato da licença e seu identificador, se informado.
- Registre a versão do aplicativo, a referência de lançamento ou o commit.
- Verifique LICENSE, COPYING, NOTICE, cabeçalhos de direitos autorais e avisos de terceiros.
- Compare as evidências do repositório com a documentação oficial e os artefatos distribuídos.
- Registre contradições, arquivos ausentes e procedência pouco clara como questões não resolvidas.
Leia o escopo da licença antes de comparar aplicativos
Não escolha um aplicativo pelo conjunto de recursos e trate a licença informada como uma nota de rodapé. Leia o texto aplicável à obra que você usará, especialmente as disposições sobre modificação, reprodução, distribuição, avisos, patentes e marcas.
Por exemplo, a Licença Apache 2.0 inclui condições explícitas para quando cópias ou obras derivadas são reproduzidas e distribuídas. Elas incluem fornecer uma cópia da licença, indicar arquivos modificados, manter os avisos relevantes e preservar as atribuições aplicáveis do arquivo NOTICE. Esses requisitos estão vinculados à reprodução e à distribuição; portanto, uma avaliação precisa depende de seu modelo de entrega proposto alcançar essas atividades.
Rótulos de licença não substituem a análise de uma combinação planejada. O FAQ da GNU GPL descreve a compatibilidade de licenças em termos de as licenças relevantes permitirem a combinação pretendida e observa que a forma da combinação pode ser importante. Quando sua oferta combina componentes de uma maneira que não está claramente documentada, isso é motivo para pausar em vez de adivinhar.
- Identifique a obra abrangida: o aplicativo, um plugin, uma biblioteca, uma imagem de contêiner ou outro artefato.
- Identifique suas ações: executar, modificar, copiar, distribuir, empacotar, fornecer a um cliente ou expor remotamente.
- Leia as condições e exceções no texto completo da licença, não apenas em um resumo.
- Liste os avisos obrigatórios, ofertas de código-fonte ou marcações de modificação que possam se aplicar ao seu modelo.
- Sinalize combinações de componentes incertas para análise especializada.
Verifique dependências, plugins, modelos, fontes e ativos incluídos separadamente
Um arquivo de licença do aplicativo principal pode não resolver os direitos de tudo que chega aos seus usuários ou é incluído em sua compilação. A orientação de licenciamento da Apache, por exemplo, reconhece que obras de terceiros podem ser incluídas no produto de um projeto e que seus textos de licença podem aparecer em arquivos LICENSE ou NOTICE, ou estar disponíveis separadamente.
Crie um inventário do que é realmente implantado, e não apenas do que aparece na raiz do repositório. Inclua dependências de execução, dependências de compilação que são distribuídas em um artefato, plugins opcionais que você ativa, temas, fontes, conjuntos de dados, arquivos de modelo e outros ativos incluídos. Não presuma que todos esses itens têm os mesmos termos do aplicativo principal.
O SPDX é útil como vocabulário de documentação e formato de SBOM. Seus conceitos de relacionamento incluem dependências, manifestos de dependências, dependências de compilação, dependências de desenvolvimento e dependências de execução. Você não precisa de um inventário automatizado perfeito antes de tomar uma decisão, mas precisa de evidências suficientes para identificar os componentes que afetam materialmente o uso pretendido.
- Crie uma linha de componente para cada dependência relevante ou item incluído.
- Registre o nome do componente, a versão, a fonte, a evidência de licença e como ele entra na pilha.
- Distinga itens de execução de itens exclusivos de compilação e de desenvolvimento.
- Verifique plugins e extensões ativados separadamente de opções não utilizadas.
- Procure avisos incluídos, textos de licença e requisitos de atribuição.
- Marque componentes desconhecidos ou personalizados como bloqueadores se forem distribuídos, modificados ou expostos a clientes.
Mantenha decisões sobre marcas, branding e domínios separadas
Uma licença de software não é uma permissão geral para usar nomes, logotipos ou a identidade visual de um projeto de qualquer forma. A análise de marcas tem uma finalidade diferente: evitar confusão sobre origem, afiliação ou endosso.
A política da Apache ilustra essa separação. Ela identifica nomes de projetos, nomes de produtos e logotipos como marcas, enquanto o próprio software é distribuído sob os termos de sua licença de software. Especificamente para projetos Apache, obras derivadas não devem usar nomes de projeto ou logotipos de projeto que possam gerar confusão, e o uso que cause confusão de marcas Apache em nomes de domínio exige aprovação por escrito.
Use a política de marcas do próprio projeto, quando disponível. Se você incluir o nome do aplicativo em uma oferta para clientes, alterar um logotipo, publicar um fork com marca ou registrar um domínio relacionado, adicione esse plano ao registro de evidências e busque orientação quando a política não o abranger claramente.
- O serviço voltado ao público usará o nome ou logotipo do projeto?
- Você descreverá o serviço como oficial, afiliado ou endossado?
- Um fork modificado manterá, substituirá ou complementará a identidade visual existente?
- O domínio planejado contém o nome do projeto ou da organização?
- O projeto publica uma política de marcas ou orientações para uso da marca?
- A apresentação pretendida pode confundir os usuários?
Entenda com precisão as questões de serviço em rede e divulgação de código-fonte
Não presuma que disponibilizar software por uma rede sempre tem o mesmo efeito que distribuir uma cópia. A GPLv3 declara que a mera interação com um usuário por uma rede de computadores, sem transferência de uma cópia, não é por si só “transmissão” nos termos dessa licença.
A AGPLv3 contém uma disposição condicional diferente para uma versão modificada que permite interação remota por rede. A seção 13 exige que quem fez a modificação ofereça aos usuários remotos a oportunidade de receber o Código-Fonte Correspondente dessa versão modificada. Isso não é motivo para fazer afirmações amplas sobre toda implantação hospedada; é motivo para identificar a licença exata, verificar se você modificou o programa abrangido e se ele permite interação remota.
Se o seu serviço incluir vários componentes, analise a licença do componente relevante e a natureza da integração. O FAQ da GNU GPL observa que o limite entre programas separados e um único programa combinado é, em última instância, uma questão jurídica. Uma arquitetura não óbvia não é lugar para uma conclusão casual de conformidade.
- Identifique se algum componente acessível remotamente está sob termos com disposições sobre interação por rede.
- Registre se sua equipe modificou esse componente e onde as modificações estão.
- Determine se os usuários recebem uma cópia, interagem apenas com um serviço ou ambos.
- Documente como o acesso ao código-fonte, os avisos e os registros de modificações seriam fornecidos, se necessário.
- Encaminhe combinações incertas, forks e obrigações de divulgação de código-fonte antes do lançamento.
Crie um registro de evidências antes da implantação
Um registro de evidências conciso transforma a diligência sobre licenças em um controle operacional. Ele deve permitir que outra pessoa entenda o que foi analisado, de onde vieram as evidências, o que a organização pretende fazer e o que permanece não resolvido.
Mantenha o registro junto com o registro de implantação e atualize-o quando mudar a versão do aplicativo, ativar um novo plugin, modificar código, trocar uma imagem, adicionar um modelo de entrega a clientes ou alterar a identidade visual pública. Isso é mais útil do que uma declaração única de sim ou não, pois pilhas auto-hospedadas evoluem.
Use identificadores padronizados e informações de SBOM quando disponíveis, mas não permita que um identificador familiar substitua a análise do texto aplicável, dos avisos e do modelo de entrega.
- Nome do aplicativo ou componente.
- Versão, lançamento, referência de imagem ou commit analisado.
- URL da fonte e localização da evidência de licença.
- Identificador de licença declarado e link para o texto completo.
- Observações sobre direitos autorais, NOTICE e atribuições.
- Notas sobre dependências e relacionamentos, incluindo itens de execução e compilação.
- Modificações feitas, planejadas ou herdadas.
- Plano de distribuição, entrega a clientes e serviço remoto.<br>Plano de marca, logotipo e domínio.<br>Questões em aberto, responsável, decisão de encaminhamento e data de análise.
Perguntas frequentes
A auto-hospedagem de um aplicativo significa que podemos usá-lo comercialmente?
Não por si só. Uma licença de código aberto em conformidade com a OSI não pode restringir o uso em um campo de atuação específico, incluindo o uso empresarial. No entanto, você ainda precisa verificar se o aplicativo e os componentes exatos estão sob os termos informados e avaliar separadamente a distribuição, as modificações, os avisos, as marcas e seu plano específico de implantação.
Um repositório público no Git é prova suficiente de que um aplicativo é de código aberto?
Não. A OSI explica que código aberto significa mais do que acesso ao código-fonte; os termos de distribuição devem atender à Definição de Código Aberto. Analise as evidências de licença autoritativas para a versão que você pretende usar.
Precisamos analisar dependências se o aplicativo tiver um arquivo LICENSE?
Sim. Obras de terceiros podem ter textos de licença ou avisos separados. Faça o inventário das dependências de execução relevantes, das saídas de compilação distribuídas, dos plugins, modelos, fontes, temas e ativos incluídos; em seguida, registre suas evidências de licença e sua função na pilha implantada.
Hospedar software GPL para usuários conta automaticamente como distribuição?
A GPLv3 afirma que a mera interação por rede, sem transferência de uma cópia, não é transmissão. O resultado preciso depende da licença aplicável, do componente e do que você realmente fornece. Não generalize essa afirmação para toda licença ou arquitetura.
O que é diferente na AGPLv3 para um serviço hospedado?
A seção 13 da AGPLv3 inclui uma obrigação condicional para uma versão modificada que permite interação remota por rede: usuários remotos devem receber, de forma destacada, acesso ao Código-Fonte Correspondente da versão modificada. Identifique se você modificou o programa abrangido e obtenha aconselhamento qualificado se a aplicação da obrigação não estiver clara.
Podemos usar o nome e o logotipo do projeto em nosso serviço hospedado?
Essa é uma questão de marcas e branding, separada da licença de software. Analise a política de marcas do projeto, especialmente antes de usar um logotipo, comercializar um fork modificado, alegar afiliação ou registrar um domínio relacionado.
Fontes e leituras adicionais
- The Open Source Definition — Open Source Initiative
- Apache License, Version 2.0 — Apache Software Foundation
- Apache Licensing and Distribution FAQ — Apache Software Foundation
- SPDX Overview — SPDX
- SPDX Specification: Relationships Between SPDX Elements — SPDX
- GNU Affero General Public License v3 — GNU Project / Free Software Foundation
- GNU General Public License v3 — GNU Project / Free Software Foundation
- GNU GPL FAQ — GNU Project / Free Software Foundation
- Apache Software Foundation Trademark Policy — Apache Software Foundation
- Docker Compose documentation — Docker