CRA e open source: quem assume a responsabilidade pelo produto?

Primeiro, separar três papéis

A Comissão esclarece que contribuir código para software que não está sob a responsabilidade do contribuidor não equivale a assumir o papel de fabricante. O software livre e aberto disponibilizado fora de uma atividade comercial fica fora do âmbito descrito. Já colocar um produto no mercado pode trazer as obrigações de fabricante, mesmo que o produto seja open source.

O steward é uma pessoa coletiva que, sem ser fabricante, apoia sistematicamente e de forma continuada o desenvolvimento de produtos abertos destinados a atividades comerciais e desempenha um papel principal na sua viabilidade. Uma fundação não recebe esta classificação apenas por se chamar fundação; é necessário examinar a atividade concreta.

O regime específico não é uma ausência de obrigações

O artigo 24 prevê uma política de cibersegurança documentada, cooperação com autoridades e reporte delimitado. As vulnerabilidades dizem respeito aos produtos em cujo desenvolvimento o steward participa; os incidentes graves abrangidos devem afetar os sistemas que disponibiliza para esse desenvolvimento. O artigo 64(10) exclui os stewards das coimas administrativas ali previstas, não do próprio regime.

O calendário exige cuidado: o artigo 71 antecipa o artigo 14 para 11 de setembro de 2026 e fixa a aplicação geral em 11 de dezembro de 2027. O artigo 24 não é nominalmente antecipado. Não inferimos que a remissão para o artigo 14 antecipe automaticamente todo o regime dos stewards; um caso concreto exige confirmação jurídica.

Perspetiva Velqory: a ficha que deve acompanhar a compra

Em vez de enviar um questionário indiferenciado à comunidade, proponho uma ficha por produto. Compras identifica o fornecedor contratual; engenharia identifica os componentes e a cadeia de atualização; jurídico valida o papel da entidade que coloca o produto no mercado. O mesmo grupo pode ter atividades diferentes: não copie a classificação de um projeto para todos os outros.

• Que produto, versão e entidade são objeto do contrato? Quem disponibiliza atualizações e recebe comunicações de vulnerabilidades?
• Que factos sustentam a classificação proposta? Registar distribuição, atividade comercial e controlo do desenvolvimento; não aceitar apenas a expressão open source.
• Que questão continua por resolver? Dar-lhe responsável e data antes da aprovação, sem transformar uma opinião do fornecedor em conclusão jurídica.

O resultado útil é uma responsabilidade identificável

Este documento não certifica conformidade nem analisa contratos reais. A recomendação é chegar à contratação com um contacto operacional, uma classificação fundamentada e uma lista explícita de dúvidas. Se ninguém consegue explicar quem corrige o produto entregue, a licença aberta não resolve essa lacuna. Também não é motivo para transferir obrigações do integrador para um contribuidor voluntário.