Conformidade de licenças open source

Esta página contém informação geral e não constitui aconselhamento jurídico. Para decisões sobre um produto específico, fale com um advogado.

Tipos de licenças open source

Tipo	Exemplos	O que costuma exigir
Permissiva	MIT, BSD, Apache-2.0	Manter os avisos de direitos de autor e de licença. A Apache-2.0 tem também condições sobre patentes.
Copyleft fraco	LGPL, MPL-2.0	Partilhar as alterações ao próprio componente licenciado
Copyleft forte	GPL-2.0, GPL-3.0	O software distribuído com ela tem de ser disponibilizado nas mesmas condições, com o código-fonte
Copyleft de rede	AGPL-3.0	Como o copyleft forte, e aplica-se também quando os utilizadores interagem com o software através de uma rede
Source-available	BUSL, SSPL	Não é open source: o código-fonte é visível, mas a utilização é restrita

O que é uma licença copyleft?

Uma licença copyleft permite usar, alterar e partilhar software, na condição de o que distribui se manter nas mesmas condições. Mantém o open source aberto. O risco para um produto comercial é que um componente de copyleft forte ligado ao seu código pode levantar a questão de saber se o seu próprio código também tem de ser divulgado.

Se isso se aplica depende da forma como o componente é usado e de como o produto é entregue. O software que distribui aos clientes está mais exposto do que uma ferramenta interna, e um produto SaaS evita normalmente as condições de distribuição da GPL, mas não as da AGPL.

Riscos comuns de conformidade

• Licenças transitivas. Um pacote permissivo pode depender de um pacote copyleft. Verificar apenas as dependências diretas não apanha isto.
• Avisos em falta. A maioria das licenças exige que mantenha a atribuição, e um ficheiro de avisos esquecido é a falha mais comum.
• Licenças alteradas. Um projeto pode mudar de licença numa nova versão, pelo que uma atualização pode alterar as suas condições.
• Declarada vs real. Os metadados de um pacote podem estar errados ou incompletos, e o código vendored pode ter a sua própria licença.
• Due diligence. Compradores e grandes clientes pedem um inventário de licenças, normalmente com pouca antecedência.

Como manter a conformidade

1. Escreva uma política. Decida, por tipo de produto, que licenças são permitidas, quais precisam de revisão e quais são proibidas.
2. Crie um inventário. Uma SBOM lista cada componente com a sua licença, incluindo as dependências transitivas.
3. Verifique automaticamente. Aplique a política na CI, para que uma nova dependência falhe no momento em que é adicionada e não numa auditoria.
4. Cumpra as obrigações. Gere ficheiros de avisos e forneça o código-fonte quando uma licença o exigir.
5. Guarde os registos. Armazene o inventário por versão, porque a questão diz normalmente respeito a uma versão que já distribuiu.

O que faz o software de conformidade de licenças

A conformidade de licenças é uma parte habitual da análise de composição de software. As ferramentas identificam os componentes, reportam as suas licenças e assinalam violações da sua política. Diferem na profundidade:

• Licenças declaradas: a maioria das ferramentas lê o que cada pacote declara nos seus metadados. É rápido e cobre o caso comum.
• Análise aprofundada de licenças: o FOSSA e o Black Duck analisam também o texto das licenças no código e ajudam nos relatórios de atribuição e na revisão jurídica. Consulte CRACI vs FOSSA e CRACI vs Black Duck.
• Ferramentas gratuitas: muitos geradores de SBOM e scanners SCA reportam as licenças declaradas sem custos. Consulte as melhores ferramentas de SCA.

Onde o CRACI se enquadra

O CRACI trata das licenças declaradas no build. Como seu runner de GitHub Actions, regista cada pacote que um job traz, e cada um inclui a sua licença declarada, pelo que as licenças copyleft são detetadas antes de chegarem ao produto. As regras de política de licenças podem bloquear um build devido a uma licença, e as exportações de SBOM em CycloneDX e SPDX incluem a licença declarada de cada componente. O CRACI trabalha a partir do que os pacotes declaram, pelo que, se precisar de fluxos de trabalho de revisão jurídica ou de análise do texto das licenças, deve usar uma ferramenta especializada a par dele.

Conformidade de licenças open source: perguntas frequentes

O que é a conformidade de licenças open source?

Significa saber que licenças open source se aplicam ao software que usa e cumprir as suas condições, como manter os avisos ou partilhar o código-fonte.

O que é uma licença copyleft?

Uma licença que permite usar e alterar software na condição de o que distribui se manter nas mesmas condições. A GPL é o exemplo mais conhecido.

É possível usar código GPL em software comercial?

Sim, mas se distribuir software que o inclua, poderá ter de disponibilizar o código-fonte desse software ao abrigo da GPL. A forma como o código é combinado é importante, pelo que deve obter aconselhamento jurídico para o seu caso.

O copyleft aplica-se ao SaaS?

As condições da GPL são geralmente desencadeadas pela distribuição, que o SaaS normalmente evita. A AGPL fecha essa lacuna ao alargar as condições aos utilizadores que interagem com o software através de uma rede.

Qual é a licença open source mais segura para uso comercial?

As licenças permissivas como MIT, BSD e Apache-2.0 são as que menos exigem. Mesmo assim, tem de manter os respetivos avisos.

Como verificar as licenças das suas dependências?

Gere uma SBOM que inclua as dependências transitivas e as licenças declaradas, ou use uma ferramenta de SCA. Aplique a sua política na CI, para que novas violações façam o build falhar.