Usando Código Open Source: Um Guia para Compliance

Um dos papéis mais importantes de um escritório de programa open source (OSPO) é garantir que sua organização cumpra suas obrigações legais ao integrar código open source com código proprietário e de terceiros em seus produtos comerciais.

É crucial estabelecer diretrizes sobre como os desenvolvedores podem usar código open source e processos detalhados para rastrear a origem do código, como ele é licenciado e onde ele acaba sendo usado. Este guia fornece um ponto de partida para um programa de compliance básico para usar, liberar e distribuir código open source.

Por que rastrear e revisar código?

Em termos simples, se sua empresa não está rastreando como e onde seus desenvolvedores usam código open source, você corre o risco de não conformidade com as licenças open source aplicáveis. Isso pode ser caro, tanto em termos de honorários advocatícios quanto de tempo de engenharia gasto para corrigir o erro. Ignorar as obrigações legais do open source também tem repercussões na reputação da sua empresa na comunidade open source.

Um OSPO ajuda a centralizar políticas e tomadas de decisão em torno do consumo, distribuição e lançamento de open source, rastreia a proveniência e o uso do código e garante que a organização não viole suas obrigações de compliance.

Idealmente, seu programa open source inclui um programa de compliance completo, desenvolvido com a ajuda de seu consultor jurídico. Este guia aborda um aspecto importante do seu programa de compliance: sua política e processos para usar, liberar e distribuir código open source.

"Um processo de compliance open source bem projetado deve garantir simultaneamente a conformidade com os termos das licenças open source e também ajudar as empresas a proteger sua própria propriedade intelectual e a de fornecedores terceiros contra divulgação não intencional e/ou outras consequências."

Ibrahim Haddad – Vice-presidente de P&D e chefe do Grupo Open Source da Samsung Research America

Benefícios de um Programa de Compliance Open Source

As empresas podem experimentar vários benefícios ao manter um programa de compliance open source:

• Vantagem técnica: Portfólios de software em conformidade são mais fáceis de manter, testar, atualizar e manter.
• Identificação de código crucial: Descubra qual código está em uso em vários produtos e partes da sua organização e/ou são altamente estratégicos e benéficos para sua estratégia open source.
• Demonstração de custos e riscos: Mais fácil de ver quando o código passa por várias rodadas de revisão.
• Construção de confiança na comunidade: Em caso de desafio de compliance, um programa pode demonstrar um padrão contínuo de atuação de boa fé.
• Preparação para transações: A garantia de compliance é uma prática obrigatória antes da conclusão de aquisições, vendas ou lançamentos de novos produtos/serviços.
• Credibilidade na cadeia de suprimentos: Melhora a compliance em toda a sua cadeia de suprimentos de software, lidando com OEMs e fornecedores downstream.

Funções e Responsabilidades de Compliance

Dentro do seu programa open source, você precisará criar uma equipe de compliance open source designada, encarregada de garantir a conformidade.

A equipe principal, frequentemente chamada de equipe de auditoria ou Open Source Review Board (OSRB), consiste em representantes das equipes de engenharia e produto, um ou mais consultores jurídicos e o Compliance Officer (que geralmente é o gerente do programa open source).

Outros indivíduos em vários departamentos também contribuem continuamente para seus esforços de compliance open source: documentação, cadeia de suprimentos, desenvolvimento corporativo, TI, localização e o Comitê Executivo Open Source (OSEC), que supervisiona a estratégia geral de open source. Mas, ao contrário da equipe principal, os membros da equipe estendida trabalham em compliance apenas em meio período, com base nas tarefas que recebem do OSRB.

O OSRB é responsável por criar uma estratégia de compliance open source e um conjunto de processos que determinam como uma empresa implementará essas regras diariamente. A estratégia estabelece o que deve ser feito para garantir a compliance e oferece um conjunto de princípios governantes para como os funcionários interagem com o software open source. Inclui um processo formal para a aprovação, aquisição e uso de open source, e um método para lançar software que contenha open source ou que seja licenciado sob uma licença open source.

Uma Política Simples para Usar Código Open Source

A política de uso é um componente essencial de qualquer programa de compliance. Este conjunto de regras está incluído no seu documento de estratégia open source (você tem um, certo?) e é disponibilizado a todos para fácil referência.

A política de uso garante que qualquer software (proprietário, de terceiros ou open source) que entre na base do produto tenha sido auditado, revisado e aprovado. Também garante que sua empresa tenha um plano para cumprir as obrigações de licença resultantes do uso dos vários componentes de software, antes que seus produtos cheguem aos clientes.

Não há necessidade de fazer um documento longo ou complicado. Uma boa política de uso de open source inclui seis regras simples:

1. Os engenheiros devem receber aprovação do OSRB antes de integrar qualquer código open source em um produto.
2. O software recebido de terceiros deve ser auditado para identificar qualquer código open source incluído, o que garante que as obrigações de licença possam ser cumpridas antes do envio de um produto.
3. Todo o software deve ser auditado e revisado, incluindo todos os componentes de software proprietário.
4. Os produtos devem cumprir as obrigações de licenciamento open source antes do recebimento pelo cliente.
5. A aprovação para usar um determinado componente open source em um produto não é aprovação para outra implantação, mesmo que o componente open source seja o mesmo.
6. Todos os componentes alterados devem passar pelo processo de aprovação.

Processo de Revisão de Código em 5 Etapas

Depois de ter uma política em vigor, você deve planejar e criar um processo que facilite a aplicação da política. Seu trabalho é facilitar o uso de open source pelos desenvolvedores e a contribuição para projetos open source.

"Se o seu processo de revisão de código for excessivamente oneroso, você retardará a inovação ou fornecerá uma boa desculpa para os desenvolvedores contornarem o processo completamente."

Ibrahim Haddad – Vice-presidente de P&D e chefe do Grupo Open Source da Samsung Research America

O processo começa com a varredura do código-fonte do pacote de software em questão, depois passa para a identificação e resolução de quaisquer problemas descobertos, realizando revisões legais e arquitetônicas e tomando uma decisão sobre a aprovação de uso.

O diagrama abaixo ilustra uma visão simplista de um processo de uso de compliance. Na realidade, o processo é muito mais iterativo. Lembre-se de que essas fases são para fins de ilustração e podem precisar ser modificadas dependendo das necessidades da sua empresa e da configuração do programa open source.

[Diagrama de fluxo do processo de revisão de código]

Vamos percorrer cada etapa do processo.

Etapa 1: Varredura do Código-Fonte

Na fase de varredura do código-fonte, todo o código-fonte é verificado usando ferramentas de software especializadas (existem muitos fornecedores comerciais que oferecem essas ferramentas, além de algumas alternativas de código aberto).

Esta fase geralmente é iniciada quando um engenheiro envia um formulário de uso online. (Veja o exemplo de formulário de uso e as regras para usá-lo, abaixo.) O formulário inclui todas as informações sobre o componente open source em questão e especifica a localização do código-fonte no sistema de repositório de código-fonte.

O envio do formulário cria automaticamente um tíquete de compliance em um sistema como JIRA ou Bugzilla, e uma solicitação de varredura de código-fonte será enviada para a equipe de auditoria designada.

Varreduras completas periódicas da plataforma também devem ocorrer a cada poucas semanas para garantir que nenhum componente de software open source tenha sido integrado à plataforma sem um formulário correspondente. Se algum for encontrado, um tíquete JIRA é emitido automaticamente e atribuído à equipe de auditoria.

Alguns dos fatores que podem desencadear uma varredura de código-fonte incluem:

• Um formulário de uso recebido, geralmente preenchido pela equipe de engenharia.
• Uma varredura completa da plataforma agendada periodicamente. Essas varreduras são muito úteis para descobrir código open source que entrou na sua plataforma de software sem um formulário de uso.
• Alterações em um componente de software previamente aprovado. Em muitos casos, os engenheiros começam a avaliar e testar com uma determinada versão de um componente OSS e, posteriormente, adotam esse componente quando uma nova versão está disponível.
• O código-fonte é recebido de um fornecedor de software terceirizado que pode ou não ter divulgado o open source.
• O código-fonte é baixado da web com um autor e/ou licença desconhecidos, que podem ou não ter incorporado código open source.
• Um novo componente de software proprietário entra no sistema de build, onde a engenharia pode ou não ter emprestado código open source e usado em um componente de software proprietário.

Após a varredura do código, a ferramenta de varredura produz um relatório que fornece informações sobre:

• Componentes de software conhecidos em uso, também conhecido como Bill of Materials (BoM) de software
• Licenças em vigor, textos de licença e resumo das obrigações
• Conflitos de licença a serem verificados pelo jurídico
• Inventário de arquivos
• Arquivos identificados
• Dependências
• Correspondências de código
• Arquivos pendentes de identificação
• Correspondências de código-fonte pendentes de identificação

Observação sobre pacotes Open Source baixados

É vital arquivar os pacotes open source baixados da web em sua forma original. Esses pacotes serão usados em um estágio posterior (antes da distribuição) para verificar e rastrear quaisquer alterações introduzidas no código-fonte, calculando a diferença entre o pacote original e o pacote modificado.

Se um fornecedor de software terceirizado usar open source, a equipe de produto que integrar esse código ao produto deve enviar um formulário de uso de open source descrevendo o open source a ser usado. Se o fornecedor de software terceirizado fornecer apenas binários, e não o código-fonte, a equipe do produto e/ou o gerente de fornecedor de software que gerencia o relacionamento com o fornecedor de software terceirizado deve obter uma confirmação (por exemplo, um relatório de varredura) de que não há open source no software fornecido.