10.3 Contratação, código aberto e licenciamento

Visão geral e motivação

Quase todo sistema de software moderno é montado, em sua maior parte, com componentes que outra pessoa escreveu. O software de código aberto forma a fundação de sistemas operacionais, linguagens, frameworks, bancos de dados e infraestrutura de nuvem. Ele entra na empresa de dois modos: pela contratação deliberada e pelas instruções import casuais de desenvolvedores individuais. Este capítulo trata de fazer esse consumo (e, onde cabe, a contribuição) de forma deliberada. Isso significa uma estratégia, conformidade de licenças, um entendimento das obrigações e do risco de copyleft e um plano para o fim de vida inevitável dos componentes de que vocês dependem.

Para grandes equipes as apostas são ao mesmo tempo jurídicas, operacionais e estratégicas. Juridicamente, as licenças de código aberto são contratos exequíveis, com obrigações reais. Errar o copyleft (licenciamento que pode exigir que obras derivadas sejam compartilhadas sob os mesmos termos) pode, no pior caso, obrigar à divulgação de código-fonte proprietário ou disparar litígio. As violações de licença podem até bloquear uma aquisição ou uma oferta pública durante a diligência prévia. Operacionalmente, as dependências não gerenciadas apodrecem: os componentes ficam sem manutenção, acumulam vulnerabilidades e chegam ao fim de vida enquanto ainda estão enterrados fundo em produção. Estrategicamente, o código aberto é mais que um insumo que economiza custo. É um jeito de evitar o aprisionamento (lock-in), atrair talento e moldar os ecossistemas de que vocês dependem, vantagens que só se capturam se vocês se engajam de propósito.

O governo tem uma dimensão adicional. Muitas jurisdições hoje têm políticas explícitas que favorecem o código aberto, os padrões abertos e o compartilhamento de código entre agências. Elas costumam ser expressas como “dinheiro público, código público”: o princípio de que o software financiado pelos contribuintes deve, por padrão, estar disponível ao público. Assim, os engenheiros do setor público precisam navegar tanto a conformidade de licenças quanto os mandatos ativos de preferir, publicar e reutilizar código aberto. Este capítulo pretende tornar tudo isso administrável em escala.

Princípios fundamentais

Código aberto é uma cadeia de suprimentos, não coisa de graça. Tratem os componentes consumidos com o mesmo rigor de qualquer fornecedor crítico.
As licenças são obrigações, não permissões para ignorar. Toda dependência carrega termos. Conheçam-nos antes de entregar.
O copyleft é uma restrição de projeto, não um tabu. As licenças copyleft são usáveis e valiosas. Só exigem que se entenda como vocês combinam e distribuem o software.
Consumam deliberadamente, contribuam estrategicamente. Decidam o que trazer e, onde isso servir a vocês, invistam em contribuir upstream em vez de bifurcar.
Inventariem tudo. Não se cumpre, protege nem atualiza o que não se vê. Uma SBOM (lista de materiais de software, um inventário completo dos componentes no seu software) é o mínimo.
Planejem o fim de vida desde o início. Toda dependência um dia ficará sem manutenção. Conheçam a sua saída antes de serem forçados a uma.
No governo, adotem o aberto por padrão. Prefiram padrões abertos e código aberto e publiquem o código pago com dinheiro público, a menos que haja uma razão específica para não fazê-lo.

Recomendações

Defina uma estratégia de código aberto e uma política de consumo

Publiquem uma política clara de como os desenvolvedores podem trazer código aberto para a organização: quais licenças são pré-aprovadas, quais exigem revisão e quais são proibidas para os seus casos de uso. Ofereçam um caminho de aprovação rápido e de baixo atrito. Uma política mais lenta que copiar código será simplesmente ignorada. Distingam os contextos, porque a mesma licença se comporta de modo diferente quando um componente é usado internamente como serviço, embutido num produto distribuído ou ligado a uma aplicação proprietária. Façam do caminho fácil o caminho em conformidade: um repositório interno curado de componentes verificados, varredura automatizada no pipeline e orientação clara que os desenvolvedores possam seguir sem ligar para um advogado nos casos de rotina.

Gerencie a conformidade de licenças, as obrigações e o risco de copyleft

Conheçam as famílias de licenças e suas obrigações. As licenças permissivas (como MIT, BSD e Apache 2.0) exigem principalmente atribuição e preservação de avisos; a Apache 2.0 acrescenta uma concessão explícita de patentes. O copyleft fraco (como LGPL e MPL) exige que vocês compartilhem as modificações dos arquivos cobertos mas em geral permite combinar com código proprietário. O copyleft forte (como a GPL) pode exigir que toda a obra distribuída seja oferecida sob os mesmos termos. O copyleft de rede (AGPL) estende essa obrigação ao software oferecido por uma rede, e não apenas distribuído como binários. As obrigações que mais importam dependem de duas coisas: se vocês distribuem o software e quão firmemente combinam os componentes. Automatizem a conformidade: varram as dependências em busca de licenças, gerem e entreguem os arquivos exigidos de atribuição e de avisos e condicionem o build à política para que uma licença proibida não entre em produção em silêncio.

Estabeleça um Escritório de Programa de Código Aberto (OSPO)

Se vocês consomem código aberto em escala, criem um ponto focal, um OSPO, que seja dono da estratégia de código aberto, da política, das ferramentas de conformidade, da governança de contribuições e dos relacionamentos com a comunidade. O OSPO contém o caos de cada equipe tomando as próprias decisões. Fornece uma expertise que as equipes individuais não conseguem manter. E captura valor estratégico: decidir em que projetos investir, quando contribuir upstream e como liberar bem os seus próprios projetos de código aberto. Até um OSPO pequeno (às vezes uma pessoa mais um grupo de trabalho multifuncional) melhora dramaticamente a consistência e reduz o risco jurídico em comparação com a liberdade geral.

Governe a contribuição e, quando couber, a publicação

Decidam deliberadamente quando contribuir de volta. Enviar correções e funcionalidades upstream aos projetos de que vocês dependem reduz o seu fardo de manutenção, porque vocês param de carregar remendos privados. Também constrói boa vontade e influência e fortalece componentes críticos para vocês. Deem aos desenvolvedores um processo claro e rápido para as contribuições aprovadas, incluindo como a propriedade intelectual e os acordos de contribuidor são tratados. Ao liberar os seus próprios projetos de código aberto, façam-no direito: escolham uma licença apropriada, documentem a governança e comprometam-se com a curadoria. Um projeto abandonado prejudica a sua reputação mais do que nenhum projeto.

Cumpra os mandatos governamentais de código aberto e de “dinheiro público, código público”

As equipes do setor público devem tratar a abertura como padrão. Prefiram padrões abertos para evitar o aprisionamento e para trabalhar entre agências e fornecedores. Publiquem abertamente o código-fonte desenvolvido com fundos públicos, a menos que se aplique uma isenção específica e documentada: para componentes sensíveis à segurança, direitos de terceiros ou preocupações de privacidade. Reutilizem antes de construir: confiram se outra agência já liberou um código adequado. Embutam essas expectativas na contratação, para que os fornecedores entreguem código aberto, reutilizável e bem documentado, com o governo mantendo os direitos apropriados, em vez de caixas-pretas proprietárias que a agência não consegue manter nem compartilhar.

Gerencie as dependências e o software em fim de vida

Mantenham um inventário vivo (SBOM) de todo componente e sua versão, licença e estado de manutenção. Mantenham as dependências razoavelmente atuais. Atualizações pequenas e frequentes são muito mais baratas e seguras que saltos raros e gigantes. Vigiem os projetos upstream em busca de anúncios de fim de vida e janelas de suporte de segurança e planejem as migrações antes que o suporte termine, não depois que uma vulnerabilidade forçar uma correria. Para componentes críticos sob risco de abandono, decidam de antemão se vocês financiarão o mantenedor, farão a manutenção vocês mesmos, bifurcarão ou substituirão. Acompanhem o fim de vida de software comercial e de código aberto por igual e mantenham o ficar sem suporte no mesmo padrão de qualquer outro risco operacional.

Compromissos: prós e contras

Escolha	Prós	Contras
Consumir código aberto livremente	Entrega rápida. Enorme alavancagem. Sem taxas de licença	Obrigações de licença, segurança e manutenção que agora são suas
Lista rigorosa de licenças permitidas	Baixo risco jurídico. Previsível	Atrasa as equipes. Pode excluir componentes genuinamente úteis
Apenas licenças permissivas	Obrigações mínimas. Fácil de combinar	Abre mão de valiosos projetos copyleft. Menos reciprocidade
Aceitar o copyleft onde adequado	Acesso a ecossistemas fortes. Benefícios de reciprocidade	Exige cuidado na combinação e na distribuição
Contribuir upstream	Menos fardo de remendos privados. Influência. Boa vontade	Esforço contínuo. Sobrecarga de PI e de processo
Construir algo proprietário	Controle total. Sem obrigações externas	Alto custo. Reinventa commodity. Vocês mantêm para sempre
Governo: publicar por padrão	Transparência. Reutilização. Evita aprisionamento	Esforço de publicação. Revisão de segurança. Curadoria sustentada

A tensão central é entre velocidade do desenvolvedor e controle. Tranquem tudo atrás de revisão pesada e os desenvolvedores contornam a política. Isso cria dependências paralelas não gerenciadas, que são piores que uma abordagem permissiva mas visível. Deixem tudo sem controle e vocês acumulam dívida jurídica e de segurança de forma invisível. A solução é automação e curadoria: façam do caminho em conformidade o caminho mais rápido, por meio de componentes pré-verificados, varredura no pipeline e padrões claros, para obter controle sem atrito. No copyleft, o compromisso não é “arriscado versus seguro” e sim “compreendido versus não compreendido”. O copyleft é inteiramente usável assim que vocês sabem como combinam e distribuem.

Perguntas para discutir com sua equipe

Qual é a sua regra explícita para o copyleft forte e de rede nos contextos interno, distribuído e servido pela rede? O copyleft é uma restrição de projeto, não um tabu, e as obrigações dependem de duas coisas: se vocês distribuem o software e quão firmemente combinam os componentes. A GPL numa ferramenta interna se comporta de modo muito diferente da GPL ligada a um produto que vocês entregam, e a AGPL estende os deveres de divulgação ao software que vocês meramente oferecem por uma rede, o que muda o seu cálculo de construir versus adotar para tudo que rodam como serviço. Escrevam a regra por contexto, para que um desenvolvedor saiba sem ligar para um advogado que (por exemplo) o permissivo é pré-aprovado em toda parte, o copyleft forte é aceitável internamente mas bloqueado do produto entregue e a AGPL exige revisão antes de tocar um serviço de rede. Levem evidências: varram a sua árvore atual de dependências e achem onde os componentes copyleft já ficam em relação à sua fronteira de distribuição. Depois condicionem o build a essa política, porque uma regra que nenhum scanner impõe é uma regra que os desenvolvedores quebrarão por acidente.
Vocês precisam de um Escritório de Programa de Código Aberto, e quem é dono hoje da política de licenças, da varredura e das decisões de contribuição? Se a resposta honesta é “ninguém” ou “cada equipe decide”, vocês estão rodando uma liberdade geral que acumula dívida jurídica e de segurança de forma invisível. Um OSPO, mesmo uma pessoa mais um grupo de trabalho multifuncional, contém esse caos e captura valor estratégico: em quais projetos upstream investir, quando contribuir e como liberar bem os seus próprios projetos. Levem evidências à reunião: alguém consegue produzir a lista atual de licenças aprovadas, a SBOM e o nome da pessoa que atenderia a uma pergunta de copyleft durante a diligência prévia de uma aquisição? A resposta deve atribuir propriedade clara e fazer do caminho em conformidade o caminho mais rápido, por componentes pré-verificados e varredura no pipeline, para que os desenvolvedores obtenham controle sem atrito. Uma política mais lenta que copiar código será simplesmente ignorada.
Quais dependências mais doeriam se fossem abandonadas amanhã, e qual é a sua resposta pré-decidida para cada uma? Toda dependência chega ao fim de vida um dia, e a versão cara desse evento é descobrir que um componente central perdeu o suporte meses atrás, só quando uma vulnerabilidade força a atenção. Para os seus componentes críticos sob risco de abandono, decidam de antemão se vocês financiarão o mantenedor, farão a manutenção vocês mesmos, bifurcarão ou substituirão. Levem evidências: da sua SBOM, listem os componentes cuja falha pararia um serviço crítico para a receita ou a missão e anotem o estado de manutenção e a janela de suporte de segurança de cada um. A resposta deve transformar o fim de vida de uma surpresa num risco operacional acompanhado, com uma migração planejada, mantido no mesmo padrão de qualquer outro risco. Manter as dependências atuais em passos pequenos e frequentes é muito mais barato que o salto raro, gigante e forçado.
Vocês conseguem produzir uma SBOM completa e atual que alcance toda a árvore de dependências transitivas, e com que rapidez? Quando uma vulnerabilidade de destaque aterrissa numa biblioteca amplamente usada, a primeira pergunta que a liderança faz é “estamos expostos, e onde?”. Uma equipe que não consegue responder em horas já está atrás, porque o risco real costuma se esconder várias camadas abaixo, em dependências que ninguém escolheu de propósito. A consideração contrária é custo e ruído: um inventário transitivo completo em muitos serviços gera uma lista grande e em constante mudança, e o excesso de alertas treina as pessoas a ignorá-la, então vocês precisam decidir que profundidade e que severidade de fato disparam ação. Levem evidências à discussão: tentem gerar agora uma SBOM nova para um serviço de produção, contem quantos componentes são diretos versus transitivos e cronometrem quanto tempo levou. Para um órgão corporativo ou governamental, liguem isso a uma meta concreta de resposta a incidentes e a qualquer dever regulatório de divulgar os componentes afetados, porque um mandato de reportar uma exposição que vocês não conseguem enumerar é um mandato que vocês violarão.
Quando vale a pena financiar, contribuir ou ser curador de uma dependência crítica, em vez de tratá-la como de graça? A maioria das organizações consome código aberto como se fosse uma utilidade pública e depois se choca quando um componente que sustenta um serviço de receita acaba sendo um voluntário sem remuneração. Decidir deliberadamente financiar um mantenedor, enviar correções upstream ou liberar e ser curador do seu próprio projeto converte um insumo frágil e gratuito num durável e influenciado, e impede os seus engenheiros de carregar remendos privados a cada atualização. A tensão é que a contribuição e a curadoria custam tempo de engenharia real e contínuo e carregam sobrecarga de propriedade intelectual e de processo, então vocês não podem fazê-lo para tudo. Levem evidências: da sua SBOM, marquem o punhado de componentes cuja falha pararia um serviço crítico à missão e anotem o número de mantenedores, o financiamento e quantos remendos privados vocês já carregam contra cada um. Para uma organização grande ou pública, pesem o custo de reputação de uma liberação de código aberto abandonada que vocês publicaram com alarde e, no governo, tratem a curadoria sustentada do código publicado pago com dinheiro público como parte da entrega, não como um extra opcional.
A sua contratação de fato entrega código aberto, reutilizável e bem documentado com os direitos de que vocês precisam, ou caixas-pretas proprietárias que vocês não conseguem manter nem deixar? Contratos escritos sem expertise em código aberto rotineiramente entregam ao fornecedor um controle de que vocês se arrependerão: formatos fechados, nenhum direito de publicar ou modificar e dependências que a agência não consegue corrigir quando o fornecedor segue em frente. Acertar isso cedo é muito mais barato que descobrir na renovação que vocês não conseguem sair. As considerações concorrentes são velocidade e escolha de fornecedor: exigir entregas abertas e portabilidade pode estreitar o campo e atrasar uma adjudicação, e alguns fornecedores genuinamente úteis resistem. Levem evidências: puxem dois contratos recentes e conferiram se especificam termos de licença, entrega de código-fonte, padrões de documentação, fornecimento de SBOM e os direitos que a organização retém. Para a contratação corporativa, liguem isso à análise de aprisionamento e de custo total; para o governo, liguem-no ao aberto por padrão e aos mandatos de “dinheiro público, código público” e ao processo documentado de isenção que permite fechar apenas as partes sensíveis à segurança e não o sistema inteiro.

Perspectiva por setor

Startup. Vocês montam quase tudo a partir de código aberto e não têm advogado, então mantenham a regra numa página: licenças permissivas como MIT e Apache 2.0 são pré-aprovadas, o copyleft forte é aceitável para ferramentas internas mas bloqueado do produto entregue e qualquer coisa estranha recebe uma revisão rápida dos fundadores. Acrescentem uma varredura de licenças e vulnerabilidades ao pipeline e mantenham uma SBOM desde o primeiro dia, porque o momento mais barato de acertar isso é antes de a diligência prévia de um adquirente pentear a sua árvore de dependências. Não proíbam o copyleft por medo: entendam-no e sigam em frente.

Pequena empresa. Sem especialista em código aberto e com orçamento apertado, apoiem-se em ferramentas e não em pessoal: um scanner no build e uma lista curta de licenças aprovadas fazem a maior parte do trabalho que uma pessoa faria. Enquadrem o consumo como comprar versus construir com honestidade, já que reinventar um componente aberto bem mantido costuma ser a escolha cara, mas também o é depender de um que vocês nunca inventariam. Mantenham um registro simples do que usam e sob que licença, para que um questionário de segurança de cliente ou um alerta de vulnerabilidade não vire uma correria.

Grande empresa. Em escala o problema é a consistência entre muitas equipes, então montem um OSPO para ser dono da política, da varredura automatizada, da geração de atribuição e da governança de contribuições e façam do caminho em conformidade o caminho mais rápido por meio de componentes curados e pré-verificados. Imponham as regras de copyleft por contexto no pipeline, mantenham SBOMs em todos os serviços e gerenciem a atualidade das dependências e o fim de vida como risco operacional acompanhado. Tratem o código aberto como gestão da cadeia de suprimentos para a maior parte da sua base de código, com evidência pronta para auditoria para a diligência prévia de aquisições.

Governo. A abertura costuma ser mandatada e não opcional, então adotem por padrão os padrões abertos e publiquem o código pago com dinheiro público, a menos que uma isenção documentada se aplique por segurança, direitos de terceiros ou privacidade. Reutilizem antes de construir, conferindo um catálogo entre governos, e embutam na contratação entregas abertas, reutilizáveis e bem documentadas e direitos retidos para receber código mantível e não caixas-pretas proprietárias. Mantenham o código publicado sob uma curadoria real e mantenham o processo de isenção estreito e transparente para que feche apenas o que precisa.

Exemplos

Startup. Uma startup de quatro pessoas que constrói um aplicativo móvel monta quase tudo a partir de código aberto e não tem advogado na equipe. Em vez de banir o copyleft por medo, os fundadores escrevem uma política de uma página: licenças permissivas como MIT e Apache 2.0 são pré-aprovadas, o copyleft forte como a GPL é aceitável para ferramentas internas mas bloqueado do aplicativo entregue para evitar deveres de divulgação e qualquer coisa incomum recebe uma revisão rápida dos fundadores. Acrescentam uma varredura de licenças e vulnerabilidades ao pipeline para que uma licença proibida não se infiltre num lançamento, mantêm uma SBOM desde o primeiro dia e enviam upstream uma pequena correção a uma biblioteca crítica para parar de carregar um remendo privado a cada atualização. Acertar isso cedo também os poupa de uma surpresa dolorosa quando a diligência prévia de um adquirente por fim penteia a árvore de dependências.

Grande empresa. Um fornecedor de software que entrega um produto distribuído roda um OSPO. O OSPO mantém uma lista de licenças aprovadas, um repositório interno curado de componentes e varredura automatizada de licenças e vulnerabilidades em todo pipeline. Quando um desenvolvedor traz uma nova dependência, o pipeline confere a licença contra a política, gera os avisos de atribuição que acompanham o produto e sinaliza qualquer coisa que exija revisão. Os componentes de copyleft forte são permitidos em ferramentas internas mas bloqueados do produto distribuído, para evitar obrigações de divulgação. A empresa envia upstream correções a algumas dependências críticas. Isso eliminou um acúmulo de remendos privados que seus engenheiros antes carregavam a cada atualização.

Governo. Um serviço digital nacional opera sob uma política de “dinheiro público, código público”. Os novos serviços são construídos sobre padrões abertos, desenvolvidos às claras num repositório público de código por padrão e reutilizados entre agências. Seus modelos de contratação exigem que os fornecedores entreguem código aberto, bem documentado e reutilizável, com o governo mantendo os direitos de publicar e modificar. Antes de começar um novo componente, as equipes buscam num catálogo entre governos por código reutilizável existente. Os módulos sensíveis à segurança são isentos de publicação por um processo documentado, e não fechando o sistema inteiro.

Justificativa de negócio: motivações, ROI e TCO

Gerenciar bem o código aberto é a diferença entre capturar sua enorme alavancagem e pagar seus custos ocultos. O código aberto permite a uma grande organização apoiar-se numa fundação que jamais poderia bancar construir. Mas o custo total de propriedade inclui conformidade, correções de segurança e a migração eventual, custos que chegam quer vocês planejem ou não. A gestão deliberada converte crises imprevisíveis e caras em custos pequenos, constantes e planejados. Essas crises incluem uma violação de copyleft achada durante a diligência prévia de uma aquisição, uma migração de emergência para fora de um componente abandonado ou uma vulnerabilidade numa dependência que ninguém sabia que estava lá.

O custo de adoção é modesto diante da exposição: um OSPO ou grupo de trabalho, ferramentas de varredura e a disciplina de manter um inventário. O custo de não adotar aparece como responsabilidade jurídica, diligências prévias malsucedidas, incidentes de segurança rastreados a dependências sem correção e a despesa composta de atualizações adiadas que por fim forçam migrações dolorosas de uma só vez. Ao defender o caso junto à liderança, enquadrem a gestão de código aberto como gestão da cadeia de suprimentos para a maior parte da sua base de código. Observem também o ganho estratégico: aprisionamento evitado, entrega mais rápida, atração de talento e influência sobre os ecossistemas de que vocês dependem. No governo, acrescentem a dimensão do mandato. A abertura costuma ser exigida e não opcional, e fazê-la bem evita tanto a não conformidade quanto o gasto público duplicado.

Antipadrões e armadilhas

Licenciamento de copiar e colar. Desenvolvedores trazendo componentes sem verificar a licença, descobrindo as obrigações só na auditoria ou na aquisição.
Sem inventário. Não conseguir responder “o que estamos usando e sob que licença?” quando surge uma vulnerabilidade ou uma pergunta de licença.
Pânico do copyleft. Banir todo copyleft por medo em vez de entendimento, abrindo mão de ecossistemas valiosos.
A liberação de código aberto abandonada. Publicar um projeto com alarde e depois nunca mantê-lo, prejudicando a reputação.
Ignorar as dependências transitivas. Verificar as dependências diretas enquanto o risco real se esconde várias camadas abaixo.
Surpresa do fim de vida. Descobrir que um componente central perdeu o suporte meses atrás, só quando uma vulnerabilidade força a atenção.
Política mais lenta que copiar. Um processo de conformidade tão pesado que os desenvolvedores o contornam, criando dependências paralelas invisíveis.
Caixas-pretas governamentais. Contratar sistemas proprietários que a agência não consegue manter, compartilhar nem deixar, em violação dos princípios do aberto por padrão.

Modelo de maturidade

Nível 1: Iniciar. Os desenvolvedores acrescentam código aberto livremente, sem política nem inventário. As licenças não são examinadas e as obrigações de copyleft são desconhecidas. O fim de vida é descoberto por acidente, em geral quando uma vulnerabilidade força a atenção. Ninguém é dono da estratégia de código aberto.

Nível 2: Desenvolver. Existem uma política básica e uma lista de licenças aprovadas, e algumas equipes as seguem. A varredura acontece, mas muitas vezes de forma manual, tardia ou só em alguns projetos. Um inventário é mantido para os grandes sistemas enquanto as dependências transitivas ficam sem mapa. A contribuição e o tratamento do fim de vida são ad hoc e inconsistentes entre as equipes.

Nível 3: Padronizar. Um OSPO ou equivalente é dono da estratégia, da política e das ferramentas em toda a organização. A varredura de licenças e vulnerabilidades é automatizada em todo pipeline, os arquivos de atribuição e de avisos são gerados automaticamente e o build é condicionado para que uma licença proibida não entre. As SBOMs são mantidas por toda a árvore transitiva, a contribuição segue um processo documentado, o fim de vida é acompanhado com migrações planejadas e as equipes governamentais publicam por padrão.

Nível 4: Gerenciar. O programa é medido e controlado em relação a linhas de base. Vocês acompanham a cobertura da varredura de políticas entre os serviços, o tempo médio para corrigir uma vulnerabilidade de dependência divulgada, a fração de componentes dentro de sua janela de suporte de segurança, a taxa de escape de violações de licença, a defasagem de atualidade das dependências e a contagem de remendos privados levados upstream. O posicionamento do copyleft em relação à fronteira de distribuição é monitorado, e as métricas contra metas conduzem cada decisão de ir ou não ir em lugar da opinião.

Nível 5: Orquestrar. O código aberto é um ativo estratégico continuamente melhorado e integrado em toda a organização. A conformidade é totalmente automatizada e os componentes fora de conformidade não chegam à produção. Vocês investem deliberadamente em projetos upstream críticos, contribuem rotineiramente e são curadores dos seus próprios projetos bem conduzidos. A atualidade das dependências e o fim de vida são geridos de modo adaptativo conforme o risco e as métricas mudam, e a abertura vira uma genuína vantagem competitiva e cívica.

Ideias para discussão

Onde fica a linha certa entre um padrão permissivo e rápido e o controle necessário para evitar dívida jurídica e de segurança?
Quando uma organização deve financiar ou manter uma dependência upstream crítica em vez de tratá-la como de graça?
Como vocês decidem quais dos seus próprios componentes valem a pena ser liberados e mantidos como código aberto?
Para o governo, qual é um processo defensável de isentar componentes da publicação por padrão sem erodir o princípio?
Quão fundo nas dependências transitivas a revisão de licenças e de segurança precisa realisticamente ir?
O copyleft de rede (AGPL) muda o seu cálculo de construir versus adotar para o software que vocês oferecem como serviço?

Principais conclusões

O código aberto é a maior parte da maioria das bases de código e precisa ser gerenciado como uma cadeia de suprimentos, não tratado como gratuito e sem consequências.
As licenças carregam obrigações reais. Entendam as famílias permissiva, de copyleft fraco, de copyleft forte e de copyleft de rede e como a distribuição e a combinação disparam deveres.
Façam do caminho em conformidade o caminho mais rápido por curadoria, varredura automatizada e padrões claros, ou os desenvolvedores contornarão a política.
Montem um OSPO para ser dono da estratégia, da conformidade, da contribuição e da curadoria em escala.
Mantenham uma SBOM, mantenham as dependências atuais em passos pequenos e planejem o fim de vida antes que ele force uma crise.
No governo, adotem por padrão os padrões abertos e publiquem o código pago com dinheiro público, reutilizando antes de construir.

Referências e leitura complementar

Heather Meeker, Open (Source) for Business and Open Source for Business
Van Lindberg, Intellectual Property and Open Source
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
OpenChain (ISO/IEC 5230), Open Source Licence Compliance
Software Package Data Exchange (SPDX, ISO/IEC 5962) specification
CycloneDX SBOM specification
Free Software Foundation, GNU General Public Licence and GPL FAQ
Open Source Initiative, The Open Source Definition and approved licence list
Free Software Foundation Europe, Public Money, Public Code
U.S. Federal Source Code Policy and Code.gov guidance
UK Government, Technology Code of Practice and open-standards principles