Conformidade de licenças em M&A: o que as equipas de diligência realmente precisam

Risco de licença é risco de negócio. Copyleft não declarado, atribuição em falta, ou uma página pública que já não corresponde ao build podem tornar-se holdbacks, cortes de preço ou programas de remediation pós-closing.

Os compradores perguntam porque herdam os produtos lançados e as obrigações que os acompanham. Vendedores que já mantêm um inventário revisto respondem mais depressa e com menos surpresas.

• Confirme que produtos e linhas de release estão no âmbito do negócio.
• Identifique cedo copyleft, network copyleft e termos de SDK proprietários.
• Separe findings de segurança da divulgação de licenças. A diligência precisa muitas vezes de ambos, mas não são o mesmo entregável.
• Pergunte se o registo está ligado ao que realmente é lançado, e não apenas a um scan do site de marketing.

Uma prova pronta para diligência é um inventário revisto por cada produto no âmbito, congelado numa publicação conhecida, com texto completo da licença e atribuição quando exigido. Uma página de atestação orientada ao comprador mais exportações correspondentes é a forma habitual.

Um lockfile colado, um SBOM não revisto, ou um ficheiro NOTICE de há três anos é input, não prova. Prova significa que alguém aprovou a representação antes de sair do edifício.

• Inventário com âmbito por produto (direto e transitivo segundo a vossa política).
• Identificadores de licença revistos por humanos e texto completo anexado.
• Um URL estável ou uma exportação gerada a partir do mesmo snapshot aprovado.
• Uma indicação clara de que release ou data o registo cobre.

A maioria das emergências começa nos mesmos buracos. Detete-os antes de chegar o pedido do data room.

Nenhum significa que o negócio falhe. Significam que alguém tem de reconstruir um registo defensável sob pressão de tempo.

• Componentes GPL, LGPL ou AGPL não declarados ou por resolver em builds lançados.
• Ficheiros NOTICE ou de atribuição desatualizados que não correspondem ao lockfile atual.
• Um SBOM tratado como divulgação concluída, sem texto de licença revisto.
• Uma única folha de cálculo a cobrir vários produtos sem âmbito por produto.
• Páginas públicas ou exportações que não podem ser rastreadas até uma aprovação de publicação.

Construa o pacote a partir do mesmo ciclo que já deveriam correr para clientes: importe o que é lançado, reveja-o, publique e depois exporte. Não invente um processo paralelo só para diligência na semana da assinatura.

Quando o comprador pede tanto um URL como ficheiros, gere ambos a partir de um único snapshot congelado para que o data room não contenha versões conflituosas.

Uma página de conformidade mantida e exportações correspondentes são infraestrutura para a diligência, não um substituto do aconselhamento jurídico. Licenças de alto risco, questões de distribuição outbound e indemnidades específicas do negócio continuam a precisar de revisão jurídica.

SourceTrust ajuda as equipas a manter o registo operacional atualizado, para que os advogados discutam os poucos casos difíceis, e não um inventário em falta.

Normalmente não por si só. Um SBOM identifica componentes. A diligência ainda precisa de licenças revistas, texto completo e um âmbito de produto claro. Trate o SBOM como a importação, e conclua revisão e publicação antes de partilhar.

Por produto: um inventário revisto atual, um URL de atestação ou divulgação equivalente, e exportações do mesmo snapshot. Saber que release cada ficheiro cobre poupa dias quando o data room abre.

Peça prova com âmbito por produto ligada aos builds do negócio: uma página mantida ou um pacote de divulgação, SPDX ou CycloneDX correspondentes se exigido, e confirmação de que as linhas copyleft foram revistas. Evite aceitar uma única folha de cálculo sem data como completa.