CRA e código aberto: distinguir colaboradores, fabricantes e administradores

O que é

Situação em 25 de outubro de 2026. O CRA trata o software de código aberto de acordo com o fornecimento do produto e o papel da entidade. Consulte novamente o regulamento, suas retificações e as orientações da Comissão sobre código aberto quando houver mudanças de financiamento, distribuição ou responsabilidade. As orientações usadas aqui foram atualizadas em 15 de outubro de 2026.

A Comissão explica que software de código aberto fornecido comercialmente no mercado pode estar abrangido pelo CRA. Ela também distingue os colaboradores de software fora de sua responsabilidade e uma categoria separada de administradores de software de código aberto. Uma licença de código aberto, por si só, não resolve essa classificação. Orientações da Comissão sobre código aberto.

Por que importa

O considerando 18 separa o financiamento do desenvolvimento do fornecimento comercial. Contribuições de fabricantes, apoio financeiro e lançamentos regulares não tornam, por si sós, uma atividade de código aberto comercial. Software não monetizado por seu fabricante não deve ser tratado como fornecido comercialmente por esse motivo. Por outro lado, um download gratuito não é conclusivo: o considerando 15 aborda a monetização por outros serviços e cobranças de suporte que excedem a recuperação dos custos reais. A análise diz respeito à organização efetiva da atividade, não apenas à licença do repositório. Regulamento, considerandos 15 e 18.

As datas também diferem. A notificação por fabricantes segundo o artigo 14 é aplicável desde 11 de setembro de 2026. As obrigações dos administradores segundo o artigo 24, incluindo a notificação, aplicam-se a partir de 11 de dezembro de 2027. A página da Comissão sobre notificações afirma essa distinção explicitamente.

Como aplicar

• Identifique a responsabilidade por cada produto. O considerando 18 exclui pessoas físicas e jurídicas que apenas contribuem com código-fonte para produtos de código aberto fora de sua responsabilidade. Essa redação não deve ser ampliada para uma isenção geral de qualquer pessoa chamada de mantenedor.
• Examine o papel de fabricante. O artigo 3(13) diz respeito à entidade que desenvolve ou encomenda o desenvolvimento de um produto e o comercializa sob seu próprio nome ou marca. Quando um produto de código aberto abrangido é colocado comercialmente no mercado, a Comissão afirma que se aplicam as obrigações do fabricante. A maioria dos requisitos mais amplos do CRA é aplicável a partir de 11 de dezembro de 2027, conforme o artigo 71; a obrigação de notificação tem a data anterior.
• Verifique separadamente a definição de administrador de software de código aberto. O artigo 3(14) identifica uma pessoa jurídica, diferente de um fabricante, que apoia sistematicamente o desenvolvimento ao longo do tempo de determinados produtos de código aberto destinados a atividades comerciais e garante sua viabilidade. Um rótulo de projeto ou uma doação, por si só, não comprova todos esses elementos.
• Leia as obrigações específicas desse papel. O artigo 24 exige uma política documentada de cibersegurança que apoie o desenvolvimento seguro e o tratamento de vulnerabilidades, além de cooperação com as autoridades de fiscalização do mercado. O escopo de notificação tem condicionantes: a notificação de vulnerabilidades depende do envolvimento do administrador no desenvolvimento do produto; a notificação de incidentes graves e as obrigações mencionadas de informação aos usuários dizem respeito a incidentes que afetam as redes e os sistemas de informação fornecidos pelo administrador para esse desenvolvimento. Não se trata de uma obrigação irrestrita de notificar cada incidente de todos os usuários que utilizam o software em etapas posteriores. Essas distinções vêm dos artigos 3 e 24.
• Mantenha a fundamentação da classificação disponível para revisão. Como proposta organizacional, registre a entidade responsável, a titularidade dos produtos, os acordos de distribuição, a monetização e a infraestrutura fornecida. Anexe os dispositivos legais usados como fundamento e identifique fatos ainda não esclarecidos para revisão qualificada.

Armadilhas

Uma isenção de multas administrativas não é uma isenção das obrigações do administrador de software de código aberto. A Comissão afirma que esses administradores não estão sujeitos às multas administrativas do CRA. Leia o artigo 64(10) junto com a retificação de 2 de julho de 2025, que corrige o intervalo de parágrafos nessa isenção. Não a estenda a um fabricante apenas porque seu produto usa uma licença de código aberto.

Por fim, o enquadramento de um projeto upstream não define as obrigações de um fabricante que integra seus componentes a outro produto. Avalie os atores e os produtos separadamente, em vez de atribuir um único enquadramento a toda a cadeia de dependências.