Edição de 03/10: steward open source e fabricante não são o mesmo papel

A licença não preenche o organograma

Esta edição dirige-se a responsáveis de projetos open source, fabricantes que os incorporam e equipas jurídicas. A pergunta é quem recebe a informação de segurança quando o mesmo código atravessa projeto, infraestrutura de desenvolvimento e produto comercial. Não relata um conflito real nem um acontecimento de 3 de outubro.

A página da Comissão sobre open source distingue fabricantes que colocam produtos no mercado de pessoas coletivas que prestam apoio sustentado ao desenvolvimento e viabilidade de determinados produtos open source destinados a atividades comerciais, no papel de steward. A licença aberta, isoladamente, não decide qual dessas relações existe. A aplicação a uma entidade concreta exige examinar a atividade.

Um regime adaptado, não um fabricante menor

O artigo24 prevê para stewards uma política de cibersegurança documentada e um enquadramento de cooperação. Não deve ser resumido como «todas as obrigações de fabricante, mas com menos recursos». A responsabilidade está associada ao papel específico que o regulamento define.

No n.º3, a remissão para o artigo14(1) aplica-se na medida do envolvimento no desenvolvimento; as remissões para artigo14(3) e (8) estão ligadas a incidentes graves que afetem redes e sistemas disponibilizados para esse desenvolvimento. Estas qualificações impedem tratar qualquer incidente em qualquer produto derivado como um dever universal e idêntico do steward.

Não alinhar dois calendários diferentes

O artigo71 distingue aplicação geral em 11 de dezembro de 2027 e aplicação do artigo14 em 11 de setembro de 2026. A Comissão esclarece na página de reporte que obrigações de stewards do artigo24(3) se aplicam a partir de 11 de dezembro de 2027. Não converter a data dos fabricantes num início antecipado de todo o regime dos stewards.

A preparação proposta pela Velqory pode começar antes: mapear contactos, infraestrutura e passagem de informação. Isso é organização voluntária desta proposta, não prova de que uma fundação já está sujeita em outubro a todos os deveres do artigo24. A redação deve manter a data e a remissão junto da conclusão.

Passar informação sem transferir o papel

A matriz é uma proposta não testada. Procura evitar que «já avisámos o projeto» signifique «já tratámos a versão vendida». O responsável pelo produto comercial deve conhecer a sua distribuição; o contacto do projeto deve saber que informação pode receber de forma segura.

O patch upstream não atualizou o produto

Cenário hipotético: um projeto publica uma correção, mas o fabricante continua a distribuir um produto que incorpora a revisão anterior. A passagem de informação precisa de dois destinatários: quem mantém o projeto e quem consegue alterar a versão comercial. Não invente que qualquer um deles é automaticamente steward.

O exercício proposto pede aos dois lados que indiquem a revisão usada, o canal seguro de contacto e o dono da decisão seguinte. Falha se o fabricante fecha o assunto apenas porque existe um commit no projeto. Passa se a dependência está ligada a uma release e a uma tarefa atribuída, sem alegar eficácia de uma atualização ainda não verificada.

Uma relação aberta precisa de fronteiras claras

A recomendação Velqory é escrever um acordo operacional pequeno sobre contacto, informação sensível e acompanhamento, sem transformar cooperação em transferência fictícia de responsabilidade. Evite exigir a voluntários declarações sobre produtos de terceiros que não conseguem conhecer.

Guarde a qualificação do papel e reveja-a se mudar comercialização, entidade ou suporte prestado. Um mesmo ecossistema pode reunir atividades diferentes; uma etiqueta para o repositório não substitui essa análise. O resultado útil é saber quem pode responder a cada pergunta, que obrigação ainda não é aplicável e que trabalho de preparação foi voluntariamente assumido.