O código aberto não é uma renúncia de responsabilidade

Publicar o código-fonte altera quem pode inspecioná-lo, reutilizá-lo e melhorá-lo. Não elimina o trabalho prático de saber o que está implementado, o que é...

O código aberto não é uma renúncia de responsabilidade

A repository is an opening, not an ending

There is a comforting little story about open source. A group publishes code. Other people can read it. The code becomes a common good, or at least a useful common nuisance. Responsibility dissolves into the crowd.

The first two sentences may be true. The last one is not. A public repository can widen inspection, reuse and contribution. It can give an organisation a clearer exit route than a closed service. It can allow a public body to examine a component without asking a supplier for permission. None of that answers the question that arrives on an ordinary Tuesday morning: which version is running here, under which licence, with which configuration, and who is going to act if the security advisory applies?

Open source changes the shape of responsibility. It does not make responsibility optional. The maintainer still has decisions to make about releases, security reports, supported versions and licensing. The organisation that packages a component still has decisions to make about provenance, updates and what it tells its users. The deployer still has decisions to make about inventory, exposure, configuration, access and recovery. A licence gives permissions and conditions. It does not provide an on-call rota.

This matters because open source has become ordinary infrastructure. It sits in operating systems, browsers, public services, research tooling, industrial systems and the libraries that make a product look more self-contained than it is. The mature question is therefore not whether an organisation is for or against open source. It is whether it can carry the responsibilities created by the software it chooses to depend on.

European policy has begun to describe that distinction more plainly. The Cyber Resilience Act regulates products with digital elements and includes a specific route for free and open-source software stewards. The route recognises that a person or organisation which provides sustained support for free and open-source software can occupy a real place in the security chain. It does not turn every volunteer who publishes code into a manufacturer. Equally, it does not allow a commercial actor to hide behind a public repository when that actor brings a product to market.

The practical consequence is pleasantly unromantic. Treat every dependency as something that must be named, understood and looked after. That is not an attack on open source. It is the discipline that lets open source remain useful when the novelty has gone.

What publication actually changes

Source availability changes several things at once. A reader can inspect the implementation rather than infer it from a marketing page. A team can reproduce a build if the build instructions, dependencies and environment permit it. A supplier can be replaced more readily when the licence and interfaces allow it. A researcher can test a claim, a security team can review a patch, and a public buyer can ask questions without treating a black box as a constitutional principle.

Those are significant public goods. They are also conditional. Code that is visible but impossible to build is less inspectable than it first appears. Code that is buildable but lacks a clear licence leaves reuse uncertain. Code that is licensed but assembled from unknown dependencies carries a provenance problem. Code that is maintained only in a branch no one can identify is not made reliable by the fact that a repository page exists.

A Open Source Initiative descreve o código aberto através de uma licença aprovada e de um conjunto de direitos, incluindo o acesso ao código-fonte e a liberdade de redistribuir e modificar nos termos estabelecidos. Essa definição é deliberadamente sobre permissões. Não é um acordo de nível de serviço, uma certificação de segurança, uma garantia de adequação a uma tarefa pública específica ou uma garantia de que um componente será mantido indefinidamente. A ausência dessas promessas não é um defeito na definição. É uma razão para ser exato sobre aquilo em que uma organização está a confiar.

Ajuda separar quatro perguntas que muitas vezes são agrupadas numa única palavra amigável. O código-fonte está disponível? Está licenciado para o uso pretendido? A organização consegue estabelecer de onde vieram o código e as suas dependências? Há alguém a assumir ativamente o trabalho operacional que esta implementação exige? Uma resposta afirmativa à primeira pergunta não responde às outras três.

Essa separação também torna as conversas menos teatrais. Uma equipa de aquisições não precisa de fingir entusiasmo por um repositório. Precisa de saber se o componente é adequado para o sistema que está a comprar ou a operar. Uma equipa de engenharia não precisa de se desculpar por usar uma licença permissiva. Precisa de saber como vai cumprir os avisos de licença, preservar os materiais exigidos, atualizar dependências e responder a um problema divulgado. Uma equipa jurídica não precisa de se tornar gestora de lançamentos. Precisa de um caminho para o processo de lançamento antes de um problema de licença se tornar uma correção pública.

O código-fonte pode passar por várias mãos. Selecione uma camada para distinguir as responsabilidades de publicação, empacotamento, colocação de produto e implementação.

A licença é um limite, não uma previsão meteorológica

As licenças são por vezes tratadas como um detalhe administrativo, como se o trabalho jurídico começasse depois de o trabalho de engenharia estar concluído. Na prática, as escolhas de licença moldam as decisões de engenharia desde o início. Afetam se um componente pode ser combinado com outro, se os avisos devem acompanhar uma distribuição, se o código-fonte modificado deve ser oferecido em determinadas circunstâncias e se uma equipa consegue cumprir as condições associadas aos direitos que pretende usar.

Isso não significa que todos os engenheiros tenham de se tornar especialistas em direitos de autor. Significa que a organização precisa de uma tradução fiável entre o software que constrói e os compromissos que assume quando distribui, aloja ou modifica esse software. A tradução tem de acontecer enquanto os factos ainda estão disponíveis: qual o pacote selecionado, qual a versão utilizada, se foi alterado, como foi ligado ou incluído, com o que é distribuído e qual é a rota de distribuição pretendida.

Não há uma resposta universal em matéria de licenças. Uma licença permissiva pode tornar a reutilização simples, exigindo ainda avisos e preservação do texto de direitos de autor. Uma licença recíproca pode acrescentar condições adicionais à distribuição ou modificação. Um acordo de dupla licença pode exigir que uma organização escolha uma via comercial ou uma via específica de código aberto. Uma organização não deve inferir obrigações a partir de um apelido de licença, de um distintivo de gestor de pacotes ou da história mal lembrada de um colega de 2014. Deve ler o texto da licença, registar a decisão e pedir aconselhamento quando o uso pretendido for incerto.

O cumprimento das licenças também não é um exercício cerimonial reservado para a semana de lançamento. Uma lista de materiais de software, um inventário de dependências e um registo de lançamento podem tornar a pergunta posterior respondível: o que foi incluído neste artefacto? Mas uma lista só é útil se descrever um artefacto, uma versão e uma data definidos. Uma folha de cálculo chamada dependencies-final-final.xlsx não é um sistema de proveniência. É uma camada arqueológica.

Para uma instituição pública, isto é mais do que tarefa administrativa. A instituição pode precisar de preservar a capacidade de explicar porque foi escolhido um componente, que termos o regem, como pode ser substituído e o que acontece se a manutenção cessar. Para uma organização comercial, os mesmos registos afetam compromissos contratuais, atualizações de produtos e comunicações com clientes. Para uma equipa pequena, a escala é diferente, mas a lógica não é. Se um projeto não consegue identificar a licença do código que distribui, não pode afirmar honestamente que a fronteira legal está sob controlo.

A medida responsável é proporcionada, não grandiosa. Registe as dependências diretas. Preserve os textos das licenças e os avisos exigidos juntamente com o lançamento. Registe as modificações materiais. Defina um ponto de revisão para termos de licenciamento novos ou invulgares. Atribua a alguém a responsabilidade de resolver incertezas. Estes são controlos modestos. O seu valor é impedirem que a incerteza se torne uma surpresa depois de o software ter circulado.

A manutenção é trabalho, mesmo quando é doada

A manutenção de software de código aberto é frequentemente descrita como se fosse uma virtude pessoal. Por vezes é. As pessoas revêem correções, respondem a perguntas, empacotam lançamentos e evitam que pressupostos antigos se tornem na indisponibilidade de amanhã porque se preocupam com uma ferramenta e com as pessoas que a utilizam. Essa generosidade merece respeito. Não deve ser usada como modelo de negócio sem uma decisão de negócio.

A manutenção é trabalho operacional. Inclui decidir que versões são suportadas, rever contribuições, publicar informação de segurança, gerir um processo de lançamento, responder a relatos, documentar alterações que quebram compatibilidade, manter a infraestrutura de compilação utilizável e, por vezes, dizer não. A última parte é subvalorizada. Um projeto que não consegue recusar um pedido de funcionalidade, uma plataforma não suportada ou um atalho inseguro não é necessariamente mais aberto. Pode simplesmente estar mais exposto.

A Estratégia de Software de Código Aberto da Comissão Europeia trata o código aberto como uma forma de melhorar a reutilização, a transparência, a colaboração e a independência tecnológica na administração pública. Esses benefícios dependem de capacidade. A reutilização exige que uma organização compreenda o que está a reutilizar. A transparência exige que alguém leia o que é divulgado. A independência exige mais do que a posse de um botão de clonagem: exige a capacidade prática de operar, adaptar ou obter suporte para o software quando o contribuidor original já não está envolvido.

É por isso que a pergunta «está mantido?» precisa de mais forma. Pode significar que existem lançamentos recentes. Pode significar que um contacto de segurança está publicado. Pode significar que o projeto descreve versões suportadas, instruções de compilação e um processo de contribuição. Pode significar que uma organização comprometeu tempo pago para o trabalho. Pode significar que quem implementa o software tem capacidade própria para manter uma bifurcação ou substituir um componente. Estes são factos diferentes. Um gráfico de atividade verde pode ser uma evidência útil, mas não é um contrato de manutenção.

Um adotante responsável deve, portanto, decidir que tipo de manutenção precisa antes de decidir o que espera que uma comunidade forneça. Uma ferramenta interna de baixo risco pode ser compatível com um projeto pequeno e um plano de atualização modesto. Um componente no centro de um produto exposto externamente precisa de um modelo de suporte mais claro, uma avaliação de vulnerabilidades mais rápida e um plano de saída. A distinção não tem a ver com o prestígio do projeto. Tem a ver com a consequência de estar errado.

Há um pequeno hábito holandês que vale a pena importar: não confundir gezellig com governado. Uma comunidade acolhedora pode ser um lugar maravilhoso para contribuir. Isso não significa que tenha obrigação de manter o seu sistema de produção a funcionar. A organização que coloca esse sistema em produção é dona dessa diferença.

A divulgação de vulnerabilidades precisa de um percurso antes de precisar de um slogan

A maioria das pessoas concorda, em abstrato, que as vulnerabilidades devem ser divulgadas de forma responsável. A parte difícil é menos abstrata. Para onde envia o denunciante uma descoberta? Quem a recebe? Que informação é necessária para a reproduzir? Quem decide se afeta uma versão suportada? Como se desenvolve uma correção sem criar uma janela de exposição pública desnecessária? Como são informados os utilizadores sobre o que fazer? Que pacotes a jusante precisam de uma atualização? O que acontece se o denunciante não receber resposta?

Estas perguntas não são prova de desconfiança em relação ao código aberto. São o trabalho de tratar os utilizadores como pessoas que precisam de uma resposta. O trabalho da ENISA sobre divulgação de vulnerabilidades e divulgação coordenada de vulnerabilidades descreve o valor de processos definidos entre denunciantes, fornecedores e outras partes relevantes. Um processo não garante que todos os relatos estejam corretos ou que todas as correções sejam rápidas. Pode reduzir a probabilidade de um problema grave começar a sua vida numa caixa de entrada sem supervisão.

Um projeto pode publicar uma política de segurança, um endereço para relatos e informação sobre versões suportadas. São sinais úteis, especialmente quando descrevem o que o denunciante pode esperar. Um projeto também pode ser demasiado pequeno para oferecer o tempo de resposta de que uma implementação importante precisa. Isso não é uma falha moral. É um facto de planeamento para a organização que escolhe a dependência.

O mesmo se aplica a jusante. Um fabricante não pode razoavelmente dizer que uma vulnerabilidade é problema de outra pessoa apenas porque o componente vulnerável começou num repositório aberto. Se o fabricante colocar no mercado da União um produto com elementos digitais, o Regulamento Ciberresiliência estabelece requisitos sobre o tratamento de vulnerabilidades e a entrega de atualizações de segurança no âmbito do quadro aplicável ao produto. O detalhe jurídico depende do produto e do papel. O ponto operacional é mais simples: a parte que disponibiliza o produto precisa de uma forma de saber se uma alteração a montante afeta aquilo que forneceu.

É aqui que um inventário se torna ativo em vez de decorativo. Tem de ligar um componente a uma versão, a uma compilação, a um lançamento de produto e a um responsável capaz de avaliar o relato. O responsável não tem de corrigir sozinho todas as falhas a montante. Tem de decidir se atualiza, atenua, desativa, notifica, compensa ou deixa de usar o componente. «Usamos código aberto» é uma descrição de um contributo. Não é um plano de resposta.

Considere um exemplo explicitamente hipotético. Uma equipa inclui uma biblioteca num serviço de processamento de documentos. Meses depois, um aviso de segurança identifica um intervalo vulnerável. Se a equipa registou o componente, a versão e os serviços em que é compilado, pode começar uma avaliação. Se conseguir reproduzir as compilações e testar a atualização, pode decidir se a solução é uma atualização, uma alteração de configuração ou uma restrição temporária. Se não tiver nem registo nem responsável, a primeira tarefa é trabalho de investigação. A vulnerabilidade pode ser idêntica em ambos os casos. O risco operacional não é.

Um percurso de divulgação não promete que todos os problemas sejam pequenos. Torna visível a próxima ação responsável quando um problema é encontrado.

Provenance is the answer to ‘what exactly are we running?’

Software provenance can sound like a word borrowed from a museum label. The underlying question is ordinary: where did this artefact come from, and can we show the path? For software, the path may include source repositories, released archives, dependency registries, build tools, configuration, signing keys, build environments and publication systems. The answer is rarely one elegant fact. It is a collection of records which must agree well enough for a person to make a decision.

Provenance does not require an organisation to claim perfect knowledge. It requires it to say what is known, what was checked and where uncertainty remains. A reproducible build may provide strong evidence that defined source and a defined environment produced a corresponding artefact. A signed release may help identify the key used to assert a release. A software bill of materials may describe declared components. None of these independently proves that code is harmless, that every transitive dependency has been reviewed or that a release is fit for a particular use. Together, they can make a later investigation much less speculative.

This distinction is important because provenance is often sold as a magic stamp. It is not. A hash can tell you that two byte sequences match. It cannot tell you that the matching program should be allowed to process sensitive records. A signature can connect a release to a key. It cannot tell you that the person controlling the key followed a good review process. An inventory can name a component. It cannot tell you whether the component is configured safely. Evidence is still evidence, not a substitute for judgement.

Yet the absence of provenance makes judgement poorer. When a team cannot establish which source revision created a deployed package, it cannot confidently connect an upstream fix to its own service. When it cannot identify a transitive dependency, it cannot assess a notice or advisory without first reconstructing the supply chain. When the build produces different results without explanation, it cannot tell whether a binary has changed because of source, environment or interference. These are practical limits, not purity tests.

European digital sovereignty is often reduced to the location of a server. Location matters. It is not enough. A system can run in Europe while relying on a build pipeline, dependency registry or update channel the operator cannot inspect, control or replace. Conversely, open source can offer a real route to scrutiny and portability, while still leaving an adopter responsible for the capability needed to use that route. Sovereignty is an ability to act under pressure, not a flag attached to a container image.

A useful provenance record should allow a technically competent colleague to trace a release backwards and forwards. Backwards: which source, dependencies and build process led here? Forwards: which services, products and users may be affected if this component is changed or withdrawn? The record can be proportionate. A small internal tool does not need the machinery of an aircraft programme. But it does need enough truth to support the consequences of its use.

The Cyber Resilience Act draws a line without pretending the world is simple

The Cyber Resilience Act is often summarised as a new set of cybersecurity requirements for connected products. That is true but incomplete. Its more useful contribution to this discussion is the distinction it makes between roles. A free and open-source software steward can be an entity that provides sustained support for the development of products with digital elements qualified as free and open-source software and that is designed to ensure the viability of those products. The regulation sets conditions around that role. It does not treat every contributor as carrying the same obligations as a manufacturer.

Esta distinção reconhece como o código aberto funciona na prática. Um projeto pode ter contribuidores individuais, uma associação, uma fundação, uma empresa que oferece suporte, uma distribuição que empacota o software, um integrador e um fabricante que o inclui num produto. As suas responsabilidades estão relacionadas, mas não são intercambiáveis. Um contribuidor pode corrigir uma falha. Um administrador pode coordenar o projeto. Um distribuidor pode empacotá-lo. Um fabricante pode colocar um produto no mercado. Um implementador pode decidir como esse produto lida com dados reais e pessoas reais. O repositório público é um ponto de encontro entre estes papéis, não um misturador legal.

Para as organizações, a leitura mais segura não é transformar a lei em folclore antes de esta ser aplicada. A lei tem datas de aplicação faseadas e disposições específicas para cada papel. A interpretação jurídica deve basear-se no texto aplicável e em aconselhamento competente, especialmente quando está envolvido um produto, uma atividade comercial ou uma colocação no mercado. A preparação operacional, no entanto, não precisa de esperar por um seminário com café frio e um diapositivo intitulado «visão geral». Inventarie os componentes. Identifique quem é responsável pelas atualizações. Preserve as provas de lançamento. Defina um canal de comunicação de incidentes de segurança. Decida o que significa suportado. Essas ações são úteis quer uma determinada cláusula se aplique hoje, no próximo ano ou nunca.

A lei também resiste a uma falsa escolha. Não diz que o código aberto é inseguro. Também não diz que a publicação isenta um produto comercial do trabalho de segurança. Reconhece que a segurança do software utilizado em produtos tem consequências públicas e que a cadeia de intervenientes precisa de responsabilidades mais claras. As obrigações exatas merecem uma leitura jurídica cuidadosa. O princípio é simples: o software que chega às pessoas através de um produto precisa de alguém capaz de tomar medidas responsáveis quando o risco se torna conhecido.

Esse princípio já é familiar noutras áreas. Uma receita publicada não isenta um restaurante da segurança alimentar. Uma norma de construção publicada não dispensa um empreiteiro do dever de a utilizar com competência. A comparação tem limites: as licenças de software, os canais de atualização e as comunidades de desenvolvimento têm as suas próprias estruturas. Mas a ideia fundamental mantém-se. O conhecimento tornado público pode tornar possível uma verificação independente. Não remove a responsabilidade de quem serve a refeição ou abre a porta.

O que os adotantes devem a si próprios

A política de código aberto mais útil é muitas vezes uma política operacional disfarçada de lista de verificação sensata. Deve responder a quem pode introduzir uma dependência, que informações devem ser registadas, como as licenças são analisadas, como as atualizações são avaliadas, como os relatórios de segurança são encaminhados e quem pode aprovar uma exceção. Deve também responder ao que acontece quando o suporte termina. Uma política que explica a seleção mas nada diz sobre a remoção é apenas meia política.

Comece pela unidade que realmente importa: o artefacto ou serviço implementado, não um catálogo abstrato de projetos favoritos. Para cada componente material, uma organização deve ser capaz de localizar a versão, a origem ou o caminho do registo, a licença, o papel interno responsável, o sistema em que é utilizado e o caminho de atualização. O nível de detalhe deve acompanhar a consequência de uma falha. O objetivo não é transformar todos os programadores em burocratas. É impedir que factos importantes se tornem conhecimento privado num único computador portátil ou na memória de uma única pessoa.

Depois, decida que provas mudarão uma decisão. Um aviso publicado pode desencadear uma avaliação. Um novo lançamento pode desencadear um teste de compatibilidade. Uma alteração de licença pode desencadear uma revisão jurídica. Uma versão suportada abandonada pode desencadear um plano de migração. Uma compilação que já não é reproduzível pode desencadear uma investigação. Sem estes gatilhos, os inventários tendem a tornar-se documentos históricos: precisos no dia em que foram exportados, educadamente ignorados depois.

Coloque a propriedade perto da ação. Uma equipa central de governação pode definir políticas e fornecer conhecimentos especializados. Não pode operar todos os serviços. Uma equipa de produto pode conhecer a arquitetura da sua própria implementação. Pode não estar equipada para interpretar todas as licenças. O acordo funciona quando a transição é explícita: o responsável pelo produto avalia o impacto, a segurança aconselha sobre a exposição e a resposta, o jurídico ou a conformidade avalia as condições da licença quando necessário, as compras regista os compromissos externos, e um decisor nomeado aceita ou rejeita o risco material. Os nomes variam. A ausência de nomes é o problema recorrente.

Mantenha uma rota de saída. O código aberto pode reduzir a dependência de um fornecedor, mas apenas se uma organização puder reconstruir, bifurcar, substituir ou contratar suporte quando as circunstâncias mudarem. Um espelho do repositório, instruções de compilação, uma rota de dependências em cache e um registo da configuração necessária podem ser trabalho monótono até o serviço original ficar indisponível ou a relação terminar. O trabalho monótono tem um bom historial em emergências.

Por fim, seja honesto sobre o risco residual. Nenhum programa de dependências pode garantir que todas as vulnerabilidades serão encontradas primeiro, que todos os projetos a montante permanecerão ativos ou que todas as questões de licença serão simples. O objetivo da governação não é prometer o impossível. É tornar a incerteza visível cedo o suficiente para que uma pessoa responsável possa decidir o que fazer com ela.

O que os mantenedores podem razoavelmente oferecer

Os mantenedores não devem ao mundo trabalho ilimitado por terem publicado código útil. Essa expectativa é injusta e insegura. Um projeto pode ser generoso na reutilização enquanto é explícito sobre a sua capacidade. Pode indicar quais versões são suportadas, onde reportar problemas de segurança, como são tomadas as decisões de lançamento, que tipos de contribuições pode rever e o que não vai prometer. Limites claros são melhores para os adotantes do que uma ambiguidade calorosa.

Mesmo um pequeno projeto pode melhorar a transição operacional com alguns documentos duradouros: um ficheiro de licença, um processo de lançamento legível, um contacto de segurança ou política de divulgação, informação de versionamento, orientação sobre dependências quando relevante, e uma declaração clara sobre se a manutenção é ativa, limitada ou concluída. Nenhum destes cria uma garantia. Cada um ajuda um utilizador a jusante a fazer uma escolha mais informada.

Quando um projeto tem apoio organizacional, a conversa pode ir mais longe. A organização pode publicar uma política de versões suportadas, descrever a sua governação, registar a sua prática de assinatura de lançamentos, manter uma rota de resposta a vulnerabilidades e explicar como os utilizadores podem obter suporte. Estes não são distintivos para uma página de destino. São promessas operacionais, e só devem ser escritas onde a organização está preparada para as cumprir.

A mensagem de manutenção mais honesta pode ocasionalmente ser "não podemos assumir isto". Isso pode significar que uma funcionalidade está fora do âmbito, que uma plataforma não pode ser testada, que um relatório de segurança precisa de mais informação, que um ramo já não é suportado ou que uma data de lançamento não pode ser prometida. Uma recusa clara dá aos adotantes algo em torno do qual podem planear. O silêncio dá-lhes uma história para contarem a si próprios, o que é geralmente um contributo mais caro.

Há também uma responsabilidade para os utilizadores que dependem de um projeto. Reporte defeitos com detalhe suficiente para os reproduzir. Siga a rota de segurança, se existir. Contribua com testes, documentação, financiamento ou revisão quando possível. Não exija uma relação de serviço de um projeto voluntário enquanto recusa reconhecer que uma relação de serviço custa dinheiro. A reciprocidade não abole papéis diferentes, mas pode tornar a cadeia menos frágil.

O código aberto pode reforçar a responsabilização

Depois de enumerar todos estes deveres, há a tentação de concluir que o código aberto cria demasiado trabalho. Não cria. O trabalho existe quer o código seja visível ou não. As dependências fechadas também precisam de inventário, consciência de licenças, resposta a vulnerabilidades, proveniência e um plano de saída. Apenas tornam algumas provas mais difíceis de inspecionar e algumas alternativas mais difíceis de exercer.

O código aberto pode permitir uma postura de responsabilização mais forte. Um comprador pode inspecionar a arquitetura. Um operador pode guardar uma cópia do código e das instruções de compilação. Um revisor independente pode testar uma afirmação. Uma autoridade pública pode evitar que o roteiro privado de um fornecedor seja a única via para uma correção. Uma comunidade pode encontrar e corrigir um problema que uma organização não detetou. São vantagens significativas, especialmente em contextos europeus onde o valor público, a continuidade e a contestabilidade não são decoração opcional.

Mas a possibilidade não é a conclusão. A inspecionabilidade só ajuda quem está apto e autorizado a inspecionar. A portabilidade só ajuda quem preservou os artefactos e sabe como os mover. Um fork só é uma estratégia de saída quando existe uma equipa, um orçamento e uma via legal capazes de o sustentar. «O código está no GitHub» não é um plano de continuidade, tal como «os ficheiros estão num armário» não é uma estratégia de arquivo.

O nosso trabalho de código aberto na Dweve mantém essa fronteira em vista. O Knot é descrito nos nossos materiais publicados como um registo de auditoria assinado e à prova de adulteração para execuções de agentes de IA, com verificação offline de um registo recebido através de uma chave pública. Isso torna uma afirmação mais inspecionável. Não decide o que uma organização deve registar, quem pode aceder a um registo, durante quanto tempo o deve conservar ou quem investiga um resultado inesperado. Essas continuam a ser decisões de governação em torno da ferramenta. A ferramenta pode preservar provas. Não pode tornar-se na organização responsável em nome de ninguém.

Essa é a promessa modesta que vale a pena manter. O código aberto pode dar às pessoas mais provas, mais opções e mais espaço para contribuir. Não se deve pedir-lhe que forneça uma absolvição fictícia de manutenção, segurança, licenciamento ou discernimento operacional.

A responsabilidade sobrevive ao botão de publicação

Publicar código-fonte é um ato útil. Pode convidar ao escrutínio, baixar barreiras à reutilização e tornar uma escolha técnica mais fácil de contestar. Numa cultura tecnológica saudável, deve ser normal que instituições públicas e empresas considerem o código aberto a sério, o apoiem devidamente e expliquem as suas escolhas sem superstição.

O botão de publicação não é, no entanto, um alçapão sob a responsabilidade. Não elimina a necessidade de saber o que um produto contém. Não corrige um serviço em produção. Não preserva um aviso de licença, não faz a triagem de uma divulgação, não mantém uma compilação nem decide se um sistema deve continuar em uso. Essas tarefas continuam a pertencer a pessoas e organizações com funções, orçamentos, autoridade e consequências.

A boa notícia é que a prática responsável não é mística. Identifique a dependência. Leia a licença. Conserve a proveniência. Decida quem é responsável pela atualização. Dê um caminho aos relatos de segurança. Preserve uma saída. Diga claramente o que é suportado e o que não é. Quando estes hábitos estão presentes, o código aberto torna-se mais do que um gesto em direção à transparência. Torna-se infraestrutura que pode ser inspecionada, mantida e em que se pode confiar por razões que sobrevivem a um dia difícil.

A pergunta por detrás da pergunta

Quando uma equipa pergunta se um componente é open source, está muitas vezes a fazer várias perguntas mais subtis ao mesmo tempo. Podemos confiar nele? Podemos abandoná-lo? Podemos alterá-lo? Outra pessoa pode auditá-lo? Podemos obter ajuda quando algo falha? A licença e o repositório podem contribuir para a resposta, mas nenhum deles consegue responder sozinho. A confiança decorre de evidências, competência, incentivos e da forma como uma implementação específica é governada. Abandonar depende de interfaces, formatos de dados, conhecimento de construção e recursos. Alterar depende de capacidade técnica e dos termos ao abrigo dos quais a alteração pode ser feita. A ajuda depende de uma relação de suporte efetiva ou da capacidade de operar sem ela.

Estas distinções são uma defesa contra o cinismo e contra o pensamento ilusório. O cinismo diz que o open source é apenas trabalho não remunerado. O pensamento ilusório diz que é automaticamente mais seguro porque muitos olhos podem inspecioná-lo. Nenhuma destas afirmações diz ao operador o que fazer a seguir. O operador precisa de saber quais olhos analisaram efetivamente a versão relevante, quem pode testar uma correção, que autoridade existe para fazer uma alteração e como o resultado chega ao sistema afetado. A segurança é uma cadeia de ações verificadas, não um provérbio sobre multidões.

A mesma contenção aplica-se à aquisição. Pedir a um fornecedor um componente open source não torna um contrato menos importante. Altera as perguntas que um bom contrato pode fazer: que componentes a montante estão incluídos, como serão tratados os avisos e as obrigações de código-fonte, que versões são suportadas, que evidências acompanham uma versão, o que acontece às correções durante o período de suporte e que material pode o cliente reter para preservar a continuidade. Um comprador deve valorizar a capacidade de inspecionar e de mudar. Deve também precificar a capacidade necessária para usar essa capacidade.

Não há virtude em criar um processo extenso para um utilitário pequeno, e não há prudência em usar um único gráfico de atividades como modelo de governação para um serviço crítico. A proporção é a arte prática aqui. Quanto maior a exposição, mais consequentes os dados, mais difícil a recuperação e mais central o componente, mais fortes devem ser os registos e os acordos operacionais. Isto não é burocracia por si só. É uma tentativa de manter a decisão real perto da consequência real.

O open source conquista o seu lugar na infraestrutura digital europeia quando ajuda as instituições a permanecerem capazes: capazes de verificar, capazes de alterar, capazes de explicar e capazes de continuar. A capacidade é mais lenta de adquirir do que o entusiasmo. Precisa de tempo, pessoas, documentação, testes e da disponibilidade ocasional para financiar trabalho que nunca se tornará um discurso de abertura de conferência. É também a coisa que permanece quando um repositório popular, uma relação com um fornecedor ou um calendário de versões muda sem pedir permissão.

Essa é a responsabilidade na sua forma útil, sem glamour e totalmente pública.

Fontes